We thought it would be useful to our networking colleagues to provide an overview of the OpenFlow protocol. Let's begin with a broad definition of what OpenFlow is.
- OpenFlow is a communications protocol that uses network-centric, network-aware intelligence in it's communication design.
- OpenFlow works on Software Defined Network (SDN) controllers placed in the network (either in switches/routers, or stand alone devices) and network nodes that enable programmability, or Software Definition.
- OpenFlow defines a new open network ecosystem that enables control of static networking components and attempts to provide management of mobility by making the network elements more programmable, configurable, and flexible.
The origin of the protocol dates to 2005 when Martin Casado created OpenFlowMartin Casado created OpenFlow, the basis for Software Defined Networking (SDN), with his thesis at Stanford University. That said, the OpenFlow 1.0.0 specification was published on December 31, of 2009. There have been several updates since. You can find the latest OpenFlow specification here.
From a high level functionality point of view, OpenFlow works as follows:
- OpenFlow controllers talk to network nodes and discover network topology, inventory of links and information within network nodes (route tables, addresses, etc.).
- Network Administrators define policies and services within the OpenFlow configuration and programmable policies.
- A packet is received by the network.
- If no prior knowledge associated with the packet, receiving node sends message to OpenFlow controller.
- If the controller determines, based on programmability and policy, the packets should be accepted, it modifies the node tables and configurations such that the packet receives the appropriate service
- This can include multiple nodes, as well as more information including oath configuration, QoS information, and much more.
The network nodes are called generically "switches". This means some sort of packet switching network node:
We see that this communication with the switches is accomplished over a secure connection or SSL.
We also see that switches have a series of tables that maintain the all the rules of how to handle a given packet or set of packets called Flow Tables:
Let's first examine the OpenFlow Match Fields that are required:
Optionally, the Match Fields can be extended to the following list:
Now that we understand what items can be matched on, let's turn to what OpenFlow rules, called Actions, can be applied to a given packet or set of packets, and if there are more than one, accumulated into an Action Set:
These Actions and Action Sets are installed into a "pipeline" within the switch:
Great, now that we have a picture of what is going on, let's zoom in on the OpenFlow Protocol message sets. We begin with the Controller to Switch Messages:
Further there are Asynchronous and Symmetric Messages supported in OpenFlow:
Let's see this in action.
To create the messaging, we have two hosts talking on an network via a switch and an OpenFlow controller.
Below we are pinging host 10.0.0.2 from host 10.0.0.1:
You can see thatthe first packet took 2.59ms, as it had to be sent to the controller. The following packets followed whatever the pipeline was, and occurred very quickly.
So let's look at the OpenFlow messages in Wireshark:
You can see above that the controller issued an OpenFlow "Flow Modification" instruction to the switch! Of course, there is much more going on here, but for overview purposes, we think this inks the concepts discussed above.
We encourage you to play with OpenFlow and suggest that you can experiment with the protocol using Wireshark and mininet. To learn how to do this, go here to our free mininet SDN course (simply log in as a guest).
We hope this helps our friends understand a little more about OpenFlow.