You are on page 1of 9


discussions, stats, and author profiles for this publication at:

A Compass Through SDN Networks

Technical Report October 2013


1 236

5 authors, including:

Thomas Zinner Michael Jarschel

University of Wuerzburg Nokia


Tobias Hossfeld Phuoc Tran-Gia

University of Duisburg-Essen University of Wuerzburg


All in-text references underlined in blue are linked to publications on ResearchGate, Available from: Tobias Hossfeld
letting you access and read them immediately. Retrieved on: 22 June 2016

Interfaces, Attributes, and Use Cases:

A Compass for SDN
Michael Jarschel, Thomas Zinner, Tobias Hofeld, Phuoc Tran-Gia, and Wolfgang Kellerer

ABSTRACT exist, is not enough to brand a device or technol-

ogy as Software Defined Networking. The
The term Software Defined Networking (SDN) external controller has to have the ability to
is prevalent in todays discussion about future change the forwarding behavior of the network
communication networks. As with any new term element directly. This enables several key bene-
or paradigm, however, no consistent definition fits of SDN. The control- and data plane can be
regarding this technology has formed. The frag- developed separately from each other, which
mented view on SDN results in legacy products lowers the entry-to-market hurdle, as a company
being passed off by equipment vendors as SDN, no longer has to have expert knowledge in both
academics mixing up the attributes of SDN with areas. Moreover, the externalization of a soft-
those of network virtualization, and users not ware-based controller produces pressure on
fully understanding the benefits. Therefore, established hardware switch vendors, which are
establishing SDN as a widely adopted technology reduced to providing forwarding hardware only.
beyond laboratories and insular deployments This has already introduced new and disruptive
requires a compass to navigate the multitude of start-ups to the market that have sped up inno-
ideas and concepts that make up SDN today. vation in the network. Even the market leader
The contribution of this article represents an Cisco has reacted to this trend by introducing its
important step toward such an instrument. It own flavor of SDN with the Application Centric
gives a thorough definition of SDN and its inter- Infrastructure concept developed at the Spin-In
faces as well as a list of its key attributes. Fur- company Insieme. Customers are also enabled
thermore, a mapping of interfaces and attributes to mix-and-match products of different ven-
to SDN use cases is provided, highlighting the dors and thus increase competition further. The
relevance of the interfaces and attributes for switch vendors have reacted to the growing
each scenario. This compass gives guidance to a interest in SDN, forming the OpenDaylight pro-
potential adopter of SDN on whether SDN is in ject for an open SDN software platform.
fact the right technology for a specific use case. Challenges in this area are to find the appro-
priate control protocol for the specific scenario
out of different protocols and protocol versions,
PRINCIPLES OF and the appropriate forwarding elements that
SOFTWARE DEFINED NETWORKING support this protocol.

How networks are currently structured and oper- LOGICALLY CENTRALIZED CONTROL
ated poses a significant financial issue to Inter- The controller of an SDN network is a logically
net service providers and, in fact, has become a centralized entity, that is, it can consist of multi-
handicap for progress in the cloud and service ple physical or virtual instances, but behaves like
provider space. SDN [1] enables a programmable a single component. The global network infor-
network control and offers a solution to a variety mation such a central controller possesses
of use cases. The success stories of these bot- enables it to adapt its network policy with respect
tom-up SDN solutions have led to a shift in the to routing and forwarding much better and faster
way operators and vendors perceive the network. than a system of traditional routers could.
In the following we define four basic principles The realization of a logically centralized con-
of SDN. Each of these principles is mandatory troller is challenging with respect to scalability
for classifying a technology as SDN. depending on the specific scenario and network or
Michael Jarschel, Thomas virtual network size. Scalability can be achieved
Zinner, Tobias Hofeld, SEPARATION OF CONTROL- AND DATA PLANE by implementing a centralized controller as a
and Phuoc Tran-Gia are The physical separation of the control- and for- distributed system where the contained informa-
with University of warding- or data plane is the best-known principle tion has to be maintained consistently.
Wrzburg. of SDN [1, 2]. It postulates the externalization of
the control plane from a network device to an OPEN INTERFACES
Wolfgang Kellerer is with external control plane entity often called the For SDN to reach its full potential in terms of
Technische Universitt controller. In particular this means that an flexibility and adaptability, it is fundamental that
Mnchen. internal software control plane, while it may still its interfaces are and remain open. A closed or

