Software-Defined Networks: on the road to the

softwarization of networking

Fernando M. V. Ramos Diego Kreutz, Paulo Verissimo

LaSIGE/FCUL, University of Lisboa, Portugal SnT/University of Luxembourg, Luxembourg
fvramos@ciencias.ulisboa.pt {Diego.Kreutz,Paulo.Verissimo}@uni.lu

ABSTRACT Network  Applica4on(s)  

Traditional IP networks are complex and hard to manage. Open northbound API
The vertical integration of the infrastructure, with the con- Controller  Pla+orm  
trol and data planes tightly coupled in network equipment,
Open southbound API
makes it a challenging task to build and maintain efficient
networks in an era of cloud computing. Software-Defined
Networking (SDN) breaks this coupling by segregating net-
work control from routers and switches and by logically cen-
nts
tralizing it in an external entity that resides in commodity me s)
g ele itche
n sw
servers. This way, SDN provides the flexibility required rdi
wa low
a for enF
t p
to dynamically program the network, promoting the “soft- Da g., O
(e.
warization” of networking.
Network Infrastructure
In this article we introduce this new paradigm and show
how it breaks the status quo in networking. We present the
most relevant building blocks of the infrastructure and dis- Figure 1: Simplified view of an SDN
cuss how SDN is leading to a horizontal industry based on
programmable and open components. We pay particular at-
ing routers and switches that forward the traffic. Net-
tention to use cases that demonstrate how IT companies such
work switches become simple forwarding devices and
as Google, Microsoft, and VMware are embracing SDN to
the control logic is implemented in a logically central-
operate efficient networks and offer innovative networking
ized controller, simplifying policy enforcement. While
services.
the controller can be implemented as a distributed sys-
tem, network applications have access to a centralized
1. INTRODUCTION programmatic model (a global network view), making
Traditional computer networks are complex and very it easier to reason about network behavior. A simplified
hard to manage [1]. To express the desired policies, view of this architecture is shown in Figure 1.
network operators need to configure each individual net- The separation of the control plane and the data
work device, one by one, either manually or with the use plane can be realized by means of a well-defined pro-
of low-level scripts. In addition to configuration com- gramming interface between the switches and the SDN
plexity, network environments have to endure the dy- controller. The controller exercises direct control over
namics of faults and adapt to load changes. Enforcing the state in the data-plane elements via this well-defined
the required policies in such a dynamic environment is southbound interface. The most notable example of
highly challenging. Current networks are also vertically such interface is OpenFlow [3, 4]. An OpenFlow switch
integrated. The control plane (that decides how to han- has one or more tables of packet-handling rules. Each
dle network traffic) and the data plane (that forwards rule matches a subset of the traffic and performs certain
traffic according to the decisions made by the control actions on the packets (dropping, forwarding to specific
plane) are bundled inside the networking devices. This port(s), modifying headers, among others). Depending
is a fundamental obstacle that has led to the slow pace on the rules installed by a control application, an Open-
of innovation of networking infrastructure. Flow switch can – instructed by the controller – behave
Software-Defined Networking (SDN) [2] is an emerg- like a router, switch, firewall, load balancer, or perform
ing paradigm that promises to change the current state other roles.
of affairs. SDN breaks the vertical integration by sep- An important consequence of the software-defined net-
arating the network’s control logic from the underly- working principles is the separation of concerns intro-

1
duced between the definition of network policies, their network view. Its purpose is therefore similar to
implementation in switching hardware, and the forward- that of a traditional operating system, but for net-
ing of traffic. This separation allows modularity by working resources.
breaking the network control problem into tractable
pieces, and making it easier to create and introduce new 4. The network is programmable through software ap-
abstractions in networking [5]. This is key to simplify plications running on top of the SDN controller.
network management and to facilitate innovation. This is a fundamental characteristic of SDN, con-
Although SDN and OpenFlow started as an academic sidered its main value proposition.
experiment [3], they gained significant traction in the
Following the concepts introduced in [5], an SDN can
industry over the past few years. Most vendors of com-
be defined by three fundamental abstractions: (i ) for-
mercial switches now include OpenFlow support in their
warding, (ii ) distribution, and (iii ) specification. Ide-
equipment. The ideas behind SDN have matured and
ally, the forwarding abstraction should allow any for-
evolved from an academic exercise to a commercial suc-
warding behavior desired by the network application
cess. The world’s largest IT companies have recently
(the control program) while hiding details of the un-
joined SDN consortia such as the ONF [4] and the Open-
derlying hardware. OpenFlow is one realization of such
Daylight initiative [6] as an indication of the importance
abstraction, which can be seen as the equivalent to a
of SDN from an industrial perspective.
“device driver” in an operating system. The distribu-
In this article we introduce Software-Defined Net-
tion abstraction should shield SDN applications from
working and show how this paradigm differentiates from
the vagaries of distributed state, logically centralizing
traditional networking (Section 2). We present the most
the network control, guaranteeing its consistency. Its
relevant building blocks of the SDN infrastructure (Sec-
realization requires a common distribution layer, which
tion 3) and discuss how SDN is leading to a change in
in SDN resides in the controller. The last abstraction is
the networking industry (Section 4). To attest the suc-
specification, which should allow a network application
cess of SDN and its take up by the industry we present
to express the desired network behavior without being
four demonstrative use cases (Section 5): Google’s B4
responsible for implementing that behavior itself.
and Microsoft’s SWAN traffic engineering solutions [7],
VMware’s network virtualization platform [8, 9], and
Statesman, a network state management service de- 3. SDN BUILDING BLOCKS
ployed by Microsoft in its data centers [10]. We con- An SDN architecture can be depicted as a composi-
clude by speculating on what the future may yield for tion of different layers, as shown in Figure 2. Each layer
SDN (Section 6). has its own specific function.

2. SOFTWARE-DEFINED NETWORKING Network Applications

Routing

balancer
Control
Access

Load
The term SDN was originally coined to represent the Programming Languages
ideas and work around OpenFlow at Stanford Univer-
sity [11]. A software-defined network is a network archi- Northbound Interface
tecture with four pillars: Controller SDN Controller
Network Hypervisor
1. The control and data planes are decoupled. Con- Southbound Interface
trol functionality is removed from network devices
that become simple (packet) forwarding elements.
Network Infrastructure
2. Forwarding decisions are flow-based, instead of des-
tination-based. A flow is broadly defined by a set (a) (b)
of packet field values acting as a match (filter) cri-
terion and a set of actions (instructions). The flow
abstraction allows unifying the behavior of differ- Figure 2: A layered view of SDN
ent types of network devices, including routers,
switches, firewalls, and other middleboxes. 3.1 Network infrastructure
3. Control logic is moved to an external entity, the An SDN infrastructure, similarly to a traditional net-
SDN controller. The controller is a software plat- work, is composed of a set of networking equipment
form that runs on commodity server technology (switches, routers, and middlebox appliances). The main
and provides the essential resources and abstrac- difference resides in the fact that those traditional phys-
tions to facilitate the programming of forwarding ical devices are now simple forwarding elements with-
devices based on a logically centralized, abstract out (or with limited) embedded control or software to

2
take autonomous decisions. The network intelligence not only isolation of network control, but also topology
is removed from the data plane devices to a logically- and address virtualization. Contrary to these platforms
centralized control system. An OpenFlow-enabled for- that virtualize an SDN, VMware’s Network Virtualiza-
warding device is based on a pipeline of flow tables tion Platform (described in more detail in Section 5)
where each entry of a flow table has three parts: (1) a provides full virtualization in data centers without re-
matching rule, (2) actions to be executed on matching quiring SDN-based hardware (the only requirement is
packets, and (3) counters that keep statistics of match- that all servers are virtualized).
ing packets.
3.4 Controller
3.2 Southbound interfaces The controller is the fundamental element in an SDN
Southbound interfaces are the connecting bridges be- architecture, as it is the key supporting piece for the
tween control and forwarding elements, thus being the control logic (applications) to generate the network con-
crucial instrument for clearly separating control and figuration based on the policies defined by the network
data plane functionality. OpenFlow is the most widely operator. Similar to a traditional operating system, the
deployed open southbound standard for SDN. It pro- control platform abstracts the lower-level details of the
vides a common specification to implement OpenFlow- interaction with forwarding devices.
enabled forwarding devices, and for the communication There is a diverse set of controllers with different de-
channel between data and control plane devices. The sign and architectural choices [2]. Existing controllers
OpenFlow protocol provides three information sources can be categorized based on many aspects. From an
for controllers. First, event-based messages are sent by architectural point of view, one of the most relevant
forwarding devices to the controller when a link or port is if they are centralized or distributed. A centralized
change is triggered. Second, flow statistics are gener- controller (such as NOX [16]) is a single entity that
ated by the forwarding devices and collected by the con- manages all forwarding devices of the network. Nat-
troller. Third, packet-in messages are sent by forward- urally, it represents a single point of failure and may
ing devices to the controller when they do not known have scaling limitations. Contrary to a centralized de-
what to do with an incoming packet or because there sign, a distributed controller (such as Onix [17]) can be
is an explicit “send to controller” action in the matched scaled up to meet the requirements of potentially any
entry of the flow table. These information channels are environment, from small to large-scale networks.
the essential means to provide flow-level information to
the controller. 3.5 Northbound interface
OVSDB [12] is another type of southbound API, de- The north and southbound interfaces are two key ab-
signed to provide advanced management capabilities for stractions of the SDN ecosystem. The southbound in-
Open vSwitches [13]. Beyond OpenFlow’s capabilities terface has already a widely accepted proposal (Open-
to configure flows and thus influence forwarding behav- Flow), but a common northbound interface is still an
ior, OVSDB allows the creation of tunnels, turning on or open issue. At this moment it may still be a bit too
off certain features, get configuration data, etc. OVSDB early to define a standard northbound interface, as use-
is therefore a complementary protocol to OpenFlow for cases are still being worked out [18]. Anyway, it is to
Open vSwitch. be expected a common (or a de facto) northbound in-
terface to arise as SDN evolves.
3.3 Network hypervisor
Long standing virtualization primitives such as VLANs, 3.6 Programming languages
NAT, and MPLS provide only limited forms of network OpenFlow resembles an assembly-like machine lan-
virtualization. These solutions are also anchored on a guage, essentially mimicking the behavior of forwarding
box-by-box basis configuration. The programmability devices, forcing developers to spend too much time on
offered by an SDN has the means to provide full network low-level details rather than on the problem to solve.
virtualization – not only isolation of virtual networks, Raw OpenFlow programs have to deal with hardware
but also topology and addressing virtualization. behavior details such as overlapping rules, the priority
FlowVisor [14] was the earliest attempt to virtualize ordering of rules, and data-plane inconsistencies that
an SDN. This platform acts as a proxy between the con- arise from in-flight packets whose flow rules are under
troller and the forwarding devices to provide an abstrac- installation. The use of these low-level languages makes
tion layer that slices an OpenFlow data plane, allowing it difficult to reuse software, to create modular and ex-
multiple controllers each to control its share (its slice) of tensive code, and leads to a more error-prone devel-
a single physical infrastructure. The isolation properties opment process. Abstractions provided by high level
provided by FlowVisor thus allow several networks to network programming languages [19] can significantly
co-exist. OpenVirteX [15] extends FlowVisor to provide help address many of the challenges of these lower-level

3
instruction sets. velopment of many Operating Systems. In addition, the
open interfaces to program on the operating systems
3.7 Network applications led to a myriad of applications developed by hundreds
Network applications can be seen as the “network to thousands of different companies. In summary, the
brains”. They implement the control-logic that will be commoditization of hardware and the creation of open
translated into commands to be installed in the data interfaces “horizontalized” the computer industry, in-
plane, dictating the behavior of the forwarding devices. creasing its pace of innovation and ultimately resulting
Take a simple application as routing as an example. The in a huge industry.
logic of this application is to define the path through Something similar is happening in networking today
which packets will flow from a point A to a point B. To (Figure 4). The networking industry was, until re-
achieve this goal a routing application has to, based on cently, based on specialized hardware, specialized con-
the topology input, decide on the path to use and in- trol planes and specialized control programs. As com-
struct the controller to install the respective forwarding puters in the 1980s, this naturally led to a vertically in-
rules in all forwarding devices on the chosen path, from tegrated industry, closed, proprietary, with a slow pace
A to B. of innovation.
Existing SDN applications either perform traditional
Specialized Features Net App Net App Net App
functionality such as routing, load balancing, and se- Specialized
SpecializedFeatures
Features Net App
App
Net App
App
Net App
App
curity policy enforcement, or explore novel approaches,
such as reducing power consumption [20]. Other ex- Closed Interface
Closed Interface Open Interface

amples include fail-over and reliability functionalities Specialized Control

Specialized Control NOX Beacon ONOS
to the data plane, end-to-end QoS enforcement, net- Plane
Plane
work virtualization, mobility management in wireless
Closed Interface
Closed Interface Open Interface
networks, among many others [2]. The variety of net-
work applications, combined with real use case deploy-
ments, is expected to be one of the major forces on
fostering a broad adoption of SDN. Merchant Switching
Specialized Switching
Chips
Chips

4. AN INDUSTRY CHANGE
SDN is leading to a profound change in the network- Figure 4: Change in the networking industry
ing industry. The emergence of this new paradigm gave
rise to analogies with the computer industry [21]. In the The availability of merchant switching chips is lead-
1980s, computers were based on specialized hardware, ing to the commoditization of networking equipment, a
specialized operating systems and specialized applica- trend comparable to the one originated by the micropro-
tions, all from the same vender (Figure 3). This indus- cessor. The advent of open interfaces to the switches,
try was thus vertically integrated, closed, proprietary, such as OpenFlow, has led to the emergence of a large
and small. The pace of innovation was relatively slow. number of controllers and network control applications.
This trend shows no sign of decreasing, and the materi-
Net App Net App
Specialized
SpecializedApplications
SpecializedApplications
Applications
Net App
Net App
App
Net App
App
Net App
App
alization of open northbound APIs will arguably foster
the emergence of an even larger number of network ap-
Closed Interface Open Interface plications. As with compute, the hardware commoditi-
zation and the availability of open interfaces to program
Specialized Operating BSD Linux Mac OS
Systems it are leading to a “horizontalization” of the networking
industry. Indeed, we are already experiencing a surge
Closed Interface Open Interface
in network innovation (network virtualization is a good
example) and the emergence of a significant number of
networking start-ups.
Commodity Hardware
Specialized Hardware
(microcomputer) 4.1 Is such change really happening?
(mainframe)

In one word, we claim: yes. Table 1 shows a (non-

Figure 3: Change in the computer industry exhaustive) list of a) switches with OpenFlow support,
b) SDN controllers and c) applications. As is clear, the
The development of the microprocessor has provoked trend illustrated in the rightmost part of Figure 4 is
a fundamental change, leading to the commoditization being fulfilled. Most vendors of commercial switches
of computers. The microprocessor and the creation of already include OpenFlow support in their equipment.
open interfaces to program it led, over time, to the de- Also, the number of controllers is already significant, as

