1. TERM PAPER
Software Defined Networking
- Madhav Sharma
I. Introduction
A computer network consists of various devices such as routers, switches and middle boxes. Some
of these devices are responsible for traffic management as well as forwarding. This vertically
integrated network architecture makes the job of network administrator increasingly complex, as
they need to apply configurations of each device manually. Software defined networking is an
emerging paradigm that makes these networks programmable.
A. What is SDN?
SDN proposes a network architecture which decouples control plane from data plane. This makes
a controller an external entity that centrally controls forwarding operations across a number of
forwarding devices. The forwarding decisions in SDN are flow based instead of destination based.
A flow is a sequence of packets between source and destination [1]. Abstraction of flow allows
unification of behavior of different devices since their service policies are identical. A controller
is programmed centrally using a north bound interface. Such architecture allows a network
administrator to have a convenient global network view.
Abstraction in network is hiding all data that isn’t relevant. [2] SDN defined three fundamental
abstractions: forwarding, distribution and specification. Forwarding abstraction allows all
forwarding operations desired by the control program without revealing underlying hardware to
the user. Distribution abstraction shields applications from fluctuations in distribution state making
distributed control a centralized problem. Specification abstraction lets application to express
desired behavior without being responsible for implementing it. (E.g.: use of network
programming languages)
B. Why SDN
Traditional IP networks are vertically integrated (control and data plane bundled together) making
them complex and hard to manage. There is a marginal change in traffic patterns within enterprise
data centers. They have less client-server applications where most of the communication happened
between one client and one server, today’s applications access various databases and servers. With
rise of cloud data storages, there is a prompt increase in traffic over wide area networks. The IP
network architecture is also hindering evolution of network infrastructure. The ipv4 to ipv6
transition which started a decade ago is still largely incomplete despite being a mere protocol
change. SDN promises a simpler, more agile, centrally managed and programmable network
compared to IP. Centralization of control logic offers less error prone and simpler way to modify
network policies through high level languages. [3]

2. II. Architecture
SDN architecture is broadly divided into 3 planes: Data, Control and Management. Data plane
consists of the forwarding devices and sublayers which interface them to the control plane. The
control plane contains the Network operating system (NOS) or the controller which acts as the
brain of the network. Its other layers deal with linking the centralized controller to the Management
plane and data plane. The previously coupled planes have very different functionalities compared
to the IP architecture. The management plane is composed of user interface applications,
programming languages and their compilers [1] (Language based Virtualization). Discussing the
layers in detail:
Figure 1: SDN Architecture [1]
A. Data Plane
i. Infrastructure
The infrastructure layer in SDN has a set of network equipment such as switches, routers and
middlebox appliances. The data plane devices are different from IP devices since the network
intelligence is removed from them and logic is moved to the control plane. These devices thus do
not have any embedded control or ability to make autonomous decisions. [1] The networks in data
plane are built atop an open interface like Openflow to facilitate compatibility and interoperability
between various control and data plane devices. The devices enabled with openflow use a pipeline
of flow tables. This pipeline of flowtables determines how each packet must be handled. Entries
in flowtables have three parts: a matching rule, actions to be taken if matching packets are
discovered and counters that keep count of the matching packets. If rules not stated for a particular
packet, it is made to follow a default rule. In case a default rule is not defined either, the packet is
discarded. Actions taken on packets include forwarding to other ports, encapsulation and
forwarding to controller and dropping.
Currently there are several Openflow based switches switches forwarding devices available in
market. Most of them have a small Ternary Content Addressable Memory (TCAM) (8000 entries)
but that is changing rapidly. The Gigabit Ethernet (GbE) switches (32000 entries) and 10 GbE
switches (80000 entries) are cruising towards deployment on business scale.[4] With virtualization

3. being one of the key virtue of SDN architecture, Software switches (e.g.: Switch Light, Open
vSwitch, XorPlus etc.) are the most promising solutions for data centers and virtualized networks.
Many start ups (e.g.: Pica8, Big Switch etc.) are fueling their resources into SDN hardware.
Another impact of SDN is rise in “white box switches” where hardware and software of a device
are sold separately giving user the freedom to load an OS of choice. [5]
ii. Southbound Interface
Southbound APIs are the bridges connecting forwarding devices to the controller. This layer
consists of protocols that provide information of the network to the control plane. Said data
includes triggering of changes in links and ports while forwarding and flow statistics. Also if action
to be taken on packet dictates, “send to controller”, the southbound APIs forward said packet
information to the NOS.
Switches generally have a long development cycle and Southbound Interfaces is a crucial
component in design. SDN based OpenFlow enabled API are gaining momentum due to their
vendor neutral design which improves interoperability. OpenFlow API is the most widely accepted
Southbound API standard for SDN. Other APIs include OVSDB, OpFlex and ForCES.[1]
B. Control Plane
iii. Network Hypervisors
Network Hypervisors allows different virtual machines to share same hardware devices. They act
as proxy between the controller and forwarding devices. SDN Hypervisors offer new tunneling
techniques eliminating the box-by-box system used by traditional IP networks and making it more
flexible. The idea behind Hypervisors is to allocate different users a set of virtual hardware
depending on the requirement. SDN Technologies slices the network further into dimensions such
as bandwidth, topology, traffic, device CPU and forwarding tables. These dimensions are
separately assigned to users to increase the efficiency of multi-tenant networks instead of assigning
entire device to a user. Guest controllers get their own flowtables.
This layer holds the key to virtualization and cloud Infrastructure-as-a-service (IaaS). IaaS
provides each user with virtual resources such as computing and storage. Users require varied
network topology and address space but the traditional approach makes the network constrained.
Users cannot configure the computing nodes and the network simultaneously. Host migration does
not trigger the migration of network port. Hence, while the configuring virtual computing nodes
takes minutes, provisioning of network can take hours making the job of network administrators
exhausting. SDN promises to change that scenario.
SDN has witnessed many technical solutions that facilitate virtualization such as FlowVisor,
OpenVirteX, AutoSlice etc. [6]

