The OpenFlow Specification

The OpenFlow Specification

• The nonprofit Internet organization [Link] was
created in 2008 as a mooring to promote and support
OpenFlow.
• The first release, Version 1.0.0, appeared on December
31, 2009.
• On March 21, 2011, the Open Network Foundation (ONF)
was created for the express purpose of accelerating the
delivery and commercialization of SDN.
• OpenFlow is an attempt to allow the programming, in a
generic way, of the various implementations of switches.
• OpenFlow attempts to exploit the table-driven design
extant in many of the current silicon solutions.

SDN © 2023 Aladdin Alsharifi 2

 The OpenFlow Switch

SDN © 2023 Aladdin Alsharifi 3

 The OpenFlow Switch
• The core function is to take packets that arrive on one port
(path X on port 2 in the figure) and forward it through
another port (port N in the figure)
• This action box has three fundamental options:
– A. Forward the packet out a local port, possibly modifying certain
header fields first.
– B. Drop the packet.
– C. Pass the packet to the controller over the secure channel.
• When the controller has a data packet to forward out through
the switch, it uses the OpenFlow PACKET_OUT message.
• In the leftmost path Y case, the controller indicates that it
wants to defer the forwarding decision to the packet-
matching logic.
• In the rightmost case, the controller directly specifies the
output port and the packet is passed to that port N

SDN © 2023 Aladdin Alsharifi 4

 The OpenFlow Switch

• A given OpenFlow switch implementation is either

OpenFlow-only or OpenFlow-hybrid.
• An OpenFlow-only switch is one that forwards
packets only according to the OpenFlow logic.
• An OpenFlow hybrid is a switch that can also switch
packets in its legacy mode as an Ethernet switch or
IP router.

SDN © 2023 Aladdin Alsharifi 5

 The OpenFlow Controller
• The data plane matches headers, modifies packets, and
forwards them based on a set of forwarding tables and
associated logic. 100 Gbps
• The control plane runs routing and switching protocols. This
process is very complex and cannot be done at line rates. The
control plane separated from the data plane.
• The OpenFlow control plane differs from the legacy control
plane in three key ways.
– it can program different data plane elements with a common,
standard language, OpenFlow.
– it exists on a separate hardware device than the forwarding plane,
unlike traditional switches
– The controller can program multiple data plane elements from a
single control plane instance.
• The controller can program the data plane elements remotely
over the Internet

SDN © 2023 Aladdin Alsharifi 6

 The OpenFlow Protocol
• The OpenFlow protocol defines the communication between
an OpenFlow controller and an OpenFlow switch.
• This protocol is what most uniquely identifies OpenFlow
technology.
• The protocol consists of a set of messages that are sent from
the controller to the switch and a corresponding set of
messages that are sent in the opposite direction.
• The most basic programming defines, modifies, and deletes
flows.
• A flow as a set of packets transferred from one network
endpoint (or set of endpoints) to another endpoint (or set of
endpoints).
• The endpoints may be defined as IP address-TCP/UDP port
pairs, VLAN
• Endpoints, layer three tunnel endpoints, or input ports,
among other things.
SDN © 2023 Aladdin Alsharifi 7
The Controller-Switch Secure Channel
• The secure channel is the path used for communications
between the OpenFlow controller and the OpenFlow device.
• Generally, this communication is secured by TLS-based
asymmetrical encryption, though unencrypted TCP
connections are allowed.
• These connections may be in-band or out-of-band.
• In the out-of-band example, the secure channel connection
enters the switch via port Z, which is not switched by the
OpenFlow data plane.
• The OpenFlow messages from the controller arriving via port
K, which is part of the OpenFlow data plane.
• When the controller and all the switches it controls are
located entirely within a tightly controlled environment such
as a data center, it may be wise to consider not using TLS-
based encryption to secure the channel.

SDN © 2023 Aladdin Alsharifi 8

 The Controller-Switch Secure Channel
The out-of-band secure channel
is relevant only in the case of an
OpenFlow-hybrid switch.

SDN © 2023 Aladdin Alsharifi 9

 OpenFlow 1.0 and OpenFlow Basics
• OpenFlow1.0 was released on December 31, 2009.
• The OpenFlow specification defines the concept of an
OpenFlow port.
• An OpenFlow V.1.0 port corresponds to a physical port.
• Sophisticated switches have supported multiple queues
per physical port.
• These queues are generally served by scheduling
algorithms (different QoS levels).
• OpenFlow embraces this concept and permits a flow to
be mapped to an already defined queue at an output
port.

SDN software switch anatomy.

SDN © 2023 Aladdin Alsharifi 10

 OpenFlow 1.0: Ports and Port Queues
QoS is very basic in V.1.0.

OpenFlow support for multiple queues per port.

