Based on the narrative of Section 3.

1, we are now in a
position to detail the principal requirements for a modern
networking approach. The Open Data Center Alliance (ODCA)
provides a useful, concise list of requirements, which include
the following [ODCA14]:
Adaptability: Networks must adjust and respond
dynamically, based on application needs, business
policy, and network conditions.
Automation: Policy changes must be automatically
propagated so that manual work and errors can be
reduced.
Maintainability. Introduction of new features and
capabilities (software upgrades, patches) must be
seamless with minimal disruption of operations.
Model management: Network management software
must allow management of the network at a model
level, rather than implementing conceptual changes by
reconfiguring individual network elements.
Mobility: Control functionality must accommodate
mobility, including mobile user devices and virtual
servers.
Integrated security: Network applications must
integrate seamless security as a core service instead of
as an add-on solution.
On-demand scaling: Implementations must have the
ability to scale up or scale down the network and its
services to support on-demand requests.

SDN Architecture

An analogy can be drawn between the way in which

computing evolved from closed, vertically integrated,
proprietary systems into an open approach to computing and
the evolution coming with SDN (see Figure 3.1). In the early
decades of computing, vendors such as IBM and DEC
provided a fully integrated product, with a proprietary
processor hardware, unique assembly language, unique
operating system (OS), and the bulk if not all of the
application software. In this environment, customers,
especially large customers, tended to be locked in to one
vendor, dependent primarily on the applications offered by
that vendor. Migration to another vendor’s hardware
platform resulted in major upheaval at the application level.

FIGURE 3.1 The Modern Approach to Computing and

Networking

Today, the computing environment is characterized by

extreme openness and great customer flexibility. The bulk of
computing hardware consists of x86 and x86-compatible
processors for standalone systems and ARM processors for
embedded systems. This makes it easy to port operating
systems implemented in C, C++, Java, and the like. Even
proprietary hardware architectures, such as IBM’s
zEnterprise line, provide standardized compilers and
programming environments and so can easily run open
sources operating systems such as Linux. Therefore,
applications written for Linux or other open operating
systems can easily be moved from one vendor platform to
another. Even proprietary systems such as Windows and Mac
OS provide programming environments to make porting of
applications an easy matter. It also enables the development
of virtual machines that can be moved from one server to
another across hardware platforms and operating systems.
The networking environment today faces some of the same
limitations faced in the pre-open era of computing. Here the
issue is not developing applications that can run on multiple
platforms. Rather, the difficulty is the lack of integration
between applications and network infrastructure. As
demonstrated in the preceding section, traditional network
architectures are inadequate to meet the demands of the
growing volume and variety of traffic.
The central concept behind SDN is to enable developers and
network managers to have the same type of control over
network equipment that they have had over x86 servers. As
discussed in Section 2.6 in Chapter 2, the SDN approach
splits the switching function between a data plane and a
control plane that are on separate devices (see Figure 3.2).
The data plane is simply responsible for forwarding packets,
whereas the control plane provides the “intelligence” in
designing routes, setting priority and routing policy
parameters to meet QoS and QoE requirements and to cope
with the shifting traffic patterns. Open interfaces are defined
so that the switching hardware presents a uniform interface
regardless of the details of internal implementation.
Similarly, open interfaces are defined to enable networking
applications to communicate with the SDN controllers.
 FIGURE 3.2 Control and Data Planes
See Figure 2.15, Software Defined Networking
Figure 3.3 elaborates on the structure shown in Figure 2.15,
showing more detail of the SDN approach. The data plane
consists of physical switches and virtual switches. In both
cases, the switches are responsible for forwarding packets.
The internal implementation of buffers, priority parameters,
and other data structures related to forwarding can be
vendor dependent. However, each switch must implement a
model, or abstraction, of packet forwarding that is uniform
and open to the SDN controllers. This model is defined in
terms of an open application programming interface
(API) between the control plane and the data plane
(southbound API). The most prominent example of such an
open API is OpenFlow, discussed in Chapter 4, “SDN Data
Plane and OpenFlow.” As Chapter 4 explains, the OpenFlow
specification defines both a protocol between the control and
data planes and an API by which the control plane can invoke
the OpenFlow protocol.
 FIGURE 3.3 Software-Defined Architecture
A language and message format used by an application
program to communicate with the operating system or
some other control program such as a database
management system (DBMS) or communications
protocol. APIs are implemented by writing function calls
in the program, which provide the linkage to the required
subroutine for execution. An open or standardized API
can ensure the portability of the application code and the
vendor independence of the called service.
SDN controllers can be implemented directly on a server or
on a virtual server. OpenFlow or some other open API is used
to control the switches in the data plane. In addition,
controllers use information about capacity and demand
obtained from the networking equipment through which the
traffic flows. SDN controllers also expose northbound APIs,
which allow developers and network managers to deploy a
wide range of off-the-shelf and custom-built network
applications, many of which were not feasible before the
advent of SDN. As yet there is no standardized northbound
API nor a consensus on an open northbound API. A number of
vendors offer a REpresentational State Transfer (REST)-based
API to provide a programmable interface to their SDN
controller.
See Chapter 5, “SDN Control Plane”
Also envisioned but not yet defined are horizontal APIs
(east/westbound), which would enable communication and
cooperation among groups or federations of controllers to
synchronize state for high availability.
At the application plane are a variety of applications that
interact with SDN controllers. SDN applications are programs
that may use an abstract view of the network for their
decision-making goals. These applications convey their
network requirements and desired network behavior to the
SDN controller via a northbound API. Examples of
applications are energy-efficient networking, security
monitoring, access control, and network management.

Characteristics of Software-Defined Networking

Putting it all together, the key characteristics of SDN are as

follows:
 The control plane is separated from the data plane.
Data plane devices become simple packet-forwarding
devices (refer back to Figure 3.2).
The control plane is implemented in a centralized
controller or set of coordinated centralized controllers.
The SDN controller has a centralized view of the
network or networks under its control. The controller is
portable software that can run on commodity servers
and is capable of programming the forwarding devices
based on a centralized view of the network.
Open interfaces are defined between the devices in the
control plane (controllers) and those in the data plane.
The network is programmable by applications running
on top of the SDN controllers. The SDN controllers
present an abstract view of network resources to the
applications.

3.3 SDN- and NFV-Related Standards

Unlike some technology areas, such as Wi-Fi, there is no

single standards body responsible for developing open
standards for SDN and NFV. Rather, there is a large and
evolving collection of standards-developing organizations
(SDOs), industrial consortia, and open development
initiatives involved in creating standards and guidelines for
SDN and NFV. Table 3.1 lists the main SDOs and other
organizations involved in the effort and the main outcomes
so far produced. This section covers some of the most
prominent efforts.
 TABLE 3.1 SDN and NFV Open Standards Activities
Documents that provide requirements, specifications,
guidelines, or characteristics that can be used
consistently to ensure that materials, products,
processes, and services are fit for their purpose.
Standards are established by consensus among those
participating in a standards-making organization and are
approved by a generally recognized body.
A standard that is: developed on the basis of an open
decision-making procedure available to all interested
parties, is available for implementation to all on a
 royalty-free basis, and is intended to promote
interoperability among products from multiple vendors.

Standards-Developing Organizations

The Internet Society, ITU-T, and ETSI are all making key
contributions to the standardization of SDN and NFV.

Internet Society

A number of standards-developing organizations

(SDOs) are looking at various aspects of SDN. Perhaps the
most active are two groups within the Internet Society
(ISOC): IETF and IRTF. ISOC is the coordinating committee for
Internet design, engineering, and management. Areas
covered include the operation of the Internet itself and the
standardization of protocols used by end systems on the
Internet for interoperability. Various organizations under the
ISOC are responsible for the actual work of standards
development and publication.
An official national, regional, or international standards
body that develops standards and coordinates the
standard activities of a specific country, region or the
world. Some SDOs facilitate the development of
standards through support of technical committee
activities, and some may be directly involved in
standards development.
The Internet Engineering Task Force (IETF) has working
groups developing SDN-related specifications in the following
areas:
Interface to routing systems (I2RS): Develop
capabilities to interact with routers and routing
protocols to apply routing policies.
 Service function chaining: Develop an architecture