2 0163-6804/14/$25.00 2014 IEEE IEEE Communications Magazine June 2014

Control Control Control
module module module To maintain open
Application control plane interfaces might be
challenging since
Northbound API
vendors try to intro-
Control Application Control
module control interface module duce proprietary
SDN network control Legacy network interfaces or to
SDN network control plane
plane control plane
Westbound API Eastbound API bypass proprietary
information via the
Southbound API
open interface. This
Hypervisor could generate addi-
Switch Switch
Hypervisor vSwitch tional value if entities
Hypervisor vSwitch User
of the same vendor
vSwitch Switch
are used, but also
lead to deadlocks
Cloud SDN WAN Legacy WAN
and performance
Figure 1. Example: interfaces of a software defined network. bottlenecks in
mixed operation.
proprietary interface limits component exchange- DEFINITION AND SIGNIFICANCE OF
ability and innovation. This is especially true for SDN INTERFACES
the interface between control- and data plane
(Southbound Interface). In the absence of a The four key interfaces of Software Defined
standard open interface, one of the main SDN Networking are illustrated in Fig. 1 for a generic,
advantages the interchangeability of network example network, consisting of three
devices and control planes would be taken away. autonomous systems (AS): a conventional IP or
This is also true for the remaining interfaces, which legacy access network at the user end, an SDN-
are discussed in more detail in the next section. based transit-WAN, and an SDN-enabled data
To maintain open interfaces might be chal- center network (cloud).
lenging since vendors try to introduce propri-
etary interfaces or to bypass proprietary Southbound-API The Southbound-API rep-
information via the open interface. This could resents the interface between control- and data
generate additional value if entities of the same plane. It is the enabler for the externalization of
vendor are used, but also lead to deadlocks and the control plane and therefore key to the corre-
performance bottlenecks in mixed operation. sponding SDN principle [2, 3]. Its realization is a
standardized instruction set for the networking
PROGRAMMABILITY hardware. Implementation examples are the
The fundamental paradigm shift in networking IETF ForCES Protocol [4] and most notably the
SDN has initiated is represented by programma- OpenFlow protocol [5].
bility. It is enabled by the external software con-
troller and open interfaces. The programmability Northbound-API SDN enables the exchange
principle is not limited to introducing new network of information with applications running on top
features to the control plane, but rather repre- of the network. This information exchange is
sents the ability to treat the network as a single performed via the Northbound-API between the
programmable entity instead of an accumulation SDN controller and an application control
of devices that have to be configured individual- plane [2, 3]. A universal, standardized North-
ly. SDN can thus be regarded as a very suitable bound API does not exist. Further, as the kind
complement to network virtualization, providing of information exchanged, its form and frequen-
the control plane for an easy operation (pro- cy depends on the targeted application and net-
gramming) of, for example, virtual networks in work, such universal API is not useful.
network substrates or to control specific flows Standardization of this interface only makes
within a virtual network as possible applications. sense for common scenarios, provided that all
Here it is essential to find the appropriate implementations are kept open. While the SDN
abstraction level, which determines on the one controller can directly adapt the behavior of the
hand the ease-of-use for network programmers, and network, the application controller adapts the
on the other hand the abstraction overhead and behavior of the application using the network. It
therewith a possible performance degradation. can be implemented as part of a single applica-
tion instance to a central entity for the entire
network responsible for all applications.
Westbound-API The Westbound-API serves
SOFTWARE DEFINED NETWORKING as an information conduit between SDN control
Key components of the SDN compass are its planes of different network domains [6]. It allows
interfaces and features. the exchange of network state information to

IEEE Communications Magazine June 2014 3

