OpenFlow

OpenFlow is a realisation of Software Defined Networking concepts. It is a pro- tocol specification designed to enable the control of network devices. Since its inception [71], OpenFlow has become the most widely recognised and deployed technologies related to the SDN paradigm. OpenFlow itself was initially envi- sioned as a tool to enable research and experimentation to take place on campus LAN [130].

Prior to OpenFlow, there had been a lack of work that had made its way from the research world to production. One of the fundamental issues identified with this process was a lack of scalability and realism in the development and evalu- ation of this work. OpenFlow aimed to combat this by allowing both research and production traffic to coexist on the same network. By doing so, network operators could continue to provide the connectivity and service to their users,

whilst the researcher would be afforded access to a specific portion orslice of this traffic, on which they could do experimentation.

This compromise between production and research requirements was typically realised through the use of tools such as Flowvisor [154], which enabled the sep- aration of traffic through establishment of pre-defined network slices. Each slice represented a subset of traffic, defined using a number of tuples, such as source and destination IP addresses, port numbers or VLAN tags. Using this tool, an experimenter could precisely define exactly the traffic they were interested in, without disrupting the other traffic flowing through the network. Importantly, this could also be done for multiple experimenters simultaneously, affording each a separate slice that offered isolation between experiments.

Key to OpenFlow, and arguably a core reason for its success, is that it was vendor agnostic; that is, it was not developed with a particular vendor, and as a result was released openly for anybody to use. This created a situation whereby a vendor could support the OpenFlow standard by implementing the minimum necessary elements of the OpenFlow specification. This openness had a significant advantage, in that a software controller supporting OpenFlow could communicate and control a variety of devices, regardless of their vendor. The initial industry support for OpenFlow came with version 1.0, which is discussed in the following section.

Version 1.0

Version 1.0 [25] of the OpenFlow specification was released in 2009 and adopted

by network vendors soon after. This version describes a single OpenFlow flow

table, consisting of a number of flow entries. When a packet is received on the device, the packet header is compared against these entries. Each entry consists of a number of fields with specific values. If a field is omitted, it is assumed that any value can be matched (wildcarded). Once a packet has matched on an entry in this table, a set of actions is applied to the packet. These actions include forwarding the packet on a specific physical port, forwarding to a virtual port (such as a port aggregation or VLAN), or even flooding the packet to all ports.

Importantly, these matches also enable the packet headers to be modified, such as changing the source or destination address, or incrementing a TTL value. If the packet does not match on any of the rules found in the flow table, then

the device passes the packet to the control so that it may make a decision on its destination. Each of these flow entries also includes a set of counters, which are updated when a packet matches. These include both packet and byte counts, and can be retrieved by the controller to use in defining the behaviour of the network. The set of actions included in the OpenFlow specification are defined in two

sets; Required Actions must be implemented by the switch in order for it to

be OpenFlow compatible, and include the functionalities mentioned previously

(forwarding to all ports, forwarding to the controller, etc.). A number ofOptional

Actions are also defined. These can be omitted if necessary, particularly in cases where the underlying device does not support the action, but may assist the developer in implementing additional functionality.

One such action is NORMAL, which passes the packet to the traditional for-

warding path supported by the switch. By chaining a number of these actions together, it is possible to manipulate the packet, or duplicate the packet, and still pass it through the regular forwarding stack of the switch. Inevitably, these optional features are not supported on every switch: typically they are found on devices where this OpenFlow has been developed on top of existing functionality, as is the case with many hardware switches. However, in the case of software switches, such as Open vSwitch [22], a traditional forwarding path is somewhat of a misnomer; they do not process packets without explicit instruction or con- figuration.

In order to support OpenFlow-capable switches, a number of compatible soft- ware controllers became available. Engineered in a variety of programming lan- guages, they provided a framework in which basic network functionality could modified and new functionality could be built. Controllers such as Beacon [90] also have external APIs, which enable third-party applications to interact with the controller and modify the forwarding plane by installing matches and actions manually, as well as retrieving counter values.

Later, version 1.1 [26] of OpenFlow was released. This version provided sup- port for multiple flow tables (rather than the single table enabled in version 1.0). It also introduced support for more field matches, and introduced multipath func- tions, where a flow can be sent over one of several paths. Further support was also added for MPLS and VLAN Q-in-Q encapsulation.

Version 1.3

In 2011, the Open Networking Foundation [21] took over the responsibility for developing the OpenFlow specification, with the aim to eventually standardise it. The first standard to be published under their custodianship was version 1.2 [27]. This version included features such as an extensible match support, allowing experimenters to define their own match fields. This was accompanied by an extensible header rewriting functionality, as well as support for IPv6. It also clarified the controller role mechanism, simplifying the process for which controllers were migrated between.

However, this saw little adoption from vendors, and in 2013, the 1.3 [28] spec- ification was released. This incorporated many, if not all, of the changes made in previous versions. It also included new functionality in the form of capability negotiation, which allowed controllers to better discover the capabilities of a con- nected device. Further to this, improved support for common IPv6 extensions was added, as well as finer-grained reporting in the form of per flow meters. This improved reporting was supplemented with the addition of a duration field for statistics, allowing packet and byte rate to be determined by a controller.

With the development and release of switches supporting OpenFlow 1.3, new controllers began to appear. Examples include the Ryu [38] controller, which offers full OpenFlow version 1.3 support, and is designed to allow researchers and developers to create functionality easily. Ryu is also used as a tool to ensure compatibility and compliance with the 1.3 specification, which enables testing across a variety of vendor hardware.

Other controllers have also been developed to meet some of the scalability concerns evident in the SDN paradigm. ONOS [61] aims to do this by operating in a distributed fashion, whilst ensuring state is synchronized between controller nodes. In order to address concerns over commercial applicability, the OpenDay- light consortium [23] is also attempting to build a controller capable of running in a production environment, and support the vast array of protocols and func- tionality necessary to do so.

Version 1.4 and Beyond

OpenFlow continues to be developed, with subsequent versions (1.4 [29] and 1.5 [30]) being released recently. In version 1.4, new features include more exten-

sible wire protocols for defining custom match fields, and extensions encompass- ing optical port properties. This also includes bundles, which allows a group of OpenFlow messages to be applied as a single operation, and synchronised tables, allowing lookups to occur on multiple tables simultaneously.

In version 1.5, egress tables were introduced, enabling processing to be done in the context of an output port (rather than input port, as previously). This version also introduces packet aware pipelines, allowing packets other than Eth- ernet packets to be processed. There is also the ability to trigger an alert when a statistics exceeds a given threshold (in opposition to regularly polling for a metric, which has a processing overhead). However, despite the extra function- ality provided in these versions, as of yet, no organisation has released a version capable of supporting either of these versions.

However, continuously iterating the OpenFlow specification to include new header fields is not necessarily a scalable nor sustainable solution; every version has included new fields, with the trend continuing in the latest releases. The expansion of fields is in part due to a growing range of mediums that OpenFlow is targeting, including optical and wireless technologies. In order to address this, P4 [64] proposed as a way to describe the data-plane connectivity of a network using a domain-specific language. Programs written in P4 specify how a switch processes packets, and works in harmony with OpenFlow to provide even greater flexibility. Importantly, P4 is both protocol and target independent, allowing new protocols to be developed without concern for the underlying hardware. It is also field reconfigurable, allowing hardware behaviour to be changed even after it is deployed.