Software Defined Networking Concepts, History, and Applications

This report provides a comprehensive overview of Software Defined Networking (SDN), a paradigm shift in network design and management. It begins with an introduction to SDN, highlighting its potential to simplify network operations by decoupling the control plane from the data plane. The report traces the history of programmable networks, starting from early initiatives like OpenSig and Active Networking, and discusses their contributions and shortcomings. It then delves into the core concepts of SDN, including the role of the controller and the communication between the control and data planes. The report also examines SDN applications and their benefits, along with the impact of SDN on both industry and academia, including the various research communities and their goals. The evolution of SDN from early programmable network ideas, the key ideas behind it, and the reasons behind its adoption are all discussed. The report provides valuable insights into the motivations, evolution, and potential benefits of SDN for network operators, researchers, and the broader networking community.

3
Software Defined Networking Concepts
Xenofon Foukas Mahesh K. Marina Kimon Kontovasilis
The University of Edinburgh The University of Edinburgh NCSR “Demokritos”
& NCSR “Demokritos”
3.1 Introduction
Software-Defined Networking (SDN) is an idea which has recently reignited the
interest of network researchers for programmable networks and shifted the attention
of the networking community to this topic by promising to make the process of
designing and managing networks more innovative and simplified compared to the
well-established but inflexible current approach.
Designing and managing computer networks can become a very daunting task due
to the high level of complexity involved. The tight coupling between a network's
control plane (where the decisions of handling traffic are made) and data plane (where
the actual forwarding of traffic takes place) give rise to various challenges related to
its management and evolution. Network operators need to manually transform high-
level policies into low-level configuration commands, a process which for complex
networks can be really challenging and error-prone. Introducing new functionality to
the network, like intrusion-detection systems and load balancers usually requires
tampering with the network’s infrastructure and has a direct impact on its logic, while
deploying new protocols can be a slow process demanding years of standardization
and testing to ensure interoperability among the implementations provided by various
vendors.
The idea of programmable networks has been proposed as a means to remedy this
situation by promoting innovation in network management and the deployment of
network services through programmability of the underlying network entities using
some sort of an open network API. This leads to flexible networks able to operate
according to the user’s needs in a direct analogy to how programming languages are

being used to reprogram computers in order to perform a number of tasks without the
need for continuous modification of the underlying hardware platform.
SDN is a relatively new paradigm of a programmable network which changes the
way that networks are designed and managed by introducing an abstraction that
decouples the control from the data plane, as illustrated in Figure 3.1. In this approach
a software control program, referred to as the controller, has an overview of the whole
network and is responsible for the decision making, while the hardware (routers,
switches etc.) is simply responsible for forwarding packets into their destination as
per the controller’s instructions, typically a set of packet-handling rules.
Figure 3.1SDN in a nutshell - key ideas underlying the SDN paradigm
The separation of the logically centralized control from the underlying data plane
has quickly become the focus of vivid research interest in the networking community
since it greatly simplifies network management and evolution in a number of ways.
New protocols and applications can be tested and deployed over the network without
affecting unrelated network traffic; additional infrastructure can be introduced without
much hassle; and middleboxes can be easily integrated into the software control,

allowing new potential solutions to be proposed for problems that have long been in
the spotlight, like managing the highly complex core of cellular networks.
This chapter is a general overview of SDN for readers who have just been exposed
to the SDN paradigm as well as for those requiring a survey of its past, present and
future. Through the discussion and the examples presented in this chapter the reader
should be able to comprehend why and how SDN shifts paradigms with respect to the
design and management of networks and to understand the potential benefits that it
has to offer to a number of interested parties like network operators and researchers.
The chapter begins by presenting a comprehensive history of programmable
networks and their evolution to what we nowadays call SDN. Although the SDN hype
is fairly recent, many of its underlying ideas are not new and have simply evolved
over the past decades. Therefore, reviewing the history of programmable networks
will provide to the reader a better understanding of the motivations and alternative
solutions proposed over time, which helped to shape the modern SDN approach.
The next part of this chapter focuses on the building blocks of SDN, discussing
the concept of the controllerand giving an overview of the state of the art by
presenting different design and implementation approaches. It also clarifies how the
communication of the data and control plane could be achieved through a well-
defined API by giving an overview of various emerging SDN programming
languages. Moreover, it attempts to highlight the differences of SDN to other related
but distinct technologies like network virtualization. Additionally, some
representative examples of existing SDN applications are discussed, allowing the
reader to appraise the benefits of exploiting SDN to create powerful applications.
The final part of the chapter discusses the impact of SDN to both the industry and
the academic community by presenting the various working groups and research
communities that have been formed over time describing their motivations and goals.
This in turn demonstrates where the current research interest concentrates, which
SDN-related ideas have been met with widespread acceptance and what are the trends
that will potentially drive future research in this field.
3.2 SDN History and Evolution
While the term programmableis used to generalize the concept of the simplified
network management and reconfiguration, it is important to understand that in reality

