With the recent advances in virtualization and abstracted computing, software-defined networking (SDN) has become a reality. Although decoupling the network control out of physical network devices into a central or clustered service has been the primary focus of SDN, the discussion around Openflow and SDN being the same is a bit of a misnomer. Before I talk about Openflow concepts and deployments strategies, let’s break down a bit of what Openflow is, the difference between SDN and Openflow, and it’s messaging scheme.
SDN != Openflow
In SDN, the network intelligence that is normally located within each network device is logically centralized in software-based controllers. This in turn makes physical (or virtual) network devices simple packet forwarding machines that can be programmed via an open interface. One of the most widely known open interface implementations is Openflow. By separating the control logic functionality from forwarding hardware, you create an environment that allows for easier: deployment of applications, network visualization, and management. So if it’s that simple, then how does it work?
Below is a brief diagram on the flow process within Openflow:
When a packet arrives at the Openflow switch, the packet header fields are extracted and matched against current flow table entries (similar to a CAM table). If a matching entry is found, the switch applies the appropriate set of instructions associated with the matching flow entry and updates it’s respective entry counters. If the flow table procedure fails to produce a match, then the flow must follow the instructions from the table-miss entry. The table-miss entry is a required entry that specifies a set of instructions to be performed when no match is found for an incoming packet. Actions can include:
- Dropping the packet
- Sending the packet out on all interfaces
- Forwarding the packet to the Openflow controller
First and foremost, communication between a software controller and Openflow switch (physical or virtual) occurs via a secure channel (TLS-enabled) on TCP port 6633 (soon to be TCP 6653). The switch and controller mutually authenticate each other by exchanging certificates via site-specific private key. Traffic to and from this secure channel is not checked against the switch’s flow table and therefore must be identified as local (to the switch). In the case of a loss of communication with the Openflow controller, the switch will attempt to contact a backup controller if configured. If not able to reach a backup controller, the switch will enter *emergency mode. *Emergency mode contains flow table entries that have been marked with the emergency bit set. These are considered as ‘always needed’ flows for operational communication. Openflow messaging is broken into 3 message types:
Controller-to-switch messages are always initiated by the Openflow controller. They are used to directly manage or audit the state of the switch.
Upon establishing a secure connection to the switch, the Openflow controller sends a feature request message to the switch. The switch must reply with a feature reply message which included the capabilities that are supported by the switch.
The Openflow controller is able to set and query configuration parameters in the switch. The switch will only respond to configuration queries sourced from the Openflow controller.
These messages are sent by the Openflow controller to manage the state of the Openflow switch. They are used to add/delete/modify flow table entries and to set port priorities. Flow table modification messages can have the following types:
- MODIFY and DELETE (for strict matching)
These messages are used for statistical collection (flow table entries, counters, etc).
These messages are used by the Openflow controller to send packets out of a specified port on the switch (static flows).
Barrier messages are used by the Openflow controller to receive notification for completed operations.
Symmetric messages are sent either by the Openflow controller or the switch. The three, unsolicited message types are:
Hello messages are sent symmetrically upon connection setup
Similar to ICMP or heartbeat connections, these messages can also be used to indicate latency/bandwidth issues.
These messages provide a way of offering additional vendor functionality within future revisions on Openflow.
Asynchronous messages are always initiated by the switch and are used to inform the Openflow controller of changes to the switch state. Switches will send asynchronous messages to the Openflow controller to indicate packet arrival, switch state change, or errors. The four asynchronous message types are:
This message is used for inbound packet entries that do not have a matching flow entry or for packets that match an entry with a send to controller action.
When flows are added to the switch via the Openflow controller, an idle timeout value indicates when the flow entry should be removed due to lack of activity as well as a hard timeout value. A hard timeout value of zero means the flow will never expire, regardless of activity. The flow-removal message is sent to the controller when a flow expires.
The switch will send port-status messages at system-defined intervals as port states change. Events included are user-defined changes (port disabled by user), virtual server disconnection (port disabled by system), and port status modifications due to spanning tree (802.1d).
As SDN grows, it’s important to understand that Openflow is an SDN concept and they are not the same. Although there are many similarities within Openflow packet flows and traditional L2/L3 packet flows, the control channel is still unique. And finally, understanding the messaging is key in modifying existing open source solutions and building new custom Openflow-enabled applications. Further breakdown of Openflow messaging can be found below: