HAL Id: hal-00825087
https://hal.inria.fr/hal-00825087v2
Submitted on 17 Jun 2013 (v2), last revised 19 Jan 2014 (v5)
HAL is a multi-disciplinary open access
archive for the deposit and dissemination of sci-
entic research documents, whether they are pub-
lished or not. The documents may come from
teaching and research institutions in France or
abroad, or from public or private research centers.
L’archive ouverte pluridisciplinaire HAL, est
destinée au dépôt et à la diusion de documents
scientiques de niveau recherche, publiés ou non,
émanant des établissements d’enseignement et de
recherche français ou étrangers, des laboratoires
publics ou privés.
A Survey of Software-Dened Networking: Past,
Present, and Future of Programmable Networks
Marc Mendonça, Bruno Nunes Astuto, Xuan Nam Nguyen, Katia Obraczka,
Thierry Turletti
To cite this version:
Marc Mendonça, Bruno Nunes Astuto, Xuan Nam Nguyen, Katia Obraczka, Thierry Turletti. A
Survey of Software-Dened Networking: Past, Present, and Future of Programmable Networks. 2013.
�hal-00825087v2�
IN SUBMISSION 1
A Survey of Software-Defined Networking: Past,
Present, and Future of Programmable Networks
Marc Mendonca, Bruno Astuto A. Nunes, Xuan-Nam Nguyen, Katia Obraczka, and Thierry Turletti
Abstract—The idea of programmable networks has recently re-
gained considerable momentum due to the emergence of the
Software-Defined Networking (SDN) paradigm. SDN, often re-
ferred to as a “radical new idea in networking”, promises to dra-
matically simplify network management and enable innovation
through network programmability. This paper surveys the state-
of-the-art in programmable networks with an emphasis on SDN.
We provide a historic perspective of programmable networks
from early ideas to recent developments. Then we present the
SDN architecture and the OpenFlow standard in particular,
discuss current alternatives for implementation and testing SDN-
based protocols and services, examine current and future SDN
applications, and explore promising research directions based on
the SDN paradigm.
Index Terms—Software-Defined Networking, programmable
networks, survey, data plane, control plane, virtualization.
I. INTRODUCTION
C
OMPUTER networks are typically built from a large
number of network devices such as routers, switches and
numerous types of middleboxes with many complex protocols
implemented on them. Network operators are responsible for
configuring policies to respond to a wide range of network
events and applications. They have to manually transform
these high level-policies into low-level configuration com-
mands while adapting to changing network conditions. And
often they need to accomplish these very complex tasks with
access to very limited tools. As a result, network management
and performance tuning is quite challenging and thus error-
prone. The fact that network devices are usually vertically-
integrated black boxes exacerbates the challenge network
operators and administrators face.
Another almost unsurmountable challenge network practi-
tioners and researchers face has been referred to as ”Internet
ossification”. Because of its huge deployment base and the
fact it is considered part of our society’s critical infrastructure
(just like transportation and power grids), the Internet has
become extremely difficult to evolve both in terms of its phys-
ical infrastructure as well as its protocols and performance.
However, as current and emerging Internet applications and
services become increasingly more complex and demanding,
it is imperative that the Internet be able to evolve to address
these new challenges.
The idea of “programmable networks” has been proposed as
a way to facilitate network evolution. In particular, Software
Bruno Astuto A. Nunes, Xuan-Nam Nguyen and Thierry Turletti
are with INRIA, France, {bruno.astuto-arouche-nunes, xuan-nam.nguyen,
thierry.turletti}@inria.fr
Marc Mendonca and Katia Obraczka are with UC Santa Cruz, {msm,
katia}@soe.ucsc.edu
Defined Networking (SDN) is a new networking paradigm
in which the forwarding hardware is decoupled from con-
trol decisions. It promises to dramatically simplify network
management and enable innovation and evolution. The main
idea is to allow software developers to rely on network
resources in the same easy manner as they do on storage
and computing resources. In SDN, the network intelligence
is logically centralized in software-based controllers (at the
control plane), and network devices become simple packet
forwarding devices (the data plane) that can be programmed
via an open interface (e.g., ForCES [40], OpenFlow [71], etc).
SDN is currently attracting significant attention from both
academia and industry. A group of network operators, ser-
vice providers, and vendors have recently created the Open
Network Foundation [13], an industrial-driven organization,
to promote SDN and standardize the OpenFlow protocol [71].
On the academic side, the OpenFlow Network Research Cen-
ter [14] has been created with a focus on SDN research. There
have also been standardization efforts on SDN at the IETF and
IRTF.
The field of software defined networking is quite recent, yet
growing at a very fast pace. Still, there are important research
challenges to be addressed. In this paper, we survey the state-
of-the-art in programmable networks by providing a historic
perspective of the field and also describing in detail the SDN
paradigm and architecture. The paper is organized as follows:
in Section II, it begins by describing early efforts focusing
on programmable networks. Section III provides an overview
of SDN and its architecture. It also describes the OpenFlow
protocol. In Section V, we discuss several SDN applications in
areas such as data centers and wireless networking. Section IV
describes existing platforms for developing and testing SDN
solutions including emulation and simulation tools, SDN con-
troller implementations, as well as verification and debugging
tools. Finally, Section VI discusses future research directions
related to SDN.
II. EARLY PROGRAMMABLE NETWORKS
SDN has great potential to change the way networks oper-
ate, and OpenFlow in particular has been touted as a “radical
new idea in networking” [67]. The proposed benefits range
from centralized control, simplified algorithms, commoditizing
network hardware, eliminating middleboxes, to enabling the
design and deployment of third-party ‘apps’.
While OpenFlow has received a considerable amount of
industry attention, it is worth noting that the idea of pro-
grammable networks and decoupled control logic has been
IN SUBMISSION 2
around for many years. In this section, we provide an overview
of early programmable networking efforts, precursors to the
current SDN paradigm that laid the foundation for many of
the ideas we are seeing today.
a) Open Signaling: The Open Signaling (OPENSIG)
working group began in 1995 with a series of workshops
dedicated to “making ATM, Internet and mobile networks
more open, extensible, and programmable” [32]. They believed
that a separation between the communication hardware and
control software was necessary but challenging to realize; this
is mainly due to vertically integrated switches and routers,
whose closed nature made the rapid deployment of new
network services and environments impossible. The core of
their proposal was to provide access to the network hardware
via open, programmable network interfaces; this would allow
the deployment of new services through a distributed program-
ming environment.
Motivated by these ideas, an IETF working group was
created, which led to the General Switch Management Protocol
(GSMP) [39], a general purpose protocol to control a label
switch. GSMP allows a controller to establish and release con-
nections across the switch, add and delete leaves on a multicast
connection, manage switch ports, request configuration infor-
mation, request and delete reservation of switch resources, and
request statistics.” The working group is officially concluded
and the latest standards proposal, GSMPv3, was published in
June 2002.
b) Active Networking: Also in the mid 1990s, the
Active Networking [95], [96] initiative proposed the idea
of a network infrastructure that would be programmable for
customized services. There were two main approaches being
considered, namely: (1) user-programmable switches, with in-
band data transfer and out-of-band management channels;
and (2) capsules, which were program fragments that could
be carried in user messages; program fragments would then
be interpreted and executed by routers. Despite considerable
activity it motivated, Active Networking never gathered crit-
ical mass and transferred to widespread use and industry
deployment, mainly due to practical security and performance
concerns [76].
c) DCAN: Another initiative that took place in the mid
1990s is the Devolved Control of ATM Networks (DCAN) [4].
The aim of this project was to design and develop the
necessary infrastructure for scalable control and management
of ATM networks. The premise is that control and management
functions of the many devices (ATM switches in the case
of DCAN) should be decoupled from the devices themselves
and delegated to external entities dedicated to that purpose,
which is basically the concept behind SDNs. DCAN assumes
a minimalist protocol between the manager and the network,
in the lines of what happens today in proposals such as
OpenFlow. More on the DCAN project can be found at [73].
Still in the lines of SDNs and the proposed decoupling of
control and data plane over ATM networks, amongst others,
in the work proposed in [99] multiple heterogeneous control
architectures are allowed to run simultaneously over single
physical ATM network by partitioning the resources of that
switch between those controllers.
d) 4D Project: Starting in 2004, the 4D project [87],
[48], [29] advocated a clean slate design that emphasized
separation between the routing decision logic and the pro-
tocols governing the interaction between network elements.
It proposed giving the “decision” plane a global view of the
network, serviced by a “dissemination” and “discovery” plane,
for control of a “data” plane for forwarding traffic. These ideas
provided direct inspiration for later works such as NOX [49],
which proposed an “operating system for networks” in the
context of an OpenFlow-enabled network.
e) NETCONF: In 2006, the IETF Network Configu-
ration Working Group proposed NETCONF [42] as a man-
agement protocol for modifying the configuration of network
devices. The protocol allowed network devices to expose an
API through which extensible configuration data could be sent
and retrieved. Although the protocol accomplishes the goal
of simplifying device (re)configuration and acts as a building
block, there is no separation of the data and control plane.
A network with NETCONF should not be regarded as fully
programmable as any new functionality would have to be
implemented at both the network device and the manager for
management to take place; furthermore, it is designed primar-
ily to aid automated configuration and not for enabling direct
control of state data. Nevertheless, it is a useful management
tool that may be used in parallel on hybrid switches supporting
other solutions that enable programmable networking.
The working group is currently active and the latest pro-
posed standard was published in June 2011.
f) Ethane: The immediate predecessor to OpenFlow was
the SANE / Ethane project [34], which, in 2006, defined a new
network architecture for enterprise networks. Ethane’s focus
was on using a centralized controller to manage policy and
security in a network. A notable example is providing identity-
based access control. Similarly to SDN, Ethane employed
two components: a controller to decide if a packet should
be forwarded, and an Ethane switch consisting of a flow table
and a secure channel to the controller.
Ethane laid the foundation for what would become
Software-Defined Networking. To put Ethane in the context of
today’s SDN paradigm, Ethane’s identity-based access control
would likely be implemented as an application on top of a
SDN controller such as NOX [49], Maestro [30], Beacon [1],
SNAC [20], Helios [6], etc.
III. SOFTWARE-DEFINED NETWORKING
ARCHITECTURE
Data communication networks typically consist of end-
user devices, or hosts interconnected by the network infras-
tructure. This infrastructure is shared by hosts and employs
switching elements such as routers and switches as well as
communication links to carry data between hosts. Routers and
switches are usually “closed” systems, often with limited-
and vendor-specific control interfaces. Therefore, once de-
ployed and in production, it is quite difficult for current
network infrastructure to evolve; in other words, deploying
new versions of existing protocols (e.g., IPv6), not to mention
deploying completely new protocols and services is an almost
IN SUBMISSION 3
Software
Control
Traditional Network
(with distributed control and middleboxes)
Software-Defined Network
(with decoupled control)
Fig. 1. The SDN architecture decouples control logic from the forwarding
hardware, and enables the consolidation of middleboxes, simpler policy
management, and new functionalities.
insurmountable obstacle in current networks. The Internet,
being a network of networks, is no exception.
As mentioned previously, the so-called Internet “ossifica-
tion” [71] is largely attributed to the tight coupling between
the data– and control planes which means that decisions about
data flowing through the network are made on-board each
network element. In this type of environment, the deployment
of new network applications or functionality is decidedly non-
trivial, as they would need to be implemented directly into
the infrastructure. Alternatively, workarounds such as using
“middleboxes” (e.g., firewalls, Intrusion Detection Systems,
Network Address Translators, etc.) overlayed atop the under-
lying network infrastructure have been proposed and deployed
as a way to circumvent the network ossification effect. Content
Delivery Networks (CDNs) [82] are a good example. Fur-
thermore, even straightforward tasks such as configuration or
policy enforcement may require a good amount of effort due to
the lack of a common control interface to the various network
devices.
Software-Defined Networking was developed to facilitate
innovation and enable simple programmatic control of the
network data-path. As visualized in Figure 1, the separation of
the forwarding hardware from the control logic allows easier
deployment of new protocols and applications, straightforward
network visualization and management, and consolidation of
various middleboxes into software control. Instead of enforc-
ing policies and running protocols on a convolution of scat-
tered devices, the network is reduced to “simple” forwarding
hardware and the decision-making network controller(s). The
forwarding hardware consists of (1) a flow table containing
an entry and an action to take on active flows; and (2) an
abstraction layer that securely communicates with a controller
about new entries that are not currently on the flow table.
A. Current SDN Architectures
In this section, we review two well-known SDN systems,
namely ForCES [40] and Openflow [71]. Both OpenFlow and
ForCES follow the basic SDN principle of separation between
control– and data–planes; and both standardize information
exchange between planes. However, they are technically very
different in terms of design, architecture, forwarding model,
and protocol interface.
g) ForCES: According to the approach proposed by the
IETF ForCES (Forwarding and Control Element Seperaration)
Working Group [40], the network device’s internal architecture
is redefined having the control element separated from the
forwarding element. However, the network device is still
represented as a single entity. The driving use case provided
by the working group considers the desire to combine new
forwarding hardware with third-party control within a single
network device. Thus, the control– and data planes are kept
within close proximity (e.g., same box or room). In contrast,
the control plane is ripped entirely from the network device
in ”OpenFlow-like” SDN systems.
ForCES defines a logic entity called the Forwarding Element
(FE), that implements the ForCES protocol, i.e. the commu-
nication protocol between FEs and CEs, and is responsible
for using the underlying hardware to provide per-packet han-
dling. Another logic entity defined in ForCES is the Control
Element (CE), that executes control and signaling functions
and employs the ForCES protocol to instruct FEs on how to
handle packets. The protocol works based on a master-slave
model, where FEs are slaves and CEs are masters.
An important building block of the ForCES architecture is
the LFB (Logical Function Block). The LFB is a well-defined
functional block residing on the FEs that is controlled by CEs
via the ForCES protocol. The LFB enables the CEs to control
the FEs’ configuration; the LFB may reside on the FE’s data
plane and is used to process packets.
ForCES has been undergoing standardization since 2003,
and the working group has published a variety of documents
including an applicability statement, an architectural frame-
work defining the entities and their interactions, a modeling
language defining the logical functions within a forwarding
element, and a protocol for communication between the con-
trol and forwarding elements within a network element. The
working group is currently active.
h) OpenFlow: Driven by the SDN principle of decou-
pling the control– and data forwarding planes, OpenFlow [71],
like ForCES, standardizes information exchange between the
two planes.
In the OpenFlow architecture, the forwarding device, or
OpenFlow switch, contains one or more flow tables. Flow
tables consist of flow entries, each of which determines how
packets belonging to a flow will be processed and forwarded.
Flow entries typically consist of: (1) match fields used to match
incoming packets; match fields may contain information found
in the packet header, ingress port, and metadata; (2) counters,
used to collect statistics for the particular flow, such as number
of received packets, number of bytes and duration of the flow;
and (3) a set of instructions, or actions, to be applied upon a
match; they dictate how to handle matching packets.
Upon a packet arrival at the OpenFlow switch, packet header
fields are extracted and matched against the matching fields
portion of the flow table entries. This matching starts at the first
flow table and may continue through subsequent flow tables.
If a matching entry is found, the switch applies the appropriate
set of instructions associated with the matched flow entry. If
the flow table look-up procedure does not result on a match,
the action taken by the switch will depend on the instructions
IN SUBMISSION 4
defined by the table-miss flow entry. Every flow table must
contain a table-miss entry in order to handle table misses.
This particular entry specifies a set of actions to be performed
when no match is found for an incoming packet. These actions
include dropping the packet, continue the matching process
on the next flow table, or forward the packet to the controller
over the OpenFlow channel. Another possibility, in the case
of hybrid switches, i.e., switches that have both OpenFlow–
and non-OpenFlow ports, is to forward non-matching packets
using regular IP forwarding.
The communication between controller and switch happens
via OpenFlow protocol, which defines a set of messages that
can be exchanged between these entities over a secure channel.
Using the OpenFlow protocol a remote controller can, for
example, add, update, or delete flow entries from the switch’s
flow tables. That can happen reactively (in response to a packet
arrival) or proactively.
1) Discussion: In [106], the similarities and differences
between ForCES and OpenFlow are discussed. Among the
differences, they highlight the fact that the forwarding model
used by ForCES relies on the Logical Function Blocks (LFBs),
while OpenFlow uses flow tables. Actions associated with a
flow can be combined to provide greater control and flexibility
for the purposes of network management, administration, and
development. In ForCES the combination of different LFBs
can also be used to achieve the same goal.
We should also re-iterate that ForCES does not follow the
same SDN model underpinning OpenFlow, but can be used
to achieve the same goals and implement similar functional-
ity [106].
The strong support from industry, research, and academia
that the Open Networking Foundation (ONF) and its SDN
proposal, OpenFlow, has been able to gather is quite impres-
sive. The resulting critical mass from these different sectors
has produced a significant number of deliverables in the form
of research papers, reference software implementations, and
even hardware. So much so that some argue that OpenFlow’s
SDN architecture is the current SDN de-facto standard. In
line with this trend, the remainder of this section focuses on
OpenFlow’s SDN model. More specifically, we will describe
the different components of the SDN architecture, namely:
the switch, the controller, and the interfaces present on the
controller for communication with forwarding devices (south-
bound communication) and network applications (northbound
communication). Section IV also has an OpenFlow focus as it
describes existing platforms for SDN development and testing,
including emulation and simulation tools, SDN controller im-
plementations, as well as verification and debugging tools. Our
discussion of future SDN applications and research directions
is more general and is SDN architecture agnostic.
B. Forwarding Devices
Forwarding devices such as switches and routers in a
software-defined network are often represented as basic for-
warding hardware accessible via an open interface, as the
control logic and algorithms are off-loaded to a controller.
In an OpenFlow network, switches come in two vari-
eties: pure and hybrid. Pure OpenFlow switches have no
legacy features or on-board control, and completely rely on a
controller for forwarding decisions. Hybrid switches support
OpenFlow in addition to traditional operation and protocols.
Most commercial switches available today are hybrids.
Though at first glance this would appear to simplify the
switching hardware, flow-based SDN architectures such as
OpenFlow may utilize additional forwarding table entries,
buffer space, and statistical counters that are difficult to imple-
ment in traditional ASIC switches. Some recent proposals [68],
[74] have advocated adding a general-purpose CPU, either on-
switch or nearby, that may be used to supplement or take
over certain functions and reduce the complexity of the ASIC
design. This would have the added benefit of allowing greater
flexibility for on-switch processing as some aspects would be
software-defined.
In some earlier work [69], authors apply network processor
based acceleration cards to perform OpenFlow switching.
They propose and describe the design options and report re-
sults that show a 20% reduction on packet delay. Also, in [94],
an architectural design to improve look-up performance of
OpenFlow switching in Linux is proposed. Preliminary results
reported show a packet switching throughput increase up to
25% compared to the throughput of regular software-based
OpenFlow switching. Another study on dataplane performance
over Linux based Openflow switching is presented in [25].
In the paper, authors compare OpenFlow switching, layer-
2 Ethernet switching and layer-3 IP routing performance.
Fairness, forwarding throughput and packet latency in diverse
load conditions are analyzed. In [58], authors derive a basic
model for the forwarding speed and blocking probability of
an OpenFlow switch, where the parameters for the model
are drawn from measurements of switching times of current
OpenFlow hardware, combined with an OpenFlow controller.
Simulation validation of the proposed model is presented.
C. The Controller
The decoupled system has been compared to an operating
system [49], in which the controller provides a programmatic
interface to the network, where applications can be written
to perform management tasks and offer new functionalities. A
layered view of this model is illustrated in Figure 2. This view
assumes the control is centralized and applications are written
as if the network is a single system. While this simplifies
policy enforcement and management tasks, the bindings must
be closely maintained between the control and the network
forwarding elements.
1) Control models: An initial concern that arises when
offloading control from the switching hardware is the scal-
ability and performance of the network controller(s). The
original Ethane [34] controller, hosted on a commodity desk-
top machine, was tested to handle up to 11,000 new flow
requests per second and responded within 1.5 milliseconds.
A more recent study [98] of several OpenFlow controller
implementations (NOX-MT, Maestro, Beacon), conducted on
a larger emulated network with 100,000 endpoints and up
to 256 switches, found that all were able to handle at least
50,000 new flow requests per second in each of the tested