influence routing decisions of each controller, time-scales. This covers wide area networks
Programmability is but at the same time enables the seamless setup where only a few change operations are required
of network flows across multiple domains. For per day, to data center networks where the con-
not only a principle the information exchange, standard inter-domain stant instantiation or migration of virtual
but also the key fea- routing protocols like BGP could be used. machines and their network connectivity has to
ture of SDN and happen in minutes or even seconds.
Eastbound-API Communication with the Example: In case of an overloaded link between
drives most SDN use control planes of non-SDN domains, for exam- two network elements with multiple routes, pri-
cases. This opens the ple, a Multi-Protocol Label Switching (MPLS) ority traffic is identified through application
control plane, uses the Eastbound-API [7]. The information and rerouted with minimal delay [9].
control plane to implementation of this interface depends on the In this case the SDN controller receives informa-
innovation using technology used in the non-SDN domain. Essen- tion about individual flows from the application
conventional soft- tially, a translation module between SDN and control plane to determine whether a certain
the legacy technology is required. In this way, application actually needs more resources and
ware development both domains should ideally appear to be fully allocates a higher priority to its flows.
methods, in turn compatible to each other. For example, the SDN
domain should be able to use the routing proto- Granularity Networking spans different pro-
enabling the col deployed between non-SDN domains or be tocol layers and also levels of data flow aggre-
customization of the able to react to Path Computation Element Pro- gates. SDN enables the control of traffic flows
network according tocol (PCEP) messages requesting path setups with a different granularity on both the aggregate
from an MPLS domain. level and the protocol layers. This can range
to a specific setup from large MPLS tunnels in core networks to a
or scenario. DEFINITION OF SDN FEATURES single TCP connection in a home LAN. This is a
The combination of these four open interfaces necessary feature to ensure scalability and enable
together with the core features we outline in the the control plane to work on different levels.
following makes SDN a very flexible and power- Example: In [10] the SDN controller operates
ful tool for network control and operation. Later on the granularity of individual flows to optimize
we show how matching SDNs unique features to the user experience for the user of one particular
use cases can help a potential adopter of SDN to session. This high granularity is feasible in net-
determine whether SDN is the right technology works with a low total number of flows, for exam-
for that use case. ple, home or access networks. In [8] SDN is used
to interconnect a virtualized access network to a
Programmability Programmability is not legacy MPLS core operating on tunnels only.
only a principle but also the key feature of SDN Each tunnel can contain a multitude of flows.
and drives most SDN use cases. This opens the
control plane to innovation using conventional Elasticity The elasticity feature of SDN
software development methods, in turn enabling describes the ability of the SDN network control
the customization of the network according to a plane to increase and decrease its resource con-
specific setup or scenario. sumption based on the required capacity. As
Example: Based on one or more external controllers run in software, they can be flexibly
information resources (e.g. cloud orchestration) instantiated and synchronized using a distributed
the routing in a network is adapted automatically or hierarchical approach on multiple physical or
to optimize resource utilization. Google uses such virtual hosts. This enables the control plane to
a mechanism to optimize the bandwidth usage react to variations in traffic mix and volume.
on links between the companys data centers. It Example: Due to a temporarily increased
achieves this by leveraging information from the amount of control traffic in a data center net-
traffic sources and grouping application traffic work, the SDN controller can no longer be host-
into flow groups with different priorities [6]. ed by a single physical device and has to be
distributed among several machines. However,
Protocol Independence Protocol indepen- when the situation resolves itself, the control plane
dence enables SDN to control or run in conjunc- can again be relocated to its original host in order
tion with a large variety of networking technolo- to conserve resources. There are several approach-
gies and protocols on different network layers. es to achieve this kind of distributed SDN con-
This feature enables migration strategies from trol plane. The Onix [11] realization is based on
old to new technologies and supports the possi- synchronizing the network information base, that
bility to even run a different network protocol is, the global state of the network, across a clus-
stack tailored for each application. ter of servers. Each server directly manages a
Example: In order to enable the migration subset of network elements and exchanges infor-
from IPv4 to IPv6 a network operator decides to mation with the rest of the network controller
run both versions of IP in parallel. This is usually instances via the shared network state.
done using tunnels and encapsulation. The authors
in [8] propose to use SDN-enabled forwarding
elements with a centralized control plane to USE CASES FOR
dynamically set up the tunnels at the end points.
Ability to Dynamically Modify Network This section introduces several use cases that we
Parameters The ability to actively modify have selected to derive and to illustrate a method
network parameters in a dynamic manner that is for classifying SDN in terms of the above fea-
close to real time defines this SDN feature. tures and interfaces.
Dynamic re-configuration is feasible in different