and capabilities for controllers to direct subsets of
traffic across the network in such a way that each
virtual service platform sees only the traffic it must
work with.
The Internet Research Task Force (IRTF) has published
Software-Defined Networking (SDN): Layers and Architecture
Terminology (RFC 7426, January 2015). The document
provides a concise reference that reflects current approaches
regarding the SDN layer architecture. The Request For
Comments (RFC) also provides a useful discussion of the
southbound API (Figure 3.3) and describes some specific
APIs, such as for I2RS.
A document in the archival series that is the official
channel for publications of the Internet Society, including
IETF and IRTF publications. An RFC may be informational,
best practice, draft standard, or an official Internet
standard.
IRTF also sponsors the Software Defined Networking
Research Group (SDNRG). This group investigates SDN from
various perspectives with the goal of identifying the
approaches that can be defined, deployed, and used in the
near term and identifying future research challenges.

ITU-T

The International Telecommunication Union—

Telecommunication Standardization Sector (ITU-T) is a UN
agency that issues standards, called recommendations, in
the telecommunications area. So far, their only published
contribution to SDN is Recommendation Y.3300 (Framework
of Software-Defined Networking, June 2014). The document
addresses definitions, objectives, high-level capabilities,
requirements, and high-level architecture of SDN. It provides
a valuable framework for standards development.
ITU-T has established a Joint Coordination Activity on
Software-Defined Networking (JCA-SDN) and begun work on
developing SDN-related standards.
Four ITU-T study groups (SGs) are involved in SDN-related
activities:
SG 13 (Future networks, including cloud
computing, mobile, and next-generation
networks): This is the lead study group of SDN in ITU-T
and developed Y.3300. This group is studying SDN and
virtualization aspects for next-generation networks
(NGNs).
SG 11 (Signaling requirements, protocols, and
test specifications): This group is studying the
framework for SDN signaling and how to apply SDN
technologies for IPv6.
SG 15 (Transport, access, and home): This group
looks at optical transport networks, access networks,
and home networks. The group is investigating
transport aspects of SDN, aligned with the Open
Network Foundation’s SDN architecture.
SG 16 (Multimedia): This group is evaluating
OpenFlow as a protocol to control multimedia packet
flows, and is studying virtual content delivery networks.

European Telecommunications Standards Institute

ETSI is recognized by the European Union as a European

Standards Organization. However, this not-for-profit SDO has
member organizations worldwide and its standards have
international impact.
ETSI has taken the lead role in defining standards for NFV.
ETSI’s Network Functions Virtualisation (NFV) Industry
Specification Group (ISG) began work in January 2013 and
produced a first set of specifications in January 2015. The 11
specifications include an NFV’s architecture, infrastructure,
service quality metrics, management and orchestration,
resiliency requirements, and security guidance.

Industry Consortia

Consortia for open standards began to appear in the late

1980s. There was a growing feeling within private-sector
multinational companies that the SDOs acted too slowly to
provide useful standards in the fast-paced world of
technology. Recently, a number of consortia have become
involved in the development of SDN and NFV standards. We
mention here three of the most significant efforts.
See Chapter 4, “SDN Data Plane and OpenFlow”
By far the most important consortium involved in SDN
standardization is the Open Networking Foundation (ONF).
ONF is an industry consortium dedicated to the promotion
and adoption of SDN through open standards development.
Its most important contribution to date is the OpenFlow
protocol and API. The OpenFlow protocol is the first standard
interface specifically designed for SDN and is already being
deployed in a variety of networks and networking products,
both hardware based and software based. The standard
enables networks to evolve by giving logically centralized
control software the power to modify the behavior of network
devices through a well-defined “forwarding instruction set.”
Chapter 4 is devoted to this protocol.
A group of independent organizations joined by common
interests. In the area of standards development, a
consortium typically consists of individual corporations
 and trade groups concerned with a specific area of
technology.
The Open Data Center Alliance (ODCA) is a consortium of
leading global IT organizations dedicated to accelerating
adoption of interoperable solutions and services for cloud
computing. Through the development of usage models for
SDN and NFV, ODCA is defining requirements for SDN and
NFV cloud deployment.
The Alliance for Telecommunications Industry Solutions
(ATIS) is a membership organization that provides the tools
necessary for the industry to identify standards, guidelines,
and operating procedures that make the interoperability of
existing and emerging telecommunications products and
services possible. Although ATIS is accredited by ANSI, it is
best viewed as a consortium rather than an SDO. So far, ATIS
has issued a document that identifies operational issues and
opportunities associated with increasing programmability of
the infrastructure using SDN and NFV.

