A Survey and A Layered Taxonomy of Software-Defined Networking
A Survey and A Layered Taxonomy of Software-Defined Networking
A Survey and A Layered Taxonomy of Software-Defined Networking
fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
I. Introduction
For a long time, networking technologies have evolved
at a lower pace compared to other communication technologies. Network equipments such as switches and routers
have been traditionally developed by manufacturers. Each
vendor designs his own firmware and other software to
operate their own hardware in a proprietary and closed
way. This slowed the progress of innovations in networking
technologies and caused an increase in management and
operation costs whenever new services, technologies or
hardware were to be deployed within existing networks.
The architecture of todays networks consists of three core
logical planes: Control plane, data plane, and management
plane. So far, networks hardware have been developed with
tightly coupled control and data planes. Thus, traditional
networks are known to be inside the box paradigm.
This significantly increases the complexity and cost of
Yosr Jarraya (Corresponding author), Taous Madi, and Mourad
Debbabi are with the Concordia Institute for Information Systems Engineering (CIISE), Concordia University, Montreal, Quebec,
Canada. e-mail: {y [email protected]}.
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
fields matching [19]. These restrictions impose significant limitations on the range of applications supported
by programmable controllers [19]. Furthermore, most of
the aforementioned proposals failed to face backwards
compatibility challenges and constraints, which inhibited
immediate deployment.
To broaden the vision of control and data plane separation, researchers explored clean-slate architectures for
logically centralized control such as 4D [6], SANE [8],
Ethane [9]. Clean Slate 4D project [6] was one of the first
advocating the redesign of control and management functions from the ground up based on sound principles. SANE
[8] is a single protection layer consisting of a logically
centralized server that enforces several security policies
(access control, firewall, network address translation, etc.)
within the enterprise network. And more recently, Ethane
[9] is an extension of SANE that is based on the principle of
incremental deployment in enterprise networks. In Ethane,
two components can be distinguished; The first component
is a controller that knows the global network topology and
contains the global network policy used to determine the
fate of all packets. It also performs route computation for
the permitted flows. The second component is a set of
simple and dump Ethane switches. These switches consist
of a simple flow table and use a secure channel to communicate with the controller for exchanging information
and receiving forwarding rules. This principle of packet
processing constitutes the basis of SDNs proposal.
The success and fast progress of SDN are widely due to
the success of OpenFlow and the new vision of a network
operating system. Unlike previous proposals, OpenFlow
specification relies on backwards compatibility with hardware capabilities of commodity switches. Thus, enabling
OpenFlows initial set of capabilities on switches did not
need a major upgrade of the hardware, which encouraged
immediate deployment. In later versions of the OpenFlow switch specification (i.e. starting from 1.1.0), an
OpenFlow-enabled switch supports a number of tables
containing multiple packet-handling rules, where each rule
matches a subset of the traffic and performs a set of actions
on it. This potentially prepares the floor for a large set of
controllers applications with sophisticated functionalities.
Furthermore, the deployment of OpenFlow testbeds by
researchers not only on a single campus network but
also over a wide-area backbone network demonstrated the
capabilities of this technology. Finally, a network operating
system, as envisioned by SDN, abstracts the state from the
logic that controls the behavior of the network [19], which
enables a flexible programmable control plane.
In the following sections, we present a tutorial and a
comprehensive survey on SDN where we highlight the
challenges that have to be faced to provide better chances
for SDN paradigm.
Application Layer
Unified Network
Monitoring and Analysis
Network
Virtualization
Security
(Fw, IDPS, WAF)
Other Business
Apps
Other Business
Apps
Westbound API
SDN
Controller
Eastbound API
SDN
Controller
Virtual Switches
2 ONF,
sdn-definition
https://www.opennetworking.org/sdn-resources/
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
App
App
App
App
Control Program
Abstract Network View
Network Hypervisor
Control Plane
Data Plane
FE
switches supporting OpenFlow. Hardware-based OpenFlow switches are typically implemented as ApplicationSpecific Integrated Circuits (ASICs); either using merchant silicon from vendors or using a custom ASIC. They
provide line rate forwarding for large number of ports but
lack the flexibility and feature completeness of software
implementations [38]. There are various commercial vendors that support OpenFlow in their hardware switches
including but not limited to HP, NEC, Pronto, Juniper,
Cisco, Dell, Intel, etc.
An OpenFlow-enabled switch can be subdivided into
three main elements [12], namely, a hardware layer (or
datapath), a software layer (or control path), and the
OpenFlow protocol:
L1
MPLS
Label
L2
IP
Src.
IP
Dest.
IP
Proto.
IP
TOS Field
MPLS
Traffic Class
L2.5
Transport
Src. Port
L3
Transport
Dest. Port
L4
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
TABLE I
OpenFlow Stacks and Switch Implementations
OpenFlow Switch
Description
Open Source
Language
Origin
OpenFlow Stack: Soft switch and control stack for hardware switching
OpenFlow Stack that follows the specification
hardware-independent software for
hardware switching
For OpenFlow on physical and hypervisor switches based on the Stanford
reference implementation
Enable Commercial OpenWRT wireless
devices with OpenFlow
yes
C/Python
Multiple contributors
yes
v 0.8
not yet
Stanford
University/
Nicira Networks
Pica8
yes
C/Lua
v 1.0
yes
v 1.0
OpenFlow
Reference
Implementation [39]
Pica8 [40]
Indigo [41]
Pantou/OpenWRT [42]
OpenFlow
Version
v 1.0
v 1.2
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
TABLE II
SDN Controllers
Controller
NOX [32]
NOX-MT [46]
POX [47]
Maestro [48]
Beacon [49]
SNAC [50]
RISE [51]
Floodlight [52]
McNettle [53]
MUL [54]
RYU [55]
OpenDaylight [56]
Open Source
yes
yes
yes
yes
yes
no
yes
yes
yes
yes
yes
yes
Language
C++/Python
C++
Python
Java
Java
C++/Python
C and Ruby
Java
Nettle/Haskell
C
Python
Java
Multi-threaded
no
yes
yes
yes
no
non-guaranteed
no
yes
yes
Level of Abstraction: Low-Level vs. High-Level. Lowlevel programming languages allow developers to deal
with details related to OpenFlow, whereas high-level
programming languages translate information provided by the OpenFlow protocol into a high-level
semantics. Translating the information provided by
the OpenFlow protocol into a high-level semantics
allows programmers to focus on network management
goals instead of details of low-level rules.
Programming: Logic vs. Functional Reactive. Most of
the existing network management languages adopt
the declarative programming paradigm, which means
that only the logic of the computation is described
(what the program should accomplish), while the
control flow (how to accomplish it) is delegated to
the implementation. Nevertheless, there exist two
different programming fashions to express network
policies: Logic Programming (LP) and Functional
Reactive Programming (FRP). In logic programming,
a program is constituted of a set of logical sentences.
It applies particularly to areas of artificial intelligence.
Functional reactive programming [65] is a paradigm
that provides an expressive and a mathematically
sound approach for programming reactive systems in
a declarative manner. The most important feature
of FRP is that it allows to capture both continuous
time-varying behaviors and event-based reactivity. It
is consequently used in areas such as robotics and
multimedia.
Policy Logic: Passive vs. Active. A programming language can be devised to develop either passive or
active policies. A passive policy can only observe the
GUI
yes
no
yes
no
yes
yes
no
yes
no
yes
yes
Origin
Nicira Networks
Nicira Networks and Big Switch Networks
Nicira Networks
Rice University
Stanford University
Nicira Networks
NEC
Big Switch Networks
Yale University
KulCloud
NTT OSRG and VA Linux
Multiple contributors
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
TABLE III
SDN programming languages
Framework
Frenetic [66], [67]
NetCore [68]
Nettle [61]
FML [69]
Procera [70]
Level
of
Abstraction
high
high
low
high
high
Query
Language
yes
yes
no
no
no
Runtime
System
yes
yes
no
no
no
Implementation
Language
Python
Python
Haskell
Python/C++
Haskell
Programming
Type
FRP
FRP
FRP
LP
FRP
Policies Type
Active
Active
Active
Passive
Active
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
10
B. Control Layer
As far as network control is concerned, the identified
critical issues are performance, scalability, and reliability
of the controller and the security of the control layer.
1) Performance, Scalability, and Reliability: The control layer can be a bottleneck of the SDN networks if
relying on a single controller to manage medium to large
networks. Among envisioned solutions, we can find the
following categories:
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
11
2) Northbound Interface Security: Multiple SDN applications may request a set of OpenFlow rule insertions, which may lead to the possible creation of security
breaches in the ongoing OpenFlow network configuration.
Among the envisaged solutions is the use of a Role-based
Authorization model to assign a level of authorization to
each SDN application.
F. Application/Control/Infrastructure Layers
The decision taken by the SDN application deployed
at the application layer influence the OpenFlow rules
configured at the infrastructure layer. This influence is
directed via the control layer. In this part of the taxonomy,
we focus on issues that concern all of the three SDN layers.
1) Policy Updates Correctness: Modification in policies
programmed by the SDN applications may result in inconsistent modification of the OpenFlow network configurations. These changes in configurations are common source
of network instability. To prevent such a critical problem,
works propose solutions to verify and/or ensure consistent
updates. Thus we enumerate two classes of solutions
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
12
Switch Resources
Utilization
[37], [76][80]
Lookup Procedure
Run-time Formal
Verification
[82]
Offline Formal
Verification
[83], [84]
Control
Partitioning
[85][89]
Controllers
Placement
[90][92]
Adding
Intelligence to
the Infrastructure
[93]
Security
[94][98]
QoS
TE
[101][103]
U-ACL
[104]
LB
[105]
Cloud
[106][117]
Mobile
[118][122]
ICN
[123][125]
NFV
[126]
Network
Virtualization
[127]
Performance
and Scalability
Control Devolving
[128][130]
Network
Correctness
[131], [132]
[58], [133]
Run-time Formal
Verification
[134]
Role-based
Authorization
[58]
Formal Verification
of Updates
[135], [136]
Update
Mechanism/
Protocol
[135][137]
Offline Testing
[138], [139]
Performance
and Scalability
Infrastructure
Layer
Correctness of
Flow Entries
Performance,
Scalability,
and Reliability
Control Layer
Controller Security
Applications
Application Layer
SDN Research
Use Cases
Control/
Infrastructure
Policy Correctness
Application/
Control
Northbound
Interface Security
Policy Updates
Correctness
Application/
Control/
Infrastructure
Network
Correctness
Fig. 4. Overview of the Surveyed Research Works Classified According to the Proposed Taxonomy
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
A. Infrastructure Layer
1) Performance and Scalability: Despite the undeniable advantages brought by SDN since its inception, it
has introduced several concerns including scalability and
performance. These concerns stem from various aspects
including the implementation of the OpenFlow switches.
The most relevant switch-level problems that limit the
support of the SDN/OpenFlow paradigm are as follows:
13
switch operation.
Packet Buffer Size The switch packet buffer is
characterized by a limited size, which may lead to
packet drops and cause throughput degradation.
Various research works [37], [76][81] addressed one or
more of these issues to improve performance and scalability of SDN data plane, and specifically of OpenFlow
Switches. These works are summarized in Table IV.
2) Correctness of Flow Entries: More than half of
network errors are due to misconfiguration bugs [140].
Misconfiguration has a direct impact on the security and
the efficiency of the network because of forwarding loops,
content delivery failure, isolation guarantee failure, access
control violation, etc. Skowyra et al. [84] propose an
approach based on formal methods to model and verify
OpenFlow learning switches network with respect to properties such as network correctness, network convergence,
and mobility-related properties. The verified properties
are expressed in LTL and PCTL* and both SPIN and
PRISM model-checkers are used. McGeer [83] discusses
the complexity of verifying OpenFlow networks. Therein,
a network of OpenFlow switches is considered as an acyclic
network of high-dimensional Boolean functions. Such verification is shown to be NP-complete by a reduction from
SAT. Furthermore, restricting the OpenFlow rule set to
prefix rules makes the verification complexity polynomial.
FlowChecker [82] is another tool to analyze, validate, and
enforce end-to-end OpenFlow configuration in federated
OpenFlow infrastructures. Various types of misconfiguration are investigated: intra-switch misconfiguration within
a single FlowTable as well as inter-switch or inter-federated
inconsistencies in a path of OpenFlow switches across the
same or different OpenFlow infrastructures. For federated
OpenFlow infrastructures, FlowChecker is run as a master controller communicating with various controllers to
identify and resolve inconsistencies using symbolic modelchecking over Binary Decision Diagrams (BDD) to encode
OpenFlow configurations. These works are compared in
Table V.
B. Control Layer
1) Performance, Scalability, and Reliability: Concerns
about performance and scalability have been considered as
major in SDN since its inception. The most determinant
factors that impact the performance and scalability of
the control plane are the number of new flows installs
per second that the controller can handle and the delay
of a flow setup. Benchmarks on NOX [32] showed that
it could handle at least 30.000 new flow installs per
second while maintaining a sub 10-ms flow setup delay
[142]. Nevertheless, recent experimental studies suggest
that these numbers are insufficient to overcome scalability
issues. For example, it has been shown in [143] that the
median flow arrival rate in a cluster of 1500 servers is
about 100.000 flows per second. This level of performance,
despite its suitability to some deployment environments
such as enterprises, leads to raise legitimate questions
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
14
TABLE IV
Survey on Initiatives Addressing Performance and Scalability at the Infrastructure Layer
Reference
Kannan and Banerjee [76]
Addressed Issue
TCAM Flow tables size and
power dissipation
Proposed Solution
Compact TCAM by replacing flow
entries with shorter Flow-ID
Narayanan
[77]
Use
multi-core
programmable
ASICs
and
a
new
switch
architecture (Split SDN Data
Plane) splitting the forwarding
fast path into TCAM-based and
software-based paths and use a
high-speed bus
Equipping switches with powerful
CPUs and gigabytes DRAM and
setup a high-bandwidth internal
link between the CPU and the
ASIC
Use
a
standard
commodity
Network Interface Card (NIC)
and achieve fast decision path by
caching flow table entries on the
NIC
Implemented a network processorbased acceleration card and an
OpenFlow switching algorithm
Implementation of a full line-rate
OpenFlow switch on NetFPGA
Algorithm for rules placement that
distributes forwarding policies and
supports dynamic incremental update of policies
et
al.
Lu et al. [78]
Tanyingyong et al.
[81]
Required Modification
Packets headers to carry the Flow-ID
and a Flow-ID table at the controller
site
Modification to switches hardware and
architecture
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
15
TABLE V
Survey on Initiatives Addressing Correctness Issues
Reference
Al-Shaer and
Al-Haj
[82]
(FlowChecker)
Layer
Infrastructure
McGeer [83]
Infrastructure
Skowyra et al.
[84]
Infrastructure
Khurshid
et
al.
[131]
(VeriFlow)
ControlInfrastructure
Kazemian
et
al.
[132]
(NetPlumber)
ControlInfrastructure
Porras et al.
[58] (FortNox)
ApplicationControl
Wang
[133]
al.
ApplicationControl
ApplicationControl
Reitblatt et al.
[135], [136] (Kinetic)
McGeer [137]
ApplicationControlInfrastructure
ApplicationControlInfrastructure
ApplicationControlInfrastructure
et
Canini et al.
[138] (NICE)
Kuzniar et al.
[139] (OFTEN)
ApplicationControlInfrastructure
Goal
Flow tables in OpenFlow
switch
networks
against
properties
expressed
in
temporal logic
Flow tables in OpenFlow
switch
networks
against
network properties
OpenFlow learning switch networks between mobile endhosts against network correctness, network convergence, and
mobility-related properties
Checks for network-wide invariant violations using existing
flow table rules at each forwarding rule is inserted by the controller
Checks for network-wide policies and invariants on every
event using existing flow table
rules
Conflicts detection and resolution between newly OpenFlow
rules inserted by applications
vs. existing OpenFlow rules
Conflicts detection and resolution between flow table rulesets
and SDN firewall applications
rules
Compliance of updated flow table rulesets with respect to nonbypass security properties
Invariance of trace properties
over updated policies
Consistent updates of the programmed policies
Testing the behavior of controller and its applications integrated wit an abstract model
of the switches
Testing the behavior of controller with its applications integrated with real OpenFlow
switches
Approach
Symbolic
BDDs
model-checking
over
Type of verification
Run-time verification
Offline verification
Run-time verification
Run-time verification
Run-time verification
Run-time verification
Run-time verification
Offline verification
Offline testing
Offline Testing
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
16
TABLE VI
SDN Control Frameworks
Proposal
Partitioning
Observation
Gran.
Full
Implementation
Horizontal with
state replication
Cross-Controllers
Coordination
Publish/subscribe messaging
HyperFlow [85]
Onix [86]
Horizontal with
state replication
or Vertical
Replicated NIB in a
replicated
transactional
database and a DHT
Full
Horizontal with
state replication
Full
Kandoo [88]
Vertical
(2
levels):
a
centralized
controller (may
be
horizontal
with
state
replication)
at the top layer
and a horizontal
deployment
with no state
replication at the
the bottom layer
Horizontal
with no state
replication
Partial (bottom
layer) Full (top
layer)
Multiple
Onix
controllers
(cluster)
running on a set of
physical servers
Multiple
controllers
(cluster with a master
controller) each on a
distinct server
Bottom layer controller
can be implemented on
a commodity middlebox as switch proxy or
directly on OpenFlow
switches
KeySpace,
Distributed
NoSQL database integrated
with each RM
CPRecovery
[141]
Centralized
Full
FlowVisor [13],
[30], [31]
Horizontal
with no state
replication
SiBF [89]
Partial
(Networkslice view for
each controller)
Application
NOX [32]
Failure Recovery
within
Network partitions
and
component
failure
switch, link, Onix
instance,
switchto-Onix link, and
Onix-to-Onix link
controller
and
switch-to-controller
link
None
None
Controller failure
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
17
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
18
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
19
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
20
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
Telefonica and Verizon) under the European Telecommunications Standards Institute (ETSI). NFV aims at
leveraging the standard IT virtualization technology in a
way that decouples network functions from proprietary
hardware appliances. It involves the implementation of
mobile and fixed network functions such as firewalling,
signaling, intrusion detection, and DNS, in software. The
implemented virtual appliances are hence designated to
be executed on different, yet standardized, environments
provided by different network vendors for different network
operators. Applying NFV is susceptible to bring several
benefits to the telecommunication industry:
It allows reducing development time and costs for
deploying new services in order to meet the emerging business requirements, which in turn, lowers the
associated risks.
It allows services to be scaled up and down based on
the actual requirements by a simple remote software
provisioning.
It opens the market to many different players to create
new virtual appliances without significant risks, which
encourages innovation.
Though being complementary and sharing two main objectives, namely, openness and innovation, NFV and SDN
are two independent paradigms. That is to say, NFV can
be implemented without separating the control plane from
the data plane as suggested by SDN. However, an NFV
infrastructure with SDN support is perfectly conceivable.
Even better, it is expected that such an alignment would
engender a greater value to NFV, since SDN enhances
compatibility, eases maintenance procedures, and provides
support for standardization.
D. Control/Infrastructure Layers
Examining the interconnection between the data and
the control Layers, two important dimensions have been
investigated in the literature: Performance and scalability
of the southbound interface and its correctness.
1) Performance and Scalability: One of the most important design goals of OpenFlow was to keep the data
plane simple and to delegate the control task to a logically centralized controller. As a result, switches have
to consult the controller frequently for instructions on
how to handle incoming packets of new flows. This tends
to congest switch-controller connections, which in turn
adds latency to the processing of the first packets of a
flow in the switch buffer. Solutions to devolve a part of
the control load to be processed by the data plane have
been proposed. For instance, Devoflow [128] design goal
is to keep flows in the data plane as much as possible by
redistributing as many decisions as possible to the switches
and maintaining a useful amount of visibility on the flows
for a central control. This can be done by minimizing the
need for frequent invocation of the OpenFlow controller for
flow setup and statistics gathering. Mainly, only detected
significant (elephant or long-lived) flows are managed by
the controller while short-lived ones are handled in the
21
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
22
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
B. Security of SDN
After reviewing the literature, we can safely affirm
that security and dependability of the SDN itself is still
an open issue. While SDN brings significant promises
to networking, it introduces many legitimate questions
about the potential security risks that SDN itself might
present to a network. Various works (e.g. [157][159]) have
investigated vulnerabilities and threat vectors related to
the deployment of SDN with OpenFlow. By decoupling
the control plane from the data plane, the attack surface
for SDNs is augmented, when compared to traditional
networks. According to Kreutz et al. [157], new attack
surface areas are introduced by SDN deployment. Three
identified vectors out of seven are specific to SDN, which
are controllers software, control-to-data layers communications, and control-to-application layers communications.
The remaining identified four threats, already present in
traditional networks, may have a potentially augmented
impact.
Among the well-known vulnerabilities of the SDN platform, controllers are susceptible to DoS attacks, which
can have a devastating impact on the whole network. By
setting up a large number of new and unknown flows, an
attacker can overwhelm the controller by a large number
of OpenFlow requests from the switch to decide on how
to handle these flows. A saturated controller would no
more be able to make decisions about the rest of the
traffic. To address such issue, Kreutz et al. [157] propose
the replication of the controller with the applications,
the use of diverse controller products, and a mechanism
to dynamically associate switches with more than one
controller. However, in a scenario where the switch has to
store packets in its input queue awaiting for the flow table
entry to be returned, the DoS can be also observed on the
level of the switch node. Several mechanisms and good
practices from several communities are proposed in [157]
to address various threats. While these recommendations
are valuable for improving the security of SDN, no concrete
solutions were provided. These recommendations need to
be followed by specific solutions that should be carefully
studied and experimented so that they do not add other
problems such as performance and scalability problems, do
not decrease the expectations from SDN (e.g. flexibility),
and do not introduce new security threats. Among the
few works proposing concrete solutions to secure control
platform in SDN, Shin et al. [93] designed and implemented AVANT-GUARD to defeat TCP-SYN flooding
attacks and network scanning. The proposed framework
is shown to successfully prevent control plane saturation
attacks (DOS) and flow-rule-flooding problem in the data
plane. However, the proposed approach is not designed to
prevent application layer DoS attacks or attacks based on
other protocols such as UDP or ICMP. Also, more works
need to be done to address more sophisticated attacks.
Another important identified threat to SDN is the communication between the applications and the controller
API. SDN networks are programmed using policies that
23
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
24
VII. Conclusion
SDN has recently gained an unprecedented attention
from academia and industry. SDN was born in academia
[9], [10], [12]. Several important organizations such as
Google [101] and VMware are running SDN networks
and several experimental testbeds are running and testing
OpenFlow networks worldwide, including NDDI [164],
OFELIA [165], FIBRE [166], JGN-X [167] and GENI [168].
Thus, a survey on SDN that studies various aspects of this
novel networking paradigm was needed.
In this paper, we elaborated a thorough survey and
tutorial on SDN to investigate the potential of SDN in
revolutionizing networks as we know them today. First, we
went back to the roots from where SDN and OpenFlow
have emerged. Then, we presented SDN concepts and
described its architecture. Therein, we detailed the main
SDNs components, namely the forwarding devices and the
logically centralized controller, along with their functionalities and interactions. We also compared various available
products conceived to support SDN deployment, such
as controllers software, OpenFlow-enabled switches, and
frameworks for SDN programming. Afterward, we studied
existing SDN-related taxonomies and proposed a layered
taxonomy that allows classifying the reviewed research
works. The proposed taxonomy presents a hierarchical
view and classifies the identified issues and solutions per
layer (or layers) they belong to.
In the second part of this paper, we surveyed the
research initiatives aiming at solving the already identified
issues and described some relevant application domains
where SDN is expected to make the difference, particularly for emerging technologies such as cloud computing.
Finally, we have investigated some of the open issues that
have been poorly addressed by the literature and thus need
to be addressed by future research efforts.
A recent IDC study [169] projected that the SDN market will increase from $360 million in 2013 to $3.7 billion
in 2016. However, in order to reach wide acceptance, we
believe that the maturity of SDN is a critical factor. This
maturity depends on the advancement in the design and
implementation of various SDN components, namely the
controllers, the switches, and the application services as
well as the interfaces across them. Furthermore, several
other issues including security, interoperability, reliability,
and scalability need further investigation. Once the maturity of SDN reaches an acceptable level, training and
education of networks stakeholders is an important step
for a smooth transition to the SDN paradigm.
References
[1] A. T. Campbell, H. G. De Meer, M. E. Kounavis, K. Miki, J. B.
Vicente, and D. Villela, A survey of Programmable Networks,
SIGCOMM Comput. Commun. Rev., vol. 29, no. 2, pp. 723,
Apr. 1999.
[2] DARPA, Active network program, http://www.sds.lcs.mit.
edu/darpa-activenet/, 1997, last Update: April 30, 1997.
[3] A. T. Campbell, I. Katzela, K. Miki, and J. Vicente, Open
Signaling for ATM, Internet and Mobile Networks (OPENSIG98), SIGCOMM Comput. Commun. Rev., vol. 29, no. 1,
pp. 97108, Jan. 1999.
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
25
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
26
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
[101]
[102]
[103]
[104]
[105]
[106]
[107]
[108]
[109]
[110]
[111]
[112]
[113]
[114]
[115]
[116]
27
European Workshop on, October 25th-26th, Darmstadt, Germany. Washington, DC, USA: IEEE Computer Society, 2012,
pp. 109113.
S. Jain, A. Kumar, S. Mandal, J. Ong, L. Poutievski, A. Singh,
S. Venkata, J. Wanderer, J. Zhou, M. Zhu, J. Zolla, U. H
olzle,
S. Stuart, and A. Vahdat, B4: Experience with a Globallydeployed Software Defined WAN, SIGCOMM Comput. Commun. Rev., vol. 43, no. 4, pp. 314, Aug. 2013.
G. Wang, T. E. Ng, and A. Shaikh, Programming your Network at Run-time for Big Data Applications, in Proceedings of
the first workshop on Hot topics in software defined networks,
ser. HotSDN 12. New York, NY, USA: ACM, 2012, pp. 103
108.
S. Das, Y. Yiakoumis, G. Parulkar, N. McKeown, P. Singh,
D. Getachew, and P. Desai, Application-Aware Aggregation
and Traffic Engineering in a Converged Packet-Circuit Network, in Optical Fiber Communication Conference and Exposition (OFC/NFOEC), 2011 and the National Fiber Optic
Engineers Conference, 2011, pp. 13.
N. Kang, J. Reich, J. Rexford, and D. Walker, Policy Transformation in Software Defined Networks, in the Proceedings of the
ACM SIGCOMM 2012 conference on Applications, technologies, architectures, and protocols for computer communication,
ser. SIGCOMM 12. New York, NY, USA: ACM, 2012, pp.
309310.
R. Wang, D. Butnariu, and J. Rexford, OpenFlow-based
Server Load Balancing Gone Wild, in the Proceedings of the
11th USENIX Conference on Hot Topics in Management of
Internet, Cloud, and Enterprise Networks and Services, ser.
Hot-ICE11. Berkeley, CA, USA: USENIX Association, 2011,
pp. 1212.
J. Matias, E. Jacob, D. Sanchez, and Y. Demchenko, An
OpenFlow-Based Network Virtualization Framework for the
Cloud, in Cloud Computing Technology and Science (CloudCom), 2011 IEEE Third International Conference on, 2011,
pp. 672678.
L. Sun, K. Suzuki, C. Yasunobu, Y. Hatano, and H. Shimonishi, A Network Management Solution Based on OpenFlow
Towards New Challenges of Multitenant Data Center, in
Information and Telecommunication Technologies (APSITT),
2012 9th Asia-Pacific Symposium on, 2012, pp. 16.
C. Rotsos, R. Mortier, A. Madhavapeddy, B. Singh, and
A. Moore, Cost, Performance & Flexibility in OpenFlow: Pick
Three, in Communications (ICC), 2012 IEEE International
Conference on, 2012, pp. 66016605.
The OpenStack Foundation, Openstack Cloud Software,
http://www.openstack.org/.
M. Banikazemi, D. Olshefski, A. Shaikh, J. Tracey, and
G. Wang, Meridian: an SDN Platform for Cloud Network
Services, Communications Magazine, IEEE, vol. 51, no. 2, pp.
120127, 2013.
G. Stabler, A. Rosen, S. Goasguen, and K.-C. Wang, Elastic
IP and security groups implementation using OpenFlow, in
Proceedings of the 6th international workshop on Virtualization
Technologies in Distributed Computing Date, ser. VTDC 12.
New York, NY, USA: ACM, 2012, pp. 5360.
T. Koorevaar, Dynamic Enforcement of Security Policies in
Multi-Tenant Cloud Networks, Masters thesis, Ecole Polytechnique de Montreal, November 2012.
V. Mann, A. Vishnoi, K. Kannan, and S. Kalyanaraman,
CrossRoads: Seamless VM Mobility Across Data Centers
Through Software Defined Networking, in Network Operations
and Management Symposium (NOMS), 2012 IEEE, 2012, pp.
8896.
F. Hao, T. V. Lakshman, S. Mukherjee, and H. Song, Enhancing Dynamic Cloud-based Services using Network Virtualization, SIGCOMM Comput. Commun. Rev., vol. 40, no. 1, pp.
6774, Jan. 2010.
B. Boughzala, R. Ben Ali, M. Lemay, Y. Lemieux, and
O. Cherkaoui, OpenFlow Supporting Inter-Domain Virtual
Machine Migration, in the Proceedings of the Eighth International Conference on Wireless and Optical Communications
Networks (WOCN), 2011, pp. 17.
T. Xing, D. Huang, L. Xu, C.-J. Chung, and P. Khatkar,
SnortFlow: A OpenFlow-Based Intrusion Prevention System
in Cloud Environment, in Research and Educational Experiment Workshop (GREE), 2013 Second GENI, 2013, pp. 8992.
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
[135]
[136]
[137]
[138]
[139]
[140]
[141]
[142]
[143]
[144]
[145]
[146]
[147]
[148]
[149]
[150]
[151]
[152]
28
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.
This article has been accepted for publication in a future issue of this journal, but has not been fully edited. Content may change prior to final publication. Citation information: DOI
10.1109/COMST.2014.2320094, IEEE Communications Surveys & Tutorials
IEEE COMMUNICATIONS SURVEYS & TUTORIALS, VOL. 16, NO. 1, JANUARY 2014
29
Taous Madi Taous Madi is a PhD student and a Research Assistant in Information
and Systems Engineering at the Concordia
Institute for Information Systems Engineering at Concordia University, Montreal, Quebec Canada. She received a Bachelor of engineering and a Magister degrees from Universit
e des Sciences et de la Technologie Houari
Boumediene, Algiers, Algeria in 2007 and
2010, respectively. Her research interests include cloud computing, mobile computing,
software-defined networking, and security.
1553-877X (c) 2013 IEEE. Personal use is permitted, but republication/redistribution requires IEEE permission. See
http://www.ieee.org/publications_standards/publications/rights/index.html for more information.