OpenFlow protocol primer: Looking under the hood
OpenFlow, a switching technology that began in 2008 as a Stanford University research project, is now gathering a lot of interest from network device vendors and managers of large switched networks. With the OpenFlow protocol, a form of software-defined networking, a network can be managed as a whole rather than as a number of individual devices.
Traditional switches use Spanning Tree or newer standards such as Transparent Interconnection of Lots of Links (TRILL) to determine how to forward packets. OpenFlow moves the forwarding decision from individual switches to a controller, typically a server or workstation.
A management application executing on the controller interfaces to all of the switches in the network, making it possible to configure forwarding paths that utilize all available bandwidth. By interfacing to cloud management software, the application can guarantee that bandwidth is in place as workloads are created or moved.
OpenFlow protocol operations
The OpenFlow specification defines a protocol between the controller and the switches and a set of operations on the switches. The controller-to-switch protocol runs over either Transport Layer Security (TLS) or an unprotected TCP connection. Commands from the controller to the switch specify how packets are to be forwarded and configures parameters such as VLAN priorities. Messages from switches inform the controller when links go down or when a packet arrives with no specified forwarding instructions.
MORE ON OPENFLOW AND SOFTWARE-DEFINED NETWORKING
Private cloud VLAN problems: Is OpenFlow the answer?
The application tier is the meat of a software-defined network architecture
OpenFlow applications work where network management fails
Forwarding instructions are based on a flow, which consists of all packets sharing a common set of characteristics. A large variety of parameters can be specified to define a flow. Possible criteria include the switch port where the packet arrived, the source Ethernet port, source IP port, VLAN tag, destination Ethernet or IP port, and a number of other packet characteristics. The controller specifies to the switch the set of parameters that define each flow and how packets that match the flow should be processed.
Each switch maintains a number of flow tables, with each table containing a list of flow entries. Each flow entry contains a match field that defines the flow, a counter and a set of instructions. Entries in the match field contain either a specific value against which the corresponding parameter in the incoming packet is compared or a value indicating that the entry is not included in this flow’s parameter set.
Flow tables are numbered beginning with table zero, with incoming packets first compared to flow table entries in table zero. When a match is found, the flow counter is incremented and the specified set of instructions is carried out.
A new flow must be created when a packet arrives that does not match any flow table entry. The switch may have been configured to simply drop packets for which no flow has been defined, but in most cases, the packet will be sent to the controller. The controller then defines a new flow for that packet and creates one or more flow table entries. It then sends the entry or entries to the switch to be added to flow tables. Finally, the packet is sent back to the switch to be processed as determined by the newly created flow entries.
Flow table instructions modify the action set associated with each packet. Packets begin processing with an empty action set. Actions can specify that the packet be forwarded through a specified port or modify packet TTL, VLAN, MPLS tags or packet QOS.
Instructions in the first flow table may carry out an action on the packet or add actions to be carried out later. Instructions may also direct packet processing to continue by comparing it to entries in another flow table. A flow entry in a subsequent table may contain instructions that add further actions, delete or modify actions added earlier or carry out actions.
An instruction may also add a value called metadata to a packet before sending it to the next flow table. That value becomes an additional parameter to be matched against the metadata value in flow table entries in the next table. Processing continues table by table until all specified instructions have been completed and the packet has been forwarded.
More SearchNetworking primers
A DevOps primer for network engineers
vSphere vSwitch primer: Design considerations
NVGRE standard primer: More VLANs and isolated tenants in the cloud
VXLAN standard primer: Extended VLANs for long distance VM migration
An instruction may specify a group identifier. Groups provide an efficient way to direct that the same set of actions must be carried out on multiple flows. Group operations are defined within the switch by entries in the group table. Each entry consists of its identifier value, a group type, a counter and a set of action buckets. Group type specifies whether all action buckets should be executed, which is useful for implementing broadcast or multicast, or that only specific buckets are to be executed.
OpenFlow protocol messaging
The protocol consists of three types of messages: controller-to-switch, asynchronous and symmetric.
Controller-to-switch messages are sent by the controller to:
- Specify, modify or delete flow definitions
- Request information on switch capabilities
- Retrieve information like counters from the switch
- Send a packet back to a switch for processing after a new flow is created
Asynchronous messages are sent by the switch to:
- Send the controller a packet that does not match an existing flow
- Inform the controller that a flow has been removed because its time to live parameter or inactivity timer has expired
- Inform the controller of a change in port status or that an error as occurred on the switch
Symmetric messages can be sent by both the switch or the controller and are used for:
- Hello messages exchanged between controller and switch on startup
- Echo messages used to determine the latency of the controller-to-switch connection and to verify that the controller-to-switch connection is still operative
- Experimenter messages to provide a path for future extensions to OpenFlow technology
OpenFlow protocol development: A promising future
The Open Networking Foundation was founded in 2011 to develop and standardize OpenFlow. Members include Cisco, Facebook, Google, HP, IBM and Juniper Networks.
The current OpenFlow specification, Version 1.1.0, contains a large number of optional features to enable further experimentation, and work is underway on Version 1.2 of the specification.
While Cisco has not announced an OpenFlow-friendly switch, other switch vendors, such as the IBM and NEC partnership, as well as HP, have implemented OpenFlow in existing products and made these units available for continued development. As vendors and network operators gain further experience with the technology, OpenFlow promises to produce a profound change in the way that networks are managed and operated.
David B. Jacobs of The Jacobs Group has more than twenty years of networking industry experience. He has managed leading-edge software development projects and consulted to Fortune 500 companies as well as software start-ups.