SDN © 2023 Aladdin Alsharifi 11

 Flow Tables
• A flowtable consists of flow entries.
• A flow entry consists of header fields, counters, and
actions associated with that entry.
• The header fields are used as match criteria to
determine whether an incoming packet matches this
entry.
• If a match exists, the packet belongs to this flow.
• The counters are used to track statistics relative to
this flow, such as how many packets have been
forwarded or dropped for this flow.
• The actions fields prescribe what the switch should
do with a packet matching this entry.
SDN © 2023 Aladdin Alsharifi 12
 Flow Tables

OpenFlow V.1.0 flow table.

SDN
© 2023 Aladdin Alsharifi 13
 Packet Matching
• When a packet arrives at the OpenFlow switch from an input
port (or, in some cases, from the controller), it is matched
against the flow table to determine whether there is a
matching flow entry.
– Switch input port
– VLANID
– VLAN priority
– Ethernet source address
– Ethernet destination address
– Ethernet frame type
– IP source address
– IP destination address
– IP protocol
– IPType of Service (ToS) bits
– TCP/UDP source port
– TCP/UDP destination port

SDN © 2023 Aladdin Alsharifi 14

 Packet Matching
• If the end of the flow table is reached without finding
a match, this is called a table miss. In the event of a
table miss in V.1.0, the packet is forwarded to the
controller.
• If a matching flow entry is found, the actions
associated with that flow entry determine how the
packet is handled.

SDN © 2023 Aladdin Alsharifi 15

 Actions and Packet Forwarding
• The required actions that must be supported by a
flow entry are to either output (forward) or drop the
matched packet.
• Five special virtual ports defined in V.1.0 that have
special significance for the output action. They are
LOCAL, ALL, CONTROLLER, IN_PORT, and TABLE.
• LOCAL indicates that the packet needs to be
processed by the local OpenFlow control software.

SDN © 2023 Aladdin Alsharifi 16

 Actions and Packet Forwarding
• ALL is used to flood a packet out all ports on the switch except
the input port. This provides rudimentary broadcast capability
to the OpenFlow switch.
• CONTROLLER indicates that the switch should forward this
packet to the OpenFlow controller.
• IN_PORT instructs the switch to forward the packet back out of
the port on which it arrived. IN_PORT normally creates a
loopback situation, which could be useful for certain scenarios.
• Another instance when IN_PORT is required is edge virtual
bridging (EVB). EVB defines a reflective relay service between a
physical switch in a data center and a lightweight virtual
switch within the server known as a virtual edge port
aggregator (VEPA).

SDN © 2023 Aladdin Alsharifi 17

 Actions and Packet Forwarding
• The TABLE virtual port, which only applies to packets that the
controller sends to the switch.
• When the output action forwards a packet to the NORMAL
virtual port, it sends the packet to the legacy forwarding logic
of the switch. Use of NORMAL makes sense only in the case of
a hybrid switch.
• FLOOD—Flood the packet along the minimum spanning tree,
which includes all OpenFlow interfaces configured for that
virtual switch instance except the ingress interface and any
interfaces that are disabled by the Spanning Tree Protocol
(STP).
• The enqueue action selects a specific queue belonging to a
particular port.
• The modify-field action informs the switch how to modify
certain header fields.

SDN © 2023 Aladdin Alsharifi 18

 Actions and Packet Forwarding

SDN © 2023 Aladdin Alsharifi 19

Messaging Between Controller and Switch

• The messaging between the controller and switch is

transmitted over a secure channel.
• Each message between controller and switch starts
with the OpenFlow header.
• This header specifies the OpenFlow version number,
the message type, the length of the message, and
the transaction ID of the message.
• The messages fall into three general categories:
symmetric, controller-switch, and async.

SDN © 2023 Aladdin Alsharifi 20

Messaging Between Controller and Switch

SDN © 2023 Aladdin Alsharifi 21

Messaging Between Controller and Switch
• Symmetric messages may be sent by either the controller or
the switch without having been solicited by the other. Hello
message, and Echo message.
• Async messages are sent from the switch to the controller
without having been solicited by the controller.
• The PACKET_IN message is the way the switch passes data
packets back to the controller for exception handling.
• The switch can inform the controller that a flow entry is
removed from the flow table via the FLOW_REMOVED
message.
• PORT_STATUS is used to communicate changes in port status .
• The switch uses the ERROR message to notify the controller
of problems.

SDN © 2023 Aladdin Alsharifi 22

Messaging Between Controller and Switch
• Controller-switch is the broadest category of OpenFlow
messages.
• They can be divided into five subcategories: switch
configuration, command from controller, statistics,
queue configuration, and barrier.
• The switch configuration messages consist of a
unidirectional configuration message and two request-
reply message pairs.
• The controller uses the unidirectional message,
SET_CONFIG to set configuration parameters in the
switch.
• The controller uses the FEATURES message pair to
interrogate the switch about which features it supports.

