OpenFlow - Counters

OpenFlow maintains multiple counters, some required and some optional, for each:

• Flow Table
• Flow Entry
• Port
• Queue
• Group
• Group Bucket
• Meter
• Meter Band

The following table lists the counters used for each of these entities. The counters wrap when they exceed the maximum bits, and there is no overflow indicator.

 

Instructions and Actions

When a match is found, things start happening. There are six concepts: Instruction, Instruction Sets, Actions, Action Lists, Action Sets, and Action Buckets.

As you can see the following table, this set of one or more Instructions in a flow entry is Instruction Set. An individual Instruction in the Instruction Set might or might not have a list of action - an Action List - associated with it.

An Action Set is passed between flow tables during flow processing. An Action list is associated with an Instruction with a flow entry of a single flow table.

Instructions 

There are six types of instructions as could see the following table. Some Instruction types have actions associated with them, and others do not, but all instructions cause a change of some type - to a packet, an action set, or to pipeline processing. 

If a switch cannot execute an instruction in a flow entry given to it by a controller, it rejects the flow entry and sends an error message to the controller.

Instruction Sets

An Instruction Set comprises the "Instructions" field in a flow entry, and consists of one or more individual Instructions. An individual Instruction Set can only contain one Instruction of each type. For example, an instruction set can contain an Apply-Actions instruction, a Write-Actions instruction, and a Goto-Table instruction, but cannot contain two difference goto-table instructions. And since there are only six Instruction types, an Instruction Set can never contain more that six Instructions. Although a given Instruction Set might not contain Instruction of all six types, Instructions in the set are executed in the following order:

1. Meter
2. Apply-Actions
3. Clear-Actions
4. Write-Actions
5. Write-Metadata
6. Goto-Table

Action Lists

Action List includes three actions:

• Apply-Action Instruction immediately executes the actions in the Action List. The actions are executed consecutively, in the order they appear on the list, so the order of the actions can matter.
• Write-Action instruction writes the actions on the Action List to the Action Set, used to pipeline processing. 
• The controller uses the packet out message to send a packet into the switch dataflow. 

Action

The following table lists the action types in current use and indicates whether they are required or optional.

 

Action Sets

As previously explained, an Action set is used in pipeline processing. 

Action buckets 

Where an Action set contains one or more actions, ac Action Bucket contains one or more Action Sets.

OpenFlow - Flow Processing

The closest comparison to a flow table might be access list or rout map. It is a list of one or more entries, and each entry has a match condition, action to take on any packets that match, and possibly an accounting function to count how many matches have occurred.

OpenFlow match structures are built using a Type/Length/Value (TLV) format, which makes changing or expanding match parameters between versions much easier.

OpenFlow match conditions fall into one of three categories:

• Flow Match
• Header Match
• Pipeline Match 
• Experimenter Flow Match

Flow Match

A flow is usually identified by a combination of parameters such as incoming port, L2 and L3 source and destination address, Class of Service bits, and upper layer ports.

Header Match

In addition to flows, a flow entry can match specific packets based on the contents of its Layer 2, 3, and 4 header. Header Match fields is almost the same list as Flow Match. But, the difference is packet-independent parameters such as ingress port, metedata, or tunnel IDs

Pipeline Match

Pipeline match fields are the information attached to a packet, other than the packet header, for pipline processing.

Experimenter Flow Match

Experimenter Flow Match is an optional category that, as you might guess, support experimentation. 

The OpenFlow Protocol - OpenFlow Messages

OpenFlow messages exchanged between the switch and the controller over the secure channel. All OpenFlow messages are encapsulated with an a OpenFlow header. Transaction ID is similar to a sequence number.

All OpenFlow messages are encapsulated with an OpenFlow header, as shown in the following table. 

Message Category are used to perform several OpenFlow operations as the following the table.

OpenFlow - Redundancy

Redundancy is essential to any reliable networks design. A realistic OpenFlow design connects each switch to multiple controllers, as you could see the following picture.

How the multiple controllers synchronize is not important to OpenFlow. But a switch connecting to multiple controllers must be able to categorize the relationships of the controllers to each other from the switch's perspective. A controller can play one of three roles:

• Equal is the default role. The switch exchanges the same messages with each controller, and does not distinguish between them, and does not load-balance among the controllers or arbitrate between the controllers. The switch relies on the controllers to coordinate the instructions they send to the switch 
• Master is same as Equal in terms of the relationship between the switch and controller, but the difference is that only a single controller can be Master. If there is a Master, all other controllers must be in a Slave role. 
• Slave is the role of all switches except the Master, when controllers are set up in a Master/Slave configuration. A Slave controller cannot send any Controller-to-Switch messages that would cause a change to the switch; it can only send messages of this type that query information from the switch or that inform the switch of its role. Similarly, a slave controller cannot receive any Asynchronous messages except port status messages. 