it encapsulates a wide number of ideas proposed over time, each having a different
focus (e.g., control- or data-plane programmability) and different means of achieving
their goals. This section reviews the history of programmable networks right from its
early stages, when the need for network programmability first emerged, up to the
present with the dominant paradigm of SDN. Along these lines, the key ideas that
formed SDN will be discussed along with other alternatives that were proposed and
affected SDN's evolution but which were not met with the same widespread success.
3.2.1 Early History of Programmable Networks
As already mentioned, the concept of programmable networks dates its origins
back in the mid-90s, right when the Internet was starting to experience widespread
success. Until that moment the usage of computer networks was limited to a small
number of services like e-mail and file transfers. The fast growth of the Internet
outside of research facilities led to the formation of large networks, turning the
interest of researchers and developers in deploying and experimenting with new ideas
for network services. However, it quickly became apparent that a major obstacle
towards this direction was the high complexity of managing the network
infrastructure. Network devices were used as black boxes designed to support specific
protocols essential for the operation of the network, without even guaranteeing vendor
interoperability. Therefore, modifying the control logic of such devices was not an
option, severely restricting network evolution. To remedy this situation, various
efforts focused on finding novel solutions for creating more open, extensible and
programmable networks.
Two of the most significant early ideas proposing ways of separating the control
software from the underlying hardware and providing open interfaces for management
and control were of the Open Signaling (OpenSig) [2] working group and from the
Active Networking [3] initiative.
OpenSig- The Open Signaling working group appeared in 1995 and focused on
applying the concept of programmability in ATM networks. The main idea was the
separation of the control and data plane of networks, with the signaling between the
planes performed through an open interface. As a result, it would be possible to
control and program ATM switches remotely, essentially turning the whole network
into a distributed platform, greatly simplifying the process of deploying new services.

The ideas advocated by the OpenSig community for open signaling interfaces
acted as motivation for further research. Towards this direction, the Tempest
framework [4], based on the OpenSig philosophy, allowed multiple switch controllers
to manage multiple partitions of the switch simultaneously and consequently to run
multiple control architectures over the same physical ATM network. This approach
gave more freedom to network operators, as they were no longer forced to define a
single unified control architecture satisfying the control requirements of all future
network services.
Another project aimed at designing the necessary infrastructure for the control of
ATM networks was DCAN [5] (Devolved Control of ATM networks). The main idea
was that the control and management functions of the ATM network switches should
be stripped from the devices and should be assigned to external dedicated
workstations. DCAN presumed that the control and management operations of multi-
service networks were inherently distributed, due to the need of allocating resources
across a network path in order to provide QoS guarantees. The communication
between the management entity and the network was performed using a minimalistic
protocol, much like what modern SDN protocols like OpenFlow do, adding any
additional management functionality like the synchronization of streams in the
management domain. The DCAN project was officially concluded in mid-1998.
Active Networking- The Active Networking initiative appeared in the mid-90s
and was mainly supported by DARPA [6][7]. Like OpenSig, its main goal was the
creation of programmable networks which would promote network innovations. The
main idea behind active networking is that resources of network nodes are exposed
through a network API, allowing network operators to actively control the nodes as
they desire by executing arbitrary code. Therefore, contrary to the static functionality
offered by OpenSig networks, active networking allowed the rapid deployment of
customized services and the dynamic configuration of networks at run-time.
The general architecture of active networks defines a three-layer stack on active
nodes. At the bottom layer sits an operating system (NodeOS) multiplexing the node’s
communication, memory and computational resources among the packet flows
traversing the node. Various projects proposing different implementations of the
NodeOS exist, with some prominent examples being the NodeOS project [8] and
Bowman [9]. At the next layer exist one or more execution environments providing a
model for writing active networking applications, including ANTS [10] and PLAN

