In this article, we will see a brief overview of the protocol that was the origin of SDNs: OpenFLow.
You can see my article Introduction to SDN if you are not familiar with this concept.
In fact, the first version of OpenFlow (1.0) was developed in 2008 by some researchers of Standfort university. Their goal was to use the network for both production and research.
I don’t like a lot of history! but if you are intersted in history, you can contact me. Time to understand how OpenFlow works. 🙂
OpenFlow is the first standard communications interface defined between the control and forwarding layers of SDN architecture. It allows direct access to and manipulation of the forwarding plane of network devices, both physical and virtual.
The protocol specifies basic attributes that can be used by any external software application to program the forwarding plane of network devices.
The OpenFlow architecture has 3 basic components:
- The OpenFlow controller;
- The OpenFlow device (Switch);
- The OpenFlow Channel.
In the OpenFlow approach, In order to reach better forward performance, devices should be kept simple, so the network control is done by the controller. The OpenFlow controller sets up all OpenFlow devices, maintains topology information and monitors the overall status of entire network.
The OpenFlow Device is any network equipment supporting the OpenFlow protocol, such as a switch. Each device maintains a Flow Table that indicates the processing applied to any packet of a certain flow.
The OpenFlow protocol works as an interface between the controller and the switches setting up the flow table.
The Flow Table is updated by the controller by adding and removing flow entries using the OpenFlow protocol. The Flow Table contains multitude of Flow Entries associated with actions to command the Switch, to apply some actions (Forward, drop or encapsulate) on a certain flow.
In the SDN/OpenFlow network, each OpenFlow device has a flow Table with flow entries as shown in the picture above. The Flow Entry consists of 3 fields:
- Header field: it is used to define the match condition to an exact flow.
- Counters: are used to count the rule occurrence for management purposes.
- Action: define the action to be applied to a specific flow.
When a packet arrives to the OpenFlow switch, it will be match by a Flow Entry in the Flow Table, so the action will be executed if the header field is matched, and the counter is updated. If the packet doesn’t match any flow entry, it will be sent to the controller over the secure channel. Note that the Flow Table has a priority associated to every entry; a higher number means a higher priority. This priority is used to match packets; the Flow Entry that has the higher priority will be used.
This is the end of this article. I hope you understood the main points of OpenFlow protocol. In next articles, I will go more in details.