4 IEEE Communications Magazine June 2014

Routing services that
Over the last decade cloud services have devel- The API between data plane forwarding and a
oped at a rapid pace. However, the innovation in centralized control plane in SDN provides ample can be realized by
this field was mainly confined to server and data opportunities for a routing protocol adaptation, the SDN concept, for
center technologies as well as distributed appli- which is very difficult in existing decentralized example, through
cations. This has led to networks becoming a routing schemes implemented on closed box net-
hindrance for cloud operations. A major reason work elements. Routing services that can be real- programming mod-
for this is the fact that networks and servers ized by the SDN concept, for example, through ules on OpenFlow
were traditionally managed separately. For cloud programming modules on OpenFlow controllers
applications to be provisioned and operated directing OpenFlow Switches, include path selec- controllers directing
quickly and in an automated manner, the man- tion for traffic optimization, multi-homing, OpenFlow Switches,
agement of both network and cloud framework secure routing, path protection, and migration include path selec-
needs to be integrated. between protocol versions, that is, IPv6.
SDN is a viable way to achieve this integra- In [13] the authors propose a hybrid SDN/BGP tion for traffic
tion, as the SDN controller as well as the cloud control plane that on the one hand leverages the optimization, multi-
orchestration framework is software, and a (stan- new possibilities in a simplified centralized rout-
dardized) interface between both worlds is there- ing approach, and other hand benefits from the homing, secure rout-
fore easily attainable. This interface can then, compatibility with legacy networks. ing, path protection,
for example, be used to notify the network con- and migration
troller of an imminent virtual machine migration MONITORING AND MEASUREMENT
or to notify the cloud orchestration that a link is SDN provides the network the ability to perform between protocol
overloaded and the server load should be moved certain network monitoring operations and mea- versions, that is, IPv6.
to a different location. surements without any additional equipment or
In [11] the benefits of such an interface are overhead. The concept was introduced in [14]
shown. The cloud orchestration software Open- and is based on the fact that an SDN inherently
Nebula is used to orchestrate virtual servers across collects information about the network to main-
multiple hosts and show that a short advance tain a global network state at the logically cen-
notification from the cloud orchestration to the tralized controller. This information can then be
SDN controller before a virtual machine migra- processed in software to obtain a subset of moni-
tion was sufficient to maintain the user sessions of toring parameters. Furthermore, active measure-
a video streaming service during the migration. ments are enabled by selectively mirroring
specific production traffic flows to the control
LOAD BALANCING plane or an external measurement device with-
Another service required for the successful oper- out the need to introduce artificial and poten-
ation of online services that are hosted in data tially disruptive measurement probe traffic into
centers is load balancing. Online services, e.g. the network. For example, by mirroring the traf-
search engines and web portals, are often repli- fic for a phone call at ingress and egress point of
cated on multiple hosts in a data center for effi- the network, the network administrator can
ciency and availability reasons. Here a load determine the delay and quality of service for a
balancer dispatches client requests to a selected particular call at a certain time.
service replica based on certain metrics such as
server load. In general, a load balancer is typi- NETWORK MANAGEMENT
cally a separately deployed function in a network Todays network management policies are usual-
that distributes the load among network and ly decided upon by the network operator and then
data center elements in its scope according to a configured once in each network element by an
certain optimization metric such as minimum administrator. The larger the network, the higher
average load or link cost. the required configuration effort becomes. Hence,
Todays solutions for load balancers are effec- an established policy is seldom modified. This
tive but have limited flexibility in terms of cus- leads to an often very inefficient network opera-
tomization. Being a proprietary middlebox tion. The fact that traffic patterns continually
function, such solutions also come at a high cost. change cannot be taken into account this way.
When using SDN technologies, load balancing In order to change this, the network needs to
can be integrated within any forwarding element be able to adapt policies dynamically and auto-
in the network, e.g. OpenFlow switch, avoiding matically based on a range of information. This
the need for separate devices. Furthermore, calls for a more general specification of network
SDN allows load balancing to operate on any policies that are subsequently translated into
flow granularity. specific rules for each device in the network
In [11] a use case for a data center load bal- using a policy engine. The logically centralized
ancer is described and a solution based on Open- control plane of SDN offers itself as a very suit-
Flow is proposed. Instead of using a traditional able way to enable such an approach, as it has
middlebox solution the functionality is realized all information about the network available.
at the OpenFlow controller and enforced by set- For example, a high-level network policy dic-
ting aggregate flow rules using wildcards in the tates the prioritization of VoIP traffic inside an
network elements. In this way the need for a Enterprise network. The SDN controller can
dedicated balancer device is no longer existent. then identify corresponding network flows and
Current research tries to provide an abstract lan- assign them to a high priority level in each
guage that allows programmers to directly con- device. This is dynamic on the one hand as VoIP
trol the network and mechanisms such as load flows are set up and terminated with each phone
balancing [12]. call, and on the other hand it is automated as