Open Development Initiatives

There are a number of other organizations that are not

specifically created by industry members and are not official
bodies such as SDOs. Generally, these organizations are user
created and driven and have a particular focus, always with
the goal of developing open standards or open source
software. A number of such groups have become active in
SDN and NFV standardization. This section lists three of the
most significant efforts.

OpenDaylight

OpenDaylight is an open source software activity under the

auspices of the Linux foundation. Its member companies
provide resources to develop an SDN controller for a wide
range of applications. Although the core membership
consists of companies, individual developers and users can
also participate, so OpenDaylight is more in the nature of an
open development initiative than a consortium. ODL also
supports network programmability via southbound protocols,
a bunch of programmable network services, a collection of
northbound APIs, and a set of applications.
See Section 5.3, “Open-Daylight”
OpenDaylight is composed of about 30 projects, and releases
their outputs in simultaneous manner. After its first release,
Hydrogen, in February 2014, it successfully delivered the
second one, Helium, at the end of September 2014.

Open Platform for NFV

Open Platform for NFV is an open source project dedicated to

acceleration the adoption of standardized NFV elements.
OPNFV will establish a carrier-grade, integrated, open source
reference platform that industry peers will build together to
advance the evolution of NFV and to ensure consistency,
performance, and interoperability among multiple open
source components. Because multiple open source NFV
building blocks already exist, OPNFV will work with upstream
projects to coordinate continuous integration and testing
while filling development gaps.
See Section 7.4, “NFV Benefits and Requirements”

OpenStack

OpenStack is an open source software project that aims to

produce an open source cloud operating system. It provides
multitenant Infrastructure as a Service (IaaS), and aims to
meets the needs of public and private clouds regardless of
size, by being simple to implement and massively scalable.
SDN technology is expected to contribute to its networking
part, and to make the cloud operating system more efficient,
flexible, and reliable.
OpenStack is composed of a number of projects. One of
them, Neutron, is dedicated for networking. It provides
Network as a Service (NaaS) to other OpenStack services.
Almost all SDN controllers have provided plug-ins for
Neutron, and through them services on OpenStack and other
OpenStack services can build rich networking topologies and
can configure advanced network policies in the cloud.

3.4 Key Terms

After completing this chapter, you should be able to define

the following terms.
application programming interface (API)
consortium
datagram
flow
IEEE 802
northbound API
open standard
packet switching
REpresentational State Transfer (REST)
Request For Comments (RFC)
service function chaining
southbound API
 standard
standards-developing organization (SDO)
TCP/IP protocol architecture

3.5 References

ODCA14: Open Data Center Alliance. Open Data Center

Alliance Master Usage Model: Software-Defined
Networking Rev. 2.0. White Paper. 2014.
ONF12: Open Networking Foundation. Software-Defined
Networking: The New Norm for Networks. ONF White
Paper, April 13, 2012.
Chapter 4. SDN Data Plane and
OpenFlow

“I tell you,” went on Syme with passion, “that every time

a train comes in I feel that it has broken past batteries of
besiegers, and that man has won a battle against chaos.
You say contemptuously that when one has left Sloane
Square one must come to Victoria. I say that one might
do a thousand things instead, and that whenever I really
come there I have the sense of hairbreadth escape. And
when I hear the guard shout out the word ‘Victoria’, it is
not an unmeaning word. It is to me the cry of a herald
announcing conquest. It is to me indeed ‘Victoria’; it is
the victory of Adam.”

—The Man Who Was Thursday, G. K. Chesterton