[11]. Finally, at the top layer are the active applications themselves, i.e. the code
developed by network operators.
Two programming models fall within the work of the active networking
community [7][12]; the capsule model, in which the code to be executed is included
in regular data packets; and the programmable router/switch model, in which the code
to be executed at network nodes is established through out-of-band mechanisms. Out
of the two, the capsule model came to be the most innovative and most closely
associated with active networking [7]. The reason is that it offered a radically
different approach to network management, providing a simple method of installing
new data plane functionality across network paths. However, both models had a
significant impact and left an important legacy, since many of the concepts met in
SDN (separation of the control and data plane, network APIs etc.) come directly from
the efforts of the active networking community.
3.2.2 Evolution of Programmable Networks to SDN
3.2.2.1 Shortcomings and contributions of previous approaches
Although the key concepts expressed by these early approaches envisioned
programmable networks that would allow innovation and would create open
networking environments, none of the proposed technologies was met with
widespread success. One of the main reasons for this failure was the lack of
compelling problems that these approaches managed to solve [6][7]. While the
performance of various applications like content distribution and network
management appeared to benefit from the idea of network programmability, there was
no real pressing need that would turn the shift to the new paradigm into a necessity,
leading to the commercialization of these early ideas.
Another reason for which active networking and open signaling did not become
mainstream was their focus on the wrong user group. Until then, the programmability
of network devices could be performed only by programmers working for the vendors
developing them. The new paradigm advocated as one of its advantages the flexibility
it would give to end users to program the network, even though in reality the use case
of end user programmers was really rare [7]. This clearly had a negative impact on the
view that the research community and most importantly the industry had for

programmable networks, as it overshadowed their strong points, understating their
value for those that could really benefit like ISPs and network operators.
Furthermore, the focus of many early programmable network approaches was in
promoting data- instead of control-plane programmability. For instance active
networking envisioned the exposure and manipulation of resources in network devices
(packet queues, processing, storage etc.) through an open API but did not provide any
abstraction for logical control. In addition, while one of the basic ideas behind
programmable networks was the decoupling of the control from the data plane, most
proposed solutions made no clear distinction between the two [6]. These two facts
hindered any attempts for innovation in the control plane, which arguably presents
more opportunities than the data plane for discovering compelling use cases.
A final reason for the failure of early programmable networks was that they
focused on proposing innovative architectures, programming models and platforms,
paying little or no attention to practical issues like the performance and the security
they offered [7]. While such features are not significant key concepts of network
programmability, they are important factors when it comes to the point of
commercializing this idea. Therefore, even though programmable networks had many
theoretical advantages, the industry was not eager to adopt such solutions unless
pressing performance and security issues were resolved.
Clearly the aforementioned shortcomings of early programmable network
attempts were the stumbling blocks to their widespread success. However, these
attempts were really significant, since they defined for the first time key concepts that
reformed the way that networks are perceived and identified new research areas of
high potential. Even their shortcomings were of high significance, since they revealed
many deficiencies that should be addressed if the new paradigm was to be successful
one day. All in all, these early attempts were the cornerstones that shaped the way to
the more promising and now widely accepted paradigm of SDN.
3.2.2.2 Shift to the SDN paradigm
The first years of the 2000s saw major changes in the field of networking. New
technologies like ADSL emerged, providing high-speed Internet access to consumers.
At that moment it was easier than ever before for an average consumer to afford an
Internet connection which could be used for all sorts of activities, from e-mail and