4. iv. Network Operating System
SDN controller or a Network Operating system (NOS) is the software stack, which runs all the
hardware underneath. Main functions of a controller are execution of programs, controlling
operations of input and output of packets, communicating throughout the system and protection.
The NOS is embedded with services such forwarding and security mechanisms, notifications,
device management and topology statistics. A controller has a layered architecture. The three main
components of NOS are: Application services, Core controller functions and elements of
southbound communications. The southbound APIs connect the controller with the hardware
underneath. They are critical in ensuring system heterogeneity and backward compatibility. The
controller is also connected to the upper layers via northbound interface (NBI). NBI abstracts the
controller functions to the user using high level programming languages.
Figure 2: Improving Scalability in SDN [1]
Controller is the network-brain and the key edge SDN has over traditional networks. It saves
network administrators hours of complex coding while approaching deployment of new network
protocols and applications. It provides the abstraction, services and APIs needed to simplify the
network. Though, distributed control more scalable and resilient in context with small to large
scale networks, the emergence of eastbound and westbound APIs help SDN controllers overcome
these limitations. Another issue with SDN controller is fault tolerance. In case a node fails,
distributed systems route the traffic via another path. Centralized controllers do not tolerate such
failures and face a shortcoming in this regard. [1]

5. Figure 3: OpenDayLight controller architecture [7]
Interoperability is one of the major focus of SDN. Thus, most of the SDN controllers are very
versatile in their southbound interfaces and architecture. However, Northbound APIs are very
distinctive for many controllers. Centralized multi threaded controllers such as Beacon, Floodlight,
Maestro share a huge market since they promote concurrent systems and have a high throughput.
Distributed controllers like OpenDayLight, DISCO and Elasticon are more popular in developers
as they are easy to scale and deploy. Most controllers support only OpenFlow southbound API.
Some of them (e.g.: Onix, HP VAN SAN) are compatible with wider range of APIs.
OpenDayLight controller solves the limitations faced by controllers at the southbound interface; it
provides a Service Abstraction Layer which allows many southbound APIs to coexist. Onix, HP
VAN SAN, ONOS and SMaRtLight offer consistency and fault tolerance. [7]
v. Northbound Interface
Northbound interface is the bridge connecting the controller to the applications. NBI is a key
abstraction along with SBI in SDN architecture.
Although southbound APIs have OpenFlow as a widely accepted industry standard, there is no
such common northbound interface. Most controllers (e.g.: Floodlight, OpenDayLight etc.)
propose their own northbound interface as they have different commands and functions. This leads
to issues in interoperability. [1]

6. C. Management Plane
vi. Language-Based Virtualization
Virtualization techniques show a user different image of same physical architecture. Virtualization
solutions can express modularity while allowing different degrees of abstraction. Thus, application
developers do not get the entire information about the network; rather they view it as one big
switch and develop their codes accordingly. Such abstraction simplifies development and
deployment of network applications significantly.[1]
vii. Programming Languages
Programming languages are languages constructed to communicate instructions to machines and
controlling its behavior using programs and algorithms. C++ and JAVA programs can make a
computer perform complex operations, similarly, in the case of SDN; programs can be used to
control data movement. SDN uses high level programming languages to elevate abstraction to
simplify programming forwarding devices and advance the development of network virtualization.
The concept of programming languages for networks is similar to object oriented programming.
Most programming languages proposed for SDNs are usually for OpenFlow enabled networks.
Declarative languages (uses structures) are the dominant paradigm in networks with an exception
of Pyretic , which is imperative. Common Programmable network languages are FaTire, Flog,
Nettle etc. [1]
viii. Network Applications
Network Applications implement the control logic that directs the behavior of forwarding devices.
It is the point of access for the users. They are used to program networks for tasks like routing and
load balancing. Applications are also responsible for enforcement of security protocols, Quality of
service, network virtualization etc. Applications can also be developed for increasing efficiency of
system and reducing power consumption.[8]
There are mainly five types of network applications:
a. Traffic Engineering: These applications orchestrate traffic such that it minimizes power
consumption, optimizes load balancing and maximizes network utilization. E.g.: Plug-n-
Serve, QNOX, ALTO etc.
b. Mobility and wireless: These applications provide down link scheduling, dynamic
spectrum usage, intercell interference coordination and device to device over loading. E.g.
Aeroflux, CROWD, Odin etc.
c. Measurement and monitoring: Monitors traffic in the network using stochastic and
deterministic packet sampling. E.g.: BISmark, DCM etc.
d. Security and dependability: Applications enforce security policies and protocols and
firewalls the network against threats. E.g.: Active security, Livesec, FortNOX
e. Data center networking: Managed networks in large server farms by techniques like virtual
network isolation and custom addressing. E.g.: Big Data Apps, CloudNaas, LIME