IEEE Communications Magazine June 2014 5

Interface Southbound Northbound Eastbound Westbound A USE CASE BASED ANALYSIS OF
Use case interface interface interface interface SDN INTERFACES AND FEATURES

X X** To analyze the importance of SDN in terms of
its interfaces and features for different use cases,
Load balancing X we map each of the use cases shown in the pre-
vious section to them. We validate the presented

Routing X features and their mapping to the use-cases.
Thus, the compass guides a potential adopter of

Monitoring and SDN, whether SDN in fact is the right technolo-
measurement gy for an arbitrary use case.
In the first step of our analysis, we map the

Network use cases to the SDN interfaces as shown in
management Table 1. Reliance on an interface is checked,
whereas non-reliance is marked with an X. As

Application- can be seen, not all use cases depend on all inter-
awareness faces. In fact, the only use case leveraging all
interfaces of SDN is the Monitoring and Mea-
The Westbound interface is not used in cases where the load balancer is only surement use case. Overall, the use cases are
responsible for a single SDN domain, e.g. a single data center.
quite heterogeneous in terms of SDN interface
** The Westbound interface is used when parts of the cloud are connected via
dependency. The most used interface appears to
a non-SDN controlled network, e.g. MPLS PCE.
be the Northbound-API interface. However,
Table 1. Mapping of use cases to SDN interfaces. Reliance on an interface no conclusion is drawn about the importance of
is checked, whereas non-reliance is marked with an X. an interface here. This depends on the specific
implementation of a use case, on how an inter-
face is used, and therefore how crucial it is. To
the devices are configured without the need for apply the SDN compass it is important enough to
physical access and any human intervention. In understand which interfaces to use for a consid-
fact, the administrator does not have to know ered use case to be implemented using SDN.
the topology of the network or the devices In the second step of our use case analysis,
involved in order to achieve the policys goal. we classify the use cases according to:
Such an approach has been implemented proto- The importance of each of the above identi-
typically in [15]. fied features as a use case enabler: HIGH
(***) = enables service, MEDIUM (**) =
APPLICATION-AWARENESS improves service significantly, LOW (*) =
Using network resources efficiently and optimiz- nice to have.
ing traffic flows toward high end-user Quality of The area of application in which these fea-
Experience (QoE) is an often cited goal for next tures are most important for each use case:
generation networks. However, it is difficult to Data Center = one data center, WAN =
realize when nothing is known about the kind of ISP Core network, Enterprise = Enterprise
applications that are run on the network and network without enterprise data center.
their state. Existing approaches in this direction As a result of the use case classification apply-
often rely on Deep Packet Inspection to identify ing these simple metrics, we obtain Table 2.
the applications. This, however, is not a very Here we observe horizontal clusters as well as
accurate technique and does not take the appli- local clusters of importance across the different
cation state or QoE into account at all [16]. use cases and areas of application. This analysis
With the Northbound-API of the SDN con- does not only validate the five SDN features as
troller, the application itself can inform the net- described previously, but also allows us to identi-
work about its properties and state. In this way, fy the importance of each feature for certain
the network controller can direct traffic flows to classes of SDN use cases.
complement rather than disrupt each other Let us have a closer look at the table. There
[9,17]. Furthermore, a previously made forward- are entire rows filled with a background color
ing decision can be revised in light of changing where all features are classified as highly impor-
situations in the network and a different applica- tant enablers for a use case. These horizontal lines
tion state. The other way around, if the network are limited to one application area only. Cloud
can no longer sustain a certain service level for orchestration, for example, is a use case that is
the application due to lack of resources, it can focused on data center environments. This is also
notify the application to modify its behavior. For confirmed by the table where the horizontal line
example, due to its architecture, SDN easily marking each SDN feature with high importance
allows cross-layer optimization between applica- runs in the data center application area. A similar
tions and their demands and the network capa- observation can be made for monitoring. Here
bilities. Thus, a better use of the network enterprise networks benefit most from all SDN
resources with respect to more generic con- features due to the high application mix that has
straints such as user-centrality [9] or energy-effi- to be monitored in enterprise networks.
ciency [11] is possible. Local clusters of importance (dark) point to a
particular importance of one SDN feature for a
use case across all three areas of application.
For example, the time-dynamics to be realized
for SDN-based routing for path protection are