Chapter Objectives: After studying this chapter,
you should be able to
Present an overview of the functions of the SDN
data plane.
Understand the concept of an OpenFlow logical
network device.
Describe and explain the OpenFlow flow table entry
structure.
Summarize the operation of the OpenFlow pipeline.
Explain the operation of the group table.
Understand the basic elements of the OpenFlow
protocol.
Section 4.1 of this chapter begins the detailed study of
software-defined networking (SDN) with a discussion of the
data plane (Figure 4.1). The remainder of the chapter is
devoted to OpenFlow, the most widely used implementation
of the SDN data plane. OpenFlow is both a specification of
the logical structure of data plane functionality and a
protocol between SDN controllers and network devices.
Sections 4.2 and 4.3, respectively, examine the OpenFlow
logical network device and the OpenFlow protocol in more
detail.
 FIGURE 4.1 SDN Architecture

4.1 SDN Data Plane

The SDN data plane, referred to as the resource layer in ITU-

T Y.3300 and also often referred to as the infrastructure
layer, is where network forwarding devices perform the
transport and processing of data according to decisions
made by the SDN control plane. The important characteristic
of the network devices in an SDN network is that these
devices perform a simple forwarding function, without
embedded software to make autonomous decisions.

Data Plane Functions

Figure 4.2 illustrates the functions performed by the data

plane network devices (also called data plane network
elements or switches). The principal functions of the network
device are the following:
 FIGURE 4.2 Data Plane Network Device
Control support function: Interacts with the SDN
control layer to support programmability via resource-
control interfaces. The switch communicates with the
controller and the controller manages the switch via the
OpenFlow switch protocol.
Data forwarding function: Accepts incoming data
flows from other network devices and end systems and
forwards them along the data forwarding paths that
have been computed and established according to the
rules defined by the SDN applications.
These forwarding rules used by the network device are
embodied in forwarding tables that indicate for given
categories of packets what the next hop in the route should
be. In addition to simple forwarding of a packet, the network
device can alter the packet header before forwarding, or
discard the packet. As shown, arriving packets may be
placed in an input queue, awaiting processing by the
network device, and forwarded packets are generally placed
in an output queue, awaiting transmission.
The network device in Figure 4.2 is shown with three I/O
ports: one providing control communication with an SDN
controller, and two for the input and output of data packets.
This is a simple example. The network device may have
multiple ports to communicate with multiple SDN controllers,
and may have more than two I/O ports for packet flows into
and out of the device.

Data Plane Protocols

Figure 4.2 suggests the protocols supported by the network

device. Data packet flows consist of streams of IP packets. It
may be necessary for the forwarding table to define entries
based on fields in upper-level protocol headers, such as TCP,
UDP, or some other transport or application protocol. The
network device examines the IP header and possibly other
headers in each packet and makes a forwarding decision.
The other important flow of traffic is via the southbound
application programming interface (API), consisting of
OpenFlow protocol data units (PDUs) or some similar
southbound API protocol traffic.

4.2 OpenFlow Logical Network Device

To turn the concept of SDN into practical implementation,

two requirements must be met:
There must be a common logical architecture in all
switches, routers, and other network devices to be
managed by an SDN controller. This logical architecture
may be implemented in different ways on different
vendor equipment and in different types of network
 devices, as long as the SDN controller sees a uniform
logical switch functionality.
A standard, secure protocol is needed between the SDN
controller and the network device.
These requirements are addressed by OpenFlow, which is
both a protocol between SDN controllers and network
devices and a specification of the logical structure of the
network switch functionality. OpenFlow is defined in the
OpenFlow Switch Specification, published by the Open
Networking Foundation (ONF).

Open Network Foundation OpenFlow Definition

This section covers the logical switch architecture defined by

OpenFlow. Our discussion is based on the OpenFlow
specification current at the time of this writing: Version 1.5.1,
March 26, 2015.
Figure 4.3 indicates the main elements of an OpenFlow
environment, consisting of SDN controllers that include
OpenFlow software, OpenFlow switches, and end systems.
 FIGURE 4.3 OpenFlow Switch Context
Figure 4.4 displays the main components of an OpenFlow
switch. An SDN controller communicates with OpenFlow-
compatible switches using the OpenFlow protocol running
over Transport Layer Security (TLS). Each switch connects to
other OpenFlow switches and, possibly, to end-user
devices that are the sources and destinations of packet
flows. On the switch side, the interface is known as an
OpenFlow channel. These connections are via OpenFlow
ports. An OpenFlow port also connects the switch to the
SDN controller. OpenFlow defines three types of ports:
 FIGURE 4.4 OpenFlow Switch