teleconference services to large file exchanges and multimedia. This mass adoption of
high-speed Internet and of all the new services that accompanied it had cataclysmic
effects for networks, which saw their size and scope increase along with traffic
volumes. Industrial stakeholders like ISPs and network operators started emphasizing
on network reliability, performance and quality of service and required better
approaches in performing important network configuration and management functions
like routing, which at the time were primitive at best. Additionally, new trends in the
storage and management of information like the appearance of cloud computing and
the creation of large data centers made apparent the need for virtualized
environments, accompanied by network virtualization as a means to support their
automated provisioning, automation and orchestration.
All these problems constituted compelling use cases that programmable networks
promised to solve and shifted the attention of the networking community and the
industry to this topic once more. This shift was strengthened by the improvement of
servers which became substantially better than the control processors in routers,
simplifying the task of moving the control functions outside network devices [7]. A
result of this technological shift was the emergence of new improved network
programmability attempts, with the most prominent example being SDN.
The main reason for the apparent success of SDN is that it managed to build on
the strong points of early programmable network attempts, while at the same time
succeeded in addressing their shortcomings. Naturally, this shift from early
programmable networks to SDN did not occur at once, but, as we shall now see, went
through a series of intermediate steps.
As already mentioned one of the major drawbacks of early programmable
networking attempts was the lack of a clear distinction between the control and data
plane of network devices. The IETF ForCES [13] (Forwarding and Control Element
Separation) working group tried to address this by redefining the internal architecture
of network devices through the separation of the control from the data plane. In
ForCES two logical entities could be distinguished; the Forwarding Element (FE)
which operated in the data plane and was responsible for per-packet processing and
handling and the Control Element (CE) which was responsible for the logic of
network devices, i.e. for the implementation of management protocols, for control
protocol processing etc. A standardized interconnection protocol lay between the two
elements enforcing the forwarding behavior to the FE as directed by the CE. The idea

behind ForCES was that by allowing the forwarding and control planes to evolve
separately and by providing a standard means of interconnection it was possible to
develop different types of FEs (general purpose or specialized) which could be
combined with third-party control, allowing greater flexibility for innovation.
Another approach targeting the clean separation of the control and forwarding
elements of network devices was the 4D project [14]. Like ForCES, 4D emphasized
the importance of separating the decision logic from the low-level network elements.
However, in contrast to previous approaches, the 4D project envisioned an
architecture based on four planes: a decision plane responsible for creating a network
configuration; a dissemination plane responsible for delivering information related to
the view of the network to the decision plane; a discovery plane allowing network
devices to discover their immediate neighbors and a data plane responsible for
forwarding traffic. One experimental system based on the 4D architecture was
Tesseract [15], which enabled the direct control of a network under the constraint of a
single administrative domain. The ideas expressed in the 4D project acted as direct
inspiration for many projects related to the controller component of SDNs, since it
gave the notion of a logically centralized control of the network.
A final project worth mentioning during the pre-SDN era is SANE/Ethane
[16][17]. Ethane was a joint attempt made in 2007 by researchers in the universities of
Stanford and Berkeley to create a new network architecture for the enterprise. Ethane
adopted the main ideas expressed in 4D for a centralized control architecture,
expanding it to incorporate security. The researchers behind Ethane argued that
security could be integrated to network management, as both require some sort of
policy, the ability to observe network traffic and a means to control connectivity.
Ethane achieved this by coupling very simple flow-based Ethernet switches with a
centralized controller responsible for managing the admittance and routing of flows
by communicating with the switches through a secure channel. A compelling feature
of Ethane was that its flow-based switches could be incrementally deployed alongside
conventional Ethernet switches and without any modification to end hosts required,
allowing the widespread adoption of the architecture. Ethane was implemented in
both software and hardware and was deployed at the campus of Stanford University
for a period of a few months. The Ethane project was very significant, as the
experiences gained by its design, implementation and deployment laid the foundation
for what would soon thereafter become SDN. In particular, Ethane is considered the

immediate predecessor of OpenFlow, since the simple flow-based switches it
introduced formed the basis of the original OpenFlow API.
3.2.2.3 The emergence of software defined networking
In the second half of the 2000s, funding agencies and researchers started showing
interest in the idea of network experimentation at scale [7]. This interest was mainly
motivated by the need to deploy new protocols and services, targeting better
performance and QoS in large enterprise networks and the Internet, and was further
strengthened by the success of experimental infrastructures like Planetlab [18] and by
the emergence of various initiatives like the US National Science Foundation’s GENI
(Global Environment for Networking Innovations). Until then, large scale
experimentation was not an easy task to perform; researchers were mostly limited in
using simulation environments for evaluation, which, despite their value, could not
always capture all the important network-related parameters in the same manner as a
realistic testbed would.
One important requirement of such infrastructure-based efforts was the need for
network programmability, which would simplify network management and network
services deployment and would allow multiple experiments to be run simultaneously
at the same infrastructure, each using a different set of forwarding rules. Motivated by
this idea a group of researchers at Stanford created the Clean Slate Program. In the
context of this project, which had as a mission to “reinvent the Internet”, the
OpenFlow protocol was proposed as a means for researchers to run experimental
protocols in everyday networking environments. Similarly to previous approaches like
ForCES, OpenFlow followed the principle of decoupling the control and forwarding
plane, and standardized the information exchanges between the two using a simple
communication protocol. The solution proposed by OpenFlow, which provided
architectural support for programming the network, led to the creation of the term
SDN to encapsulate all the networks following similar architectural principles. The
fundamental idea behind SDNs compared to the conventional networking paradigm is
the creation of horizontally integrated systems through the separation of the control
and the data plane while providing an increasingly sophisticated set of abstractions.
Looking back at all the milestones and important programmable network projects
presented in this section we can conclude that the road to SDN was indeed a long one