6 IEEE Communications Magazine June 2014

Feature Area of Protocol
Elasticity Programmability Dynamic Granularity
Use case application independence

Data center *** *** *** *** ***

Cloud orchestration WAN * * ** * ***

Enterprise * * ** * ***

Data center * * * *** **

Load balancing WAN * * ** ** **

Enterprise * * ** ** **

Data center * *** * *** **

Routing/forwarding WAN ** **** *** ** **

Enterprise * *** ** *** **

Data center ** ** *** ** ***

Monitoring and
WAN * ** *** * ***
Enterprise *** *** *** *** ***

Data center ** *** *** ** **

WAN * *** *** * **
Enterprise * *** *** * **

Data center * *** *** *** ***

WAN * *** *** *** ***
Enterprise * *** *** *** ***

Table 2. Mapping of Use Cases to SDN Features. The importance of each of the above identified features as a use case enabler:
HIGH (***) = enables service, MEDIUM (**) = improves service significantly, LOW (*) = nice to have. The area of applica-
tion in which these features are most important for each use case: Data Center = one data center, WAN = ISP Core network,
Enterprise = Enterprise network without enterprise data center. Local clusters of importance (dark grey) point to a particular
importance of one SDN feature for a use case across all three areas of application. Complete rows marked with a background
color indicate that all features are classified as highly important enablers for the use case, but limited to one application area

