We will be covering implementation of the OpenFlow switch (v1.0) and important hardware and software OpenFlow switches. Then we will introduce Mininet as an integrated environment to experience with the OpenFlow switches and controllers. The reference implementation of OpenFlow and hardware/software products

OpenFlow reference switch

OpenFlow switch is a basic forwarding element, which is accessible via OpenFlow protocol and interface. Although at first glance this setup would appear to simplify the switching hardware, flow-based SDN architectures such as OpenFlow may require additional forwarding table entries, buffer space, and statistical counters that are not very easy to implement in traditional switches with application specific ICs (ASICs).

In an OpenFlow network, switches come in two flavors, hybrid (OpenFlow enabled) and pure (OpenFlow only). Hybrid switches support OpenFlow in addition to traditional operation and protocols (L2/L3 switching). Pure OpenFlow switches have no legacy features or onboard control, and completely rely on a controller for forwarding decisions. Most of the currently available and commercial switches are hybrids.

Since OpenFlow switches are controlled by an open interface (over TCP-based TLS session), it is important that this link remains available and secure. The OpenFlow protocol can be viewed as one possible implementation of SDN-based controller-switch interactions (which is a messaging protocol), as it defines the communication between the OpenFlow switch and an

OpenFlow controller.

In figure 6.1 depicts the OpenFlow reference switch, interface, and three message types (controller-toswitch, asynchronous, and symmetric) and sub-types. These messages were briefly introduced in the previous chapter. They are presented with more implementation related details in this section. Controller-to-switch messages are initiated by the controller and may or may not require a response from the OpenFlow switch.

These messages are used to directly manage or inspect the state of the switch:

• Features: Upon the establishment of the TLS session (for example, TCP TLS session on port 6633), the controller sends an OFPT_FEATURES_REQUEST message to the switch and the OpenFlow switch reports back (via OFPT_ FEATURES_REPLY message) the features and capabilities that it has and supports. The datapath identifier (datapath_id), number of supported flow tables by data path (OpenFlow switch), switch capabilities, supported actions, and definition of ports are the important features that are reported to the controller. The datapath_id field uniquely identifies an OpenFlow switch (data path). It is a 64-bit entity and the lower 48 bits are intended for the switch MAC address, while the top 16 bits are up to the manufacturers.

• Configuration: The controller is able to set and query configuration parameters in the switch with the OFPT_SET_CONFIG and OFPT_GET_CONFIG_ REPLY messages, respectively. The switch responds to a configuration request with an OFPT_GET_CONFIG_REPLY message; it does not reply to a request to set the configuration.

• Modify state: Modifications to the flow table from the controller are done with the OFPT_FLOW_MOD message and the controller uses the OFPT_PORT_MOD message to modify the behavior of the physical ports. The flow modification commands are ADD, MODIFY, MODIFY_STRICT, DELETE, and DELETE_STRICT, which were explained in Chapter 1, Introducing OpenFlow. The port configuration bits indicate whether a port has been administratively brought down, options for handling 802.1D spanning tree protocol (STP) packets, and how to handle incoming and outgoing packets. The controller may set OFPPFL_NO_STP to 0 to enable STP on a port, or to 1 to disable STP on a port. The OpenFlow reference implementation sets this bit to 0 (enabling STP) by default.

• Read State (Statistics): The controller can query the status of the switch using OFPT_STAT_REQUEST message. The switch responds with one or more OFPT_STATS_REPLY messages. There is a type field in these message exchanges, which specifies the kind of information that is being exchanged (OpenFlow switch description, individual flow statistics, aggregate flow statistics, flow table statistics, physical port statistics, queue statistics for a port, and vendor-specific messages) and determines how the body field should be interpreted.

• Queue query: An OpenFlow switch provides limited Quality of Service (QoS) support through a simple queuing mechanism. One (or more) queue(s) can be attached to a port and could be used to map flows on it (them). The flows, which are mapped to a specific queue, will be treated according to the configuration of that queue (for example, minimum rate control). Note that queue configuration takes place outside the OpenFlow protocol (for example, through command-line interface) or an external dedicated configuration protocol. The controller can query the switch for configured queues on a port using queue query message.

• Send packet: Using this message (that is, OFPT_PACKET_OUT), the controller is able to send packets out of a specified port of the OpenFlow switch.

• Barrier: This message is sent whenever the controller wants to ensure message dependencies have been met or wants to receive notifications for completed operations. The message is OFPT_BARRIER_REQUEST and has no message body. Upon receipt, the OpenFlow switch must finish processing all previously-received messages before executing any message beyond the barrier request. When current processing is completed, the switch must send an OFPT_BARRIER_REPLY message the transaction ID (xid) of the original request.

Software-based switches

There are currently several OpenFlow software switches available that can be used, for instance, to run an OpenFlow test-bed or to develop and test OpenFlow-based network applications. A list of current software switches with a brief description, including implementation language and the OpenFlow standard, are as follows:

• Open vSwitch: This is a multilayer and production quality virtual switch licensed under the Apache 2.0 license. It is designed to enable network automation through programmatic extension, while still supporting standard management interfaces and protocols (for example, NetFlow, sFlow, OpenFlow, OVSDB, and so on.).

• Indigo: This is an open source OpenFlow implementation that runs on physical switches and uses the hardware features of Ethernet switch ASICs to run OpenFlow at line rates. It is based on the OpenFlow Reference Implementation from Stanford University.

• LINC: This is an open source project led by FlowForwarding effort and is an Apache 2 license implementation based on OpenFlow 1.2/1.3.1. LINC is architected to use generally-available commodity x86 hardware and runs on a variety of platforms such as Linux, Solaris, Windows, MacOS, and FreeBSD where Erlang runtime is available.

• Pantou (OpenWRT): This turns a commercial wireless router/access point to an OpenFlow-enabled switch. OpenFlow is implemented as an application on top of OpenWrt. Pantou is based on the BackFire OpenWrt release (Linux 2.6.32). The OpenFlow module is based on the Stanford reference implementation (userspace). At the time of this writing, it supports generic Broadcom and some models of LinkSys and TP-LINK access points with Broadcom and Atheros chipsets.

• Of13softswtich: This is an OpenFlow 1.3 compatible user-space software switch implementation based on the Ericsson TrafficLab 1.1 softswitch. The latest version of this software switch includes the switch implementation (ofdatapath), a secure channel for connecting the switch to the controller (ofprotocol), a library for conversion from/to OpenFlow 1.3 (oflib), and a configuration tool (dpctl). This project is supported by Ericsson Innovation Center in Brazil and maintained by CPqD in technical collaboration with Ericsson Research.