SDN © 2023 Aladdin Alsharifi 23

Messaging Between Controller and Switch
• The GET_CONFIG message pair is used to retrieve a
switch’s configuration settings.
• There are three messages comprising the command from
controller category. PACKET_OUT, FLOW_MOD, and
PORT_MOD.
• The controller uses PACKET_OUT to send data packets to
the switch for forwarding out through the data plane.
• The controller modifies existing flow entries in the switch
via the FLOW_MOD message.
• PORT_MOD is used to modify the status of an OpenFlow
port.

SDN © 2023 Aladdin Alsharifi 24

Messaging Between Controller and Switch
• Statistics are obtained from the switch by the controller
via the STATS message pair.
• The BARRIER message pair is used by the controller to
ensure that a particular OpenFlow command from the
controller has finished executing on the switch.
• The QUEUE_GET_CONFIG_REQUEST and
QUEUE_GET_CONFIG_REPLY message pair is the
mechanism by which the controller learns from the
switch how a given queue is configured.
• With this information, the controller can intelligently
map certain flows to specific queues to achieve desired
QoS levels.

SDN © 2023 Aladdin Alsharifi 25

 Example: Controller Programming Flow
Table

At time ta, the controller sends a

FLOW_MOD (ADD) command to
the switch

SDN © 2023 Aladdin Alsharifi 26

 Example: Controller Programming Flow
Table

idle time for a flow entry

means that after that
number of seconds of
inactivity on that flow, the
flow should be deleted by
the switch

SDN © 2023 Aladdin Alsharifi 27

 Example: Basic Packet Forwarding
The packet-matching function scans the flow table starting at flow entry

0 and finds a match in flow entry F. Flow entry F stipulates that a matching
packet should be forwarded out port P.

Packet matching function: basic packet forwarding V.1.0.

SDN © 2023 Aladdin Alsharifi 28

 Example: Switch Forwarding Packet to
Controller

• An incoming data
packet that is an
OSPF routing
packet.
• This packet should
be forwarded to
the controller.
• The processing on
the controller is
that the OSPF
routing protocol
would be run
• The controller
could then modify
the forwarding
tables
SDN © 2023 Aladdin Alsharifi 29
 OpenFlow 1.1 Additions

• OpenFlow 1.1 was released on February 28, 2011.

• Major New Features Added in OpenFlow 1.1

SDN © 2023 Aladdin Alsharifi 30

 Multiple Flow Tables
• Flow entries can be chained
by an instruction in one flow
entry pointing to another
flow table. This is called a
GOTO instruction.
• The packet is first matched
against entries of flow table
0. Other flow tables may be
used depending on the
outcome of the match in the
first table.

SDN 31
© 2023 Aladdin Alsharifi
 Groups
• V.1.1 offers the group abstraction as a richer extension to
the FLOOD option.
• The group table consists of group entries, each entry
consisting of one or more action buckets.
• The buckets in a group have actions associated with
them that get applied before the packet is forwarded to
the port defined by that bucket.
• If the controller wants to change that next hop due to a
change in IP routing tables in the controller, all the flows
can be rerouted simply by reprogramming the single
group entry.

SDN © 2023 Aladdin Alsharifi 32

 Groups

SDN © 2023 Aladdin Alsharifi 33

 MPLS, VLAN TAG and virtual port Support
• V.1.1 is the first OpenFlow version to provide full
VLAN support.
• A V.1.1 switch classifies ports into the categories of
standard ports and reserved virtual ports.
• Standard ports consist of:
– Physical ports
– Switch-defined virtual ports: Such ports are used when
more complex processing will be required on the packet
than simple header field manipulation.

SDN © 2023 Aladdin Alsharifi 34

 Virtual ports

• Reserved virtual ports consist of:

– ALL. This is the straightforward mechanism to flood
packets out all standard ports except the port on which the
packet arrived.
– CONTROLLER. Forwards the packet to the controller in an
OpenFlow message.
– TABLE. Processes the packet through the normal
OpenFlow pipeline processing. This only applies to a
packet that is being sent from the controller (via a
PACKET_OUT message).
– IN_PORT. This provides a loopback function.

SDN © 2023 Aladdin Alsharifi 35

 Virtual ports

– LOCAL (optional). This optional port provides a mechanism

whereby the packet is forwarded to the switch’s local
OpenFlow control software. A LOCAL port may be used
both as an output port and an ingress port.
– NORMAL (optional). This directs the packet to the normal
non-OpenFlow pipeline of the switch.
– FLOOD (optional). The general use of this port is to send
the packet out all standard ports except the port on which
it arrived.

