Overview of the Switch's Architecture
The architecture of the switch contains all the elements of the OpenFlow 1.3 pipeline.
The figure below gives a high level overview of the main blocks of an OpenFlow switch.
This sections gives a brief description of the functionality from the switch components. It will also present any other relevant activity performed by the components. The last piece of information is about the files where one can find code related to the component.
Ports
Packet Parser
NetPDL
Flow Tables
Group Table
Meter Table
Oflib
Secure Channel
Dptcl
OpenFlow ports are the entrance and exit doors for network packets of the OpenFlow switch pipeline. A software switch instance running on a machine may use their physical or virtual interfaces as port elements. Physical port elements can take control over Ethernet or WiFi interfaces, allowing the creation of real network topologies. Although limited by the speed of the software switch, the possibility to create a low cost testbed enriches the experience of users developing and testing OpenFlow applications.
Ports functions on the switch are not limited to the task of send and receive packets. There is a set of responsibilities associated with the OpenFlow protocol and the pipeline. Functionalities are:
-
OpenFlow enables some level of control over a port behavior. A port modification message permits the configuration of the port state. Ports can be administratively set to drop all received or forwarded packets, forbid the generation of Packet-in messages from arriving packets, and brought down. Ports elements should handle these messages and change the port behavior according to the configuration sent.
-
OpenFlow Ports keep the current state of the physical link. This information is not configurable by an OpenFlow controller, but the switch should inform the control plane about link state changes. Ports monitor the state of the port link and update the information according to changes.
-
Packets encapsulated in a Packet-in usually have only the header sent within the message. A buffer stores the packet, while waiting for the controller decision after the Packet-in. Ports elements store these packets and resend them for further processing.
-
An OpenFlow controller can ask the switch about a port description. The software switch element retrieves information such as current and max operating speeds from the interfaces of the machine and stores it. On a port description request, the element handles the message and sends the required information to the control plane.
-
Queues creation are not part of the OpenFlow protocol. However, OpenFlow can configure port queues, created by whichever mechanism, to be associated with a switch port. Ports are responsible for handling queue association and configuration.
-
Ports update port and queue packet counters.
udapath/dp_ports.h
udapath/dp_ports.c
udapath/dp_buffers.h
udapath/dp_buffers.c
lib/netdev.h
lib/netdev.c
The Packet Parser is the first stage of a packet after coming through one of the switch's ports.
The parser relies in an external library called Netbee to dissect the network protocol fields of packet. From the parsed fields, a matching structure is built and sent to the Flow Tables.
Besides the its main activity, the Packet Parser also performs some checks such as:
- TTL validity
- Addition of pipeline fields. These fields are not extracted from packets but set during the pipeline. The supported types are: inport, tunnel_id and metadata.
udatapath/packet_handle_std.h
udatapath/packet_handle_std.c
udapath/packet.c
udapath/packet.c
nbee_link/nbee_link.h
nbee_link/nbee_link.cpp
NetPDL is a description language that describes how Netbee should parse the protocols. The language uses XML and it is simple to extend from different protocols based on the descriptions currently available.
The Flow Tables is the next step after the packet parsing. It can be considered the heart of OpenFlow since packets it is always the first component of the Pipeline and packets can even return to it.
In the switch, a Flow Table is composed of a list of flows. A flow is composed by match fields and instructions described in the OpenFlow specification. After parsed, a packet is checked for a matching entry in the Flow table. If the fields match a flow, the instructions are executed.
Some facts about the implementation:
-
Flows are stored in ordered of priority. If the priorities are equal, they are ordered by the insertion time.
-
Flow table lookup is linear. It means, matching a single packet packet has complexity O(n), where n is the number of flows. It is not very efficient when there is a big amount of flows. However it is good enough for most basic tests.
-
The number of Flow Tables in the pipeline of the switch is set to 64, but increasing it is just a matter of changing its definition.
-
The pipeline code contains the handlers for flow modification messages and flow status requests.
-
Flow tables have a list of idle and hard timeout entries ordered by the time of remotion. It allows to stop as soon as the first non expired flow is spotted. The current pipeline timeout time is 100ms. It means every 0.1s the tables are checked for expired entries.
udatapath/pipeline.h
udatapath/pipeline.c
udatapath/std_match.h
udatapath/std_match.c
udatapath/dp_actions.h
udatapath/dp_actions.c
udatapath/action_set.h
udatapath/action_set.c
udatapath/flow_entry.h
udatapath/flow_entry.c
udatapath/flow_table.h
udatapath/flow_table.c
Group Table empowers OpenFlow forwarding options. Packets reach the Group Table after matching a flow entry containing a group action, in one of the Flow Tables. Group entries are stored into the Group Table. Each group entry contains an identifier, a type, counters and action buckets. Action buckets are an ordered list of action sets to be executed according to the group type.
udatapath/group_entry.h
udatapath/group_entry.c
udatapath/group_table.h
udatapath/group_table.c
The Meter Table is an element to perform simple QoS operations. Per-flow meters are attached to flow entries through the Meter instruction. A meter entry is composed by a meter id, counters and meter bands. The QoS operations to apply are defined by the meter bands. A meter band must have a type and rate value, which is the boundary to apply the action determined by the type.
udatapath/meter_entry.h
udatapath/meter_entry.c
udatapath/meter_table.h
udatapath/meter_table.c
OpenFlow messages defined by the specification follow a proper format for transmission in the network. Messages are 8-byte aligned, so there may be insertion of padding fields to follow this alignment rule. Another requirement for the message format is the byte order. The preferred format for packets sent through the network is the network byte order. As OpenFlow messages are sent over IP networks, their messages should be assembled following the Big-Endian format.
The architectures of machine's processor may operate on different byte-endianness. For instance, Intel processors use the Little-Endian byte order. So, in order to handle and assemble OpenFlow messages, conversion is required for non Big-Endian architectures.
For the mentioned reasons, a library which abstracts byte-endianness and adds any required bytes to ensure right message format is required. A Marshaling/Unmarshaling library is not an element defined by OpenFlow specification. Its main function is the translation of OpenFlow messages from the network format to an internal format and vice-versa.
The OpenFlow software switch communicates with controllers through the Communication Channel. This element connects with the Datapath and the controller and acts as a proxy between them. This element exists because the implementation of the communication channel is not defined by the specification. Since the message format is respected, implementations are free to choose the connection protocol. For instance, when security for the channel is a requirement, a protocol like TLS should be used to encrypt the messages.