At its core, the OpenFlow protocol specifies how the switch and the controller should communicate with each other. When the switch initially boots up, it registers itself with the controller. In most cases, the controller IP is specified to the switch either during the bootup process or configured on the switch out of band via management. The switch will then initiate the channel to communicate with the controller:

Following the bootup, the switch will communicate with the controller via several types of messages; the main messages are as follows:

• Symmetric: Symmetric messages are initiated by either the switch or controller. Typical symmetric messages are hello messages, echo request/reply messages, and other experimental messages for future features.
• Controller-to-switch: Controller-to-switch messages are initiated by the controller to manage the switch or query the switch for its state. They include feature and configuration queries from controller to switch, statistics collection, and barrier messages for operation-completion notifications. Also, the controller can initiate modify-state messages to change flows and groups on the switch as well as packet-out in response to switch PacketIn messaged to forward a packet out of a switch port.
• Asynchronous: The switches send the controller asynchronous messages for packet arrival, state change, or error. When the packet arrives and the switch does not have an existing matching flow entry, the event will be sent to the controller for action as a PacketIn message. The controller will respond with a packet-out message. The switch will also send any error and port-status change as well as flow removal as asynchronous messages to the controller.

Obviously, there is no need to memorize the different messages: the common messages will become natural to you the more you use and see them. The more obscure messages can always been looked up when needed. What is important is the fact that the switch and the controller are both in constant communication, and they need to synchronize to a certain degree in order for the network to function properly.

The point of the channel establishment and all the messages exchanged is to allow the network device to take proper forwarding action based on what it knows about the packet. We will look at the available matching fields in a bit, but the forwarding decisions are generally done by matching with the flow entries. Many flow entries can exist in a flow table, and each OpenFlow switch contains multiple flow tables at different priorities. When a packet arrives at the device, it is matched against the highest-priority flow table and the flow entries in the table. When a match is found, an action such as forwarding out an interface or going to another table is executed. If there is no match, for example a table miss, you can configure the action to be as follows:

• Drop the packet
• Pass the packet to another table
• Send the packet to the controller via a PacketIn message and wait for further instructions

As you can see, the OpenFlow operation is relatively simple and straightforward. Besides the separation of control and data planes, the uniqueness of OpenFlow is that it allows packets to be granularly matched, thus enabling a finer control over your packet flow.

As of OpenFlow 1.3, the following set of match fields are specified:

From the preceding chart, many of the fields OpenFlow can match against are no different than than the existing layer 2 to 4 headers. So what is the big deal? If we look back at traditional network devices, a switch that is examining VLAN information might not be looking at IP headers, a router making forwarding decisions based on IP headers is not digging into TCP ports, and an MPLS-capable device might only be dealing with label headers. OpenFlow allows network devices to be controlled by a software controller that looks at all of the available information; thus, it can make a so-called white box to be any network function as it desires. It also allows the software controller to have a total view of the network instead of each device making forwarding decisions to the best of its knowledge. This makes OpenFlow or other software controllers that provide the same function very desirable for network operators.