SDN © 2023 Aladdin Alsharifi 36

 OpenFlow 1.2 Additions
• OpenFlow 1.2 was released on December 5, 2011.

Major New Features Added in OpenFlow 1.2

SDN © 2023 Aladdin Alsharifi
 Extensible Match Support
• A generic and extensible packet-matching capability
has been added in V.1.2 via the OpenFlow Extensible
Match (OXM) descriptors.
• OXM defines a set of type-length-value (TLV) pairs
that can describe or define virtually any of the
header fields an OpenFlow switch would need to use
for matching.
• This ability to match on any combination of header
fields is provided within theOPENFLOW_BASIC match
class.

SDN © 2023 Aladdin Alsharifi 38

 Multiple Controllers
• In V.1.2 the switch may be configured to maintain simultaneous
connections to multiple controllers.
• It is duplicated and a copy sent to each controller.
• A controller may assume one of three different roles relative to a
switch:
– Equal
– Slave
– Master
• The least powerful is obviously slave mode, wherein the controller
may only request data from the switch, such as statistics, but may
make no modifications
• Both equal and master modes allow the controller the full ability to
program the switch, but in the case of master mode the switch
enforces that only one switch be in master mode and all others be
in slave mode

SDN © 2023 Aladdin Alsharifi 39

 OpenFlow 1.3 Additions
• OpenFlow V.1.3 was released on April 13, 2012.

SDN © 2023 Aladdin Alsharifi 40

 OpenFlow 1.3 feaures
• Refactor Capabilities Negotiation
– There is a new MULTIPART_REQUEST/MULTIPART_REPLY
message pair in V.1.3.
• More Flexible Table-Miss Support
– V.1.3 expands on this limited handling capability via the
introduction of the table-miss flow entry.
– The controller programs a table-miss flow entry into a
switch in much the same way it would program a normal
flow entry.

SDN © 2023 Aladdin Alsharifi 41

 OpenFlow 1.3 feaures
• Per-Flow Meters
– Meters are defined on a per-flow basis and reside in a meter
table
– A given meter is identified by its meter ID.
– V.1.3 meters are only rate-limiting meters.
– There may be multiple meter bands attached to a given meter.
– Each meter band has a configured bandwidth rate and a type.
– The units of bandwidth are not specified by OpenFlow.
– The type determines the action to take when that meter band is
processed.

SDN © 2023 Aladdin Alsharifi 42

 OpenFlow 1.3 feaures
• Per-Flow Meters
– If the current measured rate is lower than all bands, no
band is selected and no action is taken.
– If a band is selected, the action taken is that prescribed by
the band’s type field.
– The optional types described in V.1.3 consist of DROP and
DSCP remark.
– The meter counters are updated for all packets processed
by the meter, and the per-meter-band counters are
updated only when that particular band is selected.

SDN © 2023 Aladdin Alsharifi 43

 OpenFlow 1.3 feaures

Per-Flow Meters

SDN © 2023 Aladdin Alsharifi 44

 Per Connection Event Filtering
• The idea that the different controllers have asymmetrical roles
was not as effective as it could have been if all controllers
must receive the same kind and quantity of asynchronous
notifications from the switches.
• V.1.3 introduces a SET_ASYNC message that allows the
controller to specify the sorts of async messages it is willing to
receive from a switch.
• It additionally allows the controller to filter out certain reason
codes that it does not want to receive.
• A controller may use two different filters: one for the
master/equal role and another for the slave role.
• This new capability is controller-oriented rather than flow-
oriented.

SDN © 2023 Aladdin Alsharifi 45

 Auxiliary Connections
• V.1.3 introduces an additional layer of parallelism by allowing multiple
connections per communications channel. That is, between a single controller
and switch, multiple connections may exist.

SDN © 2023 Aladdin Alsharifi 46

 Example: Enforcing QoS via Meter Bands

The incoming packet is matched

against the second flow entry in
the first flowtable and that the
associated instructions direct the
packet to meter 3. The two dashed
lines emanating from the meter table
show that based on the current
measured bandwidth of the port
selected as the output port (port N in
this case), the packet may be dropped
as exceeding the bandwidth
limits, or it may be forwarded to port
N if the meter does not indicate that
bandwidth enforcement is necessary.

SDN © 2023 Aladdin Alsharifi 47

 OpenFlow Limitations
• One limitation is that the currently defined match
fields are limited to the packet header. Thus, deep
packet inspection (DPI), whereby fields in the
packet’s payload may be used to distinguish flows, is
not supported in a standard OpenFlow.
• Second, some OpenFlow abstractions may be too
complex to implement directly in today’s silicon.

SDN © 2023 Aladdin Alsharifi 48