第1页 / 共63页
第2页 / 共63页
第3页 / 共63页
第4页 / 共63页
第5页 / 共63页
第6页 / 共63页
第7页 / 共63页
第8页 / 共63页
SDN A Comprehensive Survey.pdf
C O N T R I B U T E D
P A P
E R
Software-Defined Networking:
A Comprehensive Survey
This paper offers a comprehensive survey of software-defined networking
covering its context, rationale, main concepts, distinctive features,
and future challenges.
By Diego Kreutz, Member IEEE, Fernando M. V. Ramos, Member IEEE,
Paulo Esteves Verı´ssimo, Fellow IEEE, Christian Esteve Rothenberg, Member IEEE,
Siamak Azodolmolky, Senior Member IEEE, and Steve Uhlig, Member IEEE
ABSTRACT | The Internet has led to the creation of a digital
society, where (almost) everything is connected and is acces-
sible from anywhere. However, despite their widespread adop-
tion, traditional IP networks are complex and very hard to
manage. It is both difficult to configure the network according
to predefined policies, and to reconfigure it to respond to
faults, load, and changes. To make matters even more difficult,
current networks are also vertically integrated: the control and
data planes are bundled together. Software-defined network-
ing (SDN) is an emerging paradigm that promises to change this
state of affairs, by breaking vertical integration, separating the
network’s control
logic from the underlying routers and
switches, promoting (logical) centralization of network control,
and introducing the ability to program the network. The
separation of concerns, introduced between the definition of
network policies, their implementation in switching hardware,
and the forwarding of traffic, is key to the desired flexibility: by
breaking the network control problem into tractable pieces,
SDN makes it easier to create and introduce new abstractions in
networking, simplifying network management and facilitating
Manuscript received June 15, 2014; revised October 6, 2014; accepted
November 10, 2014. Date of current version December 18, 2014.
D. Kreutz and F. M. V. Ramos are with the Department of Informatics of Faculty of
Sciences, University of Lisbon, 1749-016 Lisbon, Portugal (e-mail: kreutz@ieee.org;
fvramos@fc.ul.pt).
P. E. Verı´ssimo is with the Interdisciplinary Centre for Security, Reliability and
Trust (SnT), University of Luxembourg, L-2721 Walferdange, Luxembourg
(e-mail: paulo.verissimo@uni.lu).
C. E. Rothenberg is with the School of Electrical and Computer
Engineering (FEEC), University of Campinas, Campinas 13083-970, Brazil
(e-mail: chesteve@dca.fee.unicamp.br).
S. Azodolmolky is with the Gesellschaft fu¨r Wissenschaftliche Datenverarbeitung mbH
Go¨ttingen (GWDG), 37077 Go¨ttigen, Germany (e-mail: siamak.azodolmolky@gwdg.de).
S. Uhlig is with Queen Mary University of London, London E1 4NS, U.K.
(e-mail: steve@eecs.qmul.ac.uk).
Digital Object Identifier: 10.1109/JPROC.2014.2371999
network evolution. In this paper, we present a comprehensive
survey on SDN. We start by introducing the motivation for SDN,
explain its main concepts and how it differs from traditional
networking, its roots, and the standardization activities regard-
ing this novel paradigm. Next, we present the key building
blocks of an SDN infrastructure using a bottom-up, layered
approach. We provide an in-depth analysis of the hardware
infrastructure, southbound and northbound application prog-
ramming interfaces (APIs), network virtualization layers,
network operating systems (SDN controllers), network prog-
ramming languages, and network applications. We also look at
cross-layer problems such as debugging and troubleshooting.
In an effort to anticipate the future evolution of this new pa-
radigm, we discuss the main ongoing research efforts and
challenges of SDN. In particular, we address the design of
switches and control platformsVwith a focus on aspects
such as resiliency, scalability, performance, security, and
dependabilityVas well as new opportunities for carrier trans-
port networks and cloud providers. Last but not least, we ana-
lyze the position of SDN as a key enabler of a software-defined
environment.
KEYWORDS | Carrier-grade networks; dependability; flow-
based networking; network hypervisor; network operating sys-
tems (NOSs); network virtualization; OpenFlow; programmable
networks; programming languages; scalability; software-
defined environments; software-defined networking (SDN)
I . I N TR O D U CT I ON
The distributed control and transport network protocols
running inside the routers and switches are the key tech-
nologies that allow information, in the form of digital
packets, to travel around the world. Despite their wide-
spread adoption, traditional IP networks are complex and
0018-9219 Ó 2014 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.
14 Proceedings of the IEEE | Vol. 103, No. 1, January 2015
Kreutz et al.: Software-Defined Networking: A Comprehensive Survey
hard to manage [1]. To express the desired high-level net-
work policies, network operators need to configure each
individual network device separately using low-level and
often vendor-specific commands. In addition to the config-
uration complexity, network environments have to endure
the dynamics of faults and adapt to load changes. Automa-
tic reconfiguration and response mechanisms are virtually
nonexistent in current IP networks. Enforcing the required
policies in such a dynamic environment is therefore highly
challenging.
To make it even more complicated, current networks
are also vertically integrated. The control plane (that de-
cides how to handle network traffic) and the data plane
(that forwards traffic according to the decisions made by
the control plane) are bundled inside the networking de-
vices, reducing flexibility and hindering innovation and
evolution of the networking infrastructure. The transition
from IPv4 to IPv6, started more than a decade ago and still
largely incomplete, bears witness to this challenge, while
in fact IPv6 represented merely a protocol update. Due to
the inertia of current IP networks, a new routing protocol
can take five to ten years to be fully designed, evaluated,
and deployed. Likewise, a clean-slate approach to change
the Internet architecture (e.g., replacing IP) is regarded as
a daunting taskVsimply not feasible in practice [2], [3].
Ultimately, this situation has inflated the capital and ope-
rational expenses of running an IP network.
Software-defined networking (SDN) [4], [5] is an
emerging networking paradigm that gives hope to change
the limitations of current network infrastructures. First, it
breaks the vertical integration by separating the network’s
control logic (the control plane) from the underlying rout-
ers and switches that forward the traffic (the data plane).
Second, with the separation of the control and data planes,
network switches become simple forwarding devices and
the control logic is implemented in a logically centralized
controller (or network operating system1), simplifying po-
licy enforcement and network (re)configuration and evol-
ution [6]. A simplified view of this architecture is shown in
Fig. 1. It is important to emphasize that a logically cen-
tralized programmatic model does not postulate a physi-
cally centralized system [7]. In fact, the need to guarantee
adequate levels of performance, scalability, and reliability
would preclude such a solution. Instead, production-level
SDN network designs resort to physically distributed con-
trol planes [7], [8].
The separation of the control plane and the data plane
can be realized by means of a well-defined programming
interface between the switches and the SDN controller.
The controller exercises direct control over the state in the
data plane elements via this well-defined application prog-
ramming interface (API), as depicted in Fig. 1. The most
notable example of such an API is OpenFlow [9], [10]. An
OpenFlow switch has one or more tables of packet-
1We will use these two terms interchangeably.
Fig. 1. Simplified view of an SDN architecture.
handling rules (flow table). Each rule matches a subset of
the traffic and performs certain actions (dropping, for-
warding, modifying, etc.) on the traffic. Depending on the
rules installed by a controller application, an OpenFlow
switch canVinstructed by the controllerVbehave like a
router, switch, firewall, or perform other roles (e.g., load
balancer,
those of a
middlebox).
traffic shaper, and in general
An important consequence of the SDN principles is the
separation of concerns introduced between the definition
of network policies, their implementation in switching
hardware, and the forwarding of traffic. This separation is
key to the desired flexibility, breaking the network control
problem into tractable pieces, and making it easier to
create and introduce new abstractions in networking, sim-
plifying network management and facilitating network
evolution and innovation.
Although SDN and OpenFlow started as academic
experiments [9], they gained significant traction in the
industry over the past few years. Most vendors of com-
mercial switches now include support of the OpenFlow
API in their equipment. The SDN momentum was strong
enough to make Google, Facebook, Yahoo, Microsoft,
Verizon, and Deutsche Telekom fund Open Networking
Foundation (ONF) [10] with the main goal of promotion
and adoption of SDN through open standards develop-
ment. As the initial concerns with SDN scalability were
addressed [11]Vin particular the myth that logical cen-
tralization implied a physically centralized controller, an
issue we will return to later onVSDN ideas have matured
and evolved from an academic exercise to a commercial
success. Google, for example, has deployed an SDN to
interconnect its data centers across the globe. This pro-
duction network has been in deployment for three years,
helping the company to improve operational efficiency
and significantly reduce costs [8]. VMware’s network
Vol. 103, No. 1, January 2015 | Proceedings of the IEEE 15
Kreutz et al.: Software-Defined Networking: A Comprehensive Survey
virtualization platform, NSX [12],
is another example.
NSX is a commercial solution that delivers a fully func-
tional network in software, provisioned independent of the
underlying networking devices, entirely based around
SDN principles. As a final example, the world’s largest IT
companies (from carriers and equipment manufacturers to
cloud providers and financial services companies) have
recently joined SDN consortia such as the ONF and the
OpenDaylight initiative [13], another indication of the
importance of SDN from an industrial perspective.
A few recent papers have surveyed specific architectu-
ral aspects of SDN [14]–[16]. An overview of OpenFlow
and a short literature review can be found in [14] and [15].
These OpenFlow-oriented surveys present a relatively
simplified three-layer stack composed of high-level net-
work services, controllers, and the controller/switch inter-
face. In [16], Jarraya et al. go a step further by proposing a
taxonomy for SDN. However, similarly to the previous
works, the survey is limited in terms of scope, and it does
not provide an in-depth treatment of fundamental aspects
of SDN. In essence, existing surveys lack a thorough dis-
cussion of the essential building blocks of an SDN such as
the network operating systems (NOSs), programming lan-
guages, and interfaces. They also fall short on the analysis
of cross-layer issues such as scalability, security, and de-
pendability. A more complete overview of ongoing re-
search efforts, challenges, and related standardization
activities is also missing.
In this paper, we present, to the best of our knowledge,
the most comprehensive literature survey on SDN to date.
We organize this survey as depicted in Fig. 2. We start, in
the next two sections, by explaining the context, introduc-
ing the motivation for SDN and explaining the main
concepts of this new paradigm and how it differs from
traditional networking. Our aim in the early part of the
survey is also to explain that SDN is not as novel as a
technological advance. Indeed, its existence is rooted at
the intersection of a series of ‘‘old’’ ideas, technology driv-
ers, and current and future needs. The concepts underly-
ing SDNVthe separation of the control and data planes,
the flow abstraction upon which forwarding decisions are
made, the (logical) centralization of network control, and
the ability to program the networkVare not novel by
themselves [17]. However, the integration of already tested
concepts with recent trends in networkingVnamely the
availability of merchant switch silicon and the huge
Fig. 2. Condensed overview of this survey on SDN.
16 Proceedings of the IEEE | Vol. 103, No. 1, January 2015
Kreutz et al.: Software-Defined Networking: A Comprehensive Survey
based tools [18], used to remotely monitor and configure the
control functionality. Network policy is defined in the man-
agement plane, the control plane enforces the policy, and
the data plane executes it by forwarding data accordingly.
In traditional IP networks, the control and data planes
are tightly coupled, embedded in the same networking
devices, and the whole structure is highly decentralized.
This was considered important for the design of the Inter-
net in the early days: it seemed the best way to guarantee
network resilience, which was a crucial design goal. In
fact, this approach has been quite effective in terms of
network performance, with a rapid increase of line rate
and port densities.
However, the outcome is a very complex and relatively
static architecture, as has been often reported in the net-
working literature (e.g., [1]–[3], [6], and [19]). It is also
the fundamental reason why traditional networks are rigid,
and complex to manage and control. These two character-
istics are largely responsible for a vertically integrated in-
dustry where innovation is difficult.
Network misconfigurations and related errors are ex-
tremely common in today’s networks. For instance, more
than 1000 configuration errors have been observed in
border gateway protocol (BGP) routers [20]. From a single
misconfigured device, very undesired network behavior
may result (including, among others, packet losses, for-
warding loops, setting up of unintended paths, or service
contract violations). Indeed, while rare, a single miscon-
figured router is able to compromise the correct operation
of the whole Internet for hours [21], [22].
To support network management, a small number of
vendors offer proprietary solutions of specialized hard-
ware, operating systems, and control programs (network
applications). Network operators have to acquire and
maintain different management solutions and the corre-
sponding specialized teams. The capital and operational
cost of building and maintaining a networking infrastruc-
ture is significant, with long return on investment cycles,
which hamper innovation and addition of new features and
services (for instance, access control,
load balancing,
energy efficiency, traffic engineering). To alleviate the lack
of in-path functionalities within the network, a myriad of
specialized components and middleboxes, such as fire-
walls, intrusion detection systems, and deep packet inspec-
tion engines, proliferate in current networks. A recent
survey of 57 enterprise networks shows that the number of
middleboxes is already on par with the number of routers
in current networks [23]. Despite helping in-path func-
tionalities, the net effect of middleboxes has increased
complexity of network design and its operation.
I I I . W H A T I S S O F T W A R E - D E F I N E D
N E T W O R K I N G ?
The term SDN was originally coined to represent the ideas
and work around OpenFlow at Stanford University,
Vol. 103, No. 1, January 2015 | Proceedings of the IEEE 17
Fig. 3. Layered view of networking functionality.
interest in feasible forms of network virtualizationVare
leading to this paradigm shift in networking. As a result of
the high industry interest and the potential to change the
status quo of networking from multiple perspectives, a
number of standardization efforts around SDN are ongo-
ing, as we also discuss in Section III.
Section IV is the core of this survey, presenting an
extensive and comprehensive analysis of
the building
blocks of an SDN infrastructure using a bottom-up, layered
approach. The option for a layered approach is grounded
on the fact that SDN allows thinking of networking along
two fundamental concepts, which are common in other
disciplines of computer science: separation of concerns
(leveraging the concept of abstraction) and recursion. Our
layered, bottom-up approach divides the networking prob-
lem into eight parts: 1) hardware infrastructure; 2) south-
bound interfaces; 3) network virtualization (hypervisor
layer between the forwarding devices and the NOSs);
4) NOSs
(SDN controllers and control platforms);
5) northbound interfaces (to offer a common programming
abstraction to the upper layers, mainly the network appli-
cations); 6) virtualization using slicing techniques provid-
ed by special purpose libraries or programming languages
and compilers; 7) network programming languages; and
finally 8) network applications. In addition, we also look at
cross-layer problems such as debugging and troubleshoot-
ing mechanisms. The discussion in Section V on ongoing
research efforts, challenges, future work, and opportuni-
ties concludes this paper.
I I . S T AT U S Q U O I N N ET W O R K I N G
Computer networks can be divided in three planes of func-
tionality: the data, control, and management planes (see
Fig. 3). The data plane corresponds to the networking de-
vices, which are responsible for (efficiently) forwarding
data. The control plane represents the protocols used to
populate the forwarding tables of the data plane elements.
The management plane includes the software services,
such as simple network management protocol (SNMP)-
Kreutz et al.: Software-Defined Networking: A Comprehensive Survey
Stanford, CA, USA [24]. As originally defined, SDN refers
to a network architecture where the forwarding state in the
data plane is managed by a remotely controlled plane de-
coupled from the former. The networking industry has on
many occasions shifted from this original view of SDN by
referring to anything that involves software as being SDN.
We therefore attempt, in this section, to provide a much
less ambiguous definition of SDN.
We define an SDN as a network architecture with four
pillars.
1)
2)
The control and data planes are decoupled. Con-
trol functionality is removed from network devices
that will become simple (packet) forwarding
elements.
Forwarding decisions are flow based, instead of
destination based. A flow is broadly defined by a
set of packet field values acting as a match (filter)
criterion and a set of actions (instructions). In the
SDN/OpenFlow context, a flow is a sequence of
packets between a source and a destination. All
packets of a flow receive identical service policies
at the forwarding devices [25], [26]. The flow
abstraction allows unifying the behavior of differ-
ent types of network devices, including routers,
switches, firewalls, and middleboxes [27]. Flow
programming enables unprecedented flexibility,
limited only to the capabilities of the implemen-
ted flow tables [9].
3) Control logic is moved to an external entity, the
so-called SDN controller or NOS. The NOS is a
software platform that runs on commodity server
technology and provides the essential resources
and abstractions to facilitate the programming of
forwarding devices based on a logically central-
ized, abstract network view. Its purpose is there-
fore similar to that of a traditional operating system.
The network is programmable through software
applications running on top of the NOS that in-
teracts with the underlying data plane devices.
This is a fundamental characteristic of SDN, con-
sidered as its main value proposition.
4)
Note that the logical centralization of the control logic,
in particular, offers several additional benefits. First, it is
simpler and less error prone to modify network policies
through high-level languages and software components,
compared with low-level device specific configurations.
Second, a control program can automatically react to
spurious changes of the network state and thus maintain
the high-level policies intact. Third, the centralization of
the control logic in a controller with global knowledge of
the network state simplifies the development of more so-
phisticated networking functions, services, and applications.
Following the SDN concept introduced in [5], an SDN
can be defined by three fundamental abstractions: for-
warding, distribution, and specification. In fact, abstrac-
tions are essential tools of research in computer science
18 Proceedings of the IEEE | Vol. 103, No. 1, January 2015
and information technology, being already an ubiquitous
feature of many computer architectures and systems [28].
Ideally, the forwarding abstraction should allow any
forwarding behavior desired by the network application
(the control program) while hiding details of the under-
lying hardware. OpenFlow is one realization of such ab-
straction, which can be seen as the equivalent to a ‘‘device
driver’’ in an operating system.
The distribution abstraction should shield SDN appli-
cations from the vagaries of distributed state, making the
distributed control problem a logically centralized one. Its
realization requires a common distribution layer, which in
SDN resides in the NOS. This layer has two essential
functions. First, it is responsible for installing the control
commands on the forwarding devices. Second, it collects
status information about the forwarding layer (network
devices and links), to offer a global network view to net-
work applications.
The last abstraction is specification, which should al-
low a network application to express the desired network
behavior without being responsible for implementing that
behavior itself. This can be achieved through virtualization
solutions, as well as network programming languages.
These approaches map the abstract configurations that the
applications express based on a simplified, abstract model
of the network, into a physical configuration for the global
network view exposed by the SDN controller. Fig. 4 de-
picts the SDN architecture, concepts, and building blocks.
As previously mentioned, the strong coupling between
control and data planes has made it difficult to add new
functionality to traditional networks, a fact illustrated in
Fig. 5. The coupling of the control and data planes (and its
physical embedding in the network elements) makes the
development and deployment of new networking features
Fig. 4. SDN architecture and its fundamental abstractions.
Kreutz et al.: Software-Defined Networking: A Comprehensive Survey
lancing and routing applications can be combined
sequentially, with load balancing decisions having
precedence over routing policies.
A. Terminology
To identify the different elements of an SDN as un-
equivocally as possible, we now present the essential
terminology used throughout this work.
1) Forwarding Devices (FD): These are hardware- or
software-based data plane devices that perform a set of
elementary operations. The forwarding devices have well-
defined instruction sets (e.g., flow rules) used to take ac-
tions on the incoming packets (e.g., forward to specific
ports, drop,
forward to the controller, rewrite some
header). These instructions are defined by southbound
interfaces (e.g., OpenFlow [9], ForCES [30], protocol-
oblivious forwarding (POF) [31]) and are installed in the
forwarding devices by the SDN controllers implementing
the southbound protocols.
2) Data Plane (DP): Forwarding devices are intercon-
nected through wireless radio channels or wired cables.
The network infrastructure comprises the interconnected
forwarding devices, which represent the data plane.
3) Southbound Interface (SI): The instruction set of the
forwarding devices is defined by the southbound API,
which is part of the southbound interface. Furthermore,
the SI also defines the communication protocol between
forwarding devices and control plane elements. This pro-
tocol formalizes the way the control and data plane ele-
ments interact.
4) Control Plane (CP): Forwarding devices are prog-
rammed by control plane elements through well-defined
SI embodiments. The control plane can therefore be seen
as the ‘‘network brain.’’ All control logic rests in the appli-
cations and controllers, which form the control plane.
5) Northbound Interface (NI): The NOS can offer an API
to application developers. This API represents a north-
bound interface, i.e., a common interface for developing
applications. Typically, a northbound interface abstracts
the low-level instruction sets used by southbound inter-
faces to program forwarding devices.
6) Management Plane (MP): The management plane is
the set of applications that leverage the functions offered
by the NI to implement network control and operation
logic. This includes applications such as routing, fire-
walls, load balancers, monitoring, and so forth. Essen-
tially, a management application defines the policies,
which are ultimately translated to southbound-specific
instructions that program the behavior of the forwarding
devices.
Vol. 103, No. 1, January 2015 | Proceedings of the IEEE 19
Fig. 5. Traditional networking versus SDN. With SDN, management
becomes simpler and middleboxes services can be delivered as
SDN controller applications.
(e.g., routing algorithms) very difficult, since it would
imply a modification of the control plane of all network
devicesVthrough the installation of new firmware and, in
some cases, hardware upgrades. Hence, the new network-
ing features are commonly introduced via expensive, spe-
cialized, and hard-to-configure equipment (also known as
middleboxes) such as load balancers, intrusion detection
systems (IDSs), and firewalls, among others. These mid-
dleboxes need to be placed strategically in the network,
making it even harder to later change the network topo-
logy, configuration, and functionality.
•
•
In contrast, SDN decouples the control plane from the
network devices and becomes an external entity: the NOS
or SDN controller. This approach has several advantages.
It becomes easier to program these applications
since the abstractions provided by the control plat-
form and/or the network programming languages
can be shared.
All applications can take advantage of the same
network information (the global network view),
leading (arguably) to more consistent and effective
policy decisions, while reusing control plane soft-
ware modules.
These applications can take actions (i.e., reconfig-
ure forwarding devices) from any part of the net-
work. There is therefore no need to devise a precise
strategy about the location of the new functionality.
The integration of different applications becomes
more straightforward [29]. For instance, load ba-
•
•
Kreutz et al.: Software-Defined Networking: A Comprehensive Survey
B. Alternative and Broadening Definitions
Since its inception in 2010 [24], the original Open-
Flow-centered SDN term has seen its scope broadened
beyond architectures with a cleanly decoupled control
plane interface. The definition of SDN will likely continue
to broaden, driven by the industry business-oriented views
on SDNVirrespective of the decoupling of the control
plane. In this survey, we focus on the original, ‘‘canonical’’
SDN definition based on the aforementioned key pillars
and the concept of layered abstractions. However, for the
sake of completeness and clarity, we acknowledge
alternative SDN definitions [32], as follows.
1) Control Plane/Broker SDN: A networking approach
that retains existing distributed control planes but offers
new APIs that allow applications to interact (bidirection-
ally) with the network. An SDN controllerVoften called
orchestration platformVacts as a broker between the ap-
plications and the network elements. This approach
effectively presents control plane data to the application
and allows a certain degree of network programmability by
means of ‘‘plug-ins’’ between the orchestrator function and
network protocols. This API-driven approach corresponds
to a hybrid model of SDN, since it enables the broker to
manipulate and directly interact with the control planes of
devices such as routers and switches. Examples of this view
on SDN include recent standardization efforts at the In-
ternet Engineering Task Force (IETF) (see Section III-C)
and the design philosophy behind the OpenDaylight pro-
ject [13] that goes beyond the OpenFlow split control mode.
2) Overlay SDN: This is a networking approach where
the (software- or hardware-based) network edge is dyna-
mically programmed to manage tunnels between hyper-
visors and/or network switches, introducing an overlay
network. In this hybrid networking approach, the distrib-
uted control plane providing the underlay remains un-
touched. The centralized control plane provides a logical
overlay that utilizes the underlay as a transport network.
This flavor of SDN follows a proactive model to install the
overlay tunnels. The overlay tunnels usually terminate
inside virtual switches within hypervisors or in physical
devices acting as gateways to the existing network. This
approach is very popular in recent data center network
virtualization [33], and are based on a variety of tunneling
technologies (e.g., stateless transport
tunneling [34],
virtualized layer 2 networks (VXLAN) [35], network vir-
tualization using generic routing encapsulation (NVGRE)
[36], locator/ID separation protocol (LISP) [37], [38], and
generic network virtualization encapsulation (GENEVE)
[39]) [40].
Recently, other attempts to define SDN in a layered ap-
proach have appeared [16], [41]. From a practical perspective
and trying to keep backward compatibility with existing
network management approaches, one initiative in the IRTF
Software-Defined Networking Research Group (SDNRG)
20 Proceedings of the IEEE | Vol. 103, No. 1, January 2015
[41] proposes a management plane at the same level of the
control plane, i.e., it classifies solutions in two categories:
control logic (with control plane southbound interfaces) and
management logic (with management plane southbound
interfaces). In other words, the management plane can be
seen as a control platform that accommodates traditional
network management services and protocols, such as SNMP
[18], BGP [42], path computation element communication
protocol (PCEP) [43], and network configuration protocol
(NETCONF) [44].
In addition to the broadening definitions above, the
term SDN is often used to define extensible network man-
agement planes (e.g., OpenStack [45]), whitebox/bare-
metal switches with open operating systems (e.g., Cumulus
Linux), open-source data planes (e.g., Pica8 Xorplus [46],
Quagga [47]), specialized programmable hardware devices
(e.g., NetFPGA [48]), virtualized software-based appli-
ances (e.g., open platform for network functions virtualiza-
tion (OPNFV) [49]), in spite of lacking a decoupled control
and data plane or common interface along its API. Hybrid
SDN models are further discussed in Section V-G.
C. Standardization Activities
The standardization landscape in SDN (and SDN-
related issues) is already wide and is expected to keep
evolving over time. While some of the activities are being
carried out
in standard development organizations
(SDOs), other related efforts are ongoing at industrial or
community consortia (e.g., OpenDaylight, OpenStack,
OPNFV), delivering results often considered candidates
for de facto standards. These results often come in the
form of open source implementations that have become
the common strategy toward accelerating SDN and
related cloud and networking technologies [50]. The
reason for this fragmentation is due to SDN concepts
spanning different areas of IT and networking, both
from a network segmentation point of view (from access
to core) and from a technology perspective (from optical
to wireless).
Table 1 presents a summary of the main SDOs and
organizations contributing to the standardization of SDN,
as well as the main outcomes produced to date.
The ONF was conceived as a member-driven organi-
zation to promote the adoption of SDN through the devel-
opment of the OpenFlow protocol as an open standard to
communicate control decisions to data plane devices. The
ONF is structured in several working groups (WGs). Some
WGs are focused on either defining extensions to the
OpenFlow protocol in general, such as the extensibility
WG, or tailored to specific technological areas. Examples
of the latter include the optical transport (OT) WG, the
wireless and mobile (W&M) WG, and the northbound in-
terfaces (NBI) WG. Other WGs center their activity in
providing new protocol capabilities to enhance the pro-
tocol itself, such as the architecture WG or the forwarding
abstractions (FA) WG.
Kreutz et al.: Software-Defined Networking: A Comprehensive Survey
Table 1 Openflow Standardization Activities
Similar to how network programmability ideas have
been considered by several IETF working groups (WGs) in
the past, the present SDN trend is also influencing a
number of activities. A related body that focuses on re-
search aspects for the evolution of the Internet, IRTF, has
created the SDNRG. This group investigates SDN from
Vol. 103, No. 1, January 2015 | Proceedings of the IEEE 21
相关推荐
2023年江西萍乡中考道德与法治真题及答案.doc
2012年重庆南川中考生物真题及答案.doc
2013年江西师范大学地理学综合及文艺理论基础考研真题.doc
2020年四川甘孜小升初语文真题及答案I卷.doc
2020年注册岩土工程师专业基础考试真题及答案.doc
2023-2024学年福建省厦门市九年级上学期数学月考试题及答案.doc
2021-2022学年辽宁省沈阳市大东区九年级上学期语文期末试题及答案.doc
2022-2023学年北京东城区初三第一学期物理期末试卷及答案.doc
2018上半年江西教师资格初中地理学科知识与教学能力真题及答案.doc
2012年河北国家公务员申论考试真题及答案-省级.doc
2020-2021学年江苏省扬州市江都区邵樊片九年级上学期数学第一次质量检测试题及答案.doc
2022下半年黑龙江教师资格证中学综合素质真题及答案.doc