based on the dynamic feature of SDN as the key nitions and a lack of methodology for assessing
enabler. Monitoring is mostly concerned with the suitability of SDN concepts for certain use
data gathering across protocols and different lev- cases. Current discussions direct SDN toward an
els of granularity. This is confirmed by the table image of being a universal solution in networking.
with the SDN features protocol independence As a basis for such a methodology, we defined
and granularity expressing high importance four main interfaces in an SDN-enabled network
markings. Network management is based on the control architecture the southbound, eastbound,
features programmability and protocol indepen- westbound, and northbound interfaces and
dence as here the configuration aspect is a key we identified the five main features provided by
feature enabled by SDN. SDN technologies: programmability, protocol
The general use case application awareness independence, dynamic, granularity, and elasticity.
shows four importance clusters, namely: pro- Our analysis of selected use cases based on
grammability, protocol independence, dynamic, related publications mainly taken from recent
and granularity. workshops, conferences, and journal articles
(cloud orchestration, load balancing, routing,
measurement, network management) provides a
KEY DERIVATIONS methodology for assessing the importance of
The above definitions and use case analysis aim SDN as an enabler for certain use cases.
to create an understanding of the applicability of Our discussion shows that the use cases
the SDN principles. There is a lack of clear defi- depend on different application areas (Data cen-

IEEE Communications Magazine June 2014 7

ter, Enterprise, WAN). Referring to Table 2 we Specification,
ietf-forces-protocol-08.txt, 2006.
This approach can cannot determine a specific area of application [5] N. McKeown et al., OpenFlow: Enabling Innovation in
where SDN excels. Furthermore, different inter- Campus Networks, ACM SIGCOMM Comp. Commun.
be adapted to help faces are needed for each use case, that is, not Rev., vol. 38, no. 2, April 2008, pp. 6974.
classify other use all interfaces have to be implemented. Accord- [6] S. Jain et al., B4: Experience with a globally-deployed
software defined WAN, Proc. ACM SIGCOMM 2013
cases and gauge the ingly, development guidelines for specific con- Conference, Aug. 2013, pp. 314.
trollers can be derived based on the analysis of [7] A. Devlic, W. John, and P. Skldstrm, Carrier-Grade
potential benefits of the specific use-case in relation to the features Network Management Extensions to the SDN Frame-
and interfaces used. Different use cases are work, Proc. 8th Swedish National Computer Network-
using SDN in their ing Wksp. SNCNW 2012, June 2012.
based on different SDN features, that is, the [8] G. Hampel, M. Steiner, and B. Tian, Applying Soft-
context. Their main implementation of the features depends on the ware-Defined Networking to the Telecom Domain,
features can be iden- specific use-case. Proc. 16th IEEE Global Internet Symp. in conjunction
Similarly, a corresponding analysis of a new with IEEE INFOCOM, Apr. 2013, pp. 1338.
tified and weighted, [9] M. Jarschel et al., SDN-based Application-Aware Net-
use case can reveal whether the use case can working on the Example of YouTube Video Streaming,
and the implementa- benefit from SDN technology, that is, is there at Proc. 2nd European Wksp. Software Defined Networks
tion focus of the least one feature with high. Furthermore, the (EWSDN 2013), Oct. 2013, pp. 8792.
benefit of SDN for a certain use case increases [10] T. Koponen et al., Onix: A Distributed Control Plat-
required network with the number of important features identified. form for Large-scale Production Networks, Proc. 9th
USENIX Conf. Operating Systems Design and Imple-
applications can be Additionally, we can observe that there are more mentation (OSDI 10), Oct. 2010, pp. 35164.
planned accordingly. advanced use cases that cannot be realized in [11] M. Jarschel and R. Pries, An OpenFlow-Based Energy-
todays networks. These use cases can benefit Efficient Data Center Approach, Proc. ACM SIGCOMM
2012 Conf., Aug. 2012, pp. 878.
from or are even enabled by SDN features such [12] C. Monsanto et al., Composing Software Defined
as the presented application awareness use-case. Networks, Proc. 13th USENIX Symp. Networked Sys-
Despite the operational use-cases discussed tems Design and Implementation (NSDI 13), Apr. 2013,
above, SDN also drives innovation in other pp. 113.
[13] C. E. Rothenberg et al., Revisiting Routing Control
areas. Particularly in research testbeds [18], for Platforms with the Eyes and Muscles of Software-
prototyping [19], and for service rollout (Beta Defined Networking, Proc. First Workshop on Hot Top-
Slice), the capabilities of SDN enable innovation ics in Software Defined Networks (HotSDN 12), Aug.
within networks. Accordingly, the areas of appli- 2012, pp. 1318.
[14] C. Yu et al., FlowSense: Monitoring Network Utiliza-
cation are not limited to the discussed use-cases, tion with Zero Measurement Cost, Proc. Passive and
but are expected to expand beyond the scope of Active Measurement Conf. (PAM 2013), Jan. 2013, pp.
todays networks. However, this discussion is not 3141.
the intended topic of this article. [15] H. Kim and N. Feamster, Improving Network Manage-
ment with Software Defined Networking, IEEE Com-
mun. Mag., vol. 51, no. 2, Feb. 2013, pp. 11419.
CONCLUSION [16] T. Hofeld et al., Challenges of QoE Management for
Cloud Applications, IEEE Commun. Mag., vol. 50, no.
Due to its innovation potential, SDN is seen as 4, Apr. 2012, pp. 2836.
[17] G. Wang et al., Programming Your Network at Run-
one key technology to enable and operate next- Time for Big Data Applications, Proc. First Workshop
generation networks. However, different defini- on Hot Topics in Software Defined Networks (HotSDN
tions and meanings of the term SDN currently 12), August 2012, pp. 10308.
exist, leading to a fragmented view. [18] R. Sherwood et al., Can the Production Network be
the Testbed, Proc. 9th USENIX Conf. Operating Sys-
This article is a major step toward a better tems Design and Implementation (OSDI 10), Oct. 2010,
understanding of SDN, its necessary interfaces, pp. 36578.
as well as its key attributes. Based on an induc- [19] B. Lantz, B. Heller, and N. McKeown, A Network in a
tive approach, we derived a mapping of inter- Laptop: Rapid Prototyping for Software-Defined Net-
works, Proc. 9th ACM SIGCOMM Wksp. Hot Topics in
faces and attributes to SDN use cases. In a Networks (Hotnets-IX), article no. 19, Oct. 2010.
second step, a mapping of use cases to SDN fea-
tures, highlighting the importance of the specific
features to the use-cases and areas of applica-
tion, is performed. This approach can be adapt- [1] R. Wang, D. Butnariu, and J. Rexford, OpenFlow-based
Server Load Balancing Gone Wild, Proc. 11th USENIX
ed to help classify other use cases and gauge the Conf. Hot Topics in Management of Internet, Cloud,
potential benefits of using SDN in their context. and Enterprise Networks and Services (HotICE 2011),
Their main features can be identified and weighted, Mar.s 2011.
and the implementation focus of the required
network applications can be planned accordingly. BIOGRAPHIES
Therefore, the main contribution of this arti- MICHAEL JARSCHEL is a Ph.D. candidate working in the Next
cle is to supply SDN adopters with a compass Generation Networks research group at the Chair of Com-
and a map to reach the desired answer to the munication Networks in Wrzburg. He received his diploma
question of using SDN in a specific scenario. in computer science from the University of Wrzburg in
2009. His main research interests are Software Defined
Networking, QoE, and Cloud Networks, with a focus on
REFERENCES performance evaluation.
[1] T. Nadeau and K. Gray, SDN: Software Defined Net-
T HOMAS Z INNER is heading the NGN research group Next
works, OReilly Media, Sept. 2013, ISBN: 978-
Generation Networks at the Chair of Communication Net-
works in Wrzburg. He finished his Ph.D. thesis on Perfor-
[2] Open Networking Foundation, Software-Defined Net-
mance Modeling of QoE-Aware Multipath Video
working: The New Norm for Networks, https://www.
Transmission in the Future Internet in 2012. His main
research interests cover the performance assessment of
resources/white-papers/wp-sdn-newnorm.pdf, 2012.
novel networking technologies, in particular software-
[3] S. Sezer et al., Are We Ready for SDN? Implementation
defined networking and network function virtualization, as
Challenges for Software-Defined Networks, IEEE Com-
well as network-application interaction mechanisms.
mun. Mag., vol. 51, no. 7, July 2013, pp. 3643.
[4] A. Doria, R. Haas, and J. H. Salim, ForCES Protocol

