IP/Network

  

 

 

 

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.

 

 

General Requirement

 

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.

 

 

Structure of OpenFlow Switch

 

Overall structure of OpenFlow Switch described in the whitepaper ([1]) can be illustrated as shown below.

 

 

 

Flow Table and Entries

 

< OpenFlow Switch Specfication v1.5.0 - Table 1: Main components of a flow entry in a flow table >

 

 

OpenFlow Message Types

 

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

[5]