Physical port: Corresponds to a hardware interface of
the switch. For example, on an Ethernet switch,
physical ports map one to one to the Ethernet
interfaces.
Logical port: Does not correspond directly to a
hardware interface of the switch. Logical ports are
higher-level abstractions that may be defined in the
switch using non-OpenFlow methods (for example, link
aggregation groups, tunnels, loopback interfaces).
Logical ports may include packet encapsulation and
may map to various physical ports. The processing
done by the logical port is implementation dependent
and must be transparent to OpenFlow processing, and
those ports must interact with OpenFlow processing like
OpenFlow physical ports.
Reserved port: Defined by the OpenFlow
specification. It specifies generic forwarding actions
such as sending to and receiving from the controller,
 flooding, or forwarding using non-OpenFlow methods,
such as “normal” switch processing.
Within each switch, a series of tables is used to manage the
flows of packets through the switch.
The OpenFlow specification defines three types of tables in
the logical switch architecture. A flow table matches
incoming packets to a particular flow and specifies what
functions are to be performed on the packets. There may be
multiple flow tables that operate in a pipeline fashion, as
explained subsequently. A flow table may direct a flow to a
group table, which may trigger a variety of actions that
affect one or more flows. A meter table can trigger a
variety of performance-related actions on a flow. Meter
tables are discussed in Chapter 10. Using the OpenFlow
switch protocol, the controller can add, update, and delete
flow entries in tables, both reactively (in response to
packets) and proactively.
See Chapter 10, “Quality of Service”
Before proceeding, it is helpful to define what is meant by
the term flow. Curiously, this term is not defined in the
OpenFlow specification, nor is there an attempt to define it in
virtually all of the literature on OpenFlow. In general terms, a
flow is a sequence of packets traversing a network that share
a set of header field values. For example, a flow could
consist of all packets with the same source and destination IP
addresses or all packets with the same virtual LAN (VLAN)
identifier. The sections that follow provide a more specific
definition of this concept.

Flow Table Structure

The basic building block of the logical switch architecture is

the flow table. Each packet that enters a switch passes
through one of more flow tables. Each flow table consists of
a number of rows, called entries, consisting of seven
components (see part a of Figure 4.5), as defined in the list
that follows.

FIGURE 4.5 OpenFlow Table Entry Formats

Match fields: Used to select packets that match the
values in the fields.
Priority: Relative priority of table entries. This is a 16-
bit field with 0 corresponding to the lowest priority. In
principle, there could be 216 = 64k priority levels.
Counters: Updated for matching packets. The
OpenFlow specification defines a variety of counters.
Table 4.1 lists the counters that must be supported by
an OpenFlow switch.
 TABLE 4.1 Required OpenFlow Counters

Instructions: Instructions to be performed if a match

occurs.
Timeouts: Maximum amount of idle time before a flow
is expired by the switch. Each flow entry has an
idle_timeout and a hard_timeout associated with it. A
nonzero hard_timeout field causes the flow entry to be
removed after the given number of seconds, regardless
of how many packets it has matched. A nonzero
idle_timeout field causes the flow entry to be removed
when it has matched no packets in the given number of
seconds.
Cookie: 64-bit opaque data value chosen by the
controller. May be used by the controller to filter flow
statistics, flow modification and flow deletion; 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.

Match Fields Component

