Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
EE Times-Asia > Networks

Using OpenFlow protocol to control network flow

Posted: 17 Feb 2012 ?? ?Print Version ?Bookmark and Share

Keywords:software-defined networking? OpenFlow? Open Networking Foundation?

Security applications like intrusion detection and prevention (IDS/IPS) rely on flow state because attacks may be spread across packets, TCP payloads, or even fragmented IP packets. In particular, the open-source IDS/IPS application Snort uses the Stream5 preprocessor to reassemble TCP flows to run signature-based rules against the whole TCP payload.

Antivirus applications take this a step further and actually terminate flows at the TCP layer, parse the application protocol (such as HTTP, SMTP, and peer to peer) potentially even reassembling file attachments and scanning these for threats. Next generation firewalls are taking the concept even further by combining user and application identification and flow-based security processing with data plane L2 switching, L3 routing, network address and port translation, and VPN termination. These applications are impossible without stateful flow-based processing but differ from OpenFlow in a fundamental fashion in that they don't use flow-based processing for forwarding but rather for higher-layer processing.

Figure 2: Separation of OpenFlow switch and controller.

OpenFlow operation
OpenFlow is based on a switching device with an internal flow-table and a standardized interface to add and remove flow entries. Openflow provides an open, programmable, virtualized switching platform where the underlying switching hardware is controlled via software that runs in an external, decoupled control plane.

As previously described, traditional switches and routers combine packet forwarding and control-plane functionality into a single device. These devices work in a distributed manner with other switches and routers to determine topology and packet forwarding through a network.

OpenFlow switches upset this architecture by separating these two functions such that data-plane flow forwarding still resides on the switch, but flow-forwarding decisions are determined in a separate, out-of-band OpenFlow controller or hierarchy of controllers, typically implemented in a standard x86 server(s) that have a communications path to all OpenFlow switches in the network to install the per-flow forwarding policies.

This architecture puts the network intelligence into the controller(s) where flow forwarding is centrally defined; this intelligence is downloaded to the flow tables in the switching infrastructure (figure 2). The OpenFlow switches and controllers communicate via the OpenFlow protocol that defines messages, such as packet-received, send-packet-out, modify-forwarding-table, and get-stats.

The data path of an OpenFlow enabled switch abstracts the switching plane as a flow table where each flow table entry contains a configured set of the defined 15 packet fields (or implied fields) to match traffic against and determine how to treat the flow in the form of an action.

There are numerous actions possible, but some examples are: to send the packet to a particular destination interface; rewrite the packet header fields in some fashion; or to drop the traffic. When an OpenFlow Switch receives a packet that doesn't contain a flow entry in the cached flow table, it sends this packet to the OpenFlow controller that is responsible for making a decision on how to handle this packet. It can drop the packet, or alternatively it can send instructions in the form of a flow entry back to the switch that populates the flow-table cache and directs the switch as to how to forward all subsequent packets in the flow.

OpenFlow hybrid architecture
One of the major changes between the OpenFlow 1.0 specification and the 1.1 revision is the notion of nested or recursive flow forwarding. Switches can have one or more flow tables and a group table where, when a packet arrives, the switch first finds the highest-priority matching flow entry and applies instructions or actions based on the flow fields. Figure 3 illustrates the concept.

Figure 3: OpenFlow processing pipeline. (Click on image to enlarge)

The action from this first lookup may be to send the matched data and action set to next table in the switch for subsequent processing. Flow entries may also direct the switch to forward traffic to a port (physical, virtual, internal) or to a group table for packet flooding, multipath forwarding, fast reroute, or link-aggregation use cases. Unknown flows may be forwarded to the OpenFlow controller, dropped, or sent to the next table for processing.

While the promise that OpenFlow offers is disruptive and revolutionary, traditional Ethernet switched and IP routed networks will not disappear overnight. In support of the promise of OpenFlow, properly implementing the technology in light of existing techniques needs to be considered.

OpenFlow switches are often implemented in traditional L2/L3 switching and routing hardware, and there is a need to support both OpenFlow operation and traditional switching simultaneously to ensure a smooth transition to flow forwarding. In addition, one can consider that not all traffic in a network needs to be controlled in network slices.

?First Page?Previous Page 1???2???3???4?Next Page?Last Page

Article Comments - Using OpenFlow protocol to control n...
*? You can enter [0] more charecters.
*Verify code:


Visit Asia Webinars to learn about the latest in technology and get practical design tips.

Back to Top