8 IEEE Communications Magazine June 2014

TOBIAS HOSSFELD is heading the FIA research group Future
Internet Applications & Overlays at the Chair of Communi-
cation Networks in Wrzburg. He finished his Ph.D. in
2009 and his professorial thesis Modeling and Analysis of
Internet Applications and Services in 2013. He has pub-
lished more than 100 research papers in major conferences
and journals, receiving four best paper awards, three
awards for his Ph.D. thesis, and the Fred W. Ellersick Prize
2013 (IEEE Communications Society).

PHUOC TRAN-GIA is a professor at the Institute of Computer

Science and head of the Chair of Communication Networks
at the University of Wrzburg, Germany. His current
research areas include architecture and performance analy-
sis of communication systems, and planning and optimiza-
tion of communication networks. He has published more
than 100 research papers in major conferences and jour-
nals, and recently received the the Fred W. Ellersick Prize
2013 (IEEE Communications Society).

WOLFGANG KELLERER is a full professor at the Technische Uni-

versitt Mnchen (TUM), heading the Institute for Commu-
nication Networks in the Faculty of Electrical Engineering
and Information Technology. Until 2012 he has been direc-
tor and head of wireless technology and mobile network
research at NTT DOCOMOs European research laboratories
for more than ten years. His research resulted in more than
100 publications in the area of mobile networking and ser-
vice platforms.

IEEE Communications Magazine June 2014 9