4
is the number of control programs. smoothly. Management applications are sophisticated
The world’s largest IT companies are now part of a in their own right. More challenging still, the different
number of SDN consortia, which is demonstrative of its applications that continuously run in these networks (it
impact in the industry. The Open Networking Foun- is common to have, for instance, a traffic engineering
dation (ONF) [4], for instance, is an organization ded- application alongside another to mitigate link failures)
icated to the promotion and adoption of SDN through can conflict with each other.
open standards development. Its signature accomplish- Statesman [10] is an SDN-based solution deployed
ment is the introduction of the OpenFlow standard. in Microsoft Azure datacenters that provides a state
The ONF already has over 150 member companies in- management abstraction aimed to solve this problem.
cluding dozens of start-ups exclusively dedicated to SDN Specifically, this service introduces two main ideas to
technology. Another good example of this trend is the simplify the design and deployment of network man-
OpenDaylight initiative [6], a collaborative open source agement applications. First, it maintain different views
project hosted by The Linux Foundation. The goal of of network state to prevent conflicts and invariant vi-
the project is to design and implement an open source olations. Applications cannot change the state of the
SDN platform. For this purpose its members – which network directly. Instead, each application applies its
already add up to more than 40 – commit to donate own logic to the network’s observed state to generate
software and engineering resources for the project. proposed states that may change one or more state vari-
ables. Statesman merges all proposed states into one
5. USE CASES target state while ensuring safety and performance in-
variants. Second, Statesman uses a dependency model
Another indication of the importance of SDN from
to capture the domain-specific dependencies among state
an industrial perspective is its adoption by IT compa-
variables.
nies such as Google, Microsoft, and VMware. The use
cases we present in this section are paradigmatic in that 5.3 Network virtualization
respect.
As mentioned before, networking has long supported
5.1 Traffic engineering virtualized primitives such as virtual links (tunnels such
as MPLS) or broadcast domains (VLANs to slice L2
The wide area network (WAN) that connects the dat-
networks). Traditional network virtualization technolo-
acenters of cloud providers is critical for the perfor-
gies do not provide full network virtualization and re-
mance of Internet services. WAN links are very expen-
quire significant manual network management on a box-
sive, and to guarantee the required performance WAN
by-box basis. As a consequence, current network pro-
routers consist of high-end, specialized equipment. To
visioning can take months, while compute provisioning
compound the problem, providers are unable to fully
takes only minutes.
leverage their high investment on the infrastructure.
VMware has recently started offering a network vir-
Given the extreme lack of efficiency of these inter-datacenter
tualization solution using SDN principles, the Network
networks they are provisioned for an average utilization
Virtualization Platform (NVP) [8] (commercialized as
of 30-40%.
NSX [9]). NVP is designed for multi-tenant datacenters
Recognizing this problem, Google and Microsoft have
and has been deployed in dozens of production environ-
deployed large-scale SDN infrastructures for boosting
ments over the last few years. NVP is an edge-based
the utilization of their inter-datacenter links. These
implementation that does not require SDN-based hard-
systems – Google’s B4 [7] and Microsoft’s SWAN [22]
ware. The only requirement is for the datacenter com-
– leverage on SDN to substantially increase the utiliza-
puting resources controlled by NVP to be fully virtual-
tion of their WAN links. In particular, the logical cen-
ized. In NVP a centralized controller cluster is responsi-
tralization of network control enables centralized traf-
ble for configuring the virtual switches in the hypervisor
fic engineering and simpler traffic prioritization, mak-
of every host (OpenvSwitch [13]) with the appropriate
ing it possible to have these links used up to nearly
logical forwarding. The solution then leverages on a
100% utilization without impairing the quality of ser-
set of tunnels between every pair of host-hypervisors to
vice. Besides avoiding link usage inefficiencies, the net-
forward traffic.
work equipment used in these solutions is built from
merchant switch silicon, further reducing costs and in-
creasing flexibility. 6. THE FUTURE OF SDN
We conclude this article with our view on some im-
5.2 Network management portant challenges faced by SDN. The way they will be
Datacenter operators have developed, over the years, addressed will certainly shape its future.
automated systems for managing their traffic and in- First, we expect the SDN software stack to evolve in
frastructure, in order to keep their networks running at least two ways: in offering new network abstractions

