II. Software-Defined Networking
2.5 OpenFlow
2.5.1 OpenFlow Hardware
OpenFlow was first proposed in 2008 as a compromise to bridge the gap between researchers and vendors. Researchers needed a mechanism for low-level flow control on real switching hardware to be able to rapidly develop and test new protocols and architectures. Vendors, however, were understandably reluctant to expose the inner workings and trade secrets of their devices, which they saw as contributing greatly to their hard-earned market shares. Determined to avoid the stalemate of ForCES, OpenFlow was designed to expose the minimum-needed control in a platform-agnostic
way without requiring the opening of vendors’ hardware. This allowed greater steps in research, as prior options were all unsuitable: “the commercial solutions are too closed and inflexible, and the research solutions either have insufficient performance or fanout, or are too expensive” [15].
An OpenFlow switch provides at least one flow table and a control channel to at least one controller (via TCP or TLS) [15]. Figure 4 depicts the basic components of an OpenFlow switch and its control channel to an external OpenFlow controller.
OpenFlow Switch Specification
Version 1.3.5
1 Introduction
This document describes the requirements of an OpenFlow Logical Switch. Additional information
describing OpenFlow and Software Defined Networking is available on the Open Networking Foundation
website (https://www.opennetworking.org/). This specification covers the components and the basic
functions of the switch, and the OpenFlow switch protocol to manage an OpenFlow switch from a
remote OpenFlow controller.
Controller Flow Table Flow Table OpenFlow Channel
...
Pipeline OpenFlow Switch OpenFlow Protocol Group TableFigure 1: Main components of an OpenFlow switch.
2 Switch Components
An OpenFlow Logical Switch consists of one or more flow tables and a group table, which perform packet
lookups and forwarding, and one or more OpenFlow channels to an external controller (Figure 1). The
switch communicates with the controller and the controller manages the switch via the OpenFlow switch
protocol.
Using the OpenFlow switch protocol, the controller can add, update, and delete flow entries in flow
tables, both reactively (in response to packets) and proactively. Each flow table in the switch contains
a set of flow entries; each flow entry consists of match fields, counters, and a set of instructions to apply
to matching packets (see 5.2).
Matching starts at the first flow table and may continue to additional flow tables of the pipeline (see
5.1). Flow entries match packets in priority order, with the first matching entry in each table being
used (see 5.3). If a matching entry is found, the instructions associated with the specific flow entry are
executed (see 5.9). If no match is found in a flow table, the outcome depends on configuration of the
table-miss flow entry: for example, the packet may be forwarded to the controllers over the OpenFlow
channel, dropped, or may continue to the next flow table (see 5.4).
Figure 4. The basic components of an OpenFlow switch [16]
Flow tables are configured by the controller and contain flow entries. Each flow entry specifies a match that ties the entry to the header fields of a given flow. For example, one entry may match any flows where the first packet is destined to a particular Media Access Control (MAC) or Internet Protocol (IP) address, while another may match on the source TCP port number. Each flow entry may also provide counter mechanisms for the controller to query and gain statistical information about the number of packets matching each flow entry. Finally, each entry contains an
action to be performed on matching flows, such as forwarding the packets out of a given switch port, sending matching packets to the controller, or (in versions 1.1 and later) specifying an alternative flow table pipeline. The control channel protocol is the OpenFlow switch protocol itself [16].
OpenFlow 1.0 (2009) and earlier versions specified a single flow table to be sup- ported in hardware, with 1.1 (2011) and later providing the option for multiple tables to be supported by hardware. Multiple tables, when supported by the hardware, act as a one-way pipeline to provide more sophisticated flow control and better performance. Figure 5 depicts a pipeline of n flow tables inside an OpenFlow switch, with each packet that passes through the switch potentially picking up new metadata and actions at each table. At the end of the pipeline, any actions attached to that packet are applied.
OpenFlow Switch Specification Version 1.3.5
Table 0 Table 1 Table n Packet Execute Action Set Packet In Action Set Action Set = {} OpenFlow Switch Packet Out
...
Ingress port Packet + ingress port + metadata Action Set(a) Packets are matched against multiple tables in the pipeline
Match fields: Ingress port + metadata + pkt hdrs Action set Flow Table
➀
Find highest-priority matching flow entry➁
Apply instructions:i. Modify packet & update match fields (apply actions instruction)
ii. Update action set (clear actions and/or write actions instructions)
iii. Update metadata
➂
Send match data and action set to next table➀
➁
➂
Action set Match fields: Ingress port + metadata + pkt hdrs(b) Per-table packet processing
Figure 2: Packet flow through the processing pipeline.
5.1 Pipeline Processing
OpenFlow-compliant switches come in two types: OpenFlow-only, and OpenFlow-hybrid. OpenFlow- only switches support only OpenFlow operation, in those switches all packets are processed by the OpenFlow pipeline, and can not be processed otherwise.
OpenFlow-hybrid switches support both OpenFlow operation and normal Ethernet switching opera- tion, i.e. traditional L2 Ethernet switching, VLAN isolation, L3 routing (IPv4 routing, IPv6 routing...), ACL and QoS processing. Those switches should provide a classification mechanism outside of Open- Flow that routes traffic to either the OpenFlow pipeline or the normal pipeline. For example, a switch may use the VLAN tag or input port of the packet to decide whether to process the packet using one pipeline or the other, or it may direct all packets to the OpenFlow pipeline. This classification mech- anism is outside the scope of this specification. An OpenFlow-hybrid switch may also allow a packet to go from the OpenFlow pipeline to the normal pipeline through the NORMAL and FLOOD reserved ports (see 4.5).
The OpenFlow pipeline of every OpenFlow Logical Switch contains one or more flow tables, each flow table containing multiple flow entries. The OpenFlow pipeline processing defines how packets interact with those flow tables (see Figure 2). An OpenFlow switch is required to have at least one flow table, and can optionally have more flow tables. An OpenFlow switch with only a single flow table is valid, in this case pipeline processing is greatly simplified.
Figure 5. OpenFlow packet matching through multiple tables [16]
Figure 6 is a flow chart showing the order in which matches are examined for each packet and table, and if a match exists, how updates may occur to possibly modify the packet before forwarding it. Figure 6 should be viewed as the logic that occurs when a packet is sent to any of the tables of Figure 5. The first decision in Figure 6 is to find whether there exists a match for this particular packet in the table. If there is a match, any actions are applied, and the packet may continue to be processed by other tables if a “goto-table” statement exists. If there is no match in the current table, the last decision of the flow chart is to check the table for a miss flow entry. The
miss flow entry is a catchall action that matches any unmatched packet. Note that the default action if no match exists is to drop the packet; an unconfigured OpenFlow switch, by specification, forwards no traffic.
OpenFlow Switch Specification
Version 1.3.5
• cookie: opaque data value chosen by the controller. May be used by the controller to filter flow
entries affected by flow statistics, flow modification and flow deletion requests. Not used when
processing packets.
• flags: flags alter the way flow entries are managed, for example the flag OFPFF_SEND_FLOW_REM
triggers flow removed messages for that flow entry.
A flow table entry is identified by its match fields and priority: the match fields and priority taken
together identify a unique flow entry in a specific flow table. The flow entry that wildcards all fields
(all fields omitted) and has priority equal to 0 is called the table-miss flow entry (see 5.4).
A flow entry instruction may contain actions to be performed on the packet at some point of the pipeline
(see 5.12). The set-field action may specify some header fields to rewrite. Each flow table may not
support every match field, every instruction, every action or every set-field defined by this specification,
and different flow tables of the switch may not support the same subset. The table features request
enables the controller to discover what each table supports (see 7.3.5.5).
5.3 Matching
Packet In Start at table 0 Match in table n? Update counters Execute instructions:• update action set
• update packet/match set fields • update metadata Goto- Table n? Execute action set Yes Yes No No Table- miss flow entry exists? Drop packet No Yes
Figure 3: Flowchart detailing packet flow through an OpenFlow switch.
On receipt of a packet, an OpenFlow Switch performs the functions shown in Figure 3. The switch starts
by performing a table lookup in the first flow table, and based on pipeline processing, may perform
table lookups in other flow tables (see 5.1).
Packet header fields are extracted from the packet, and packet pipeline fields are retrieved. Packet
header fields used for table lookups depend on the packet type, and typically include various protocol
header fields, such as Ethernet source address or IPv4 destination address (see 7.2.3). In addition to
19
© 2015; The Open Networking Foundation
Figure 6. Flow chart for OpenFlow’s Match, Action, and Instruction [16]