% !TEX encoding = IsoLatin

OpenFlow switches were born to perform fast, context-based forwarding. The forwarding decision is taken based on the flows loaded into the device. This flows consist of \textit{match-fields} used to match incoming packets, this fields can be headers, ingress port or metadata.
For each flow is present a set of \textit{actions} that must be applied on each matching packets, these action can modify packet fields, drop the packet or simply forward it to another port.

Flows are grouped in tables, these tables are ordered by the \textit{table-id} parameter. When a packet is received it exploring the tables until a matching flow is found and the corresponding action is taken. If no flows are found the default action is taken. This process is highly optimized with hash based data structures and the EMC already mentioned.

We decided to use these flows as filtering rules using only two actions.
\begin{itemize}
	\item \code{DROP}: to drop the matching packet.
	
	\item \code{NORMAL}: to let the standard network stack processing the packet.
\end{itemize}

Flows can be injected from an OpenFlow controller directly into the virtual switch, the injection process is done with a \textit{flowmod} message that contains the flow parameters that need to be injected.

Managing flows injection it is possible to realize a stateless packet filetring directly inside the virtual switch, gaining in performance due to the efficiency of this devices.

In our project we divided OpenFlow flow injection in three main phases:
\begin{itemize}
	\item \textit{Controller initialization}: in this phase the controller is initialized, all the parameters are configured. At the end of this phase the controller will be running, with all the virtual switches connected to it and ready to receive new flows.
	
	\item \textit{Rule conversion}: in this phase the security policy rules are converted into OpenFlow compatible messages. A single rule can be represented with multiple flows.
	
	\item \textit{Flow injection}: in this phase all the generated messages are sent to the virtual switch. The controller sends message via TCP connection initialized in the startup phase.
\end{itemize}

\subsubsection{Requirements}

To work properly it is necessary that all virtual switches in the deployment has configured, as controller, the host that will run the distribution tool. This can be easily done specifying the IP address and the port of the TCP connection on which the controller is going to listen for new connections.