5
 Table 1: List of switches with OpenFlow support, controllers and applications
Switch Manufacturers Controllers Applications
Arista Networks Beacon Access control
Big Switch Networks Floodlight Energy-efficient network
Brocade Networks Mul Integrated security
Cisco NOX Load balancing
Dell ONIX Mitigation of DoS attacks
Extreme Networks ONOS Network monitoring
HP Open Daylight Network virtualization
Huawei OpenContrail Network-as-a-Service
IBM POX QoS policy enforcement
Juniper ProgrammableFlow Traffic engineering
NEC Rosemary Traffic steering
NetGear Ryu User mobility
Pica8 Trema VM migration

and in increasing its security and resilience. The work References

around the Frenetic project [19] has pointed the direc- [1] T. Benson, A. Akella, and D. Maltz. “Unravel-
tion for the former, but new abstractions will eventually ing the Complexity of Network Management”. In:
arise, including for network monitoring, traffic engineer- NSDI. NSDI’09. Boston, Massachusetts, 2009, pp. 335–
ing, security, and others. We also expect the security 348.
and dependability of the infrastructure to be an increas-
ing focus of concern in the future [23]. [2] D. Kreutz et al. “Software-Defined Networking:
The initial deployment of SDNs has been mostly fo- A Comprehensive Survey”. In: Proceedings of the
cused in data center environments. It is only natural for IEEE 103.1 (2015), pp. 14–76.
SDN to expand to other, less homogeneous, environ- [3] N. McKeown et al. “OpenFlow: enabling innova-
ments, ranging from carrier-grade backbones and cel- tion in campus networks”. In: SIGCOMM CCR
lular networks to inter-domain routing (e.g., Internet 38.2 (Mar. 2008), pp. 69–74.
exchange points). [4] ONF. Open Networking Foundation. http://www.
The problem of migration from traditional networks opennetworking.org/. 2014.
to SDN and the emergence of hybrid deployments is
[5] S. Shenker. The Future of Networking, and the
a related challenge. Panopticon [24] is one example of
Past of Protocols. 2011.
an architecture and methodology that implements SDN
inside enterprise legacy networks. We anticipate other [6] OpenDaylight. OpenDaylight: A Linux Founda-
such solutions to appear to increase the pace of SDN tion Collaborative Project. http://www.opendaylight.
adoption. org. 2013.
Finally, the integration of Network Function Virtu- [7] S. Jain et al. “B4: experience with a globally-
alization (NFV) with SDN is another important chal- deployed software defined wan”. In: SIGCOMM.
lenge. NFV is an emergent concept that proposes the SIGCOMM ’13. Hong Kong, China: ACM, 2013,
use of virtualization technologies to virtualize network pp. 3–14.
node functions, therefore enabling middlebox function-
[8] T. Koponen et al. “Network Virtualization in Multi-
ality to run on virtual machines. Its integration with
tenant Datacenters”. In: NSDI. Seattle, WA, Apr.
SDN is increasingly being considered fundamental by
2014, pp. 203–216.
the networking industry – it is one of the main goals
of the OpenDaylight project, for instance – as a pro- [9] VMware, Inc. VMware NSX Virtualization Plat-
moter of the softwarization of the complete networking form. 2013.
infrastructure. [10] P. Sun et al. “A Network-state Management Ser-
vice”. In: SIGCOMM. SIGCOMM ’14. Chicago,
7. REFERENCES Illinois, USA: ACM, 2014, pp. 563–574.