with various ideas being proposed, tested and evaluated, driving research in this field
even further. SDN was not so much of a new idea, as it was the promising result of
the distilled knowledge and experience obtained through many of the ideas presented
in this section. What SDN managed to do differently compared to these ideas is that it
integrated the most important network programmability concepts into an architecture
that emerged at the right time and had compelling use cases for a great number of
interested parties. Even though it remains to be seen whether SDN will be the next
major paradigm shift in networking, the promise it demonstrates is undeniably very
high.
3.3 SDN Paradigm and Applications
In this section we focus on the key ideas underlying the SDN paradigm, the most
recent instance in the evolution of programmable networks. In order to better
understand the SDN concepts and to comprehend the benefits that this paradigm
promises to deliver we need to examine it both macro- and microscopically. For this,
we begin this section by presenting a general overview of its architecture before going
into an in-depth analysis of its building blocks.
3.3.1 Overview of SDN Building Blocks
As already mentioned, the SDN approach allows the management of network
services through the abstraction of lower level functionality. Instead of dealing with
low level details of network devices regarding the way that packets and flows are
managed, network administrators now only need to use the abstractions available in
the SDN architecture. The way that this is achieved is by decoupling the control plane
from the data plane following the layered architecture illustrated in Figure 3.1.
At the bottom layer we can observe the data plane, where the network
infrastructure (switches, routers, wireless access points etc.) lies. In the context of
SDN these devices have been stripped of all control logic (e.g., routing algorithms
like BGP) simply implementing a set of forwarding operations for manipulating
network data packets and flows, providing an abstract open interface for the
communication with the upper layers. In the SDN terminology these devices are
commonly referred to as network switches.

Moving to the next layer we can observe the control plane, where an entity
referred as the controllerlies. This entity encapsulates the networking logic and is
responsible for providing a programmatic interface to the network, which is used to
implement new functionality and perform various management tasks. Unlike previous
approaches like ForCES, the control plane of SDN is ripped entirely from the network
device and is considered to be logically centralized, while physically it can be either
centralized or decentralized residing in one or more servers, which control the
network infrastructure as a whole.
An important aspect which distinguishes SDN from previous programmable
network attempts is that it has introduced the notion of the network operating system
abstraction [19 ]. Recall that previous efforts like active networking proposed some
sort of node operating system (e.g., NodeOS) for controlling the underlying hardware.
A network operating system offers a more general abstraction of network state in
switches, revealing a simplified interface for controlling the network. This abstraction
assumes a logically centralized control model, in which the applications view the
network as a single system. In other words, the network operating system acts as an
intermediate layer responsible for maintaining a consistent view of network state,
which is then exploited by control logic to provide various networking services for
topological discovery, routing, management of mobility and statistics etc.
At the top of the SDN stack lies the application layer, which includes all the
applications that exploit the services provided by the controller in order to perform
network-related tasks, like load balancing, network virtualization etc. One of the most
important features of SDN is the openness it provides to third-party developers
through the abstractions it defines for the easy development and deployment of new
applications in various networked environments from data centers and WANs to
wireless and cellular networks. Moreover, the SDN architecture eliminates the need
for dedicated middleboxes like firewalls and Intrusion Detection Systems (IDS) in the
network topology, as it is now possible for their functionality to be implemented in
the form of software applications that monitor and modify the network state through
the network operating system services. Obviously, the existence of this layer adds
great value to SDN, since it gives rise to a wide range of opportunities for innovation,
making SDN a compelling solution both for researchers and the industry.
Finally, the communication of the controller to the data plane and the application
layer can be achieved through well-defined interfaces (APIs). We can distinguish two