OpenFlow, an instance of the SDN architecture, is a set of specifications maintained by the Open Networking Forum (ONF). At the core of the specifications is a definition of an abstract packet processing machine, called a switch. The switch processes packets using a combination of packet contents and switch configuration state. A protocol is defined for manipulating the switch's configuration state as well as receiving certain switch events. Finally, a controller is an element that speaks the protocol to manage the configuration state of many switches and respond to events.
Protocol DecompositionThe OpenFlow protocol can be broken into four components: message layer, state machine, system interface, and configuration. The image and table below illustrate these components, their interaction, and describe their function at a high level.
|Message Layer||The message layer is the core of the protocol stack. It defines valid structure and semantics for all messages. A typical message layer supports the ability to construct, copy, compare, print, and manipulate messages.|
|State Machine||The state machine defines the core low-level behavior of the protocol. Typically, it is used to describe actions such as: negotiation, capability discover, flow control, delivery, etc.|
|System Interface||The system interface defines how the protocol interacts with the outside world. It typically identifies necessary and optional interfaces along with their intended use, such as TLS and TCP as transport channels.|
|Configuration||Almost all aspects of the protocol have configurations or initial values. Configuration can cover anything from default buffer sizes and reply intervals to X.509 certificates.|
|Data Model||Another way to consider the OpenFlow protocol is to understand its underlying data model. Each switch maintains a relational data model that contains the attributes for each OpenFlow abstraction. These attributes either describe an abstractions capability, its configuration state, or some set of current statistics.|
Switch AnatomyAn OpenFlow switch can be broken into two components: the switch-agent and the data plane. The switch-agent speaks the OpenFlow protocol to one or more controllers. Additionally, it communicates with the data plane using the requisite internal protocol. The switch-agent will translate commands from the controller into the necessary low-level instructions to send to the data plane, and internal data plane notifications to the appropriate OpenFlow messages and forward to the controller. The data plane performs all packet forwarding and manipulation; however, based on its configuration sometimes it will send packets to the switch-agent for further handling.
|OpenFlow Protocol||This is the switch side instance of the OpenFlow protocol.|
|Core Logic||This component manages the switch, executes commands against the data plane as necessary, manages the data plane offload, etc.|
|Data Plane Offload||Often the control plane will offload some functionality present in OpenFlow but not provided by the existing data plane implementation.|
|Data Plane Protocol||This is an internal protocol used to configue the data plane state.|
Data PlaneThe data plane of a switch is composed of only a few things: ports, flow tables, flows, classifiers, and actions. Packets arrive and leave the system on ports. Packets are matched to flows in flow tables using classifiers. Flows contain sets of actions which are applied to each packet that it matches.
|Ports||Packets arrive and leave a switch on a port. Different versions of the protocol support different types of ports, properties, and configurations.|
A classifier matches a packet to a flow entry in a flow table.
|Instructions & Actions||
Instructions and actions govern how a packet is processed once it matches a flow entry in a flow table.
Data Plane - Packet LifecycleEach packet experiences the same behavior as it traveses the switch data plane. When a packet arrives a key is built that contains both information from the packet, such as the values of certain protocol fields, as well as metadata collected about the packet, such as arrival port, arrival time, etc. The key is used to select a particular flow in a flow table and its associated actions are applied to the packet. An action set can drop, mutate, queue, forward, or direct that packet to a new flow table.
|1.||Packet Arrival||Packets arrive on ports, these can be physical or virtual. It is important to remember information about arrival ports for source-based processing later in the pipeline.|
|2.||Key Extraction||Each packet has a small portion of meta data built, called the key, after arrival. The key includes several fields from within the packet as well as side information suck as: location of the buffered packet, header values, arrival port, arrival clock, etc. The key is what is fed to the rest of the pipeline.|
|The key is used to search a table; however, multiple tables may be present. In this case a table must first be selected. When a packet goes thorugh the pipeline for the first time the first table is selected by default; subsequent tables may be selected through actions or table misses.|
|4.||Flow Selection||The key is used to select a particular flow in a table. The first flow of a table where the classifier subsumes the key becomes the selected flow.|
|5.||Action Application||Each row contains a set of actions to apply to all subsumed packets. When a flow is selected its actions are applied to the corresponding packet. Actions may modify the packets state and/or affect treatment of the packet.|