Software-Defined Networking Concepts

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.1 SDN 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 controller and 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 programmable is 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