Each controller is responsible for sending a Controller-to-Switch message called Role Request to tell the switch what its role is. Although OpenFlow does not specify the Master/Slave election mechanism between controllers, it does specify a 64 bit number, call Generation-Id, in the role request message that allows switch to keep track of the most recent Role Request messages during a role change.

Auxiliary Connections 

When there are multiple connections, one connection is the main and the others are auxiliary connections. The main connection must be established first, and then the auxiliary connections are established. 

Two identifiers are used with auxiliary connections:

• Datapath ID identifies all the connections between the same switch and the same controller. That is, the main and the auxiliaries all use the same Datapath ID 
• Auxiliary ID differentiates the main connection from an auxiliary connection. The Auxiliary Id of an auxiliary link is some non-zero number

OpenFlow - Meter Table

A meter table allows OpenFlow to create a simple Quality of Service mechanism that measures the rate of a flow and then imposes a specified rate limit. Each entry on the meter represent a meter.

The fields within the meter entry are as follows:

• Meter Identifier is a 32-bit unsigned integer identifying meter
• Meter Bands is an unordered list of meter bands, each of which specifies a rate and an instruction for processing a packet. 
• Counters are incremented whenever a meter process a packet

A meter band consists of the following fields:

• Band Type, how a packet is to be processed.
• Rate, the lowest rate at which the meter band can apply
• Burst, defines the granularity of the meter band
• Counter, are incremented when a packet is processed by the band
• Type Specific Arguments, are used with some band types to define additional instructions

OpenFlow - Group Table

A group table consists of a set of entries which represents some group of packets that should be treated in the same way. A group is a means of applying a common set of output actions to aggregate flows; this is, by designating a packet as a member of a group, actions can be efficiently applied or change across multiple flow.

Each group entry consists of :

• A 32-bit group identifier 
• A group type, which is one of
• All: This used for multicast and broadcast
• Select: Using a selection algorithm such as round-robin or hash based on user definitinos, the packet is sent to only only the group action sets
• Indirect: Execute a single action set for all packets sent to the group
• Fast Failover: This group type allows forwarding to be quickly move from a failed port to a live port without consulting the controller.  
• A couter, record statistics of matching packets 
• Action buckets, which each contain a set of actions to be executed. 

OpenFlow - Pipeline

A switch with a single flow table is specified in Specification 1.0.0. But the problem with this single-table implementation is that it does not scale. To remedy the limitations of a single-table switch, 1.1.0 introduced multiple tables and a mechanism, call pipeline processing which allow the user to create a hierarchy of processing using a sort of "if then goto" logic. As you could show the following picture.

The OpenFlow pipeline is a series of flow tables, number sequentially starting with 0. All incoming packets to the switch must be processed through table 0, and then may be forwarded to some numerically higher table along with metadata that can be matched at the next table.

The following picture illustrates how pipeline processing works. When a packet arrives on some port, the ingress port is recorded and the packet is sent to flow table 0. Ac Action Set is associated with the flow, which is initially an empty set. If a matching flow entry is found, the associated instructions in that entry are either executed or add to the Action set.


The process is repeated at each table, and after the last table in the pipeline has processed the packet, the instructions in the Action Set are executed sequentially.

A table-miss occurs if a packet does not match any flow entry at a given table. If a Table-miss entry is not included in the table, the default action when no match is found in the table is to drop the packet.

The single pipeline process illustrated in the last Figure is linear. But the follwoing picture shows how different match conditions can point to different tables, creating a complex series of processing actions.

OpenFlow component - Flow Table

The flow table consists of a set of entries, as shown in the following picture.

• A Match Field, specifying the conditions under which a packet is matched. This can be a combination of incoming port, Ethernet and IPv4 header files, high-layer ports, or metadata
• A Priority Field, set the precedence of the flow entry
• A Counter Field, record statistics of matching packets
• A Instruction Field, specify actions to be performed on matching packet, this field is called Actions
• A Timeouts Field, specify the maximum amount of time or idle time before the entry is expired by the switch
• A Cookie Field, used by the controller to filter flow entries. 
• A Flags Field, alter the way flows are managed. 

