SDN - OpenFlow
OpenFlow is a technology designed in University / Universities in order to test new ideas on networking algorithms or architecture. Of course, they can test their ideas on a small test environment (e.g, a couple of connected PCs or a single PC with multiple NICs) or using several specifially designed Hardwares (switches and routers). But Scaling would be one of the most important factors in any new networking technologies. You can never guarantee that a new idea proved working well with a small network with a small traffic works the same way in a real life networking environment.
Is there any way to let the researchers verify their idea in real networking environement with real traffic in a campus ? This was the main motivation that created OpenFlow. Now with introduction of SDN (Software Defined Networking) and its possible adoption in 5G networking, OpenFlow start getting strong attention and becomes one of the strongest candiate for the standard SDN component.
Due to the situations described above, the researchers want to have network components that can provide following features as described in [1].
- Amenable to high-performance and low-cost implementation
- Capable of supporting a broad range of research
- Assured to isolate experimental traffic from production frame
- Consistent with vendors' need for closed platforms
Technical Background for OpenFlow Switch
Putting forward requirements are easy, but letting the industry to realize the requirement is not easy. Especially it would be extremely difficult for Academia to change the moviding directions of industry players with big name. As a reconciliation, researchers tried to come up with a solution based on following observation (This is directly quoted from Ref [1]. I am blindly quoting this from the reference to let you get the first-hand feeling from the researchers).
The basic idea is simple: we exploit the fact that most modern Ethernet switches and routers contain flow-tables (typically built from TCAMs) that run at line-rate to implement firewalls, NAT, QoS, and to collect statistics. While each vendor’s flow-table is different, we’ve identified an interesting common set of functions that run in many switches and routers. OpenFlow exploits this common set of functions.
OpenFlow provides an open protocol to program the flow-table in different switches and routers. A network administrator can partition traffic into production and research flows. Researchers can control their own flows - by choosing the routes their packets follow and the processing they receive. In this way, researchers can try new routing protocols, security models, addressing schemes, and even alternatives to IP. On the same network, the production traffic is isolated and processed in the same way as today.
Overall structure of OpenFlow Switch described in the whitepaper ([1]) can be illustrated as shown below.
< OpenFlow Switch Specfication v1.5.0 - Table 1: Main components of a flow entry in a flow table >
There are three types of OpenFlow message types as listed below :
- controller-to-switch message
- asynchronous message
- symmetric message
Controller-to-Switch message : As it implies, this is the type of message sent from Controller to Switch. The functionality of the messages is to manage or inspect the status of the switch.
|
Message |
Description |
|
|
Features |
Function |
request the identity and the basic capabilities of a switch |
| Response |
reply with the identity and basic capabilities of the switch |
|
|
Configuration |
Function |
set and query con guration parameters in the switch |
| Response | ||
|
Modify-State |
Function |
add, delete and modify ow/group entries in the OpenFlow tables and set switch port properties. |
| Response | ||
|
Read-State |
Function |
collect various information from the switch, such as current con guration, statistics and capabilities. |
| Response | ||
|
Packet-out |
Function |
send packets out of a speci ed port on the switch, and to forward packets received via Packet-in messages. |
| Response | ||
|
Barrier |
Function |
ensure message dependencies have been met or to receive notifications for completed operations |
| Response | ||
|
Role-Request |
Function |
set the role of its OpenFlow channel, or query that role. This is mostly useful when the switch connects to multiple controllers |
| Response | ||
|
Asynchronous- Configuration |
Function |
set an additional lter on the asynchronous messages or query the filter |
| Response | ||
Asynchronous message : This is the type of message sent from Switch to Controller. The functionality of the message is to update the Controller of network event and changes to the switch status.
|
Message |
Description |
|
|
Packet-in |
Function |
Transfer the control of a packet to the controller |
| Response |
|
|
|
Flow-Removed |
Function |
Inform the controller about the removal of a ow entry from a flow table |
| Response | ||
|
Port-status |
Function |
Inform the controller of a change on a port |
| Response | ||
Symmetric message : This is bidirectional message. It can be either from Switch to Controller or Controller to Switch.
|
Message |
Description |
|
|
Hello |
Function |
this messages are exchanged between the switch and controller upon connection startup |
| Response |
|
|
|
Echo |
Function |
verify the liveness of a controller-switch connection and measure its latency or bandwidth. |
| Response | ||
|
Error |
Function |
notify the other side of the connection of problems. |
| Response | ||
|
Experimenter |
Function |
provide a standard way for OpenFlow switches to o er additional functionality within the OpenFlow message type space |
| Response | ||
Reference
[1] OpenFlow: Enabling Innovation in Campus Networks
[2] OpenFlow Switch Specification - Version 1.5.0 ( Protocol version 0x06 ), December 19, 2014
[3] OpenFlow Switch Specification - Version 1.4.0 (Wire Protocol 0x05), October 14, 2013
[4] OpenFlow Switch Specification - Version 1.0.0 (Wire Protocol 0x01),December 31, 2009