Controlling network flow with the OpenFlow protocol

Daniel Proch, Netronome

January 30, 2012

Daniel Proch, Netronome

What is OpenFlow?
OpenFlow is an open standard that was originally designed to allow researchers to run experimental protocols in their campus networks. Prior to OpenFlow, there was no practical way for researchers to try new protocols and networking techniques in a real network infrastructure carrying real traffic.

OpenFlow allows network administrators or programmable software to define the paths that flows take through a network, regardless of the underlying network topology and the particular hardware over which the traffic traverses. OpenFlow allows networks to be carved into "slices" where a particular slice is allocated a flow-specific path through the infrastructure and may optionally allocate portions of the network resources across that path.

OpenFlow wrests the distributed, address-based control of packet forwarding out of the switches and routers that traffic goes through, and gives programmatic control of flows to the administrator of the network itself. This per-flow forwarding capability allows data-center and carrier networks to strategically place flows where the required resources exist. The resources that can be exploited might include network path, bandwidth, security policy, and latency, to name only a few of the many possibilities.

While originally designed for network researchers, other interesting applications of the technology have become evident as the standard has progressed. OpenFlow has caught the attention of those building massive data centers and cloud-based virtualized network infrastructure as well as telecommunications carriers.

SDN enables inexpensive feature insertion for new services and new revenues and allows networks to be built with common off the shelf (COTS) hardware to lower equipment expenditures, while giving programmatic control of network infrastructure back to those responsible for building and administrating these networks.

Do flows really matter?
More users and more applications are driving an increase in throughput that networks need to support. This results in more individual "network conversations" or flows per segment. So how does one define a flow? A flow is a unidirectional sequence of packets all sharing a set of common packet header values. Importantly, in OpenFlow, the concept of a flow is not defined in a rudimentary fashion considering only the destination to which the traffic is addressed.

OpenFlow optionally uses numerous packet header fields to define the concept of a flow, as shown in Figure 1. In the OpenFlow standard specification (v 1.1), the following fields may be used in flow definition:

• Ingress interface
• Packet metadata
• Ethernet source address
• Ethernet destination address
• Ethernet type
• VLAN ID
• VLAN priority
• MPLS label
• MPLS traffic class
• IPv4 source address
• IPv4 destination address
• IPv4 protocol/ARP opcode
• IPv4 ToS bits
• TCP/UDP source port/ICMP type
• TCP/UDP destination port/ICMP code


Click on image to enlarge.

The concept of flow processing is not new--it has been a mainstay in many network and security devices for many years. As examples, with stateful firewalls, security processing happens at beginning of the flow and this flow state is used to process the session afterwards.

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.