It is important to note that the flow table in the switch is not the same thing as the Forwarding Information Base (FIB). A FIB is a simple set of forwarding instructions mapping, at minimum, a destination address to an outgoing port. It supports destination-based switching. An OpenFlow flow table is a sequential set of instructions matching multiple fields, and taking some action based on that match - it supports flow-based switching. 

OpenFlow switch can be either OpenFlow-only or hybrid. A hybrid switch can run under both an SDN controller and the switch vendor's proprietary control plane.

OpenFlow component - Channel

Precedent to the connection startup, the switch must be configured with the controller's IP address. Optionally the controller could be configured with the switch's IP address, but the goal is the same: The two devices must be able to find each other.

Channel Connections 

The OpenFlow connection operates over TCP, and both the switch and the controller listen on port 6653 and this connection is usually encrypted over Transport Layer Security (TLS) Protocol. 

After TCP session is established and certificates are exchanged by TLS, the controller and switch exchange Hello messages to negotiate the OpenFlow version to use. After agreement the version, the connection is up and two sides use Echo messages to monitor the connection. 

Connection Interruption

If one side cannot support the version advertised by the other side, it sends an error message and the connection is closed, such as, echo replies are not received, the switch will enter one of two stats depending on implementation: 

• Fail secure mode: The switch continues to operate, but does not try to send messages or packets to the controller. Entries in the flow tables continue to time out as they normally would. 
• Fail standalone mode: The switch reverts to operating as a standalone (non-OpenFlow) switch. This mode is usually only used by hybrid switch.

Connection Reestablishment 

When a switch reestablishes a session with the controller after a connection interruption, the existing entries in the flow table continue to be used. 

Message Delivery 

Once the channel is established, Controller and switch could exchange OpenFlow messages:

• Controller to Switch, messages are used by the controller to manage the switch 
• Asynchronous messages are send from the switch to the controller. To notify a change in flow stat or port status, or an error message.
• Symmetric messages can be sent by either the controller or the switch. These messages are hello, echo requests, and replies, and such on 

OpenFlow component - Port

OpenFlow defines three types of standard ports, and an OpenFlow switch must support all three:

• Physical ports
• Logical ports
• Reserved ports

Physical Ports

Physical ports correspond directly to the hardware interfaces on a switch. When a physical switch supports multiple OpenFlow logical switches, the hardware interfaces might be shared among several or all of the logical switches. In this case, the openflow physical port on a logical switch is virtual slice of the corresponding physical interface. This virtual slice is like a VLAN, or sub-interface.

A single physical interface can support multiple virtual physical ports.

Logical Ports

Logical ports do not correspond directly to hardware interfaces. This kind of interfaces you encounter on any kind of L2 or L3 switch, such as tunnel interfaces, loopback interfaces, null interfaces, MPLS LSPs, and link aggregation groups.  From the perspective of the OpenFlow process, a logical port is usually treated the same as a physical port. 

Reserved Ports  

Reserved ports are ports used for internal packet processing, for special functions such as flooding. 

OpenFlow Overview

OpenFlow defines an interface between and SDN controller and a switch. Within the larger context of SDN, it is the "southbound" interface of the controller.

OpenFlow is not alone in that role. There are alternative messaging protocols and alternative means of communication between the controller and the switch. 

The following picture shows a diagram of the basic OpenFlow components.They are 

• OpenFlow Controller
• OpenFlow Logical Switch, which contains
• Ports
• Secure channel
• Flow Table containing a set of flow instructions - flow entries - that tell the switch how to handle a given packet

Controller 

The controller is responsible for communicating instructions to the switch across the secure channel, but the OpenFlow protocol has no say in how the controller determines what instructions to send. The instructions might be determined by automated orchestration component, by direct operator intervention, or by traditional path determination protocol such as OSPF or BGP. 

Switch

Packet processing happens through a set of tables: flow tables, a group table, and a meter table. The tables are populated with instructions from the controller through the OpenFlow channel. Packet enter and exit processing through ports, just as they would in normal switch.

Ports 

Ports on an OpenFlow switch serve the same input/output purpose that they do on any switch. A port can be added, changed, or removed in the switch configuration using, for example from the controller. Port changes must be communicated to the controller so that the controller can clean up any flow entries related to the port. 

Secure Channel

The OpenFlow channel is the communications interface between the switch and the controller. Anything OpenFlow related happening between the switch and controller - instructions and configuration from the controller to the switch, notifications from the switch to the controller, and packets passing from processing to the controller or from the controller into processing- goes over this channel. 

Flow Table

The flow table consists of a set of flow entries. Based on flow entries, the switch forwards the packet.