7. III. Analysis
A. Benefits
Software Defined Networking offers many advantages over traditional IP networks. Since,
traditional IP networks have data and control plane coupled together, they make tasks of network
administrators like manually provisioning or configuring application an arduous task. With
internet “ossification” on horizon and internet of things gaining momentum, networks are getting
increasingly complex and constrained. Software defined Networking adds significant abstraction
and virtualization to the network making it more simple, agile and automated. Programmable
networks are easy to manage and promote innovation.[9]
B. Limitations
As a developing technology, SDN has some issues. Physically centralized controller can be
regarded as a single point of failure for entire network. Single point of access also raises security
concerns since whole network will be at risk if the controller gets compromised. Low fault
tolerance is another limitation of Software defined networks. These networks are not extensively
scalability and have limited resilience. There is no widely accepted standard for a North Bound
Interface. Also development cycle of SDN infrastructure is long, thus, its large-scale deployment
will take a lot of time.[9]
C. Future
SDN is getting widely accepted in enterprise networks and data centers across the globe. Its
thorough traffic management and policy enforcement have led large corporations invest in SDN.
Google, Microsoft, Facebook, CISCO and HP have contributed to Open networking foundation,
an open foundation for standardizing SDN hardware and software. Google has implemented SDN
in 12 of its data farms. One of its most important specialties is reduced power consumption. SDN
enabled data farms save 10-20% of energy because less cooling is needed for servers. Power
consumption in Google server farms accounts to 0.01% of world’s energy; hence a 10-20%
decrease is a significant chunk of power. Cloud computing also desires a more virtualized network
that can provide more quality service to its customers. SDN is also instrumental in ubiquitous
connectivity of infrastructure based wireless area networks, the bridge between traditional phones,
LTE and wifi. IPv4 to IPv6 transition was declared a decade ago but is still not completely
deployed. This is because making a protocol change in IP networks is difficult. SDN offers better
interoperability that can facilitate this change faster.[9]
IV. CONCLUSION
Although a promising technology, to prepare Software designed networks for future development,
significant advancements need to be made in the controller and switch design to improve its
performance, scalability, and robustness

8. REFERENCES
[1] Kreutz, D.; Ramos, F.M.V.; Esteves Verissimo, P.; Esteve Rothenberg, C.; Azodolmolky, S.;
Uhlig, S., "Software-Defined Networking: A Comprehensive Survey," in Proceedings of the
IEEE , vol.103, no.1, pp.14-76, Jan. 2015
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6994333&isnumber=6994307
[2] URL: http://whatis.techtarget.com/definition/abstraction
[3] URL: https://www.opennetworking.org/sdn-resources/sdn-definition
[4]URL:https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-
papers/OF-PI__A_Protocol_Independent_Layer_for_OpenFlow_v1-1.pdf
[5] URL: https://www.youtube.com/watch?v=WabdXYzCAOU
[6] N. M. K. Chowdhury and R. Boutaba,‘‘A survey of network virtualization,’’Computer
Networking vol. 54, no. 5, pp. 862–876,2010
URL: https://cs.uwaterloo.ca/research/tr/2008/CS-2008-25.pdf
[7] URL: http://socializedsoftware.com/2013/04/08/the-linux-foundations-collaboration-
opendaylight-project-open-source-sdn/
[8] E. Reinecke, ‘‘Mapping the future of software-defined networking,’’ 2014
URL:
http://www.dimensiondata.com/Global/Documents/Dimension%20Data's%20Pr%C3%A9cis%2
0-%20Mapping%20the%20future%20of%20software-defined%20networking.pdf
[9] Nunes, B.A.A.; Mendonca, M.; Xuan-Nam Nguyen; Obraczka, K.; Turletti, T., "A Survey of Software-
Defined Networking: Past, Present, and Future of Programmable Networks," in Communications Surveys
& Tutorials, IEEE , vol.16, no.3, pp.1617-1634, Third Quarter 2014
URL: http://ieeexplore.ieee.org/stamp/stamp.jsp?tp=&arnumber=6739370&isnumber=6880447