The match fields component of a table entry consists of the
following required fields (see part b of Figure 4.5):
Ingress port: The identifier of the port on this switch
on which the packet arrived. This may be a physical
port or a switch-defined virtual port. Required in ingress
tables.
Egress port: The identifier of the egress port from
action set. Required in egress tables.
Ethernet source and destination addresses: Each
entry can be an exact address, a bitmasked value for
which only some of the address bits are checked, or a
wildcard value (match any value).
Ethernet type field: Indicates type of the Ethernet
packet payload.
IP: Version 4 or 6.
IPv4 or IPv6 source address, and destination
address: Each entry can be an exact address, a
bitmasked value, a subnet mask value, or a wildcard
value.
TCP source and destination ports: Exact match or
wildcard value.
UDP source and destination ports: Exact match or
wildcard value.
The preceding match fields must be supported by any
OpenFlow-compliant switch. The following fields may be
optionally supported.
Physical port: Used to designate underlying physical
port when packet is received on a logical port.
Metadata: Additional information that can be passed
from one table to another during the processing of a
packet. Its use is discussed subsequently.
VLAN ID and VLAN user priority: Fields in the IEEE
802.1Q virtual LAN header. SDN support for VLANs is
discussed in Chapter 8, “NFV Functionality.”
IPv4 or IPv6 DS and ECN: Differentiated Services and
Explicit Congestion Notification fields.
SCTP source and destination ports: Exact match or
wildcard value for Stream Transmission Control
Protocol.
ICMP type and code fields: Exact match or wildcard
value.
ARP opcode: Exact match in Ethernet Type field.
Source and target IPv4 addresses in ARP
payload: Can be an exact address, a bitmasked value,
a subnet mask value, or a wildcard value.
IPv6 flow label: Exact match or wildcard.
ICMPv6 type and code fields: Exact match or
wildcard value.
IPv6 neighbor discovery target address: In an IPv6
Neighbor Discovery message.
IPv6 neighbor discovery source and target
addresses: Link-layer address options in an IPv6
Neighbor Discovery message.
MPLS label value, traffic class, and BoS: Fields in
the top label of an MPLS label stack.
Provider bridge traffic ISID: Service instance
identifier.
Tunnel ID: Metadata associated with a logical port.
TCP flags: Flag bits in the TCP header. May be used to
detect start and end of TCP connections.
IPv6 extension: Extension header.
Thus, OpenFlow can be used with network traffic involving a
variety of protocols and network services. Note that at the
MAC/link layer, only Ethernet is supported. Therefore,
OpenFlow as currently defined cannot control Layer 2 traffic
over wireless networks.
Each of the fields in the match fields component either has a
specific value or a wildcard value, which matches any value
in the corresponding packet header field. A flow table may
include a table-miss flow entry, which wildcards all match
fields (every field is a match regardless of value) and has the
lowest priority.
We can now offer a more precise definition of the term flow.
From the point of view of an individual switch, a flow is a
sequence of packets that matches a specific entry in a flow
table. The definition is packet oriented, in the sense that it is
a function of the values of header fields of the packets that
constitute the flow, and not a function of the path they follow
through the network. A combination of flow entries on
multiple switches defines a flow that is bound to a specific
path.

Instructions Component

The instructions component of a table entry consists of a set

of instructions that are executed if the packet matches the
entry. Before describing the types of instructions, we need to
define the terms action and action set. Actions describe
packet forwarding, packet modification, and group table
processing operations. The OpenFlow specification includes
the following actions:
Output: Forward packet to specified port. The port
could be an output port to another switch or the port to
the controller. In the latter case, the packet is
encapsulated in a message to the controller.
 Set-Queue: Sets the queue ID for a packet. When the
packet is forwarded to a port using the output action,
the queue ID determines which queue attached to this
port is used for scheduling and forwarding the packet.
Forwarding behavior is dictated by the configuration of
the queue and is used to provide basic QoS support.
SDN support for QoS is discussed in Chapter 10.
Group: Process packet through specified group.
Push-Tag/Pop-Tag: Push or pop a tag field for a VLAN
or Multiprotocol Label Switching (MPLS) packet.
Set-Field: The various Set-Field actions are identified
by their field type and modify the values of respective
header fields in the packet.
Change-TTL: The various Change-TTL actions modify
the values of the IPv4 TTL (time to live), IPv6 hop limit,
or MPLS TTL in the packet.
Drop: There is no explicit action to represent drops.
Instead, packets whose action sets have no output
action should be dropped.
An action set is a list of actions associated with a packet that
are accumulated while the packet is processed by each table
and that are executed when the packet exits the processing
pipeline.
The types of instructions can be grouped into four
categories:
Direct packet through pipeline: The Goto-Table
instruction directs the packet to a table farther along in
the pipeline. The Meter instruction directs the packet to
a specified meter.
Perform action on packet: Actions may be
performed on the packet when it is matched to a table
entry. The Apply-Actions instruction applies the