6
[11] K. Greene. MIT Tech Review 10 Breakthrough Tech-
nologies: Software-defined Networking. goo.gl/KVDOD1.
2009.
[12] B. Pfaff and B. Davie. The Open vSwitch Database
Management Protocol. RFC 7047 (Informational).
Internet Engineering Task Force, Dec. 2013.
[13] B. Pfaff et al. “The Design and Implementation of
Open vSwitch”. In: NSDI. Oakland, CA: USENIX
Association, May 2015, pp. 117–130.
[14] R. Sherwood et al. “Can the production network
be the testbed?” In: OSDI. OSDI’10. Vancouver,
BC, Canada, 2010, pp. 1–6.
[15] A. Al-Shabibi et al. “OpenVirteX: Make Your Vir-
tual SDNs Programmable”. In: HotSDN. HotSDN
’14. Chicago, Illinois, USA: ACM, 2014, pp. 25–
30.
[16] N. Gude et al. “NOX: towards an operating sys-
tem for networks”. In: CCR (2008).
[17] T. Koponen et al. “Onix: a distributed control
platform for large-scale production networks”. In:
OSDI. OSDI’10. Vancouver, BC, Canada: USENIX
Association, 2010, pp. 1–6.
[18] J. Dix. Clarifying the role of software-defined net-
working northbound APIs. goo.gl/7MXw4o. 2013.
[19] N. Foster et al. “Frenetic: a network programming
language”. In: SIGPLAN Not. (2011).
[20] B. Heller et al. “ElasticTree: saving energy in data
center networks”. In: NSDI. NSDI’10. San Jose,
California: USENIX Association, 2010, pp. 17–17.
[21] N. Mckeown. How SDN will Shape Networking.
2011.
[22] C.-Y. Hong et al. “Achieving high utilization with
software-driven WAN”. In: SIGCOMM. SIGCOMM
’13. Hong Kong, China: ACM, 2013, pp. 15–26.
[23] D. Kreutz, F. M. Ramos, and P. Verissimo. “To-
wards secure and dependable software-defined net-
works”. In: Proceedings of the second ACM SIG-
COMM workshop on Hot topics in software de-
fined networking. HotSDN ’13. Hong Kong, China:
ACM, 2013, pp. 55–60.
[24] D. Levin et al. “Panopticon: Reaping the Ben-
efits of Incremental SDN Deployment in Enter-
prise Networks”. In: USENIX ATC. USENIX ATC
’14. Philadelphia, PA: USENIX Association, 2014,
pp. 333–345.