Master Project SDN Haider Raza

Is SDN a Viable Solution to Traditional Networking Architecture Benefits, Challenges, and Existing Solutions
Syed Haider Raza - 40224242 – MSc in Advanced Networking
Is SDN a Viable Solution to Traditional

Networking Architecture: Benefits,
Challenges, and Existing Solutions
SYED HAIDER RAZA
Supervisor: Dr. Imed Romdhani

Internal Examiner: Isam Wadhaj
Submitted in partial fulfillment of the requirements of

Napier University for the degree of
Master in Advanced Networking
School of Computing
August 2017
1
Authorship Declaration
I, Syed Haider Raza, confirm that this dissertation and the work presented in it are
my own achievement.
1. Where I have consulted the published work of others this is always clearly
attributed;
2. Where I have quoted from the work of others the source is always given.
With the exception of such quotations this dissertation is entirely my own
3. work;
4. I have acknowledged all main sources of help;
5. If my research follows on from previous work or is part of a larger
collaborative research project I have made clear exactly what was done by
others and what I have contributed myself;
6. I have read and understood the penalties associated with Academic
Misconduct.
7. I also confirm that I have obtained informed consent from all people I have
involved in the work in this dissertation following the School's ethical
guidelines
Type name: Syed Haider Raza

Date:
Matriculation no: 40224242
2
Data Protection Declaration

Under the 1998 Data Protection Act, we cannot disclose your grade to an
unauthorized person. However, other students benefit from studying dissertations
that have their grades attached.
Please sign or type your name under one of the options below to state your
preference.
The University may make this dissertation, with indicative grade, available to
others.
The University may make this dissertation available to others, but the grade may not
be disclosed.
The University may not make this dissertation available to others.
3
Abstract
Internet is the mother of digital society where everything and everyone is connected
from anywhere. Despite the wide spread of this technology, traditional IP
networking is complex to configure and very hard to manage the size of the network
we already dealing with and in the future to top it off existing networks are
vertically integrated control and data plane tied together which is barrier to
innovation. SDN is an emerging technology with vast potential it breaks the vertical
integration, promote network centralization, software based networking,
simplifying n/w management. This study is a survey on SDN starts with motivation
of SDN first its background and concept, second part contains the SDN benefits and
particularly how SDN affects Data Center environment. Next to anticipate the future
of this technology a discussion is presented on challenges with focus on aspects like
Scalability, Fault-tolerance, Security and Lack of standardization and existing
solutions. Afterwards Methodology and Discussion is presented in accordance with
survey results to finally answer objectives of this study.
4
Table of Contents:
1 Introduction…………………….……………………………………….…………………...........11
1.1 Problem and Context…………………….……………………………………….……….11
1.2 Aims…………………….……………………………………….……………………………….13
1.3 Objectives…………………….……………………………………….……………………….13
1.4 Thesis Outline…………………….……………………………………….…………………14
1.5 Literature Review…………………….……………………………………….……………14
2 Theoretical Background …………………….……………………………………….……….16

2.1 SDN Paradigm…………………….……………………………………….…………………16
2.1.1 Early Programmable Networks…………………….…………………………..16
2.1.1.1 Open Signaling…………………….……………………………………….…….17
2.1.1.2 GSMP…………………….……………………………………….………………….17
2.1.1.3 Active Networks …………………….………………………………………….17
2.1.1.4 DCAN…………………….……………………………………….………………....19
2.1.1.5 4D Architecture…………………….……………………………………….…...20
2.1.1.6 NETCONF…………………….……………………………………….……………21
2.1.1.7 ForCES …………………….……………………………………….……………....21
2.1.1.8 Ethane…………………….……………………………………….………………..22
2.2 Software Defined Networking………………….……………………………………………23
2.2.1 Tier Architecture…………………….……………………………………….…………24
2.2.2 Comparison of Conventional and SDN Switch…………………….………...26
2.2.2.1 Conventional Switch…………………….…………………………………....26
2.2.2.2 SDN Switch…………………….……………………………………….………...27
2.3 Open Flow Protocol………………….……………………………………….…………………28
2.3.1 Open Flow Evolution…………………….……………………………………….…..29
2.3.2 Open Flow Data plane…………………….……………………………………….....31
2.3.2.1 Open Flow Operating Principles…………………….…………………...31
2.3.2.2 Open Flow Tables…………………….………………………………........... 32
2.3.2.3 Pipeline Processing…………………….……………………………………. 32
2.3.2.4 Flow Entry…………………….……………………………………….…………32
2.3.2.5 Open Flow Packet Matching…………………….…………………………33
2.3.2.6 Table Miss…………………….……………………………………….………....33
2.3.2.7 Open Flow Message Types…………………….…………………………...34
2.3.3 Open Flow Control Plane…………………….………………………………………34
2.4 Conclusion…………………….……………………………………….……………………………35
3 SDN Benefits…………………….……………………………………….………………………......36
3.1 Benefits…………………….……………………………………….…………………………….....36
3.1.1 Holistic and central control of multi-vendor environment………….....36
3.1.2 Cost Reduction…………………….……………………………………….……………36
3.1.3 Enhancing Configuration…………………….…………………………………......37
3.1.4 Innovation and Automation…………………….………………………………….37
5
3.1.5 Enhancing Performance…………………….……………………………………….38

3.1.6 Increased reliability and security…………………….……………..…….…. 38
3.2 SDN in DCN Problems and Solutions…………………….……………………….…… 39
3.2.1 Data Center Evolution…………………….………………………………….…… 39
3.2.2 Data Center Segregation…………………….…………………………….……... 40
3.2.3 Cloud Deployment…………………….…………………………………….……….40
3.2.4 Increasing Demands and Data center limitations……………….……….40
 Mac-address Burst…………………….……………………....………..41
 Limitations of Vlans…….………………………………….….………..41
 Spanning Tree…………………….…………………………….…………41
 Manageability of resources…………………….…………….………42
 Failure recovery…………………….…………………………………....42
 Multi-tenancy…………………….………………………………………..43
3.3 SDN Solutions for DCN…………………….……………………………………….…………43
3.3.1 Mac-address Burst and Limitation of Vlan…………………….………....44
3.3.2 Manageability of resources…………………….……………………………....44
3.3.3 Failure recovery…………………….……………………………………….……..45
3.3.4 Multi-tenancy…………………….……………………………..…………………..45
3.4 Conclusion…………………….……………………………………….……………...………….46
4 SDN challenges and Existing Solution…………………….…………………………..….47

4.1 Scalability…………………….……………………………………….………………………….47
4.2 Existing Solutions…………………….……………………………………….……………....48
4.2.1 DIFANE……………………………….……………………………………….………….48
4.2.2 Kandoo …………………….……………………………………….……………………50
4.2.3 Maestro…...……………….……………………………………….…………………….51
4.2.4 NOX-MT…………………….……………………………………….………………….. 53
4.3 Fault Tolerance…………………….……………………………………….………………….54
4.4.1 Data plane Fault tolerance…………………….…………………………………..54
4.4.1.1 Failure Detection…………………….…………………………………..54
4.4.2 Control plane Fault tolerance…………………….………………………………56
4.4.2.1 Shared data store controller framework………………………..56
4.4.2.2 CPRecovery…………………….…………………………………………..58
4.5 Security …………………….……………………………………….………………………….. .59
4.5.1 Control and Data plane related challenges…………………….…………....59
4.5.2 Channel related challenges…………………….………………………………….62
4.6.1 Preventive efforts for controller related challenges……………………..63
4.6.2 Preventive efforts for switch related challenges…………………….…….65
4.6.3 Preventive efforts for channel related challenges…………………………67
4.7 Lack of standardization…………………….……………………………………….……....68
4.8 Existing solutions…………………….……………………………………….……………….68
4.8.1 ITU-T and JCA on SDN…………………….………………………………………....68
4.8.2 ETSI NFV ISG…………………….……………………………………….……………..69
6
4.8.3 IETF/IRTF…………………….……………………………………….…………………69
4.8.4 ONF…………………….……………………………………….……………………………70
4.8.5 Open day light platform…………………….………………………………………..70
4.8.6 ONOS platform…………………….……………………………………….…………....70
4.9 Conclusion…………………….……………………………………….…………………………..71
5 Research Methodology…………………….……………………………………….…………..72
5.1 Purpose…………….…………………………………….………………………………………....72
5.2 Development of Research Questions…………………….……………………………....72
5.3 Development of Sub Questions…………………….……………………………………....73
5.4 Data collection tools…………………….……………………………………….……………..74
5.5 Design of data collection tools…………………….………………………………………..75
5.5.1 Matrix of DCTs used to mapped against the relevant RSQX…………....75
5.6 Design of survey…………………….……………………………………….…………………..75
5.7 Conclusion…………………….……………………………………….…………………………..79
6 Evaluation and Discussion…………………….……………………………………….…….80

6.1 Aim……………..…………………………………….……………………………………….………80
6.2 Survey data…………………….……………………………………….………………………....80
6.2.1 Questionnaire responses…………………….………………………………………80
6.2.2 General information about participants………………………………….…....80
6.3 Discussion…………………….……………………………………….……………………………80
6.4 Primary research question…………………….……………………………………….…....86
6.5 Critical Analysis and Conclusion…………………….……………………………………..87
6.5.1 Introduction…………………….……………………………………….
……………… 87
6.5.2 Study Overview…………………….……………………………………….…………..87
6.5.3 Restating the Aims of the study…………………….……………………………..87
6.5.4 Research findings summary…………………….…………………………………. 88
6.5.4.1 Evaluation of the survey…………………….…………………………….90
6.5.5 Analysis…………………….……………………………………….…………………….91
6.5.5.1 Study strength…………………….……………………………………….91
6.5.5.2 Study limitation…………………….……………………………………..91
6.5.5.3 Future research Areas…………………….…………………………….92
6.5.6 Conclusion…………………….……………………………………….………………..92
7 References…………….……………………………………….……………………………………..93
8 Appendix…………………….…………………………………….………………………………....100
9 Appendix…………………….……………………………………….………………………………105
7
List of Figures
Figure 2.1 - Early Programmable Networks……………………………………………..……..16
Figure 2.2 - DCAN Design……………………………………….………………………………….….20
Figure 2.3 - 4D Architecture…………………………………….…………………………………….20
Figure 2.4 - ForCES Architecture…………………...…………………...………………………….22
Figure 2.5 - Ethane Architecture…………………...……………………………………………….22
Figure 2.6 - SDN Architecture…………………...…………………………………………………...24
Figure 2.7 - Classical Switch Design…………………...…………………………………………..26
Figure 2.8 - SDN Switch Design…………………...…………………...……………………………27
Figure 2.9 - Open Flow Framework………………….…………………………........................29
Figure 2.10 - Open Flow Timeline………………….………………………………………………30
Figure 2.11 - Packet Traversing ………………….……………………………….......................31
Figure 2.12 - Pipeline Processing………………….……………………………………………….32
Figure 2.13 - Flow Entry Fields………………….………………….………………………………32
Figure 2.14 - Packet Matching………………….………………….………………………………..33
Figure 3.1 - Server virtualization….…………….………………….……………....................39
Figure 3.2 - Vlan Exhaustion………………….……………………………….…….…………….41
Figure 4.1 - DIFANE Architecture………………….…………………………........................49
Figure 4.2 - Kandoo Architecture ………………….…………………………….....................50
Figure 4.3 - Pull Based Distribution………………….………………………….....................52
Figure 4.4 - Protection Paths………………….………………….…………….........................56
Figure 4.5 - Shared Data Store Framework………………….……………….....................57
Figure 4.6 - Recovery Component………………….……………………………....................58
8
List of Tables
Table 2.1 – Open Flow-enabled switches…………………………………….................................. 27
Table 2.2 – Major Update in Each Open Flow Version…………………………………………. 30
Table 4.1 – Scalability Metrics…………………...………………….......................…………………….
54
Table 5.1 – Sub Research Questions…………………...…………………...........…………………….
72
Table 5.2 – Sub Questions Development…………………...…………………..……………………. 73
Table 5.3 – Matrix…………………...…………………...…………………...……........…………………….
75
Table 5.4 – Reasons of SQX for RSQX…………………...………………….........……………………. 76
Table 6.1 – First SQ Response Rate…………………...…………………............…………………….
80
Table 6.2 – Second SQ Response Rate…………………...………………….......…………………….
81
Table 6.3 – Third SQ Response Rate…………………...…………………..........…………………….
83
Table 6.4 – Fourth SQ Response Rate………………...………………………...……………………..
84
Table 6.5 – Fifth SQ Response Rate…………………...…………………............…………………….
84
Table 6.6 – Sixth SQ Response Rate…………………...…………………............…………………….
85
Table 6.7 – Seventh SQ Response Rate…………………...……………….........…………………….
86
Table 6.8 – Design Classifications…………………...………………..................……………………. 88
Table 6.9 – Security Challenges Summary…………………...………………..……………………. 89
Table 6.10 – List of Existing Solutions in Respect to CIA Model….......……………………. 90
9
Acknowledgement
I would like to sincerely grateful to my supervisor Imed Romdhani for all the
support and guidance given and thoughtful advices for producing this study.
Additional thanks go to Esam for being my second marker
I also would like to thank to all those who assisted in this project when conducting
the survey and to all those whom moral support remained during this project.
Finally, I wish to thank my parents for their support and encouragement throughout
the project.
10
1 Introduction
1.1 Problem and Context
The existing network infrastructure has been used and maintained for decades and
there haven't been any major groundbreaking changes seen while technology
continues to evolve, the most dominant hindrance is resource management in
networks this keeps administrators in a continuous struggle while the requirements
of Data Center and Enterprises continuously growing. Networks composed of
vendor specific routers, switches, and middleboxes including (IDS, firewall, load
balancers) and network protocols which have gone through years of
standardization and interoperability test procedures creates hurdle when there is a
network change that does not efficiently meets the customer real-time application
needs. Moreover, the configuration of individual network devices from a variety of
vendors is time-consuming which often result in degradation of network
performance. To avoid this static configuration and performance degradation, there
is a substantial change required in the current networking architecture that can
handle the ever-growing needs of networks and open new avenues for constant
innovations which ease the management in Data Centers, Enterprises, and ISPs in a
simpler way.
This led to the development of Software Defined Networking a new shift from
existing traditional internet architecture that stands out and still remains successful.
SDN architecture promises to accommodate the weaknesses of current networking
paradigm by defining two distinct features. SDN separate the control plane (traffic
handling) from the data plane (data forwarding) and second delivering a platform in
the control plane using single software (controller) can control multiple elements in
the forwarding plane. Although the concept of separating the two planes is not new
but still the excitement of SDN fosters significantly in the past few years with the
introduction of APIs (Application Programming Interfaces) like Open Flow
(southbound communication protocol) and OVSs (Open Virtual Switches) controlled
by a controller can act like a (Switch, Router, NAT, etc.) depending on what flows
are being installed in OVS by the controller other vendors like HP, IBM, Juniper and
Cisco which came up with their on view of SDN. Using Open Flow platform, new API
11
has been launched in a span of few years API like (dynamic access control, load
balancing, network virtualization etc.). Open Flow is a prevalent innovative
approach to the innovation that predates the term SDN. This approach of Network
Programmability is a far-fetched idea from the time of Active Networking and the
result of many network projects in the past 20 years that came before but they
never been adapted as SDN.
Some of the Recent researchers including (Future Internet Research, Global

Environment for Network Innovations, Future Internet Design, New Generation
Networks, Future Internet Research and Experimentation etc.). Researchers
realized that these projects are not as efficient as they should be and all drive the
conclusion that the development of the future networks cannot be cope up with the
closeness of traditional networks. The problem arises as networks started to grow
rapidly, performing networking in existing architecture remained a hindrance to
network innovation until current problems are addressed with an effective and
efficient approach. As more and more proprietary network device becomes a
necessity to the ever-growing networks it also adds a lot of complexity to the
network regarding protocols, because of no unification in the network framework
for the management, thus network configuration and manageability of networks
becomes difficult for the network administrators. i.e. (Routers transmit data
depending on the traffic load without a guarantee of QoS, distribution of routers
enables the router to control the data transmission individually. Therefore, the
global view is hidden from the admins to improve the QoS). In closed network
platforms, the deployment of the new protocols is difficult, because all the current
devices are built on traditional networking protocols. The Implementation of new
protocols cannot take place without the appropriate open API. This limits the
network programming and makes network administrators unable to customize
network according to their practical needs and hinder the network innovation. Due
to closed network framework, Network device vendors are averse to any open
standard interfaces to preserve their profits hence reduce the flexibility of
networks. With it a traditional issue like Box to Box network configuration
increased the time to days or even weeks which significantly cause network
efficiency, the manual configuration of devices prone to human errors and
maintaining the status quo equipment leads to high OPEX.
SDN not only lower the barriers of proprietary device and protocols and defines the
open network architecture with consistent innovation to address the problems of
the traditionally designed network is also perceived as viable solutions to DCN,
Enterprises, and ISPs. However, we still need to look what are the challenges and
solutions exists for SDN besides its benefits and based on the discussion it is
attempted to conclude whether we chose Software Defined Networking is the way
forward or not.
12
1.2 Aims
This section intends to provide the process and procedure which will be carried out
in this study based on the chosen subject, and what are the Aims and Objectives it
will achieve at the end of its completion. The aims are listed below:
 To investigate what is Software Defined Networking and how it contributes

to the innovation in networking.
 Software Defined Networking play a significant role If it does then what are
the advantages of adapting it and concerning different networking
environment what benefits it bring to DCNs (Data Center Networks).
 What are the challenges causing the hindrance to adoption of SDN if so then
what are the industry solutions currently existed and how efficient are they?
 Does migration to SDN becomes necessary from present network

architecture and Are we ready for it?
1.3 Objectives
Project aims will be accomplished by completing the following objectives.
 To achieve the first, aim a comprehensive literature review is required in

relation to SDN introduction and its background that lead to the development
of Open Flow and SDN architecture.
 To achieve the second aim significant SDN benefits and problems and SDN
solutions which are impacting the performance of DCNs needs to be drawn
out from the literature review result in establishing a significance of SDN
from the existing networking architecture.
13
 To achieve the third aim, it is necessary to highlight the challenges of SDN

and its research efforts for mitigation are required to be presented from the
authentic sources and by utilizing the gathered information workings of
research efforts will be determined in the discussion section.
Ultimately after performing analysis with the help of survey results in the discussion
section of all the objectives the conclusion will be drawn to answer the primary
research question.
1.4 Thesis Outline
This study is structured as follows:
 Chapter 1 contains with the introduction of the dissertation and set the aims
of the project.
 Chapter 2 comprised of the theoretical introduction and background of

Software Defined Networking describing the early research efforts that laid
the foundation of SDN and explain the OpenFlow protocol characteristics
from the authentic sources followed by the literature review on the
significance of SDN
 Chapter 3 revolves around the benefits of SDN to traditional networks and

especially the section related to Data center networks their problems and
solutions in SDN are presented.
 Chapter 4 deals with challenges/barriers of SDN and for each challenge,

multiple solutions are presented. That can be adopted to mitigated such
barriers.
 Chapter 5 provides the Research Methodology for conducting the survey is

discussed in which primary question is broken into multiple Sub research
questions.
 Chapter 6 is composed of evaluation of sub research questions in the light of

survey responses and literature review is presented and it end with analysis
and conclusion of this study.
1.5 Literature Review
14
Introduction
The literature review serves the detailed overview of the background of the chosen
subject area, highlight the key components. SDN background and its comparison
with the network architecture is absolutely an essential part of this study for the
reader to grasp the discussion which is presented in this research, and to
understand the research question “Does migration to SDN is necessary and
unavoidable and are ready for it” in this study the discussion will be presented in the
light of challenges and benefits of SDN. All this is accompanied through existing
bibliography that is being cited appropriately. The research is presented with a
profound reading from Books, related to SDN technologies published scientific
papers and articles from authentic sources. As SDN is relatively a new architecture,
as compared to its predecessors it's been assured that all the sources that are cited
in this work are current publications and are up to the current networking trends.
15
Chapter 2
SDN Background and Introduction
2 Theoretical Background
2.1 SDN Paradigm
Software Defined Networking, started at UC Berkeley and Stanford University in
2008 where Martini Casado developed the Open Flow protocol which later evolves
into SDN. The Open Networking Foundation (ONF) a non-profit, dedicated
organization take the lead in promotion and adoption of SDN using Open Flow
protocol which becomes the first standard for SDN architecture.
This chapter provides the detailed overview of some of the early programmable
Network, Protocols, and Software Defined Networking.
2.1.1 Early programmable Networks

The following chapter discusses early programmable networks beginning from the
nineties to the current research effort. The logic of decoupling and centralization of
networks although started from the telecommunication (circuit switching) in the
1980s, with Intelligent Network Architecture then as the internet begins to grow in
1990s researcher tailored their research towards programmable networks from
Mid 1990s till this day the evaluation is continuing. In Fig we see numerous
established projects, protocols and predecessors designs that led to current SDN
architecture. In the following paragraphs, we briefly review some of them to in
order to understand the background of SDN.
Figure 2.1 – Early Programmable Networks
16
2.1.1.1 OPEN SIGNALING

In the Mid-nineties, Open Signaling working groups dedicated to “Making ATM, the
Internet more extensible and programmable”. The Open Signaling architecture was
defined to separate the control functionality from the network device using the open
network interface. The driving force to proposed this framework came from
perceiving the closed vertical integration of switches and router that are a hurdle to
the innovative environment and rapid deployment of network service. By using the
open interface Open Signaling approach easily interact with low layer services. Open
signaling was purely based on programming the telecommunication based ATM
networks below figure explains Open Signaling architecture. However, realizing the
approach IETF working group came up to fill the gap of interaction between
controlling and forwarding element to define a protocol known as GSMP. (Open
Signaling and Mobile Networks, 1999)
2.1.1.2 GSMP
Driven by the idea of programmable networks, IETF working group was established
that led the development of GSMP (General Switch Management Protocol) which is
based on Master and Slave design, where controller sends the request message to
the receiving node where each message specifies whether a response is required
with a built-in identifier that associate the response with the request also each
response from the network node indicates the success or failure. In GSMP there are
six classes of request and response messages including:
 Connection Management.
 Reservation Management.
 Port Management.
 State and Statistics.
 Configuration.
 Quality of Service.
Through above-mentioned classes of the message, GSMP allows the external
controller to establish and release session, retain the network status information,
management of ports, request and delete the reservation of network devices etc.
GSMP last version 3 was released in June 2002. Furthermore, Active Networking
Group in 95-97 introduced which is relatively a new architecture to program the network
and viewed network nodes as network nodes details are mentioned below.
(GSMP Applicability, 2002).
2.1.1.3 Active Networks

As the introduction of Software Defined Networking background continuous,
author, of this study like to caution the reader that any history is nuanced than a
17
single narrative might suggest and in Furthermore with this regard the term SDN
etymology itself is complex. The concept of programmable networks begins with the
projects started in early to mid-1990 and span till 2010. In 1990 with rising of
internet surpassing the simple communications like file transfer and emails to
varied applications and greater usage lead the researchers to develop new protocols
and enhance the network services testing and simulating protocols in lab
environment while depending on the availability of funds and high level of
motivation researchers decided to took those notions to IETF (Internet Engineering
Task Force) for the standardization because of slow standardization process which
ultimately ends up frustrating many researchers. With time some of the researchers
eventually come up with the idea to separate the network control, this is somewhat
roughly based the idea of relative ease of re-programming a PC. Which later further
developed to persuade an “Active Networking“. An approach to network control
which no longer see the network as a passive mover of bits but rather as a more
general view of computations that paves the path to envisioning a “Programming
interface” which basically exposed the resources on individual networking node
enabling researchers to provide custom functionality to packets moving through
node to node, this changing dynamics of network control is denunciation to many
who were advocating that network core should remain simple, so that the internet
continue to flourish.
Active Networking research started as an alternative to network services which was
already leading by IP stack and ATM in the 1990s. Active networking in this regard
was the clean-slate approaches which were further followed and improved in a
recent program like GENI (Global Environment for Network Innovation), FIND
(Future Internet Design) in US and FIRE (Future Internet Research and
Experimentation Initiative) in EU. Below is the timeline for past 20 years showing
different programmable network projects.
There were two programming approaches that were adopted in the Active
Networking.
 Capsule Model/Integrated Approach.
 Programmable Node Model/Discreet Approach.
In capsule model, the program fragments are integrated into every data packet
sent to the network, upon arrival of these capsules at the node (router/switch) the
node interprets the program and sends the embedded data as instructed by the
integrated program. In this model, each node would have a built-in mechanism to
perform functionality based on the encapsulated code.
In programmable node model, programs do not send in every data packet rather
programs are injected into the active node, User sends the program to network node
where they reside until the data packets arrived and according to program node
18
behaves and traverses the data packet in the network, data packet may have some
information that would let the node to decide what program to execute.
Capsule model further develops the idea of installation of new data-plane across a
network and using caching to enhance the distribution of code.In this way network
operator have the ability to program the network node extensibility. Active
networking introduces three concepts which later becomes the building block of
Software Defined Networking. (Active Networking, 1997)
 Programmable Functions.
 Network Virtualization.
 Unified architecture for middlebox.
In the paper, the author describes that although the notion of programmable
functions in the network helps the innovation it was not suitable for the real
deployment, and demand for more programmability in production networks
initially becomes the first motivation for SDN. It describes although control and data
plane programmability was continued to develop in parallel. However active
networks were more focused on data plane while early notions of SDN was focused
on the control plane. Active networking also produced a framework for multiple
programming models which led to network virtualization. Shared Node Operating
System (NodeOS) was one of the components, which provide EE ( Execution
Environment ) and shared resources architecture, where each node defines VM
( Virtual Machine ) for operation. Therefore the reason for NodeOS existence as a
separate entity is to aid EE in delivering some degree of programmability. (The Road
to SDN, 2013)
2.1.1.4 DCAN
Moreover in mid-1990 Devolved Control of ATM Networks. This project suggested
that in order develop the scalable network infrastructure the control and
management functionality of the node (in this case ATM switches) should be
separated and reside in some external entity (controller). which set the foundation
of current SDN architecture. DCAN assumes the need for a protocol that can drive
the communication between the two entities, which is what aligns with today
OpenFlow design. (Devolved Control of ATM Networks)
19
Figure 2.2 – DCAN Design
2.1.1.5 4D Architecture
The 4D architecture in mid-2000 developed a clean slate design with a separation
between the routing logic and protocols responsible for the interaction between the
network elements. In the 4D architecture, they divide the network functionality into
4 planes to view the network holistically and configuration management (FIB
computation in each router in the network) “decision” plane was utilized. The
“dissemination and Discovery” planes were used for maintaining node stats like link
up/down information and to discover the directly attached neighbors. Last the data
plane responsible for the forwarding of the traffic. (Clean slate 4D approach to
network control and management, 2005)
Figure 2.3 – 4D Architecture
20
2.1.1.6 NETCONF
Network Configuration Protocol purposed by IETF in 2006. NETCONF was
developed as a management protocol for configuration modification of network
devices. Using API NETCONF traverse management statistics to nodes. Before
NETCONF it was SNMP (Simple Network Management Protocol) which was
introduced in late 80’s, SNMP was intended to configure the network devices, but
apparently, despite what it was developed for it ends up being the performance and
fault monitoring tool. In the earlier version of SNMP, the lack of strong security was
the vulnerability which was addressed in the later releases. At that time NETCONF
was new an alternate approach to addresses the shortcoming of SNMP.
Unfortunately, NETCONF was not the approach that can provide the full
programmability and control functionality of network device because there is no
decoupling of control and data plane rather NETCONF act as a useful management
tool that accomplishes the task of reconfiguring the device in much simpler manner.
However, the ForCES IETF group was able to develop the architectural framework
and protocol that provide the functionality of control and data plane separation.
(NETCONF, 2006).
2.1.1.7 ForCES
The Forwarding and Control Element Separation IETF group separate the
networking node control element from the forwarding element. In the IETF
Specification, two logic entities are defined FE (Forwarding Element) and CE
(Control Element), FE uses the underlying network hardware which is controlled by
CE using control and signaling functions and employs the ForCES for
communication with FE. ForCES protocol used the earlier Master and Slave design
considering the GSMP where CE is master and FE is a slave. The most important
element in this framework is the LFB (Logical Function Block) which reside in FE
and through the communication protocol, CE used LFB to instruct the FE how to
perform packet processing. One element to note here that ForCES defines FE and CE
architecture it's not like where control element is completely ripped off and placed
to an external entity that controls the forwarding element which we see later see in
SDN. Because ForCES is limited to logical separation it can run in the traditional
devices while OpenFlow cannot if OpenFlow standards are not supported. In the
next section, we dive into the ethane project which later transforms into OpenFlow
the first standardized protocol for SDN. (Forwarding and Control Element
Separation (ForCES) Protocol, 2010)
21
Figure 2.4 – ForCES Architecture
2.1.1.8 Ethane
Sane/Ethane platform was the new architecture, powerful yet providing simple
manageability along strong security back in 2006, which enhanced the enterprise's
networks. Ethane allows the network engineers to define a network-wide policy and
apply it to every node. The trick behind management simplification and deployment
of policy to node along the path is that all the operation complexity is performed by
the central controller as we clearly see in Figure (2.4). By using the secure channel
controller communicate with the switches and decision made whether the packet
should be allowed or denied. In the switches, flow tables are maintained and
controller computes the routes for the flow and also controller makes sure that each
flow must be permissible by network policy otherwise it is dropped. This was the
core concept of SDN framework we see today which is further evolving and
advancing rapidly. (Ethane Taking Control of the Enterprise, 2007)
Figure 2.5 – Ethane Architecture
22
2.2 Software Defined Networking

In this section and onwards we look at the SDN architecture in the light of numerous
research paper, explaining the composition of SDN.
There is no single definition that describes SDN, beginning with the pioneer ONF
(Open Network Foundation) describe it as an emerging network migration where
network decision making is logically centralized in the software-based controller
that maintain the global view through this abstraction network appear to the
application as a single logical switch (Software-Defined Networking: The New
Norms for Networks, 2012).
In research papers SDN is defined as a flexible and agile framework for the network
operators to provide services author describe the pillar of SDN is the controller that
defines and controls flows in forwarding element. Others describe SDN as a
simplified management model that makes the network innovative through network
programmability. They further describe how SDN brought the fundamental change
in the traditional way of networking by decoupling the control logic from the
forwarding element.
(Software-defined networking: A comprehensive survey, 2015, A survey on
software-defined network and Open Flow: from concept to implementation, 2014).
The infrastructure layer (data plane) which composed of router and switches
concerned with forwarding of packets, where the control logic moved to the
external device (server in this case) also known as a controller the logical
centralization of network intelligence in SDN controller instead of distributed to
multiple network resources and provides the high-level view of all the underlying
physical resource in the network.
These distinctive features make the Software Defined Networking programmable,
flexible, adaptable, manageable and cost effective which can modify existing
network environment from closed, static to open and innovative. Further
description of SDN tiers which make this new architecture different from classical
networks is presented below.
(A survey of software-defined networking: the past, present, and future of
programmable networks 2014, A survey on software-defined networking. 2015, A
survey and a layered taxonomy of software-defined networking, 2014, Network
innovation using OpenFlow: A survey, 2014)
23
2.2.1 Tier Architecture

The SDN framework which is defined by ONF (Open Network Foundation) is based on
three-layer architecture design as shown in figure 2.5 below. (Software-Defined
Networking: The New Norms for Networks, 2012)
Figure 2.6 – Software Defined Architecture
In this design, every tier has its explicit functionalities
1. In three-layer architecture application layer allows the administrator and

software developer to develop and customize their application according to
business needs without waiting for a vendor-specific program that can be
time-consuming. Moreover, network operators can leverage the network
using specific applications like (QoS, security and configuration automation,
management, optimization of network resources etc). According to Adnan et
al application layer programs share network behavior and requirement with
the SDN controller via northbound API and the extraction of the information
from the underlying network resources is carried according to the policy or
network behavior. Ultimately these instructions translated from high-level
applications to low-level infrastructure layer to program the forwarding
device.
2. The control layer is the hub of “network intelligence”, Author Kreutz et al

define the controller as the special network component which is logically
centralized but can be physically distributed for failover. Xia et al and Jarraya
et al define it as a software platform used for establishing and terminating
24
the flows and path in SDN. They further describe that overall network
management is handled in the controller while it aids the programmability of
the entire network and providing the high-level abstraction view to the layer
above using the northbound interface and to network nodes with the
southbound interface, Faraday et al in-research paper mentioned control
layer as intermediator between application and data plane and give
importance to an efficient design of the controller and its interfaces. Below
are some of the popular controller used today.
3. The infrastructure layer basic functionality is packet forwarding. Through

the usage of wired cables or wireless radio channels, the device is
interconnected and forwarding decisions are communicated to these devices
using southbound interface (Open Flow etc). Kreutz et.al defines the
forwarding decision as a flow based rather destination based where they
define a flow in a broader sense a set of packet fields containing values used
for matching criteria and set of instructions for packet transmission.
Therefore, in SDN architecture flows reside in the flow table and are utilized
by interconnected forwarding devices which make up the infrastructure
layer.
Hence, SDN layer abstraction levitates the Burdon from network operators to
configure thousands of individual devices instead having global view of the entire
network and define a universal policy for their entire network, SDN architecture
also facilitates the programmer to write programs for their business-critical and
through API (Application Programmable Interface) communicate the policies and
services to forwarding device. However, SDN abstraction layer depends highly on
the data plane to make the interaction itself possible to layers above. To achieve this
goal, traditional switches and router are not the viable choices, instead, SDN
switches like (OF-only Switches, and OF-Hybrid Switches) are required.
(Secure and Dependable Software Defined Networks, Software-Defined Networking:
A comprehensive Survey, A Survey on Software-Defined Networking, A Survey and a
Layered Taxonomy of Software-Defined Networking, Software Defined Networking:
A survey)
25
2.2.2 Comparison of Conventional and SDN Switch

2.2.2.1 Conventional Switch
In traditional networking, packet forwarding and intelligent decision making
occurred in the same device as shown in figure 2.6
Figure 2.7 – Classical Switch design

The control plane generally responsible for providing the operation like signaling,
routing decisions etc and based on general processors and in data plane packet-
switching functions takes place using ASICs (Application Specific Integrated
Circuits) which are very fast and performs forwarding at wire speed (line rate),
However to hold the path forwarding information flow tables in switches are used
typically built from special CAM or TCAM. But the main differences between the
classical and SDN switch is the architectural design which defines the distinction
between the two nodes.
2.2.2.2 SDN Switch
By means of SDN, network node becomes a simple packet forwarding devices with
little to no intelligence and all the controlling capabilities reside in server controller
responsible for high-level decision-making for routing, network stats, policies etc
from a centralized location. But in order implement high-level policies and retrieve
information from the infrastructure layer network nodes needs to provide support
for SDN framework, SDN agent or component should be present in the switch which
can communicate with the controller as shown in figure 2.7.
26
Figure 2.8 – SDN Switch Design
Xia W et al describe that unlike the conventional structure of the switches that runs
routing algorithms to make routing decisions. The new architecture striped the
control functions from SDN enable switches as result switches only concerned with
the gathering and reporting of the network status and packet forwarding element
according to the imposed rules, these rules passed from the controller are stored in
the local Memory like TCAM, SRAM (Ternary Content Addressable Memory, Static
Random-Access Memory). Xia W et al agreed that this structure will reduced
complexity which in turn leads to easy manufacturing and low-cost solutions for
DCNs (Data Center Networks) and enterprises. Some of the most popular SDN
switches based on Open Flow protocol below is the table of Open Flow enabled
switches provided and in later section detail overview of Open Flow Switch and
control plane presented.
Grou Product Type Versio Maker Brief description

p n
8200zl and 5400zl Chassis V1.0 Hewlett-Packard Data center class (switch module).
Black Diamond X8 Switch V1.0 Extreme Network Cloud scale hybrid (Ethernet/open flow).
CX600 Series Router V1.0 Huawei Carrie class MAN router.
EX9200 Ethernet Chassis V1.0 Juniper Chassis based switches cloud (Data Centers).
EZ chip NP-4 Chip V1.1 EZ chip Technologies High-performance 100-Gigabit Network
Processors.
MLX series Router V1.0 Brocade Service providers and enterprise class router.
Novi Switch Switch V1.3 Novi Flow High-performance Open Flow Switch
Net FPGA Card V1.0 Net FPGA 1G and 10G Open Flow implementations.
HW Rack Switch G8264 Switch V1.0 IBM Data center switch supporting virtual fabric and
Open Flow.
PF5240 and Switch V1.0 NEC Enterprise class hybrid Ethernet/Open Flow
PF5820 switch.
Pica8 3920 Switch V1.0 Pic8 Hybrid Ethernet/Open Flow Switch.
27
Plexxi Switch 1 Switch V1.0 Plexxi Optical multiplexing interconnect for data
center.
Arista 7150 Series Switch V1.0 Arista Network Data centers hybrid Ethernet/Open Flow
switch.
LINC Switch V1.4 Flow forwarding Erlang-based soft switch with OF-config 1.1
support.
Open switch Switch V1.0-1.3 Open Community Switch platform designed for virtualized server
environment,
SW Open flow click Vrouter V1.0 Yogesh Mundad Open flow switching element for click software
routers.
Switch light Switch V1.0 Big switch Thin switching software platform for
physical/virtual switches.
Pantou/Open WRT Switch V1.0 Stanford Turns a wireless router into an OF-enabled
switch.
Xor Plus Switch V1.0 Pica8 Switching software for high-performance
ASICS.
Open flow Switch V1.0 Stanford Of switching capability to a Linux PC with
reference multiple NICs.
Ofsoftswitch13 Switch V1.3 Ericsson, CPqD OF1.3 compatible user-space software switch
implementation.
Table 2.1- Open Flow-enabled switches
Kreutz D et al elaborate that software switches have become the driving force for
virtualized networking infrastructure and deliver promising solutions for DCNs.
Authors also highlight that how there were memory constraints regarding the size
of TCAM which were not sufficient to hold the flow entries, it is now increasing
rapidly with some of new switches specially the Gigabit switches for enterprise that
have a support of 32,000 L2 and L3 to 64,000 match flows, other switches like
10GbE providing support up to 80,000 L2 flows like (Net FPGA). On the other hand,
switches utilizing high-performance chips like (Np 4 and EZ chip) which enable
these devices to provide TCAM memory supporting flow entries from 125,000 up to
10,00000. Various Open Flow switches have been produced by Networking
hardware vendors as shown in Table 1 ranging from SME equipment’s too high-end
data center equipment like (100 GBE switches) these high devices become a
mandatory for big DCNs where terabytes of application data traverse per second. As
we have seen some of the SDN Open switches and vendor specific utilizing Open
Flow. In the next section, we look Open Flow in detail and its operations. (A Survey
on Software-Defined Networking, Software-Defined Networking: A comprehensive
Survey)
2.3 Open Flow Protocol

ONF (Open Network Foundation), defines the open standard protocol Open Flow as
the first medium of communication between the control and data plane of SDN
networks as illustrated in figure 2.9.
28
Figure 2.9 – Open Flow Framework
Open flow allows devices at the data plane to be accessible and manipulated both in
physical and virtual environment for instance through Open flow administrator can
gain access to the open flow enabled switch to modify flow table and flow entries
instruct the device how to direct the network traffic, these flows can be modified in
a minimum amount of time according to author Li W et al in paper (A survey on Open
Flow-based Software Defined Networks: Security challenges and countermeasures).
In figure 2.8 we can see that communication between the controller and the Open
flow switch take place via Open flow protocol over a secure channel, it is essential to
have security mechanism in place to avoid the flow entries from the malicious user.
Open flow protocol defines numerous types of flow message that traverse through
SDN architecture which will be discussed in Open Flow message type section, As the
open flow protocol demand increased for Open Flow (HW and OVS) vendors start
adding the open flow protocol into their commercial devices making them the “Open
Flow Hybrid” devices include (Switches, Router, wireless AP etc.). Thus, Open Flow
allows the innovative deployment of switching and routing protocols without
requiring the vendor to expose the internal working of the device. Moreover, the
virtual machine migration which often required in DCNs becomes much easier to
deploy and mobile IP network and high-security networks are more easily handled
with Open Flow in SDN architecture.
In the following sections, the Open Flow switch functionality is deeply inspected
starting from the processing of the Open Flow protocol its evolution and end with
the Open Flow control plane.
2.3.1 Open Flow Evolution

The open flow protocol version 1.0 first came into being in December 2009. Due to
the continue enhancement by ONF, where open flow version 1.0 had only 12 match
fields and a single flow table led to latest version 1.5.0 which offer greater flexibility
by providing 41 matching fields with multiple flow tables the scalability and
29
functionalities have been greatly extended over the past few years as detailed in
figures 2.14.
Figure 2.10 – Open Flow timeline

Below a table is presented summarizing the updates done to Open Flow protocol
during the standardization process by the ONF.
Versions Features Reasons Use Cases
Multiple Table To avoid Flow Entry

1.0 Explosion
-1.1 Group Table Load balancing,
To apply action set to failover, and link
Vlan and Mpls Group of Flows Aggregation
Support
1.1 - 1.2 OXM Match Improve Matching

Framework Capability
Multiple Controller Failover

Controller Load Balancing/Scalability and Controller Load
Balancing
Meter Table QoS with Diff Services

1.2 - 1.3
Table Miss Improve flexibility
Flow entry
Synchronized Improve Table Scalability MAC learning and

1.3 - 1.4 Table Forwarding
30
Bundle/Atomi Improve Switch Multi Switch

c Operation Synchronization Configuration
Egress Table Packet processing at

1.4 -1.5 Output port
Bundle Further Improvement in

Scheduling Switch Synchronization
Table 2.2 – Major Update in Each Open Flow Version
2.3.2 Open Flow Data Plane

2.3.2.1 Open Flow Operating Principles
This section focused on the overview of the OF Switch component operations. When
OF switch first receives the packet that has no flow entries stored in the flow table it
sends the packet toward the controller. Upon receiving the packet, the controller
then made the decision whether to drop the packet or to define the flow entry in the
switch. If the controller instructs the switch with flow entry the switch learns how
to forward subsequent packet in the future as depicted in figure 2.10.
Figure 2.11 - Packets traversing by the OF switch
31
2.3.2.2 Open Flow Tables
As Open Flow tables are the core of the OF protocol. There are number of
fundamental mechanism which comprised the Open Flow table. The most popular
among them are pipeline processing, packet matching, table-miss, others.
2.3.2.3 Pipeline Processing
In pipeline processing, the packets are matched against the number of flow tables,
the flow tables of an OF switch are numbered sequentially start from the (0). The
first packet entered in the OF switch matched against the flow entries of flow table
(0). If the flow entry matched then the action associated with the flow entry is
executed. These actions may direct packet towards the next table, where the process
is repeated as shown in figure 2.11
Figure 2.12 – Pipeline Processing
In the pipeline processing, the flow entries can only instruct the packet towards the
flow table which has a greater number in other words packet can only go forward
not backward. The flow entries of the last flow table do not contain any instructions
and if the flow entry does not match the packets then the pipeline processing stops
and packet is processed with some specific actions. But normally packets found the
match entry and forwarded toward its destination. If the packet does not match any
of entry in any of the flow tables then, in this case, it is matched with the “Table
miss” the instructions associated with table miss will be discussed in the later
section.
2.3.2.4 Flow Entry
Each Flow entry has number of fields and is identified by match and priority
variable fields. According to specification, each unique entry is comprised of match
and priority field in the flow table. If the flow entry contains the wild card (means all
field absent) and has priority of zero then is called Table-miss flow entry and
actions associated with the table miss entry is carried out for the packets.
Figure 2.13 – Flow Entry Fields
32
2.3.2.5 Open Flow Packet Matching
On receipt of a packet, OF switch start processing the packet by doing the lookups in
the table (0) and may further carry on the lookup in pipeline processing manner,
matching fields of the packet are extracted from the packets, extracted packets fields
may differ because packets are of several types like (Ipv4 address or Ethernet
source address). It’s not necessary that only the header fields are matched meta
data field and ingress port can also use for matching. If the matching entry is found,
then the instructions set associated with matched flow entry is executed by OF
switch. Instruction may contain (packet forwarding, packet modification or modify
pipeline processing) it is to note here that packets are only matched with the highest
priority flow entry and if the multiple matching flow entries found with same
highest priority then the selected flow entry is clearly undefined. Moreover, if some
actions are carried out on packets in pipeline processing those alteration reflected
in the packet match field which shows the current state of the packets but normally
packets are forwarded if the instructions in matching flow entry does not specify the
next table as shown in figure 2.12. However, if no match found then the table-miss
flow occurred explained in the following section.
Figure 2.14 – Packet Matching
2.3.2.6 Table Miss
Table-miss flow event happen when no packet match is found. According to the
(ONF) Open Flow specification, each flow table must support the table-miss flow
entry for processing the table misses. If the packets matched with table miss flow
entry then OF switch take actions instructed by the table miss flow entry.
33
Instruction could be to direct the packets towards the controller or to simply drop
as seen in figure 2.13. As the table, miss flow entry is installed by the controller and
it may expire in case where no table miss flow entry exist in the flow table the
unmatched packets are dropped (discarded).
2.3.2.7 Open Flow Message Types
There are three types message which are used to modify the flow entries in the
flows table, for statistics and keep alive.
 Controller to Switch message.

 Asynchronous message.
 Symmetric Message.
 Controller to Switch, these types of message used to maintain the state of

the switch which include its flow configuration, flow and group table entries.
These messages are mostly initiated by the controller and it may or may not
require a response from the. A packet-out message is included in this class
which is used when switch sent packet towards the controller and controller
direct the packet to the switch output port instead of dropping it
 Asynchronous, messages are the numerous status messages. These

messages are send without the any soliciting the controller from the switch
and include the packet-in message which send by the switch towards
controller for packets it does not have any flow in the flow table. Messages
including in this class are mentioned below.
 Symmetric, these message also does not require any solicitation from either
side.
2.3.3 Open Flow Control Plane

Above literature review described the open flow data plane architecture, in this part
the open flow control is focused. As we already know controller regulates the
network in SDN architecture. Which provides a high-level view of the network and
manage -network nodes at the infrastructure layer. In this section, we look at flow
insertion -approaches of the controller which are categorized in three types.
 Reactive approach.
 Proactive approach.
 Predictive approach.
34
In reactive approach, when switch receives the packet does not find in flow in the
table it sends the packet towards the controller which makes some decision like
(forwarding to output port or dropping the packet) in any case flow entry is
installed in the switch flow table and all the subsequent packets follows the installed
flow. This is the how controller mostly operate.
In proactive approach, high accuracy is required of the flow route the packet is
going to follow because flow entry for specific packet are inserted in the flow table
by the controller before the arrival of the packets. In this case, switch already know
where to forward the packet without communicating with the controller. In this
approach number of messages between the controller and switch are reduced which
result in the reduction of performance overhead.
In predictive approach, controller gathers the historical data regarding
performance of the network to define and make modification in the route and flow
in the flow table. (Open Flow Specification, 2014)
2.3.4 Conclusion
The literature review present in this chapter aimed to give the thorough overview of
the back ground of Software Defined Networking as part of this study. SDN
background deals with all the Pre SDN technologies that give the reader an
understanding of how previous technologies functions and what are improvement
that had been done over the years that led to the current SDN architecture,
difference between SDN three tier architecture design is discussed which is the most
important aspect of SDN and the evaluation of conventional and SDN switch.
Moreover, Open flow framework is described in detail its features, operation and the
evolution of Open Flow protocol, so that the reader knows how different versions of
Open flow protocol over the time improved which greatly enhance the capability
and performance of SDN architecture as Open Flow protocol is currently -only
standard protocol for the SDN there are other proprietary and open protocol are
available in the market but Open Flow is the most widely used one.
35
Chapter 3
Software Defined Networking Benefits
In this section SDN benefits are described in general and although the applicability
of SDN today in networking domain is widespread in this section consideration is
given to Data Center Network (DCN) the problem DCN are facing and how SDN can
resolve the issues concerning DCN and later in chapter 3 challenges and research
efforts for SDN presented.
3.1 Benefits
As the traditional network methods are practiced which makes networking more
complex than ever especially in a last decade and with the advent the of Big data
that dramatically impact the network management. Although there is uncertainty
present but despite of this many companies is distancing from traditional
networking and adapting SDN as a solution to cope network management in a cost
effective and efficient manner. In general, SDN provide following benefits.
 Holistic and central control of multi-vendor environment
 Cost Reduction
 Enhancing Configuration
 Innovation and automation.
 Enhancing Performance
 Increased reliability and security
3.1.1 Holistic and central control of multi-vendor environment

The most notable benefit of SDN compare to traditional networks it is the
centralized view and holistic control making it easier to centralized the
management and provisioning for the enterprises and ISP’s also as demands from
customer are kept increasing new application and VMs are setup on demand makes
it hard to accommodate new processing request such as those for Big data and time
consuming. SDN accelerate the service delivery and improve agility for both virtual
and physical device from the central location.
3.1.2 Cost Reduction

CAPEX and OPEX take a huge leap when it comes to SDN. As SDN deliver
improvements in administering the network, optimize the server usage and provide
better control of virtualization due to abstraction that drives the operation cost
down and contributes to faster returns. As far as CAPEX is concerned SDN give new
36
life to existing data plane devices existing hardware can be reconfigured by using
the instruction from the SDN controller other than that there are many companies
who are building “white box” device that has no specific vendor associated to it
which makes them low-cost efficient hardware many people in the industry
advocate relocation of the control logic to centralized general server like x86 class in
different network domains especially data center promises to lower the CAPEX
cost.
3.1.3 Enhancing Configuration

Configuration is the most vital part to manage the network especially with the
addition of new equipment in the existing network to achieve the coherence in the
network a proper configuration is required which is hectic in traditional network
due to the heterogeneity among device manufacturer and configuration interfaces
not only uniformity is present among devices but also the manual processing of
device likely error prone and tedious. It is now accepted that automatic dynamic
configuration of network is a challenge. But not anymore because SDN provide the
remedy to this problem. SDN provide the unification in the control plane over
heterogeneous network devices like (switches, router, Middleware devices etc.) and
reduce the Burdon of manual configuration as such as that whole network can easily
be programmed and dynamically optimized based on the network status.
3.1.4 Innovation and Automation

Due to exponential growth and innovation of network applications forces the
networks to build a new architecture that could copy the existing challenges. This
becomes evident that new networks architecture should encourage automation and
innovation rather serve its efforts in trying to predict and perfectly meet the
requirements of future network applications. Due to the limitation of existing
networks any new idea or design meets up challenges regards to experimenting and
implementation when attempted to make it interact with the current networks. The
main limitations are the proprietary hardware and software which constantly
barriers the existing networks to adopt any innovation, prevent alteration for any
experimentation any demonstration for new network practice are conducted in
separate testbed from which sufficient confident is not gained for industry
deployment of innovative designs. But with the initiation of SDN architecture which
solely based on open hardware platform opens new avenues to encourage constant
innovation by defining programmable networks platform to experiment and deploy
innovative designs to efficiently meet with new application challenges. The high
programmability of SDN blur the line of separation between the virtual networks
that led to experimentation on a real environment. The constant and progressive
implementation of new idea are now possible with SDN which delivers an interface
that provide seamless transition from experimentation phase to a real deployment.
37
3.1.5 Enhancing Performance

Every business desire to make the most out of the already deployment
infrastructure. However, in traditional networks, the environment is mostly multi-
vendors where various branded network technologies are co-existing due to which
the performance optimization has been considered difficult. Approaches practiced
in existing networks focused on maximizing performance of a subset of networks or
optimize the quality of user experience of some network services. SDN introduction
offers an opportunity to enhance the network performance globally rather focused
to certain operations of the network by allowing the centralized controlling
functionality with a global network view and efficient traversing of information
between the SDN layers architecture (Application, Control, and Data plane). As a
result, many existing challenges easily managed with numerous properly designed
protocols. This new architecture develops and easily deploy solutions to problems
like (traffic scheduling, end-to-end congestion control, energy efficient operations,
load balancing, QoS etc.) to prove their effectiveness in enhancing the network
performance. (A Survey on Software-Defined Networking, 2015)
3.1.6 Increased reliability and security

Software defined networking abstraction enables IT to state high-level
configurations and global policy statements which are imposed on device at the
infrastructure layer via Open Flow protocol. The need to configure individual device
is eliminated by the Open flow based SDN architecture whenever the end-point
device, application, or service is added or moved or if any policy change is required
which result in reduction the likelihood of network failure hence improve the
network reliability. As SDN controller deliver the complete topology view and
control over the existing network the controller makes sure that access control,
security, traffic engineering and other policies remains intact and deployed
consistently across the wired and wireless networks infrastructure and not only
consistency is achieved in deployment of security policies but security policies are
implemented on a granular basis among all the network equipment SDN security
applications are capable of sent any suspicious traffic flows towards middleware’s
like (firewall and IDS/IPS) immediately. It is evident that potential of SDN is great in
achieving network security visibility and accelerating the pace of deploying
networking services. But there are still challenges remain that needs to be taken
care of which are mentioned in the section of SDN challenges. (Software Defined
Networking: The New Norms for Networks, 2012)
38
3.2 SDN in DCN Problems and Solutions
3.2.1 Data Center Evolution
As the internet growth becomes impeccable both in speed and communication

technologies, it gave rise to highly intense processing data center. Prior to DCs
interoperations between storage, networks and computing exists on desktop PCs of
business users, As the storage demands increased in parallel with the requirement
for collaboration Servers (like Mail servers, Web servers, Database servers etc.)
were installed, which were used by a number of desktop user in an enterprise
organization, these servers were all localized providing dedicated service to the
local clients, with the passage of time departmental servers failed to handle the
growing load and collaborative requirements, So enterprises server were moved to
the centralized data centers, most important is the manageability, servers at the site
are hard to manage they need proper infrastructure, resources to run them which
are costly as compared to if located offsite and second reason to sharing resources
among the enterprise’s users. Data centers provide physical separation of the
servers, their storage and the networks that provide an interconnection with the
end user. But a revolution took the traditional server architecture a decade ago, with
the introduction of Server virtualization. This term introduced when VMware
invented a technology that enables the host machine to run multiple guest operating
system depending on the processing and storage capability of the host through the
medium called Hypervisor, which emulates a real computing environment.
Fig 3.1 - Server Virtualization
This idea (VMware) was originally for the engineers who wanted work on Linux for
their computing needs rather than windows, through VMware they can execute
windows for any specific requirements within Linux and close the program like any
other program running in normal OS. With the advent of this technology, a server
that-runs a single OS and specific applications, if compared with existing data
center servers seems irrelevant, because of existing servers increase computing and
storage capacity, and capability of executing multiple OS in a virtualized
39
environment. Where an OS like Windows Server that previously occupied the entire
bare metal machine now runs on top of a high processing and a large amount of
storage capable host machine along with a number of VMs, from the network
operators perspective this makes them easier to manage, allow the optimization of
resources and provision of specific application services to their clients. (SDN
O’Reilly, 2013)
3.2.2 Data Center Segregation
As the density of servers and storage combine with high bandwidth availability the
trend shifts to host more and more services, with the increase in hardware, demand
for power consumption and cooling of those server farms increased equally, costing
organizations a high OPEX (Operation Expenditure) data center start adopting the
virtualization approach that enables them to optimize the use of hardware, decrease
the power requirement and allow them to quickly create, remove applications and
services. But with virtualization where data centers able to increase the efficiency,
this also placed challenges in the form of meeting the service demands in DCs that
was never seen before, with sheer numbers of VMs deployed in DCs effect the
network devices which were not able to cope up the processing required for Big
Data, specifically areas that are affected with problems like MAC address table size,
Number of VLANs and Spanning Tree and others, these will be discussed in
Increasing demands section first look at the segregation of data centers that have
grown so large that they hold thousand, even tens of thousands of servers. These
data center can be segmented into three categories.
 Private single-tenant.
 Private multi-tenant.
 Public multi-tenant.
3.2.3 Cloud Deployment
The data center in the past only accessible using private communication channels.
But as with the passage of time, these data centers has begun to be accessible
through the internet and being referred as Cloud. There are further three categories
of cloud deployment which are commonly known as.
 Public cloud.
 Private cloud.
 Hybrid cloud.
3.2.4 Increasing Demands and Data Center Limitations
After a brief introduction of some of the problem areas earlier that comes along with
the server virtualizations. In this section, we will do a detail analysis why these
40
areas are affected with server virtualization which was initally supposed to make
the operations efficient but end up being insufficient as the demand increases
significantly.
Mac Address Burst: Mac address tables are used for the determination of the ports
or interfaces in networking devices (switches, routers) out of which the device
forward and received frames. Because the number of entries provided in the Mac
table is adequate for the network demands in the past, but as the network growth
with Virtualized environments, demands on the Mac address tables of TOR (Top-of-
Rack) switches increased this creates a problem. Networks in the past had the
maximum number of Mac addresses entries in the Mac table at any certain time.
With the advent of server virtualization and multi-tenant environments, the number
of servers possible in L2 networks has increased significantly, with each virtual NIC
on each server, this bursting of Mac address creates a problem overflowing of Mac
tables. Commonly Switches learn Mac addresses as the frames are received on the
ports, when the port received the initial frame it prompts a response, on that
response switch is able to learn the port and bound that Mac address with the
particular port and propagates its Mac table this is carried out in normal
circumstance unless the switch Mac table is not full, if it is then the received frame
for a particular destination continue to be flooded and could cause a substantial
performance issues.
Limitation of VLANs: When extension 802.1Q was created to define local area a
network (LAN), it was not known at that time that networks would ever need more
than 12bits to hold potential V-LAN IDs.
Fig 3.2 – VLAN Exhaustion
VLANs are key the characteristics in layer 2 data center networks to segment the
networks especially in multi-tenants environments where network isolation for
security and QoS is required. The (12-bit) VLANs served well for the many data
center that requires fewer than 4096 VLANs and since the size of VLANs (12-bit)
cannot be expanded to accommodate a large number of VMs a new solution is
needed to overcome this hurdle. (Software Defined Networks a Comprehensive
Approach, 2014)
Spanning Tree: To avoid loops in the networks IEEE 802.1d standard was
introduced, switches learned loop-free forwarding tables by observing the traffic
41
pattern forwarding through them, eliminating the broadcast storm in the networks.
Earlier spanning tree take some time (seconds) to conveLimirgence completely, but
with the later improved standard (IEEE 802.1w and IEEE 802.1s) this was taken
care and convergence time dramatically increased, even with all these
improvements STP still leaves a fully functional link unused. Data centers cannot
afford this they wanted to optimize the links between nodes. With server
virtualization, the frequency of disruption is increased, adding the re-convergence,
though later STP flavors provide rapid failovers but still, it counts as an inefficiency
factor in the large data center with high amount virtualization. Another way to avoid
the STP limitation is to configure server within the rack to be L3 networks,
However, this cannot cope with the compatibility of L2 model for inter-VM
communication. (RFC 7348, 2014)
Management of Resources: Currently data centers are much more efficient than a decade
ago, with the exponential growth of virtual servers and storage capabilities, that makes
them adaptable to changes rather much quickly than the networks can cope. Firstly in large
DC environments, changes in the network can take time, and the possible repercussions of
mistaken network change, that could cause a significant disruption in the DC resources like
(storage, computing, and communication). On the other hand configuration of individual
server resources (CPU, memory, network, and storage) becomes much more complex if not
impossible to meet the specific needs of customer applications. Another aspect of it is
running multiple services on a single server while maintaining the guaranteed QoS through
the use of SLA (service level agreements), this degrades the performance of the hosts and
penalties are paid by the provider if SLAs are not up to the agreed standards.To integrate
any change in existing DC networks without compromising the performance and reduce the
complex implementations of meeting the customer demands, a framework is required that
address DC automation and performance related issues and deliver a network
architecture that can par current DCs needs. (Network and server resource
management strategies for data center infrastructures A survey, 2016)
Failure Recovery: Growing needs and scaling demands lead data center to host
range of services, to deliver these services effectively, DCs should be fault-tolerant,
easy to manage and reliable. But a recent study suggested that links in the data
center are more likely to fail than the devices, burst of links caused by protocols, and
load balancers subject to more software faults. Also including DCs size and scale and
routing in DCs makes it a complex task to recover from the failure nowadays. It
takes a long time for DC routing to recover which result in significantly impacting
the real-time and interactive applications like (i.e stock trading, search etc). Longer
durations -of loss of connectivity is highly unacceptable to critical applications,
especially if combined with the poor recovery decisions only magnifies the recovery
growth. The -most important consideration for failure recovery lies in optimal
reconfiguration, determinism and predictability with the different distributed
protocols running inter -and extra DCs make the recovery results unpredictable.
Redundancy in DCN (Data Center Networks) consider to be one of the solutions for
the failover but it is not effective entirely as it thought to be. First bugs could disrupt
the failover mechanism and can arise if there is an uncertainty in choosing the
42
alternative path. Furthermore, protocol issues such as (timeouts, Stp

reconfiguration may result in loss of traffic). Therefore, a complete view is required,
so that link failure, device faults, backup path selection can be carried out in a most
effective manner possible to yield the best results. (Understanding network failures
in data centers measurement, analysis, and implications, 2011)
Multitenancy: Multi-tenancy is an approach in a cloud environment like SaaS

(Software as a Services). Let’s first define what the multi-tenant applications are
and then will move towards what are the challenges MTDC (multi-tenant data
centers) are currently dealing with. In multi-tenant environment multiple tenants
(customer) share a single hardware resource it’s an environment where
virtualization hide the hardware this let tenants share the single application and
database instance and enable tenants to configure their applications according to
their needs and business requirements. Where multi-tenancy levitates the Burdon
by optimal utilization of the hardware and providing the ease of management,
effective provision of resources and suppressing the CAPEX (Capital Expenditure).
Still, MTDC poses severe challenges in the form of.
 Security.
 Scalability.
 Maintenance.
 Zero-Downtime.
 Performance
.
3.3 SDN Solutions for DCN
As this already a known knowledge that Software defined networking can done in
three diverse ways Open SDN, SDN hypervisor-based Overlays, and SDN via API,
here in this section will see how SDN is able to resolve problems DCNs are currently
facing. NFV (network function virtualization) as many said it’s hard to distinguish
between SDN and NFV and several of the traits are closely resemble to what SDN is
comprised of like automation of the network and virtualization same goes for the
NFV but it’s just that in NFV virtualization of application and services is part of
wider movement. Most of the time SDN and NFV technologies are work in
conjunction to provide better control and performance of the networks. The virtual
overlay introduced by SDN aids in managing and provisioning the virtual networks
functions with NFV. Now a day the motion has become so strong that network
function virtualization has become synonymous with SDN.
To mitigate the problems of DCNs as mentioned earlier, three SDN flavors SDN
hypervisor-based overlays (using tunnel technologies), Open SDN and SDN via API
are used because they are the only ones which have been recognized commercially
till today. Although there are three SDN types but only two are discussed below to
resolve DCNs needs.
43
3.3.1 Mac Address Burst and Limitation of VLANs

SDN Overlays
To mitigate against the Mac bursting and Vlans exhaustion in data center tunneling
is the tunneling is the most viable option. That’s way SDN overlays is an
understandable choice here. As far as the Mac bursting is concerned it is resolved by
using VXLAN and NVGRE where only the MAC addresses of tunnel endpoint (VTEPs)
are visible which are at hypervisor assume if there are 8 VMs per hypervisor, then
total number of mac are reduced by the factor of eight. If more VMs are added per
hypervisors then Mac savings are greater because only end points Mac addresses
will be visible.
This solution also recognized the problems with limited number of VLANs. Because
4096 VLANs in an immense size DCNs are not enough to cope all the tenants the
tunneling technology is the new solution to resolve this issue for multi tenancy and
not the VLANs where the number tunneled networks can be 16 million using VXLAN
and NVGRE.
Open SDN
Open SDN possesses the capability of handling up the DCNs limitations. But moving
the control functionality to a centralized controller does not directly resolve the
limitation like (MAC bursting and Limitation of VLANs). However, Open SDN can
create a solution which is an instance of SDN via overlays. The controller can create
tunnels which act like tunnel end points and Open flow rules will be used to push
out traffic from the host towards the tunnels. Such tunneling support hardware is
already exist through which SDN devices can be built and derive the benefits of
tunneling. Hence Open flow SDN has ability to solve these DCN limitations.
3.3.2 Management of Resources
SDN Overlays
It is easy to manage network resources like (adding, moving, removing and
modifying) because SDN via overlays is based around virtualization it does not
involve in the underlay network. The device and resources that are being managed
in the overlay network are mostly virtual switch, routers, middleboxes that makes
the task simple and are restricted to the construction and deletion of overlay
networks which are carried within tunnels which are explicitly defined for this. Due
to the tunnel factor in SDN via overlays, the task of managing resources is less
complex and isolated which makes it easier to manage each virtual resource as if
compared it to the management in underlay network where changes are needed to
be applied and replicated across all the physical devices in the network.
44
Moreover, the argument still exists that although SDN via overlay provides greater
flexibility and agility to add, remove and modify resources the overlay network is
not firmly coupled with the underlay network that’s why a level of certainty is not
achieved where many argued that whether underlay has the capacity to handle all
the changes made in overlay networks of course increasing the capacity to bear the
load is a solution but it’s not an efficient solution in many eyes.
Open SDN
Open SDN required to extract the view of the underlay network resources and by
achieving such high-level abstraction Open SDN can view and manage the network
resource in a much efficient manner than to control these resources device by
device at the infrastructure layer. This abstraction of Open SDN provides the
opportunity to not only control the network operations of the infrastructure layer
but also traffic engineering can be optimized effectively using underlay resources in
a more proficient manner than the traditional practices which are time-consuming,
hectic and does not bear any innovation.
3.3.3 Failure Recovery
SDN Overlays
Because the network is virtualized in the SDN overlays and does not deal with
physical network, as a result, the improvement mechanism from failure recovery
are very limited. If any failure occurred in the underlay network it is mostly dealt
with the mechanisms already present and it becomes hard to diagnose the
interaction between the physical and virtual topologies when the problem occurred.
Open SDN
In Open SDN all the network functionality is controlled by the centralized controller
the complete network topology is already known which makes the rerouting
decisions predictable and consistent in case of any failure event.
3.3.4 Multitenancy
SDN Overlays
The main concern of Multi-tenant data center that all the tenants pass the traffic on
the same physical network which is shared among them and only Vlan was the way
of isolating different tenants which was not suffice. SDN overlay resolve problems
for MTDCN like (Security, Scalability, Performance etc) by creating a virtual network
on top of underlay network. These overlay networks become the alternate for the
VLANS for isolation, security, and performance for each tenant. VLANs in overlay
networks becomes appropriate to a single tenant, as a result, each tenant has access
to 4096 VLANs for their different applications which seems sufficient for any single
tenant.
45
Open SDN
In a similar fashion like SDN overlays Open SDN can also virtualized the network
using layer 3 tunnel-based overlays or another way is to use L2 tunnel
technologies like (MAC in MAC and Q in Q) which can separate the traffic from
different tenants and using Q in Q can also provide 4096 time 4096 VLANs which
becomes approximately 16 million to cope the need of MTDC’s the number of
VLANs through Q in Q are same as VXLAN and NVGRE which are used in Overlays.
(Software Defined Network A comprehensive approach, 2014)
3.4 Conclusion
In conclusion, the literature review represents the general benefits of SDN which are
leverage by early adopters and potential adopters will receive, starting from
centralized control, cost reduction, easy configuration and security to performance
enhancements. Apart from general benefit this chapter also deals with problems
Data Center Networks are facing in their environment because of traditional
networking which has scalability and performance constraints, the solutions to each
DCNs problems are not only presented but solutions are presented regarding SDN
types as there are some of the most recognized ones which are Open SDN, SDN via
Overlays and SDN via API but even from three types only the first two a SDN flavors
are considered as affective solutions for DCNs issues.
The following chapter relates to challenge/barriers of SDN and to see what other
research solutions are available to these problems.
46
Chapter 4
SDN Challenges and Existing Solutions
In this section Challenges of Software Defined Networking and Existing Solutions
are presented. In previous chapter potential of SDN are highlighted with the advent
of separation of control and data plane to evolve independently resulting in greater
flexibility and enable rapid innovation in the networks which were mostly static for
more a than decade. But even the significant advantages SDN brought to the current
networks there are still concerns in industry and academia about the challenges in
SDN architecture. Below are the numerous challenges and their solutions from
various research paper are presented which are utmost important in unleashing the
potential of Software Defined Networking.
4.1 Scalability
In SDN scalability is the most widely discussed issue, which greatly impact the
performance of the controller and the devices in the infrastructure layer. According
to kreutz et al scalability concerned mostly deal with the two most crucial factors
one is controller handling of flows per second “Throughput” and second the flow
setup overhead “latency”. Authors describe that in SDN OF controller works
reactively when receive OF switch receives the packet of new flow it sent it to
controller for handling the packet which load the controller. Especially in large
networks where a single controller computing millions of flows per second and
processing of every new flow adds up the load and in turn led to degradation of
processing throughput and controller perceive as performance bottleneck for the
network. Also decoupling of control and data plane makes the controller to set up
new flows to OF switches while computing new flows result in latency factor.
Authors are agreed that these two factors (flow handling and flow setup) are major
concerns associated with the SDN control plane. karakus et al, in paper, consider the
control plane performance as the utmost importance in planning the scalable SDN
architecture. Authors of this paper although agreed that various other researchers
explore control plane performance in respect to (different networks, architecture
design and deployments etc). and recommend number of performance metrics like
(path installation period, link usage) etc to evaluate the scalability performance of
the controller. However, the most vital and prominent metrics are still the controller
throughput referring to Number of flow processing per second and latency referring
to Flow set up as aforementioned. Authors further fined grained the reasons of these
challenges by splitting into three categories.
47
 Decoupling of control and data planes.

 High number of flow handling in controller.
 Controller and OF switch communication delay.
Decoupling of control and data planes
The separation design of SDN architecture plays a part to scalability issues. Because
the network nodes are managed by external controller the communication between
the switch and controller has to be established for the computation of the packets
resulting a signaling overhead especially when large number of packet processing is
involved. Thus, makes the control plane a bottleneck issue.
High number of flow handling in controller
A single controller design may invoke the problem of high number flow handling in
the control plane as compare to distributed or hybrid design since the single
controller becomes the focal point of all the flow processing. In the event of
increasing, number of network nodes (switches and router, host etc) may reinforce
the foregoing problem in the control plane. SDN controller like NOX has capability of
processing 30k flows per second that may be sufficient for small to medium size
networks. Since the controller has the limited number of CPU which may not copy
the incoming request from the substantial number data plane devices such as
devices in Data center networks resulting the delay in programming the network
device which eventually speed down the network.
Controller and OF switch communication delay
Placement of the controller in network is also a contributing factor to the latency.
Authors describe flow setup latency increased due to inefficient physical placement
of the controller the longer the distance between the controller and switches makes
the communication inefficient resulting higher latency, latency can be determined
by measuring the packet processing time RTT (Round Trip Time) between the
controller and the switch. If the controller and switch communication RTT is higher
than flow setup is high too. (Software-Defined Networking: A comprehensive
Survey, 2015, A survey: Control plane scalability issues and approaches in Software-
Defined Networking, 2017)
4.2 Existing Solutions

4.2.1 DIFANE
Distributed Flow Architecture for Network Enterprises this effort proposed a
distributed architecture. This architecture used AS (Authority Switch) to preserve
the network traffic at the data plane. DIFANE architecture comprised of a controller
(with a backup) responsible for policy management, generating the rules and divide
rules to authority switches in the network. Authority switches are the dedicated
48
devices with higher memory and processing power than the ingress switch acting as
an intermediator between the controller and ingress switches. When the ingress
switch receives packet for which it has no flow information the ingress switch
redirects the packet towards the authority switch based on the partition rule. Before
going any further, it is essential to mention that DIFANE architecture is based on
wild card rules which are classified in three categories.
 Cache rules
 Authority rules
 Partition rules
Cache Rules are ingress switch cache rules for so that subsequent data hit cache a
get processed.
Authority Rules, are installed and updated by the controller and are local to
authority switches when the packet hit the authority rule the control function of AS
triggered and install the rule to ingress switch.
Partitioned Rule, are local to all the switches these rules make sure that packet
should always match at least one rule in the switch installed by the controller.
Figure 4.1 – DIFANE Architecture

Upon receiving the packet authority switch generate the rule and redirect the
feedback to ingress switch which is cached for subsequent packet of the same flow
and forwarded towards the egress switch. Afore-mentioned rules have set of
priorities and only the highest priority rule is executed, cache rules have the highest
priority because it does not direct towards the authority switch for processing
authority rules have higher priority in authority switch and primary partition rules
contain higher priority than the backup partition rules.
Authority Switch Failover
In the event of authority switch failure, all packets using the authority switch are
dropped. To cope this problem a distributed authority switch mechanism is
designed in the DIFANE to minimize the packet loss. In this mechanism, controller
49
replicate the same group of authority rules to all other authority switch. Because all
the switches used link state routing protocol to propagate the information regarding
the states of the switches when the ingress switch receives failure notification
message a primary partition rules present in each egress switch which is
responsible for directing traffic towards the failed authority switch invalidates the
primary partition rule and automatically run the back-partition rule to redirect the
traffic towards the backup authority switch.
As DIFANE is a distributed architecture based on rule distribution across authority
switches which handle substantial number of flow computation result in improving
the scalability issue and improving the controller performance. (Scalable flow-based
networking with DIFANE, 2010)
4.2.2 Kandoo
Kandoo controller act like open flow controller but it has extension that are used for
identifying the application requirement running on top of the controller, hide the
distributed controller complexity and event propagating in the network. Kandoo
controller architecture help reduce scalability issue by using the two layers of
controllers to minimize the traffic overhead. In this framework, and used multiple
local controller and logical Root controller. In this architecture, each switch at the
data plane is controlled by on one local controller but each local controller can
control number of switches. To respond the flow, request the root controller install
the flows to the switch through the respective local controller that correspond with
the requesting switch.
Figure 4.2 – kandoo Architecture

As figure 3.1 shown that number frequent events are handled by the local controller
which in result in shielding the root controller from those frequent events that may
led to degrade the performance of the controller reducing the throughput and
increase the latency. Another advantage of kandoo is unlike DIFANE where local
controllers can be implemented in the Open Flow switch because they act like proxy
to the root controller and does not required complete network view and they can be
linearly increased as the switches increases in network. (Kandoo: a framework for
efficient and scalable offloading of control applications, 2012)
50
4.2.3 Maestro
Open flow based another control plane architecture to enhance the scalability in
SDN. Maestro is based on Multi-threaded (a single core executes multiple processes
concurrently) Maestro controller uses multiple system cores to leverage its
capabilities and its design is based on three principles that aid the Maestro in scaling
the network regarding (Throughout and Latency).
 Even Distribution of work load
 Reduce cross-core overhead.
 Reduce memory consumption.
Before going further few terms need to be clarified.
Task manager: Task manager is a medium in maestro responsible for managing
pending computation.
Worker thread: Worker thread used to execute operations required by the task
manager and they are based on number of cores of the controller machine.
After defining the terms let’s begin with the first principle.
Even Distribution of work load, because the controller leveraging its capability by
utilizing the multi core processor, this enable Maestro to maximize the throughput
(handling of flows) in the controller by evenly distributing the load across the
worker thread. Through this way, Maestro ensure that no core sit in idle state while
there is work load (flow request) is pending. To achieve this maestro, realize the
task manager and design it in such a way where task manager makes the worker
thread to use “pull” method for any pending request. One may raise argue that
instead of pulling the request into worker thread, it should be designed where flow
request should be pushed as they come in towards the worker thread in hope to
achieve the equal distribution of load. Unfortunately, this is not possible in the Open
flow as each flow request vary in path led to more configuration message to
processes which ultimately required different processing cycles in the CPU. This
becomes the reason for using the “pull” method in the worker thread where each
worker thread shares Packet Task where flow request queue. So, when there is
packet in queue any available worker thread can process and through this design
work is distributed evenly among the worker threads as shown in figure 3.3.
51
Figure 4.3 – Pull based distribution

Reduce cross-core overhead, is the reason when running code or active used data
traverse between the processors which do not share the same cache this creates an
overhead when trying to perform synchronization of the core state and cache. To
maximize the performance of the controller Maestro, perform two steps. First
Maestro used the task set call that allow it to bind the core with the specific worker
thread this led to stop OS to rescheduled the active running code to another
processor core which in turn prevent the large overhead and known as Code
binding. Second maestro reduce the cache synchronization is to ensure that
processing of the single flow request is performed in the same processor. To
accomplish this Task manager framework designed as discussed earlier. Whereas
the worker threads pull the packets from the shared Raw Packet task queue but
they also has their own dedicated task queue and all those task that are for flow
process stage and output stage depicted in figure 3.1 are held in the dedicated task
queue and worker thread always pull the tasks from the dedicated task queue first if
they queue is empty than pull it from the shared Raw Packet Task queue in this
way not only workload distributed among worker thread evenly but also processing
of the flow request is performed in the same working thread where it is queued this
design is known as thread binding.
Reduce memory consumption, is necessary to avoid performance degradation of
the controller. High memory consumption occurred when a high number network
traffic such flow request generated by the input stage this exhaust memory and
result in deficient performance. Maestro must find the solution that not only reduce
the memory but also make sure that the controller has enough buffered requests to
be processed otherwise controller must re-grow the TCP window size to take in
enough flow requests which incur time and could cause processor idling. To cop this
Maestro, prioritize the input, flow process and out stages shown in figure 3.3 by
doing this tasks in output stage has highest priority, task in the flow process stage
receives medium priority and low priority for tasks in the input stage through this
data does not accumulate in any of stages and only Raw packet task queue is
backlogged this enable the maestro to configure one threshold that ensure how
52
many packet in the Raw Packet task queue to be processed by the input stage these
packets known as PRT (pending raw packet threshold) with it dedicated thread
receives the coming packet from the socket buffer is relatively lightweight than flow
request processing the dedicated thread keep the queue filled according to required
threshold without utilizing high CPU cycles result in reducing the memory. (Maestro:
A System for Scalable Open Flow Control, 2010)
4.2.4 NOX-MT
Nox-MT is successor to the Nox controller it’s a multithreaded controller
implemented on C++ which provide better scalability (throughout and response
time) than its predecessor by adopting the following.
 I/O batching a well-known technique for reducing the overhead of I/O and
aggregating number of messages send them to destination as single packet)
which is well known technique for reducing the processing overhead and
improving the throughput
 Porting a technique to process I/O and Enhance the ASIO libraries.
 ASIO Asynchronous Input output is slow technique for data processing. IO
(Asynchronous I/O enable the system to permit other processing before
transmission even finished I/O operation on a system).
 Malloc a fast-multi-processor aware implementation that work well with
the multi core system.
NOX-MT through porting boost the ASIO processing which result in simplifying the
multi-threaded (multi-processing) functionality of the controller. ASIO act as a
switch practitioner for the controller (switch practitioner run inside the main
thread and responsible for listening to switch connections and distribute them
among the worker threads).
Same operation is performed by Boost ASIO libraries to allocate the OF switches to
worker threads statically in the controller. Furthermore, no task batching is
performed a technique where multiple received packets are allocated to the worker
threads for processing in the controller only individual incoming packets are
processed and are aggregated (batching) in case of high traffic before being sent out.
However static input batching is performed in the controller aiding in
accomplishing the high throughput in SDN architecture. But still, there are some of
issue which are associated in NOX carried to NOX-MT deficiencies like (heavy usage
memory allocation and copy of redundant memory on per request basis) there are
also other limitations if fixed it would greatly improve the performance of the
controller. (On Controller Performance in Software-Defined Networks, 2012)
Although there are number of frameworks and controllers available but discussing
all the solutions are out of the scope of this study. Therefore, 1 framework and 3
53
controller’s architectures are presented above and below are there throughput and
latency result mentioned.
Research Efforts Throughput Latency

(Flows/sec) (Flow setup)
DIFANE Up to 3 Million Minimum 0.4ms
Kandoo Up to 1.3 Million -
Maestro Up to 3.5 Million Average 55ms
NOX-MT Up to 1.8 Million Average 2ms
Table 4.1 – Scalability Metrics
4.3 Fault Tolerance

In SDN to ensure the fault tolerance is a very significant factor and SDN should
define mechanism to gracefully and transparently recover the network in the event
of a network failure. But before explaining the Research efforts failures in SDN
architecture must be rectified to scale down the impact. Akyildiz et al describe the
control plane and data plane failure where a switch identified the link failure but
they do not have the intelligence to establish the alternate route they completely
depend on the controller to install the alternate route to continue the network
traffic in addition to it if the failed node come online it is again the controller
responsibility to reinstate the network topology and the optimal link for the
network traffic. Due to fact that controller must restore the failure and notify all the
connected nodes in the network with in 50 ms which is required by carrier-grade is
still a challenging task while failure is not only occurred in the data plane they can
damage the network heavily if occurred in the control plane so the reliability of the
controller is very critically. (A roadmap for traffic engineering in SDN-Open Flow
Networks, 2014, Resilience support in software-defined networking: A survey,
Computer Networks, 2015)

4.4.1 Data plane Fault tolerance
4.4.1.1 Failure Detection
Fault tolerance is accomplished in any network especially in carrier-grade networks
by planning the network topology while considering all the failure so that alternate
paths can be provided at the required time. Second step before implementing any
mechanism for the provision of alternate path the detection of the failure is
necessary. First approach is LOS (Loss of Signal) used for detecting the failures in
one specific port of forwarding node another approach is BFD (Bi-directional
forwarding Detection). Ahmed et al define this extensively used protocol as agnostic
which enables it to be used with any transport layer protocol for detecting link
54
failure between the network nodes. BFD used ECHO (request/reply) where one
node request series of packets (hello) from its neighboring node to check the
liveliness of the link in between. In BFD failure is detected on per link basis, not per
path any detection of a failure triggered the controller to perform necessary actions
at the data plane in following two steps.
 Restoration path.
 Protection path.
Restoration path, in the restoration path, there is no alternate path configured in
the forwarding devices additional signaling required to compute the alternate path
which takes over in the event of failure. when the failure occurred, a message is
generated and sent to the controller the message is comprises of all the affected
paths. Due to this controller calculates the restoration path for all the affected
switches using the SP (shortest path) protocol for rest of the topology and flow table
is modified for all the affected switches and for all others there are two possibilities
if they are only on the failed path their entries are removed and the switches which
are only on the restoration path new entries are installed.
Protection path, in the protection path, the path is reserved with the working path
every connected switch holds two forwarding entries in its flow table a pre-
configured protection path and the working path in the event of any failure pre-
configured path is utilized without any need of further signaling overhead. (Fast
failure detection and recovery mechanism for dynamic networks using software-
defined networking, 2016)
Sharma et al describes restoration and protection in context of performance where
restoration requires functions like (deletion, addition etc) between the controller
and node which required time protection is much faster no communication
established between the controller and node and as protection path is pre-
configured in the node it does slightly increase the flow setup time as extra
operations for protections path is required by the node but in general it does not
affect the scalability instead because there is no further communication once the
path is installed it result in reducing the latency when failure occurred. However,
protection path enables fast convergence they also required the large flow tables,
therefore, group table are used here instead of flow table to handle large amount of
flows
55
Figure 4.4 – Protection (A) and Restoration paths(B)

When authors perform the experiment with 14 switches using the protection path
they recorded the max restoration time was 60 ms and flow were restored between
42 and 48 ms which meets the requirement of carrier grade network as discussed
earlier which is 50ms where in other studies it is found that the restoration path
time was between 200 to 300 ms. Therefore, the large-scale networks mostly
preferred the protection path as a solution as the data plane for fast failure recovery.
(Open Flow: Meeting carrier-grade recovery requirements, 2012)
4.4.2 Control plane Fault tolerance

As SDN is provides logically centralized framework. Which purely based on the
controller especially the Open Flow which is the only standardized protocol and
various other protocols designed to define policies and action for the network at the
infrastructure layer. This makes the controller very critical which is acting as
mediator between the application plane and data plane. Hence the reliability of the
controller becomes the focal point for the SDN architecture. It is essentially
important to resolve the single point of failure in the layer. There other approaches
out suggesting different solution but the most fundamental approach is to recover
from the controller failure in SDN is “primary and secondary replication” where
secondary takes over when the primary failed to respond. Few of effort are
proposed below.
4.4.2.1 Shared Data Store Controller Framework
The key idea proposed in this framework is to have data store connecting with all
the controller instances and all the controller manage their action through a
dependable data store running on top of it. This framework makes sure that the
network states and application are maintained consistently. There are number of
servers (replicas) running on any standard controllers (flood light, ODL, etc.) this
eliminate the single point of failure without interrupting the consistency of the
network. In the shared data store framework, the most prevalent technique is used
for replication is SMR (State Machine Replication SMR is the method for
56
implementing the fault tolerant system by replicating servers and ensure the
coordination of client with the replicas). The replicated state machines use the
protocol known as VR (View stamped Replication) which is more solid than the
Paxos (most popular distributed protocol) that make sure that data stores and
replicated server are updated with consistency.
Figure 4.5 – Shared Data Store Framework

As the figure 3.5 describe the architecture to avoid failure in the control plane of the
SDN. Where set of controllers connected with the number switches and all the
decisions of the application running on top of controller are based on two factors
one Open flow events and consistent network state which all the client controller
share on the data store which also makes the communication between the
controller’s simple like (reading and writing) on shared data store and no room is
left for the codes to solve communication conflicts and complexities.
Two of the most known problem domains in control layer are solved through this
architecture one controller failure it’s not anymore if controller or its associated
machinery stop functioning because all the network states are stored in fault
tolerant shared data store. Another one is controller and switch connection failure
for this every switch has a multiple connection using the master-slave configuration
advent in Open flow version 1.2 where master controller being monitored
constantly by other slaves so in the event of failure one from the slave can take over
and resume the communication. Besides resolving these two control plane problems
this framework also viable in SDN deployment where controller is centralized and
controller distribution is not necessary in this case data store is used for storing the
state of the relevant controller and application running on the primary controller
manage the network and just like the switch master-slave relationship secondary
controller monitor the primary controller in case of failure secondary take the
primary role ensuring the normal network functionality. In the following section,
57
primary and secondary architecture is discussed. (On the Feasibility of a Consistent

and Fault-Tolerant Data Store for SDN, 2013)
4.4.2.2 CPRecovery Component
Centralized control management exposed the vulnerability of the network and a
single failure event in control plane can compromised the whole network because
every aspect of the SDN relied heavily on controller it’s a strategic point another
framework is defined known as CPRecovery Component. Although Open flow
protocol is the only standardized protocol that does provide the possibility to run
backup controller however in Open specification coordination between the
controller is vague. Therefore, it is essential to have mechanism that provide the
coordination capability between the controllers. So that network service running on
controller can be protected. To increase the fault tolerance CPRecovery is
component based primary-secondary controller technique that offer resilience
against several types of failures as SDN is already a component driven architecture
which provides the interface to significantly enhance interaction among the
network components making the development of services much less complicated.
Figure 4.6 -CPRecovery Component

Normal Phase
In normal operations when network controller receives the packet-in message
which specifies the packet arrival the network OS confirms if the packet is received
by the controller if it is then the (flag is Primary must be true) once primary
controller is identified then the OS check that is there already a flow entry present
for the packets if it does then the destination port to which packets must be sent is
verified and flow is created and associated to packets sent out towards the switch. If
there no entry present for the arriving packet a new entry is created in the source
table and its port and flow path associated with the MAC and the secondary network
controller is checked for reachability if the reachability is present between the
58
primary generate a message containing the MAC and the flow path and sent in the
direction of the secondary controller and wait for the ACK which ensure the
network state is updated.
Recovery Phase
In the event of primary controller failure (primary server shutdown, link between
the controller and switch is down etc) switch start sending the inactivity probe
towards the controllers when no response is received switch start looking for
secondary controller in its list (defined in switch configuration) upon finding the
controller it starts connecting to it by completing a handshake process. The
secondary controller receives the joining request and create a (data path join event)
and (set is primary flag to true) which indicate that it primary controller also the
new primary send state update message towards the former primary which act as
secondary controller if comes online again. Not only the coordination mechanism is
delivered using the CPRecovery component but the recovery method also allows the
controller to provide services like (authentication, load balancing, and access-
control) that prove the adaptability of CPRecovery. (A replication component for
resilient Open Flow-based networking, 2012)
4.5 Security
Authors in research paper agreed that Open Flow is the leading standard for the
deployment of SDN. But in addition to it also give pave to many potential challenges
to the network security. In this section identification of security challenges for OF
based SDN is presented defined in three categories.
 Control plane related challenges.
 Data plane related challenges.
 Channel related challenges.
Furthermore, potential challenges of three planes are evaluated against the security
CIA model (Confidentiality, Integrity, and Availability) for sake of better
understanding where in general terms confidentiality defined rules to make sure
that information access is limited. Integrity make sure that the related information
is not amended and Availability make sure that authorized personnel can access the
information.
4.5.1 Control and Data Plane related challenges

This expose the challenges associated with the control plane and data plane, where
the intruder can manipulate the controller switches and hosts. In networking SDN
without a proper security design is describe as double edge. The controller on which
the data plane relied upon can become a bottleneck for SDN and can used as major
59
target for DOS and flooding attacks. Let say if the data plane device requests the
flows from the controller and instead of receiving the correct flow receive unknown
flows it could result in degrading the performance of the network or bog it down. In
the same manner, if controller required information from data plane devices and
received data other than the expected or not at all this may led to network failure
below are challenges in context of CIA model are mentioned below.
Confidentiality: At the control, plane preventing sensitive data (policies, rules, and
controller information) from leaking to unauthorized personal in the same way in
data plane to prevent data like (switch communication, flow tables, group table data
etc) from being exposed to attacker.
Integrity: At the control plane integrity means alteration of controller data by
unauthorized means. There should be many rules installed like flow rules, firewall
in controller but still, it is possible that intruder may somehow orchestrate various
other rules to bypass the controller boundary. Integrity at the data plane level, it
means to protect information from being altered in any sense from any
unauthorized source information regarding (hosts, switches).
Availability: At this level of the control plane all the related data should be available
to all authorized personnel so that information can be retrieved as needed from the
controller and can be configured as per policy. Controller is a strategic point as it
deals with the applications and data plane layers in SDN. The data plane level
availability is referring that the all information related to data plane should be
accessible to on controller request. (A survey on Open Flow based Software Defined
Security challenges and countermeasures, 2016)
Below are the challenges that an intruder can pull to target the network.
Scan: Attacker by the scanning as the initial step for a much larger attack is
performed to understand the topology information and to gather sensitive
information from the controller by sniffing the network data at the control level.
Scanning at the data plane level can provide information related to (host and
interaction details between switch and host). But such information could have led to
much bigger attacks like (DOS or DDOS).
Spoof: If this type of attack successfully conducted then the attacker can imitate as a
controller by having a complete control over the network can result in generating
flow entries in flow tables of switches etc, and SDN operator would be unaware of
those false flows because lack of visibility and could easily led to APT (Advanced
Persistent Threats).
Spoofing at the data plane level Feng et al see spoofing attacks as deceptive where
attacker act like (switch or host) to gain illegitimate advantages. These type attacks
in SDN are ARP and IP spoofing where in ARP spoofing attacker intent to relate its
60
MAC with the legitimate host IP address to receive or monitor certain data. (InSAVO:
Intra-AS IP source address validation solution with Open Router, 2012)
Hijack: Hijacking of the controller simply led to modification of data and redirection
of traffic where incoming packets for controller end up at attacker machine which
can compromised the SDN architecture. Hong et al rectify one such attack where
attacker can spoof the target host in trying to hijack the host location information
from the OF controller this attack is known as Host location hijack.
In relation to hijacking attack at a data plane level, Hong et al defines if the attacker
able to hijack a specific switch they can have access to information related switch-
controller communication (flows) switch-host communication switch-switch
communication. In case of hijacking a host, attacker can gather data not only from
the hijacked one but from other also like (password etc). This attack is perceived as
much stronger in data and control planes in comparison to spoofing attacking.
Tampering: If the attacker instantiates false flows at the controller by either north
and south bound API this simply enable the attacker to control the traffic between
all three planes and by-passing all the security.
Hong et al define these attacks at the data plane level as unauthorized alteration of
network data by delivering a malicious flow causing the network misbehave.
Authors perform a practical by injecting a false LLDP which advertise a fake link
between two switches in the Open Flow network and through that injection they
able to receive the genuine LLDP packet. (Poisoning network visibility in software-
defined networks: new attacks and counter measures, 2015)
Denial of Service and Other attacks: DoS attacks is another scenario for SDN
where attacker launch attack against the controller to make controller unfunctional
or to cause it to respond and request message extremely slow. In this regard Shin
and Gu present an DoS attack to SDN network involved two steps.
 When client send packet towards SDN a client observes vary response time
because the flow setup time added for the new flows as compare to no added
time in case of existing flow and these response times are defined as T1 (new
flow) T2 (existing Flow) once the attacker identifies the T1 from T2 they can
fingerprint the SDN network but still couple of issues (1) how to gather T1
and T2 values (2) how to know T1 values differ from T2. For the authors
advice, the scanning method (header field change) to overcome first issue
two crafted packets sent to the target network response time recorded for
each packet. Once the attacker has the values then those values using t-test
(statistical method) are evaluated to find out the whether T1 and T2
significantly differ or not. If the testing method show the target network in
SDN. Then second step is taken.
61
 More crafted packets are sent towards the SDN network to consume the
resources of the network to make it unfunctional. (Attacking Software-Defined
Networks: A First Feasibility Study, 2013)
other attacks which are primarily used to bog down the services on SDN
network at (control and data plane) including (flooding, smurf, amplification of
DNS).
4.5.2 Channel related challenges

In channel, related challenges weak links at channel level are presented which are
exposed by the attacker. Channel in SDN relates the communication between the
controller and network node. One challenge which is very well known in traditional
network also present in SDN is (Man in the Middle Attack) in Open Flow based SDN
as no proper trust method is present between the controller and the switch (TSL
encryption is optional) that leaves it open for the attacker attacks like MITM and
other are described below in context of CIA model.
Confidentiality: As described earlier confidentiality refers to conceal information
unauthorized sources in channel interaction between the controller and switches
must be secured. So that MITM could not take place.
Integrity: Any alteration to data at any plane compromise the Integrity in context of
channel level there should be a mechanism which make sure that traversing of data
should remain consistent, trustworthy, non-repudiate and accurate.
Availability: As discussed earlier but availability at channel level means that only
the authorized sources can communicate with each other in this case (controller and
switches) no third party should be involved in this interaction.
MITM: Lara et al mentioned in the paper that although Open Flow agree the use of
TLS (Transport Layer Security) but it is not mandatory which define that there is
not a standard mechanism present through which a communication can be
protected and in this there is possibility that information traversing between two
planes can be in plain text. And without any robust trust system MITM attack could
become more feasible. MITM attacks once performed on the targeted network could
easily compromise all the aspects of CIA model. For example, data can be stolen it
can be modified and obviously accessible to unauthorized sources.
Channel monitoring: These types of attacks are performed on Open Flow channel
for reconnaissance or learning the traversing information between switches and the
controller. In the Open flow based SDN network Lara et al describe that such type of
attacks are very hard to detect because there is very inadequate support in the Open
Flow for traffic monitoring which makes it very hard even for security application to
identify and learn changes precisely in the network which result in failed
rectification. (Network Innovation using Open Flow: A Survey, 2013) .
62
Repudiation: In this scenario, any entity involved in the communication can deny
from communicating this denial of communication could be a result of MITM where
attacker masquerades to both entities that the attacker is the other entity involved
in the communication. To stop this denying of communication Non-repudiation
technique used mostly related to accountability to hold entities liable for
repudiation.

This section is comprised of different research efforts to mitigate against
aforementioned security challenges SDN is currently facing. All the
countermeasures are defined here are in the context of OF controller, OF switches
and the communication channel that connects these two SDN elements. However, in
the literature review, it is not necessary that each effort represent certain solutions
that only related to controller or switch or channel instead they cover more than
one aspect of the SDN architecture Efforts are divided in three categories mentioned
below.
 Preventive Efforts for Controller Related Challenges.
 Preventive Efforts for Switch Related Challenges.
 Preventive Efforts for Channel Related Challenges.
4.6.1 Preventive Efforts for Controller Related Challenges

ARM: Address Resolution Mapping module is introduced as a defend against the
spoofing attack. The ARM module implementation in controller enable the
controller to provide management that can centralized the ARP functionality.
Through this module controller able to learn, track and validate MAC address of only
authorized sources (i.e. user, host) and any ARP request that cannot be validated by
the ARM module is discarded by the controller. (Implementing layer 2 network
virtualization using Open Flow: challenges and solutions, 2012)
VAVE: Virtual source address validation edge is an extension of SAVI (source
address validation improvement) to mitigate the address resolution. The VAVE
module is incorporated in the OF controller. If any packet from outside the
boundary which is form by OF devices reached at the boundary is matched against
the flow entries in the flow table if no entry is found then packet is sent towards
controller where VAVE application verifies the source address of the packet by
checking them against the VAVE rules to judge whether to drop or allow if packets
are not verified then the added flow entry is generated and configured on the router
to cut any spoofing attempts. In this approach, only VAVE module is required and no
new protocol is required on switch side controller define the rules of each SAVI
device from the VAVE application. (Source address validation solution with Open
Flow/NOX architecture, 2011)
63
TopoGuard: TopoGuard is new mechanism used in integration any open controller

like (flood light, RYU, Maestro, NOX, ODL etc) to provide protection against the
Network Topology poisoning. In the architecture design of the topo guard, there are
several component including (Port Manager, Host Prober, Port Property DB and
Topology Update Checker) topology update checker used the information provided
by the port manager and host prober to automatically detect and validate any
change in the network topology. When a change is identified in topology like (host
migration and new link discovery) the update checker triggered the port property
database to check precondition of the update and on the other hand instruct the
host prober to check postcondition of the update and due to the verification of pre-
and post-condition any falsified host migration attack can be automatically detected
and mitigated. There is also time factor involved in host migration which causes
overhead but it can be reduced using the roll back method.
To reduce the time overhead roll-back method is used in the event of (host
migration) if the host location is verified in the precondition than the (shutdown flag
for that host is enabled in the port property) without any unnecessary waiting for
the verification of postcondition result from the host prober. But if the host prober
presence a suspicious attack in host migration than update checker withdraws from
the last update and initiate the attack alert as a result only time served in verifying
the precondition is counted.
In the event of new link discovery update checker first makes sure the integrity of
LLDP (link layer discovery protocol) for this TLV (cryptography Hash of DPID and
Port number) is embedded in the LLDP packet as the new link comes up update
checker verified the hash TLV and by checking the device type of the switch port of
the new link update checker investigate whether any host present on the path of
LLDP if there is and any update present in HOST port it is immediately denied and
attack alert is triggered. Another way to fabricate the link is to use the compromised
host to spread LLDP packets between two target nodes. When LLDP is being relayed
topo guard rectified the violation of device and specific ports to mitigate it.
(Poisoning network visibility in software-defined networks: new attacks and
counter measures, 2015)
Flood Guard: Another way to perform DoS attack is data-control saturation attacks
by sending messages from switch to controller and saturating both the flow tables
and controller resources. To address these type of attacks Flood Guard is presented
which does not required any adjustment in the SDN architecture Flood Guard adds
two functional modules in current Open flow framework. One proactive flow rule
analyzer second packet migration module to mitigate data-to-control saturation
attack the analyzer module is responsible for enforcing the major functions of the
network it runs as application on top of controller and packet migration which is
running migration agent application to forward benign packets toward controller
64
and makes sure it does not overload the controller. Before any attack detection,
Flood Guard use symbolic execution to create set of path conditions for every
packet-in handler function for every application.
Once it is done flood guard sits in idle state the time the attack is detected flood
guard move to init state and migration agent starts directing table-miss (packets
with no flow entries) towards data plane cache (component sits between control
and data plane) whereas analyzer module track the application running in the
controller and changes the path condition which were pre-configured at the same
time data plane cache component start processing the cache packets and create
packet-in message. Once the proactive rules are generated flood guard move to
defense state and analyzer module forward rules toward the switches and
continuous to update proactive rules. This process keeps running until the attack is
over. Once it is complete analyzer stop migrating table miss packets and data cache
component moves back to idle states after processing all the cached packets. (Flood
Guard: A DoS attack prevention extension in software-defined networks, 2015)
4.6.2 Preventive Efforts for Switch Related Challenges

OF-RHM: Open Flow Random Host Mutation is one of the technique used to cope
security challenge by changing the IP address (rIP)of end host on random and
frequent basis that will make the attacker harder to compromise the system. There
are two main aims of OF-RHM. First, the mutation of IP address process should be
transparent to ensure the transparency. To achieve transparency OF RHM does not
alter the original ip address of the host instead associate the virtual IP address(vIP)
with each host randomly. Second altering the ip address required unpredictability
and speed to distort the attack plan. But it is not possible until the constraint of
unpredictability and speed (mutation rate) are satisfied. To satisfy this constraint
satisfaction problem a SMT (satisfaction Modulo theory) is provide as a solution
which is comprised of two component (1) gateway for rIP and vIP translation (2)
global management for organizing mutation across network. SDN is pave the way
for translation with minimum overhead and management as required by delivering
central management.
(Open flow random host mutation: transparent moving target defense using
software defined networking, 2012)
VeriFlow: Is introduced as interface or layer between the controller and data plane
devices to investigate any invariant violations in the network when any modification
takes place. Existing tool for this purpose was not sufficient enough for bug
detection, misconfiguration, or deliberate attempt of any alteration perform offline
checking which is time-consuming from min to hrs. The VeriFlow, on the other hand,
provide dynamic verification of invariant violations as rules are inserted, deleted or
altered network wide. Although online detection is a complex task but in three steps
65
Veriflow optimise this effectively (1) monitoring of live network

communication/rules generated by control plane applications to network devices
must passed through Veriflow layer and their effects must also be validated at high
speed (2) narrow down verification to only those sections of the network whose
working are modified by the update (3) instead of verifying invariant with
established techniques that are not efficient like (BDD solver etc) custom protocols
are used aiming to mitigate attacks. (Veriflow: Verifying network-wide invariants in
real time, 2012)
OFGuard: Is another data-to-control DoS attack mitigation framework for SDN
based networks. The OFGuard framework based on two key mechanism to protect
such attacks (1) Packet migration utilized control plane applications to monitor rate
of Packet_in message from switches and determine the usage percentage of the
capacity of network if the flooding attack is rectified on the basis of certain
threshold then first step the application write wildcard rule with lowest priority
that matches all the entries in the ingress switch as a result all the table-miss
packets moved towards data plane cache to protect switch and controller which is
the second element (2) Data plane cache is a remote machine responsible for
storing table-miss packet for determining and evaluating fake packet (header fields
are matched with the flow entry) if it matches it considered as normal packet and it
is tagged with VLAN and sent back to ingress switch to follow normal processing
towards the destination while all other are discarded. (OF-GUARD: A DoS Attack
Prevention Extension in Software-Defined Networks, 2014)
FlowNAC: The logic behind the Flow network access control is to attain a control
over which type of traffic from the user is permitted to access the network. Traffic
associated with the specific service requesting by the user is uniquely rectified and
matched in the data plane. FlowNAC can be based on these three components.
Supplicant (entity that needs to be authenticated), Authenticator and Authentication
server. But the information exchange between these three component and the data
model need to be updated in the following way.
1. Protocol between the authenticator and supplicant required to distinguish
between different authentication and authorization process from the same
user (i.e. same Mac Address).
2. Identifier who is requesting for service must have three diverse name spaces
like (username, service, domain).
3. At the authentication server, a policy must be added that should evaluated
the service request from the user.
4. Once the user is authenticated and authorize set of flow entries are
combined (i.e matching field and actions) with the user parameter (i.e Mac
address). This set of flow entries is very explicit to the requested service to
make sure that the service is isolated and can be proactively activated one
66
thing is to be noted that FlowNAC only authorize the access to the services
rather than involved in configuring the service across the network.
5. The protocol between the authenticator and the authentication server
should be updated to support the transmission of set of authorized flows to
the authenticator which enforce the appropriate access control based on set
of authorized flows because of AA process.
(FlowNAC: Flow-based Network Access Control, 2014)
4.6.3 Preventive Efforts for Channel Related Challenges

HIP: To secure the channel between the controller and switches open flow
specification proposed to use TLS (Transport layer security) mechanism this
approach is not strong enough to cope the security issues of control channel from IP
based attack like (IP spoofing, DoS, TCP SYN) to prevent such attacks Host Identity
Protocol (HIP) is proposed. HIP is consisting four major components.
 Security Gateways: Responsible for establishing IPsec tunnels with the
switches and perform registration and authentication of new switches, in
addition, multiple SecGWs deployment prevent single point of failure.
 Security Entity: Responsible for controlling the SecGWS and use ACL
containing legitimate identities of switches for authorization Sec entity also
gather statistical information to classify the abnormal traffic pattern and
instruct the controller to terminate the communication with any suspected
switch.
 Local Sec Agent: Installed in the switch and only responsible for establishing
a secure channel between the controller and the switch.
 IPSec BEET: Bounded end to end tunnel between the SecGWs and switches is
established by the HIP that separates the role of IP as a locator and Host
identity of each host. Each HIP host (switch) has its own public/private key
pair where public key is used as device HI and SA (security association) are
established between the end devices by using the protocol known as HIP
base exchange (HIP BEX). Moreover, these HI’s for each switch are pre-
configured before the device joins the network and additionally the HI’s are
also added in the ACLs in the Sec entity so that fake identities can be
distinguished. Because HIP relies on Base Exchange protocol that contains
PKI and established SA for IPsec tunnel the authentication remain strong
and tunnel remains encrypted for payload traversing between the SecGW
and switches.
The proposed architecture protects the communication channel when used against
the attacks likes (DoS, spoofing, replay, and eavesdropping). (Securing the Control
Channel of Software-Defined Mobile Networks, 2014)
67
Avant Guard: The Avant guard method extend the design of Open flow by adding
couple of modules in the data plane the first is (1) Connection migration and second
one (2) Actuating trigger. In this way amount of communication traverse from data
to control plane can significantly be reduced in the event of DoS attack which result
in resolving the bottleneck in the channel between the data and control plane.
Connection migration module add intelligence to switches so that the sources that
uses TCP handshake can be separated from one that will not. It means only those
connection request that completes the TCP handshake will be forwarded towards
the controller and second module actuating trigger used to report network status
and payload information also used to trigger a flow rule under pre-defined
condition to help control plane for ease of managing the network flows without
delays. (AVANT-GUARD: scalable and vigilant switch flow management in software-
defined networks, 2013)
4.7 Lack of Standardization

Another one of the Significant reason which hinder the adoption of SDN is its lack of
standardization. Detaching the control plane functionality and putting it into a
separate entity is not enough new protocols are needed to effectively provide the
efficient interfaces between the planes (Application, Control and Data) new API that
work between the plane are required like South bound API that work between
controller and devices and North bound API works between Applications and the
controllers and east and west API for interfaces in distributed controller
environments. These north and south bound API need standardization as early as
possible to avoid market fragmentation. Currently the most renowned and de facto
protocol for SDN architecture is Open Flow framework which has its own limitation
like it does not provide any mechanism through which the device status can be
determined and programming the port or trunk interfaces are not allowed and also
non-packet flows (wave length flows) are not handled by Open Flow although the
improvements are made with every new version but it is debatable that the
framework of Open Flow today is a byproduct of limited experiments instead a
mechanism developed to support network services. (SDN's missing links: Five
barriers blocking SDN adoption by providers, Software-Defined Networking:
Standardization for Cloud Computing’s Second Wave, 2014)

4.8.1 ITU-T and JCA on SDN
International telecommunication union and Joint Coordination Activity on SDN have
joint hands at 2013 to gather up to date information regarding various
standardization for SDN that are taking place including (virtualization of network
functions, programmable networks, and Network as a Service). JCA-SDN has come to
68
know many works related to SDN in numerous SGs (Study Groups) of ITU-T and
SDOs (Standard Development Organizations). Some of them are mentioned below.
Study Group 13
Study Group 13 is leading the study group of SDN and responsible for developing
the SDN framework, SDN and service aware networking of future networks
and network virtualization.
Study Group 11
Study Group 11 is responsible for signaling, testing and standardized protocol with
its requirements for number of networking technologies. SG 11 work in conjunction
with SG 13 working on (protocol procedures relating to specific services over
ipv6) is studying in SG11 in relation with SDN for ipv6.
Study Group 15
Study Group 15 is responsible for developing the standards for transport, access and
home networks and power usage network infrastructure, system, equipment,
optical fiber and their installation, maintenance. Regarding SDN SG 15 has started a
draft called (Architectural for SDN Control of Transport Networks) which is
associated with the ONF SDN architecture.
Study Group 17
Study Group 17 is responsible for security related work and often works in
conjunction with other standard development organization (SDOs). The SG 17 work
on (security aspect of ubiquitous telecommunication services) that cover the
security service in relation to SDN and (Security architecture and framework)
also dealing with how to secure the SDN environment.
4.8.2 ETSI NFV ISG

ETSI’s Industry Specification Group for NFV and SDN was created to accomplish the
consistent methods and common architecture for the hardware and software
infrastructure needed to support network virtualization. Although SDN and NFV are
complementary but they are independent of each other SDN can be virtualize and
deployed without NFV and vice-versa.
4.8.3 IETF/IRTF
69
Internet Engineering Task Force is open community for network designer, vendors,
operators, and researchers continue working to evolve the Internet architecture.
There are many working groups related to SDN are present to bring standards for
SDN to name few NVO3 (Network Virtualization Overlays) this WG works on
signaling for tunneling protocol its framework has been developed in 2013 and
protocol extension is currently in progress. While IETF is focusing on the
standardization of SDN where as IRTF (Internet Research Task Force) is dedicated
to long term research. In IRTF SDN RG (Research Group) is currently working which
is responsible to explore on numerous aspects of SDN including but not limited to
definition to taxonomies to scalability and applicability to security and others.
4.8.4 ONF
Open Network Foundation is organization focused to the promotion and adoption of
SDN through open standards. Its stresses an open, collaborative and development
process that is determined and launch the Open Flow standards which enables the
remote programming of the forwarding plane. While there are issues with Open
Flow as mentioned earlier ONF is keeping evolving the Open Flow standards to
address the needs of deployment and work on new effective standards to expand
the SDN benefits.
4.8.5 Open Day Light Platform

ODL project is one of the open sources collaborative project founded by Linux
Foundation it was developed to deliver the platform which neutral and open source
SDN technology. ODL first started as controller but soon transformed into ODL
platform it’s a shared platform where end user’s customer and anyone with SDN
goals can work collaboratively to find innovative solutions. The ODL project is
intended to be extensible and configurable, so it can potentially support emerging
SDN open standards. It introduces new protocols and technologies for SDN includes
Common Controller Infrastructure, protocol plug-in, SDN application suites,
standard based north bound interfaces, virtual overlay networks. ODL also deals
with south bound protocols including I2RS (Interface to Routing Systems), Path
computation Element (PCE), Network Configurations (NETCONF) and Application
Layer Traffic Optimization (ALTO).
4.8.6 ONOS Platform

Open network Operating System is another platform its SDN based operating
system targeted for service providers ONOS is highly available, high performance,
scalable and high-level abstraction which makes it easier to for users to create
application services. ONOS also claimed to be distributed SDN system which can
scale with the network size and as application demands, rich north bound API are
used to achieve the simple programming by the applications at the application layer.
70
ONOS platform have been grown from control centric open flow network to control
and configuration platform which not only delivers core by improving from
distributed services to providing extensions and network application but also
enhanced north and south bound protocols. ONOS also provide solutions for
dynamic configuration of devices based on (NETCONF and YANG). (SDN Standards
Activities in ITU-T and other SDOs, 2015).
4.9 Conclusion
In conclusion, four challenges are presented that are major hurdles of SDN before its
wide adoption and multiple mitigation techniques according to the challenge are an
of this chapter. Challenges that are presented deals with performance optimization
of SDN (throughput and latency), network continuation during and after the failure,
security challenge and lack of standards which is also rated high in survey
responses. Viable solutions to these problems are discussed in much greater detail.
Although there are number solutions available SDN still not being considered by
SME’s it could be since not many use cases are present for these solutions. Once
these solution gains confident it will be much likely that SME will start shifting from
hardware to software based networking.
Next chapter present research methodology intended for the development of
research sub questions which will be used to direct the data collection process.
71
Chapter 5
Research Methodology
5.1 Purpose
Through investigating the literature review, the benefits and challenges and the
research efforts of Software Defined Networking were explored although after
exploring the potential of SDN it is still hard to answer the primary question on
which this dissertation is based on. Because of it number of sub-questions are
required to gain more insight from network professional who are part of various IT
related organization. For this project, the targeted organization are (ISPs, Data
centers, and Service providers). The methodology is composed of various sections.
Development of Research Sub Questions
Data Collection Tool
Design of Data Collection Tools,
5.2 Development of Research Questions

Primary Research Questions and Sub Research Questions
This study is seeking to answer the primary question which is:
Does migration to SDN becomes necessary from present network architecture
and Are we ready for it?
To answer this question number sub questions are shaped which will ultimately
help in information gathering. Research sub questions are presented in below Table.
RSQ1 Is SDN a mature technology?
RSQ2 What are the barriers of adopting Software Defined Networking for IT
organization?
RSQ3 What benefits IT organizations are expecting from SDN and Is SDN able
to provide it effectively?
72
RSQ4 What are the vendor specific and open solutions available for SDN and
which solution appeal most to IT organizations?
RSQ5 How early should we expect from DCN, ISP and Enterprises to move from
current network practices to SDN?
RSQ6 Can we afford to live without SDN indefinitely?
Table 5.1 – Sub Research Questions
5.3 Development of Sub Question

Following table organizes the sources that are used for the preparation of each RSQX. A
brief description of the sources is provided.
RSQX Literature Sources Involvement to

Development of RSQX
RSQ1 (Ortiz, S. 2013, pp 10-12) In this paper, a discussion
is made whether SDN is
Ortiz, S. (2013). Software-Defined Networking: on the verge of
On the Verge of a Breakthrough or not and
Breakthrough Computer, 46(7), 10-12 many of the researchers
believe that after several
years of SDN hyped this
technology is finally
gaining grounds in the
industry.
See Chapter 1 and

Chapter 2 literature
review to gain more
understanding of
significance of SDN.
RSQ2
(Kreutz, D. 2015, pp 52-53) 5 SDN barriers are
identified which are
(Karakus, M. 2017, p. 282) delaying the adoption of
SDN.
(Akyildiz, I. 2014, p. 16)
(Wenjuan, Li, 2016, pp 130-132)
(SDN's missing links: Five barriers blocking SDN

adoption by providers,
Software-Defined Networking: Standardization
for Cloud Computing’s Second Wave, 2014)
See Chapter 4 for the

detail explanation of SDN
73
barriers.
RSQ3 (Xia, W, 2015, pp 29-30) 6 benefits of SDN are
mentioned that are
(Software-Defined Networking: The New Norm paving way to the
for Networks ONF White Paper April 13, -2012 innovation of SDN.
)
Specially SDN utilization
in the Data Center
Networks resolved much
of their problem which
are previously hurdles for
DCNs to work efficiently.
SDN overlays/NFV used
Technologies like
(VXLAN, NVGRE) to
mitigate DCNs problems.
RSQ4 This question is important because it will show ----
what market trends are towards software
defined networking. What are the open and
closed solutions already available and most
importantly is to know whether open SDN
solutions could become the reason for IT
organization to adopt SDN beside other benefits.
RSQ5 This question is necessary to answer the second See Chapter 3 and 4
part of the primary question After looking at
benefits and solutions to SDN
barriers/challenges and it is quite possible that
SDN could be adapted by IT companies earlier
than expected but after the analysis of survey
results, it will be easy to determine.
RSQ6 This is the most essential question which will be ----

influenced by the answers of other Sub research
questions and led to conclude the answer for the
primary question.
Table 5.2 – Sub Questions Development
5.4 Data Collection Tools

“To gather data there are number of way available counting from surveys, interviews,
and observations, but every technique has its pros and cons respectively”. (Robson,
2002, pp. 230-232, 272-273, 310-311).
74
Although there are various methodologies available but not every method is used
according to the context of the research study. In this regard, observational
methodology is inappropriate because the study focus is to answer the primary
question which led to the further development of sub research questions and not
observe in given situation. Another option is to conduct the face-to-face interviews
but due to the limited amount of time availability, it was not possible. As an author
of this study we know the fact that if the data is collected from not all but 2 out three
would have increase the certainty in the result but as already mentioned the reason
due to the certain limitation is couldn’t be possible. As a result, self-administered
online survey was selected as the prime tool to be used to attain the perspective of
our targeted audience ranging from Network support engineer to network
Architect.
To gather the data for the research sub-questions to finally conclude the analysis for
the primary question. A survey containing 10 questions was designed and multiple
UK ISPs, Enterprises and Data Centers and on different social and IT forums which
are related to SDN technology were selected. Although the survey was sent to all the
selected platforms the receiving responses were 57 and even out of 57 seven of the
response somehow could not added to the survey due to some known reasons.
Based on 50 responses collected this dissertation will try to answer the Research
questions.
5.5 Design of Data Collection Tool

5.5.1 Matrix of DCTs Used to Mapped Against the Relevant RSQX
Following are the data collection tool (DCT) which was used to operationalize each
of RSQX.
RSQX Data Collection Tools to Operationalize RSQX
RSQ1 To ensure that IT industry has shown its confident that SDN is leading
platform for future networking. To be sure of it survey results and
chapter 2 and 3 provides considerable amount of information to draw a
conclusion.
RSQ2, Chapter 4 and 3 highlights the significant amount of information
RSQ3 regarding the challenges/barriers and benefits of SDN also Survey
results will aid to answer these questions.
RSQ4, Solely Survey result will dominate the major part of the response for
RSQ5, these questions although information can be taken from chapter 3 and 4
RSQ6 to aid in answering.
Table 5.3 – Matrix
5.6 Design of Survey

Survey was shaped to operationalize Research sub-questions, most of the survey
questions were specific to retrieve the information which aid in answering RSQX but
75
couple of questions were not very specific and will be useful in performing the
analysis.
The online survey composed of 10 questions went live for a period of two weeks
(fourteen days). The link was posted on the SDN related forums, general IT forums,
to ISP, DCNs and sent towards number of participant directly participants including
(network professional belonging to various networking environments). To
counteract against the non-response a reminder was issued after seven days but it’s
been observed that not many from targeted audience responded. The survey was
anonymized to encourage the participation.
The survey was presented in Appendix 2
The key motivation behind every survey questions (SQX) will now be explained and
justification for inclusion of every component made. Following table mapped the
each SQX to its corresponding RSQX.
SQX RSQX Rationale and Justification for the Inclusion of SQX
SQ1 General To understand the targeted audience someone like who
information has an experience of over 20 years is in a better
will impact position to answer the questions than to someone who
all has a less experience. But again, survey cannot be
responses. ignored alone based on the reason that it contained the
data that comes from the network professional who
spend less time in the industry and not from the highly
experienced ones although it does make an impact but
its rejection only for that reason cannot be justified.
Hopefully as an author of this study we assume that will
get some well-balanced responses.
SQ2, SQ3 RSQ1 and To understand how many professional in the industry
general agreed that SDN is ready to be adapted on a large scale
information by DCNs, ISP and enterprises or do they think it is still
early and needs more time and rigorous testing before
being deployed. As SDN is already adapted by big
names such google (B4), Facebook, Yahoo etc will see
what response we receive.
As there are more than one designs available to deploy

SDN architecture this question will give us the insight
about what professional think which designs choice is
more preferred than others and that can be more
effective to their business.
SQ4 RSQ3 This question is solely targeted to see what benefit SDN
will give them that will drive the ISP, DCNs and
enterprises to move from their traditional network
76
practices towards the adaption of software defined

networking and from various choices which ones are
the most important ones that could play a vital role in
deployment of SDN.
SQ5 RSQ2 This question is to obtain information from the
respondent of what do they perceive about the
disadvantages of SDN technology which are creating
hurdles for SDN to make its mark. So that we know
which ones are the most prominent cons of SDN
technology which must be coped before prominently
adapted by SDN SME to large DCNs and ISPs.
SQ6, SQ7, RSQ4 As there are a lot of solutions available in the market
from well-known vendors to vendor who are
anonymous at some extent and they all bombard the
market with their own versions of SDN based on
distinctive designs of SDN responses for this question
will determine which vendor’s SDN solution IT
organization are looking for most recognized ones are
the VMware, Cisco, and Huawei. As there are not only
vendor specific solutions available but also open source
projects that are contributing the development of SDN.
The second question is specifically targeted to
determine in which open solution IT organization are
interested in or do they still believe that adopting a
well-known solution for SDN implementation is a far
better choice. It is noted that besides involving into
their own SDN solution some well-known vendors are
also contributing in the open source projects one of the
project is ODL (Open Day Light) project member
including (Cisco, NEC, Ericsson, Citrix, ZTE, Huawei,
Dell, Arista, Juniper) and many others.
Information gathered from these two questions will be

used to conclude which vendor solutions are mostly
preferred by IT companies and has the more potential
to effectively deploy SDN technology.
SQ8 RSQ4, SDN technology is a composed of number components
general that works under the umbrella of SDN component like
information (controller, switches, router, application, kits,
platforms) to figure out which of these components
most network professional have interest in as there are
starter kits available which can be used to test the SDN
before final implementation some vendors that
provide kits ( Pica8, NEC, BigSwitch, Plexxi, Cisco ACI,
Dell, Borcade and Open contrail), SDN platforms that
77
are available some of them are (ODL, ONOS, Project

Floodlight, VMware NSX, Beacon, Juniper contrail, POX,
Nauage etc) and others in the same way application
used in SDN to make the network effective are (Security
service, Network Intelligence and Monitoring, WAN,
Cloud, routing, wireless etc).
SQ9 RSQ5 This question is to understand how much knowledge
do they have regarding the implementation of SDN
what do respondent think in which phase they think
SDN technology is currently implemented in their
organization. Responses will give us the opportunity to
figure out the rate of SDN deployment we can somehow
predict how early or far SDN technology is before
taking over the traditional networking.
SQ1 RSQ6 SDN is still a modern technology which move
networking from hardware based to software based
and there are number of big names in the industry that
transform a part of their network infrastructure
towards SDN as mentioned earlier one of them is
google B4 project. Reason is clear for this question is to
know how many IT organization already Tested SDN
significantly in their companies or are they currently in
the testing phase or none the less there is no SDN
implementation in their pipeline it will give us the idea
about the ratio of SDN implementation although it’s a
limited one because data will be collected from the
scale close to 50 or more respondents but it will be
enough for the measurement to determine whether we
should carry on with traditional networking or SDN is
on the verge of breaking traditional barriers to
innovate the networking paradigm altogether.
It can be said that SQ 9 and 10 are the most important

questions which will have a strong influence in
determining the answer to the primary question.
Table 5.4 – Reasons of SQX for RSQX

To gather valid and reliable data from the survey, questions should be explicit and
easily to understand by the survey participants (Robson, 2002, p. 231). Although
this dissertation does not contain any complex and technical jargons, which is
reflected in preparation of the survey everyday language is used in the survey and
all the complicated jargons and terminologies are avoided to make the respondent
more likely to focus on presenting its view rather stuck to any specific word which
can lost the participant interest. Most of the questions presented are the close ended
78
question which multiple choice as this will ease the respondent to answer then to
form his own opinion to some to some extent this option” to provide your own
view” is given where found necessary. To measure the attitude of respondent
towards given subject close end question with multiple choices is easy to measure
than to open ended question. As Robson mentioned that
“it’s impossible to measure attitude from a response to any single statement rather
multiple statements must be used to receive the complete picture of the respondent’s
attitude to subject matter can be built upon” (Robson, 2002, p.293). Another reason
to choose close ended questions it’s because SDN is relatively modern technology
and it is possible that in our survey network professionals with less than 5 years of
industry expression participate without much knowledge of SDN, so option are
there to aid him/her in responding, although measure have been taken especially
when posting survey to individuals by ensuring that they have the knowledge of
SDN and have already worked in the industry for good amount of time. It is
understandable that forcing an opinion could be argued and can be count as
deficiency in this study but instead of receiving substantial number of responses
with all the impartial and uninformative answers a compromise on close end
questions is viewed as a far better choice to receive limited but relevant
information.
5.7 Conclusion
In concluding section, the primary research question has taken in to evaluation by
restated as six sub questions that are used for the data gathering process. The
process of data gathering tools were debated. Moreover, survey was rectified as a
principle data gathering tool to utilized with it a discussion pertaining the type of
questionnaire used for the survey was presented. The design and development of
questions was discussed which includes rationale and justification of including
survey questions and data collection tools to operationalize which show how
research sub question were operationalize with results of survey and by reviewing
the literature and finally the complete survey design is shown in the appendix
section.
The next section is containing the evaluation of survey results. Discussion of the
findings relating to the six sub-questions is made and in the light of sub questions
answer to the primary research question is collected.
79
Chapter 6
Evaluation and Discussion
6.1 Aim
To answer the six research sub questions mentioned previously, two methods were
adapted. First, data gathered from the literature review in chapter 3 and 4 were
used to answer multiple sub questions and secondly results collected from the
survey mentioned in the appendix were evaluated to answer multiple sub questions.
Consequently, after collecting and evaluating all the responses from the sub
questions answer to primary research question is obtained.
6.2 Survey Data

6.2.1 Questionnaire Responses
The total of 82 number of survey responses were received out of which 7 survey
response could not make it due to some unknown reasons. The rest of 75 responses
were evaluated with the objective of answering six research sub questions.
6.2.2 General Information about Research Participants
Before moving towards answering the research sub question in the light of survey
results and literature review it’s better to know how much IT experience our survey
respondent have. The majority of respondent having an experience of between the
10-15 years (38%), then 5-10 years (26%) than 0-5 years (18%) and lastly over 20
years (16%).
6.3 Discussion
Research Sub Question 1
Is SDN a mature technology?
80
Ready for test and Still in development Ready for Not Ready for
development production production
25.33% 29.33% 26.67% 18.67%
Table 6.1 – First SQ Response Rate
Considering the responses received in survey it showed that majority of the vote is
in the favor of that SDN technology is still in the developing stages and not yet to be
mature for wide deployment. Although major technology vendors recognize the fact
that SDN is a future frontier there is still no consensus on the interoperability
standards for their complete network products and other challenges SDN is dealing
with despite this technology is open as mentioned in chapter 4. Until there are
standard solutions for SDN challenges it can be said that only the early adopters
think of Google (B4) to which SDN give new life will move forward with the broad
deployment of this technology. But it does not mean that SME shouldn’t have this
technology in their IT roadmap because there are only random solutions to its
barriers and not the standards ones. Standards bodies are working like ONF (open
network foundation) to build new standards for wide adaptation as mentioned in
chapter 2 the improvement that has been done by ONF in Open Flows protocol in
the span of few years it identifies that SDN is moving in the right direction other
than standardization other important factors should also be considered like as to
how much network infrastructure should be controlled by centralized management,
whether SDN open solution are better or proprietary, how SDN define network
security and last but not least what part of hardware versus software in SDN
architecture. But as this technology is evolving it is safe to say that many in IT
industry will soon change their preferences and move implement SDN for their
Business demands.
What are the barriers of adapting Software Defined Networking for IT
organization?
Lack of Lack Controller Highly Still in Performanc Single Controller Others
standard experts and targete early e concerned point of placemen
s for switch d stages for failure t
technical design attacks centralized
support are control
possible
49% 68% 17% 65% 50% 56% 62% 28% 1%
Table 6.2 - Second SQ Response Rate
To figure out why SDN is still not being widely adapted according to market trends
above results outlined the reasons. There are other significant barriers for SDN
mentioned chapter 4 which are also recognized in the survey results such as lack of
standards, Security as (highly targeted attacks are possible), Scalability as
(performance concerned for centralized control) and fault tolerance as (single point
81
of failure). Below only those shortcomings are mentioned that are also a part
challenge section in chapter 4.
Lack of standards
In SDN one of the significant issue is lack of standardization in solutions, in
protocols, in high-level programming language for defining flows as detailed is
provided in chapter 4 and as acknowledged in survey results this is a major issue
which is playing its role in keeping industry at distance from implementing the
technology. As mentioned in earlier currently there are various open and vendor
specific solutions exist and number working groups from different standard bodies
(IETF/IRTF, ONF, ITU-T etc) are continuously developing and improving standards
for SDN and number of vendor solution.
Lack experts for technical support
As survey results shows that 68% believe that lack expertise is another one of big
reasons slow adoption by the IT industry and not as expected. But as an author of
this study to some extent, I would say yes this is because programming is the core
concept of SDN. SDN move network from hardware to software and this creates a
perception that SDN required advance programming skills to some extent it does
required because till now there is no standardized language and mostly (C++, C,
python etc) and other language are used. Normally network engineers don’t work
with language which slow down the phase of SDN adoption because IT companies
believes they don’t have right skill set for SDN or that it would be expensive to hire
with the right skills. But as this evolution is progressing vendor specific GUI solution
like Cisco APIC-EM, Open Stack applications etc are increasing in which no coding is
required these platforms provide such interfaces that allow to utilize SDN
capabilities for you network.
Highly targeted attacks are possible
Security challenges defined in chapter 4 as one of the most significant barrier. As
SDN gives the concept of centralized management which enhance the network
management at the same time can also be used against the network infrastructure.
In security section of chapter 4, the three main security mechanisms were discussed
where attacks can be possible in the control plan, data plane and in the channel. Any
attack in any of the plane could easily led the network to lose CIA from all three
planes such as if the attack to controller succeed then the whole network is come
under the influence of in the SDN environment. In the same manner attacks to data
plane or channel where end devices and connection mediums if targeted can easily
jeopardize the network infrastructure. Because of this, it is very important to
protect these planes. So that security threats can be mitigated.
Performance concerned for centralized control
82
This is another one of the problems highlighted significantly in the survey results. It
is highly possible that in SDN centralized structure controller can bogged down due
handling of high number incoming packets which result in reduction of throughput
and increase in latency as described earlier in the study. Due to which in the
solution section number of mitigation techniques among others were presented.
Which were pointing to the fact that SDN should devolved for better processing in
this way it can increase the throughput, reduce the latency and able to mitigate
single point failure issue which is another one highlight problem area in survey
result. Therefore, solutions like DIFANE architecture which present authority
switches setup between the controller and egress switch to increase the
performance, Kandoo controller provide the framework for local controller act as
interface between the controller and switch, Maestro uses multi core systems to
leverages to evenly distributed its work load, reduction in cross core overhead and
reduction in memory consumption. NOX-MT uses I/O batching, porting, ASIO and
Malloc to increase the performance of the SDN architecture.
What benefits IT organizations are expecting from SDN and Is SDN able to
provide it effectively?
Improved Improved Improved Improve Centralized Simplified Cost Cost Open Other
Reliabilit scalability network d visibility network savin saving source
y for performance security operations g on on
growing and OPEX CAPEX
workload Efficiency
s
61% 73% 80% 68% 76% 70% 60% 57% 69% 0%
Table 6.3 – Third SQ Response Rate
To answer this question in the context of survey result and literature review from
chapter 3 the answer is very clear. Software defined networking is a paradigm
which delivers innovative architecture that is composed of above-mentioned
benefits. In terms of benefits of SDN organization can expect but not limited to such
as practical deployment of centralized control in a multi-vendor environment is now
possible because of it unification of device control is possible through SDN
architecture vendor specific devices already start supporting protocols like Open
flow. As SDN is well-known for pouring life to existing hardware as many of the
devices already support for protocols like Open Flow which mean lower CAPEX as
the demand increase many companies must overhaul their device with new devices
but with SDN deliver better optimization of device utilization reduce the OPEX
which is endorse in the survey result.
Simplified network operation indeed before admins configure network on device
per device basis but by using SDN platforms changes to network can performed
83
much more efficiently and effectively not only there is a centralized control but
many configurations can be automated. SND is double edge sword when it comes to
security but it provides much more effective approach because controller provides
single point control which deals with all the security policies and regulation and are
distributed throughout the network infrastructure it allows network admins to
respond to security incident effectively by giving them real time visibility and
network can be programmed to respond certain type of attacks without any
intervention from admins simply alleviating human reliance.
Network visibility is counted as one of the biggest benefits of SDN. As SDN provide
the abstracted view of the underlying hardware running at infrastructure layer to
application plane where admin can rectify any security challenges, performance
drops, outages of any sort without interfering with the network activity that can
degrade the network and maximize and minimize the network performance
according to required business demand.
What are the vendor specific and open solutions available for SDN and which
solution appeal most to IT organizations?
Cisco Vmware Bigswitch Juniper Brocade Huawei Dell HP Other
29% 30% 4% 18 % 2% 8% 1% 5% N/A

Table 6.4 – Fourth SQ Response Rate
Open Day Flood Ryu ONOS (Open Open Flow Visor Other
Light Light Network Operating Contrial
System
45% 18% 8% 8% 8% 2% 9%
Table 6.5 – Fifth SQ Response Rate
As result shows that the solution that attract most to the network professional is
ODL project followed by Flood light and the market leader perceived in SDN as
VMware followed by cisco. Some of the option in not included in the Market leader
because they haven’t received any responses including (Plexxi, Arista and Pica8)
they are present in snip shown attached in appendix.
ODL is understandable to be most preferred choice because it’s a project in which
many vendors invest necessary resources in building the open source SDN platform
including (Cisco, Citrix, Big Switch, arista, Ericson, HP, IBM, Nuage Networks,
Brocade) and those that were initially a part of this project but left in 2015 including
84
(Juniper, VMware). Since its creation, many ODL versions have been released which
are mentioned below.
1. Hydrogen.
2. Helium.
3. Lithium in 2015 and with the advent of lithium ODL controller becomes ODL
project.
4. Beryllium in 2016.
5. Boron in 2017.
According to ONF Controller 2016 white paper ODL still takes the lead over ONOS,
RYU, Open contrail and on other with over 600 developers supporting ODL project
and continuing their contribution in ODL, high number implementation is seen for
ODL worldwide just to name few like (AT&T, Tencent etc). According to paper,
ONOS is on top as WAN controller and mostly backed by Huawei, Ciena. While RYU
is still very active controller but not in the enterprises environment but rather in
DCNs.
On the other hand, VMware is perceived as the Market leader and in a SDN is
virtualization and to some extent it is. According to the ONF paper Cisco SDN
solution like (ACI, Apic EM, IWAN) gaining momentum with over 1100 deployments
15 – 20 percent in production where VMware chasing behind with its solution
VMware NSX to take the title with over 900 deployment 10-20 percent in
production. As the result in the survey shows and according ONF white paper both
are leading the market with there on specific solutions. It will be interesting to see
whether in the future open solution will be more preferred or vendor specific ones.
As far as the study survey goes ODL open solution is the most preferred one.
How early should we expect from DCN, ISP, and Enterprises to move from
current network practices to SDN?
Significant Limited Evaluating in Thinking about What is SDN
deployment deployment non-production it
environment
8% 13% 35% 40% 2%
Table 6.6 – Sixth SQ Response Rate
Respondents were asked to specify their level of concern on deployment of SDN
technology in their organization from the options mentioned above in the table. It
seems that in general companies are very much interested in adopting SDN. But not
many companies according to this survey have currently deployed this technology.
If you move away from the significant deployment tab it gives a clear indication that
although companies wanted to deploy but they somehow show reluctance with 40%
agreed that they are thinking about it and not even want to evaluate it in the non-
85
production environment. This could be because SDN is not a mature technology if

we look at the still in development and not ready for production options which
were mentioned earlier in the first RSQ if two results are combined which becomes
46% and compared it with Thinking about it options which is 40% not much
significant difference is present who perceive that SDN is still not ready for any
deployment in the production environment.
On the other hand, results from survey also shown that 56% (combining first three
options result) is ready to implement SDN in near future some already have.
Although the results of this survey are not from substantial number of sample but
still it proves that IT industry is moving towards the adoption of SDN and
acknowledges its potential.

Can we afford to live without SDN indefinitely?
No plane to test Testing Already Tested
39% 45% 15%
Table 6.7 – Seventh SQ Response Rate
60% of the respondent acknowledges SDN is taking over the traditional networking.
It is definite to say that benefits of SDN are far more convincing than its
Barriers/challenges and as SDN will make more progress in IT industry more
significantly over the couples of years as technology grows more, SDO set standards
and as IT managers become more comfortable with the benefits SDN bring to their
companies. Living without SDN at this point makes no sense IT industry is catching
up fast as companies like Google, Amazon, Facebook, and Microsoft and service
provider like AT&T, NTT etc already running SDN in their networks this also
encourages SME business to move their network to SDN.
6.4 Primary Research Question
Does migration to SDN becomes necessary from present network architecture

and Are we ready for it?
Through the evaluation of research sub questions, it is identified that Software

defined networking is the novel approach IT industry is looking for to innovate their
networks and as far as the migration from traditional network to SDN is concerned
the survey results and literature presented in this study is an evidence that it is not
only necessary but mandatory. This is evident that SDN has created a lot of
excitement in the IT industry and offer possibility of greatly simplified network
automation, has provide the opportunity to greatly reduce the cost of the network
infrastructure which is a big concern. Software defined networking has emerged to
86
move networks from hardware to software make them more agile and
programmable to cope the dynamic nature of future networks.
Are we ready for it as an author of this study I predict that SDN infrastructure
adoption will accelerate in coming years exponentially as more and more use case
will emerge and as more open standards emerges beside Open Flow. A lot more
companies we see are now developing network service applications for SDN we see
SDN brings the value of network virtualization to an entire new level by enabling
those services to affect the network directly and dynamically on behalf of user or
hosted application.
There is absolutely no doubt the software defined networking debate will rage on as
there is a lot of SDN talk in the IT industry and we see in the coming years there will
much more diving in SDN. Nevertheless, it is inevitable SDN is here to stay as a
revolutionary step for paving the way to highly optimized and available
architecture.
6.5 Critical Analysis and Conclusion

6.5.1 Introduction
This section provides a conclusion of the dissertation. Starting with the overview of
the previous chapters and restate the aims of the project and summarizes finding of
the research followed by the future research areas and concluding remarks.
6.5.2 Study Overview

Chapter 1 composed of aims and objectives of this work and outline the primary
research question of this study aim to answer. Chapter 2 shed light on describing
detailed background of SDN all the technologies that came before SDN and laid the
foundation of programmable networks and provide the comprehensive review of
first standardized Open Flow protocol. Chapter 3 outlined the benefits of SDN and
focused on DCNs one of the networking environment and detailed its issues which
are present due to the usage of traditional networking architecture and describe
how Open and Overlay SDN can resolves these problems. Chapter 4 deal with
challenges/barriers that are hurdle in the wide adaption of SDN and their mitigation
solutions although not all the challenges and solutions are present which are out of
the scope of this study. Chapter 5 provides a research methodology where number
sub research questions are identified to answer the primary research question
collective. Chapter 6 delivers a conclusion composed of strength and limitation of
this project, future research areas rectified during the course this dissertation.
6.5.3 Restating the Aims of the Study
87
 To investigate what is Software Defined Networking and how it contributes

to the innovation in networking.
 Software Defined Networking play a significant role If it does then what are
the advantages of adapting it and concerning different networking
environments what benefits it bring to DCNs (Data Center Networks).
 Are there challenges causing the hindrance to adoption of SDN if so then

what are the industry solutions currently existed and how efficient are they.
 Does migration to SDN becomes necessary from present network

architecture and Are we ready for it?
6.5.4 Research Finding Summary
Data obtained from the literature review identified that Software Defined
Networking beside it benefits does contain challenges that are hindering its
implementation on a large scale even after number of big names adapted this
technology for their networks. However, there are other challenges but in this study,
only the most recognized ones are discussed with their solutions to mitigate it like:
Scalability (Throughput and Latency) challenge in SDN is most significant as directly

degrade the performance of the SDN architecture. Three factors were identified in
this regard which can lower the throughput and increase the latency.
 Decoupling of control and data plane.

 High number of flown handling in controller.
 Controller and Open Flow switch communication delay.
To mitigate solutions that are presented including one framework and three
controller designs that can resolve scalability challenge such as
 DIFANE.
 Kandoo.
 Maestro.
 NOX-MT
The above-mentioned scalability proposal/approaches can be classified in to three

approaches in topology based which is based on single controller design, distributed
based on distributed (flat), hierarchical design and hybrid design and mechanism
bases on multi-threading and I/O batching controller. It is possible that some
controller may belong to more than one approach due their controller design.
88
Approaches Topology Distributed Mechanism

Related Related
Centralized Distributed Hierarchical Hybrid Parallelism
Based
Optimization
DIFANE -  -
Kandoo -  -
Masetro - - - - 
NOX-MT  - - - 
Table 6.8 – Design Classifications
Second challenge is Fault tolerance another one of the core issue of SDN as we know
switch are dependent on the controller and have no intelligence if some failure
occurred along the path switch determine it but it cannot provide the alternate path
because of its dependency on controller which causes delay also failure in the
control plane could bog down the complete network because of it failure detecting
and fault tolerance solutions which are mentioned:
 Fault tolerance in Data plane

 Bi-directional Forwarding Approach.
 Fault tolerance in Control plane
 Shared Data Controller Framework.
 CPrecovery Component.
Security is utmost important challenge for the SDN as mentioned earlier that Open
Flow protocol is identified as a potential security loop hole and attacks can be
launched on all three level that are part of SDN architecture (controller level, switch
level, and channel level) that may damage the CIA (security model). To be noted that
attacks on Open flow based SDN are becoming more complicated by leveraging the
vulnerabilities of various levels. Challenges are almost similar in nature but when
used against SDN architecture it changes the dynamic of the attack table followed
summarized the attacks
.
Category CIA MODEL Attacks
Switch level Challenges Confidentiality Scanning, Hijacking, Spoofing,
etc
Integrity Tampering, Hijacking,
replaying etc
Availability Scanning, DoS etc
Controller Level Challenges Confidentiality Scanning, spoofing, hijacking,
89
replaying attacks etc

Integrity Tampering, hijacking,
replaying etc
Availability Scanning, DoS etc.
Channel level Challenges Confidentiality MITM, network monitoring etc

Integrity MITM, repudiation etc
Availability MITM, hijacking etc
Table 6.9 – Security Challenges Summary
Thus, it seems that weakness left in Open Flown SDN will continue the attacks and
more highly advance attack like (APT) could be possible due to which effective
solutions to countermeasure such attacks are mentioned below:
Levels Literature Solutions Confidentiality Integrity Availability

Work
Yao et.al VAVE   
Hong et.al Topo guard   
Controller Hu et.al Flow guard   -
Level
Solutions
Matias et.al ARM - - 
Switch Wang et.al OF-Guard   

Level
Solutions
Jafarian et.al OF-RHM   -
Khurshid Veriflow   -
et.al
Matias et.al FlowNac   
Channel Liyanage e.al HIP   

Level
Solutions
Shin et.al Avant-   
Guard
Table 6.10 – List of Existing Solutions in Respect to CIA Model
Lack of Standardization is last as far this study is concerned but not least of SDN.
After conducting a literature review that there are number of SDO working for the
development of open standards beside ONF and It will be interesting to see if Open
solution dominate the market or the vendors specific solutions. Currently, Cisco and
VMware are dominating the market with their SDN solutions but this could change
in the future as more efficient open solutions become available in the market.
6.5.4.1 Evaluation of the survey indicated:
90
First According to survey responses half of them agreed that SDN is either ready for
full production deployment or ready for test in non-production environment.
From three approaches of SDN (open, overlays and hybrid) mostly went with the
choice of hybrid designs and which showed that although half of them think that
SDN should be adapted but it should be adapted in such a way that the current
network practices shouldn’t be removed altogether instead they prefer the
transitionally deployment. Suggesting a trust deficit on SDN from IT industry.
Majority of the respondent expect performance optimization, scalability, central
visibility from SDN architecture for their network which SDN can provide as
mentioned in the benefits section of the study also reduction of cost is not preferred
as it was expected security, open source and reliability are also remained average
preference and simplified network operation is a also stand as high preference and
it should be due to fact that configuring today's network on per device basis and
setting QoS is considered very hectic prone to errors.
According to market domination, Cisco remain the first choice followed by Vmware
and Juniper and Huawei among vendor solutions and considering the open solution
ODL takes the lead followed by Floodlight open flow based solution and then ONOS,
Open Stack also gains ground and Ryu. The future of SDN will be very interesting as
it will decide that could this technology which started as an open source end up
being vendor specific solutions or remained open and provide solutions like ODL
which is result of many number of vendors.
High number of responses are in favor of SDN controller, application, and
development kit for testing but platforms like (Cisco ACI etc) that combine
controller applications etc hold the first choice.
Lastly mostly believe that SDN is the future there is no doubt in there according to
responses there are limited number of production deployment and high number of
response rate for non-production testing and moving toward testing phase it is now
justified to that SDN will eventually be adapted massively as it is being predicted on
different platform and this study survey also come to the same conclusion that it is
the future of the networking we all are moving rapidly.
6.5.5 Analysis
6.5.5.1 Study Strength
The concept of software defined networking was comprehensively investigated.
Despite SDN is still a recent technology there are number sources available online
for instance (website, blogs etc). The matter on this subject is although available but
it cannot be completely reliable to be included. Due to the fact, this study contains
91
academic literature review and information available from credible sources, which
result in an up-to-date literature review on SDN.
In conducting this study, it was rectified that not many studies identify the factors
focused in this study. Therefore, this thesis delivers the valuable contribution in
exploring the challenges, research effort, and benefits specifically how SDN elevate
the problems for DCNs. Hence aims that were set initially are accomplished.
6.5.5.2 Study Limitation

The limitation of this study is that the number of response that were received from
the survey is not as what was expected previously because conducting an online
survey led to limited sample gathering and respondent availability as a result, not
enough data is gathered for comprehensive analysis additionally there is a
possibility exist that the collected data from the survey may come from the sources
that does not have much experience in the IT industry which could affect the survey
response. Second in collecting the information some of the responses are lost which
again affect the result derived from the survey.
6.5.5.3 Future Research Areas

This study provides the generalized view of the SDN architecture design, benefits,
and its barriers and tried to answer the primary question on which this study is
based upon. But many other grounds that are open for research for example
technologies like NFV which is very complementary to SDN can be further
investigated. In SDN open flow by far is not the only implementation other
developing implementation can be researched. Further study of SDN in carrier
networks with their requirement, and wireless mesh network with fast client
mobility, Open, and vendor specific SDN solutions should be considered.
6.5.6 Conclusion
This study pursued to investigate the why the migration from the traditional
networking to SDN architecture is necessary. A detailed literature review was
presented first detailing the background technologies that led the development of
SDN and further towards the benefits and challenges all in the light of credible
academic literature on the subject and some from reliable online sources.
Furthermore, survey was prepared to assess the industry attitude towards SDN and
how willing they are to adapt the SDN and derive their view on SDN. The primary
research question was further broken down into six sub research question and the
responses of said survey with material from literature review were used to first
answer the sub question before finally answer the primary question which
92
ultimately showed that migration to SDN will be mandatory in the recent future.
Afterward the strength and limitation of the project were also discussed.
7 References
.Akhunzada, A., Gani, A., Anuar, N., Abdelaziz, A., Khan, M., Hayat, A & Khan, S (2016),
Secure and Dependable Software Defined Networks, Network and Computer
Application, 61, 199-221, Retrieved July 5, 2017 from
http://www.sciencedirect.com.ezproxy.napier.ac.uk/science/article/pii/S1084804
515002842
Akyildiz, I., Lee, A., Wang, P., Luo, M., & Chou, W (2014) A roadmap for traffic engineering
in SDN-Open Flow networks, Computer Networks, 71, 1-30, Retrieved July 6, 2017
from
614002254
Ahmed, R., Alfaki, E., & Nawari, M. (2016). Fast failure detection and recovery
mechanism for dynamic networks using software-defined networking. Basic
Sciences and Engineering Studies (SGCAC), 2016 Conference of, 167-170, Retrieved
July 5, 2017 from
http://ieeexplore.ieee.org.ezproxy.napier.ac.uk/document/7458023/?reload=true
Botelho, F., Valente Ramos, F., Kreutz, D., & Bessani, A (2013). On the Feasibility of
a Consistent and Fault-Tolerant Data Store for SDNs. Software Defined Networks
(EWSDN), 2013 Second European Workshop on, 38-43, Retrieved July 8, 2017
from http://ieeexplore.ieee.org.ezproxy.napier.ac.uk/document/6680556/
Bezemer, C., Zaidman, A., (2010). Multi-Tenant SaaS Applications: Maintenance
Dream or Nightmare, TUD-SERG, (1872-5292) Retrieved July 15, 2017 from
93
http://swerl.tudelft.nl/twiki/pub/Main/TechnicalReports/TUD-SERG-2010-
031.pdf
Campbell, A., Katzela, I., Miki, K., & Vicente, J. (1999). Open signaling for ATM,
internet and mobile networks (OPENSIG'98). ACM SIGCOMM Computer
Communication Review, 29(1), 97-108, Retrieved July 1, 2017 from
http://dl.acm.org/citation.cfm?id=505762
Casado, M., Freedmen, M., Pettit, J., Luo, J., Mckeown, N., Shenker, S. (2007). Ethane:
Taking Control of the Enterprise. Proceedings of the 2007 conference on
Applications, technologies, architectures, and protocols for computer
communications, 37(4), 1-12. Retrieved June 25, 2017 from
http://dl.acm.org.ezproxy.napier.ac.uk/citation.cfm?doid=1282427.1282382
Cai, Z., Cox A., Eugene, T (2010). Maestro: A system for scalable Open
flow control, 1-10, Retrieved July 5, 2017 from
https://pdfs.semanticscholar.org/6a6c/794083cbdf79de0fcd206569
9477290b5546.pdf
Doria, A., & Sundell, K. (2002). General Switch Management Protocol (GSMP)
Applicability. RFC 3294, 1-6. Retrieved july 1, 2017 from
https://tools.ietf.org/html/rfc3294
Devolved Control of ATM Networks. Retrieved from June 23, 2017 from
https://www.cl.cam.ac.uk/research/srg/netos/projects/archive/dcan/
Doria, A., Hadi Salim, J., Haas, R., Khosravi, H., Wang, W., Dong, L., Gopal, R., Halpern.,
J. (2010). Forwarding and Control Element Separation (forCES) Protocol
Specification. RFC 5810, (2070-1721), 5-10. Retrieved June 27 from
https://tools.ietf.org/html/rfc5810
Enns, R. (2006). NETCONF Configuration Protocol. RFC 4741 Proposed Standard, 5-
10. Retrieved June 24, 2017 from https://tools.ietf.org/html/rfc4741
Farhady, H., Lee, H & Nakao, A (2015). Software-Defined Networking: A
survey. Computer Networks, 81, 79-95, Retrieved july 7, 2017 from
615000614
Feamster, N., Rexford, J., & Zegura, E. (2013). The Road to SDN. ACM Queue, 11(12),
3-5. Retrieved July 2, 2017 from
https://www.cs.princeton.edu/courses/archive/fall13/cos597E/papers/sdnhistor
y.pdf
94
Fonseca, P., Ricardo, B., Edjard, M & Passito, A (2012). A replication component for
resilient OpenFlow-based networking, IEEE, 1-7, Retrieved july 20, 2017 from
http://ieeexplore.ieee.org.ezproxy.napier.ac.uk/document/6212011/
Feng, T., Bi, J., Hu, H., Yao, G., Xiao, P (2012). InSAVO: Intra-AS IP source address
validation solution with OpenRouter, In Proceedings of INFOCOM, 1-2 Retrieved
June 19, 2017 from
https://pdfs.semanticscholar.org/750f/52599a470f8d3777bd79e813efa6a58dd67
b.pdf
Greenberg, A., Hjalmtysson, G., Maltz, D., Myers, A., Rexford, J., Xie, G., Zhang, H.
(2005). A clean slate 4D approach to network control and management. ACM
SIGCOMM Computer Communication Review,35(5), Retrieved July 1, 2017 from
https://people.csail.mit.edu/alizadeh/courses/6.888/papers/4d.pdf
Goransson, P., Black, C., (2014). Software Defined Networks A Comprehensive

Approach, USA: Elsevier
Gill, P., Jain, N., & Nagappan, N. (2011). Understanding network failures in data
centers: Measurement, analysis, and implications. ACM SIGCOMM Computer
Communication Review, 41(4), 350-361, Retrieved June 19, 2017 from
http://delivery.acm.org.ezproxy.napier.ac.uk/10.1145/2020000/2018477/p350-
gill.pdf?ip=146.176.250.96&id=2018477&acc=PUBLIC&key=C2D842D97AC95F7A
%2E955D16440231B4DF
%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35&CFID=795780712&CFTOKEN
=22198391&__acm__=1502362568_a677da474ba21a44b09517cb6c845930
Hong,S., Xu,L.,Wang,H., Gu,G (2015). Poisoning network visibility in software-
defined networks: new attacks and counter measures. In: Proceedings of NDSS, San
Diego, USA, Retrieved June 18, 2017 from
https://www.internetsociety.org/sites/default/files/10_4_2.pdf
Hu, F., Hao, Q., & Bao, k., (2014). A Survey on Software-Defined Network and Open
Flow: From Concept to Implementation. Communications Surveys & Tutorials,
IEEE, 16(4), 2181-2206, Retrieved june 28, 2017 from
http://ieeexplore.ieee.org.ezproxy.napier.ac.uk/document/6819788/?
arnumber=6819788&tag=1
Jarraya, Y., Madi, T., & Debbabi, M. (2014). A Survey and a Layered Taxonomy of
Software-Defined Networking. IEEE, 16(4), 1955-1980, Retrieved July 2, 2017 from
http://ieeexplore.ieee.org.ezproxy.napier.ac.uk/stamp/stamp.jsp?
arnumber=6805151
Jafarian, J.H., Al-Shaer, E., Duan,Q (2012). Open flow random host mutation:
transparent moving target defense using software defined networking. In
Proceedings of the ACM Work shop on HotTopics in Software Defined Networks
95
(HotSDN), Helsinki, Finland, 127–132, Retrieved July 17, 2017 from

http://www.ece.cmu.edu/~ece739/papers/movingtarget.pdf
Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C., Azodolmolky, S., & Uhlig, S.,
(2015). Software-Defined Networking: A comprehensive Survey, IEEE, 103(1), 14–
76, Retrieved June 28, 2017 from https://arxiv.org/abs/1406.0440
Karakus, M., Durresi, A (2017).
A survey: Control plane scalability issues and approaches in Software-Defined
Networking, Computer Network, 112, 279-293 Retrieved july20, 2017 from
http://ac.els-cdn.com.ezproxy.napier.ac.uk/S138912861630411X/1-s2.0-
S138912861630411X-main.pdf?_tid=bf910fc4-7dbf-11e7-a3f6-
00000aab0f01&acdnat=1502364996_d0f1ac44d26929513431cf91defe5c2c
Khurshid, A., Zhou, W., Caesar, M., & Godfrey, P (2012). Veriflow: Verifying network-
wide invariants in real time. ACM SIGCOMM Computer Communication
Review, 42(4), 467-472, Retrieved July 3, 2017 from
http://delivery.acm.org.ezproxy.napier.ac.uk/10.1145/2380000/2377766/p467-
khurshid.pdf?ip=146.176.250.96&id=2377766&acc=ACTIVE
%20SERVICE&key=C2D842D97AC95F7A%2E955D16440231B4DF
%2E4D4702B0C3E38B35%2E4D4702B0C3E38B35&CFID=795780712&CFTOKEN
=22198391&__acm__=1502391874_972a576a93a6d9b84368ee8a9b16246f
Lara, A., Kolasani, A., Kolasani, A & Ramamurthy, B. (2014). Network Innovation
using OpenFlow: A Survey. IEEE, 16(1), 493-512, Retrieved July 1, 2017 from
http://ieeexplore.ieee.org.ezproxy.napier.ac.uk/stamp/stamp.jsp?arnumber=6587999
Li, W., Meng, W & Kwok, L (2016). A survey on Open Flow-based Software Defined
Networks: Security challenges and countermeasures. Network and Computer
Applications, 68, 126-139, Retrieved July 5, 2017 from http://ac.els-
cdn.com.ezproxy.napier.ac.uk/S1084804516300613/1-s2.0-S1084804516300613-
main.pdf?_tid=bbb7053c-7da8-11e7-9f79-
00000aab0f6b&acdnat=1502355111_2e5316247fdc853299d20ccae0f51bdb
Li, W., Meng, W., Kwok, L (2016). A survey on Open Flow based Software Defined
Security challenges and countermeasures, Networks Security challenges and
countermeasures, 68, 126-139, Retrieved July 12, 2017 from
http://www.sciencedirect.com/science/article/pii/S1084804516300613
Lara, A., Kolasani, A., & Ramamurthy, B (2013). Network Innovation using
OpenFlow: A Survey, IEEE, 16(1), 493-512, Retrieved June 26, 2017 from
http://ieeexplore.ieee.org/document/6587999/
Liyanage, M., Ylianttila, M., & Gurtov, A. (2014). Securing the control channel of
software-defined mobile networks, IEEE, 1-6, Retrieved July 10, 2017 from
96
Lin, Y, Pitt, D, Hausheer, D. Johnson, E & Lin, Y (2014), Software-Defined

Networking: Standardization for Cloud Computing’s Second Wave, IEEE, 19-20,
Retrieved July 14, 2017, from
https://www.opennetworking.org/images/stories/downloads/sdn-
resources/IEEE-papers/SDN-Standardization.pdf
Munir, S. (1997). Active Networking. Recent Advances in Networking. Retrieved
June 25, 2017 from http://www.cse.wustl.edu/~jain/cis788-
97/ftp/active_nets/index.html
Matias, J., Borja, T.,Alaitz,M.,Jacob,E.,Nerea,T (2012). Implementing layer 2 network
virtualization using Open Flow: challenges and solutions. IEEE, 30–35, Retrieved
June 19, 2017 from http://ieeexplore.ieee.org/document/6385044/
Matias, J., Garay, J., Mendiola, A., Toledo, N., & Jacob, E. (2014). FlowNAC: Flow-based
Network Access Control. IEEE, 79-84, Retrieved july 16, 2017 from
Mahalingham, M., Dutt, D., Duda, K., Agarwal, P., Kreeger, L., Sridhar, T., Bursell, M., &
Wright, C (2014). Virtual Extensible Local Area Network (VXLAN), RFC 7348, (2070-
1721), 4-5, Retrieved july 12, 2017 from
https://tools.ietf.org/html/rfc7348#section-3
Nunes, B., Mendonca, M., Nguyen, X., Obraczka, K., & Turletti, T., (2014). A Survey of
Software-Defined Networking: Past, Present, and Future of Programmable
Networks. Communications Surveys and Tutorials, IEEE Communications Society,
Institute of Electrical and Electronics Engineers, 16 (3), 1 – 12, Retrieved June 30,
2017 from https://hal.inria.fr/file/index/docid/932982/filename/hal_final.pdf
Nadeau, T., & Gray, K (2013). SDN: Software Defined Networks, United State of
America: O'Reilly Media
Nolle, T, SDN's missing links: Five barriers blocking SDN adoption by providers.
Retrieved June 23, 2017 from http://searchtelecom.techtarget.com/tip/SDNs-missing-
links-Five-barriers-blocking-SDN-adoption-by-providers#
(2014). Open Flow Specification Ver 1.5.0, Retrieved July 10, 2017 from
https://www.opennetworking.org/images/stories/downloads/sdn-resources/onf-
specifications/openflow/openflow-switch-v1.5.0.noipr.pdf
Ren, K., Wang, C & Wang, Q (2012). Security Challenges for the Public Cloud. Internet
Computing, IEEE, 16(1), 69-73 Retrieved June 22, 2017 from
http://ieeexplore.ieee.org.ezproxy.napier.ac.uk/stamp/stamp.jsp?
arnumber=6123700
97
Robson, C. (2002). Real World Research: A Resource for Social Scientists and
Practitioner-Researches. Oxford: Blackwell Publishing
(2012). Software Defined Networking: The New Norms for Networks, 1-12,
Retrieved June 26, 2017 from
https://www.opennetworking.org/images/stories/downloads/sdn-
resources/white-papers/wp-Sdn-newnorm.pdf
Silva, A., Smith, P., Mauthe, A & Filho, A (2015) Resilience support in software-
defined networking: A survey, Computer Networks, 92, 189-207, Retrieved July 9,
2017 from
615003229
Sharma, S., Staessens, D., Colle, D., Pickavet, M, & Demeester, P (2012). OpenFlow:
Meeting carrier-grade recovery requirements, Computer Communications, 36, 656-
665, Retrieved July 30, 2017 from
412003349
Shin, S., Gu, G (2013). Attacking Software-Defined Networks: A First

Feasibility Study, ACM HotSDN 13, 165-166, Retrieved June 19, 2017
from http://dl.acm.org/citation.cfm?id=2491220
Shin, S., Yegneswaran, V., Porras, P., Gu, G (2013). AVANT-GUARD: scalable and
vigilant switch flow management in software-defined networks, ACM, 413–424,
Retrieved June 22, 2017 from
http://faculty.cse.tamu.edu/guofei/paper/AvantGuard-CCS13.pdf
Tso, F., Jouet, S., & Pezaros, P (2016). Network and server resource management
strategies for data center infrastructures: A survey. Computer Networks, 106, 209-
225, Retrieved July 10, 2017 from http://ac.els-
cdn.com.ezproxy.napier.ac.uk/S1389128616302298/1-s2.0-S1389128616302298-
main.pdf?_tid=1b914aa2-7db9-11e7-84b2-
00000aab0f27&acdnat=1502362144_0e122dd64f18fb743a50df648b222d77
Tootoochain, A., Gorbunov, S., Ganjali, Y., Casado, M., Sherwood, R (2012) On
Controller Performance in Software-Defined Networks, Retrieved July 2, 2017 from
https://www.usenix.org/system/files/conference/hot-ice12/hotice12-
final33_0.pdf
98
Wang, H., Xu, L., Gu, G (2015). FloodGuard: A DoS attack prevention extension in
software-defined networks. In: Proceedings of the International Conference on
Dependable Systems and Networks(DSN), 239–250, Retrieved July 1, 2017 from
http://ieeexplore.ieee.org/abstract/document/7266854/
Wang, H., Xu, L., Gu, G (2014). OF-GUARD: A DoS Attack Prevention Extension in
Software-Defined Networks, 1-2, Retrieved June, 19 2017, from
https://www.semanticscholar.org/paper/OF-GUARD-A-DoS-Attack-Prevention-
Extension-in-Soft-Wang-Xu/5ab4f2446bc906cdbeaa2f60e59808d5355047c2
Weissberger, A (2015, July 5), SDN Standards Activities in ITU-T and other SDOs,
Retrieved July 11, 2017 from http://techblog.comsoc.org/2015/07/05/sdn-
standards-activities-in-itu-t-and-other-sdos/
Xia, W., Wen, Y., Foh, C., Niyato, D., Xie, H., (2015). A Survey on Software-Defined
Networking. IEEE, 17(1), 27-51, Retrieved June 30, 2017 from
http://ieeexplore.ieee.org/abstract/document/6834762/
Yu, M., Rexford, J., Freedman, M., & Wang, J. (2010). Scalable flow-based networking
with DIFANE. ACM SIGCOMM Computer Communication Review, 40(4), 351-362,
Retrieved July 12, 2017 from http://dl.acm.org.ezproxy.napier.ac.uk/citation.cfm?
doid=1851275.1851224
Yeganeh, S., Ganjali, Y (2012). Kandoo: a framework for efficient and scalable
offloading of control applications, ACM HotSDN 12, 19-24, Retrieved July 14, 2017
from http://dl.acm.org.ezproxy.napier.ac.uk/citation.cfm?id=2342446
Yao, G., Bi, J., Xiao, P (2011). Source address validation solution with Open
Flow/NOX architecture, IEEE, 7-12, Retrieved July 13, 2017 from
99
8 Appendix 1
EDINBURGH NAPIER UNIVERSITY SCHOOL OF COMPUTING
MSc RESEARCH PROPOSAL
1. Student details
Last (family) name Raza

First name Syed Haider
Napier matriculation number 40224242
2. Details of your program of study
MSc Programme title Advanced Networking

Year that you started your diploma modules 2016
Month that you started your diploma September
modules
Mode of study of diploma modules Full-time
Date that you completed/will complete your 14 August 2017
diploma modules at Napier
100
3. Project outline details
Please suggest a title for your proposed project. If you have worked with a
supervisor on this proposal, please provide the name. NB you are strongly advised
to work with a member of staff when putting your proposal together.
Title of the proposed project Is SDN a Viable Solution to Traditional

Networking Architecture Benefits, Challenges,
and Existing Solutions.
Is your project appropriate to your Yes, it is.
program of study?
Name of supervisor Mr. Imed Romdhani
I do not have a member of staff lined up
to supervise my work
4. Brief description of the research area - background

Please provide background information on the broad research area of your project in
the box below. You should write in the narrative (not bullet points). The
academic/theoretical basis of your description of the research area should be evident
through the use of references. Your description should be between half and one page
in length.
This study is about the working of Software Defined Networking (SDN). This has
become evident that network technologies always play a crucial role when it comes
to network technologies, especially cloud computing which is growing
unprecedently, today networks are not dynamic they seem to be scalable but
certainly, they are not they are rigid in comparison to the possibilities of what SDN
can bring to the current networking architecture. “This technology seems to have
taken off suddenly, but it is actually part of the history of trying to make the
computer networks programmable” [1]. As we see today, virtualization and cloud
have brought revolution in IT from the storing of a high number of data to providing
service virtually to any part of the world, services like (Infrastructure, Platform,
Software and even Malware) is being delivered. But this virtualization potential is
not totally optimized for networking Different frameworks for SDN has been put
forward since 2011 till, now when big names like Google, used SDN framework and
built their own Hardware switches to provide connectivity between their Data
101
Centers, but still organization are not sure about SDN and what it promises to bring
to their current networks due to lack of understanding, deployment, cost and
untrained staff etc. This is why we still work with complex network architecture
which is not innovative as the virtualized server architecture. From Routers and
switches to firewall and IDS to Load balances all of this runs complex and control
software which are all closed and proprietary.
This becomes tedious for network admins to configure individual network device
using configuration interface that varies between vendors. This way of working has
slowed the innovation in networking and adds the complex procedures that make
the network work and over the top add the exponential cost of deployment of new
hardware periodically especially for a business like (Google, Facebook, etc.).
Software-Defined-Networking, As the name, suggests it is now becoming the
paradigm of how the network should work in this dynamic environment, which is
highly scalable and innovative that gives freedom to the network administrator to
define networks with a push of buttons and enables them to continuously innovate
and evolve networks. “The concept of programmable networks has been proposed to
facilitate network evolution, SDN is a technology in which the forwarding
(hardware) plane is decoupled from the control plane (for example the protocols
and control software’s)” [2]. SDN is also classified in three assorted approaches.
 Open SDN.
 SDN via API.
 SDN via Overlays.
In this study, the focus will be upon different frameworks for SDN, Challenges, Effects
and what are the security concerns, reviewing and correlating research papers and
articles with it highlight the widely used protocol Open Flow which is designed by
ONF (Open Network Foundation). “ONF is leading the advancement of SDN and
standardizing the SDN architecture such as the Open Flow protocol, which
structures communication between the control and data planes of supported
network devices. Open Flow is the first standard communicating interface designed
specifically for SDN, providing high-performance, granular traffic control across
multiple vendors’ network devices” [3] and the Cisco view of deploying the SDN
architecture via API (Application Programmable Interface).
Besides SDN potential, this study also deals with the fact that whether SDN is a
feasible solution. The author in [4] states “that the deployment of SDN incur some
important challenges to be successfully adapted to the production networks some
of are (Performance and Modeling, centralised controller failure, Security)” and an
author in [5] “describes SDN issues in terms of (Switch Design, Controller
Availability, Scalability, Hybrid Deployments)”.
Therefore the discussion in this research will be based on an understanding of
102
working, problems and benefit and also existing solutions related to SDN and will
attempt to conclude whether or not Cloud providers Enterprizes, ISP are ready to
adapt Software Defined Networking as the way to move forward with networking
in the present internet architecture.
5. Project outline for the work that you propose to complete

Please complete the project outline in the box below. You should use the emboldened
text as a framework. Your project outline should be between half and one page in
length.
The idea for this research arose from:
The idea arose from one of the subject areas in the course and from internet research I am
curious to know how Software Defined Networking works as there is a lot of hype in
research community and as infant for real world deployment, I am interested to know what
it means to legacy Internet architecture, what potential it promises, what are the
improvement areas and what research efforts have been done.
The aims of the project are as follows:
To find SDN working, vulnerabilities, what are the feasible solutions available to mitigate,
and evaluate the potential benefits of SDN architecture.
The main research questions that this work will address include:
 What are the present challenges associated with SDN?
 Is SDN an efficient solution to Network Management, Performance Tuning, Security,

Reliability, Real-time traffic demands and Resolve scalability issue?
 Does a migration to SDN become necessary from present network architecture and
are we ready for it?
The software development/design work/another deliverable of the project will be:
Evaluation of Software Defined Networking and SDN research efforts which have been
presented by numerous authors and deliver a survey result which will be utilized to obtain
103
information about SDN to answer the research question.
The project will involve the following research/field

work/experimentation/evaluation: Understanding of Software Defined Networking
programming capabilities, vulnerabilities, benefits, and evaluate the proposed approaches
to figure out efficient solutions to SDN problems. From the literature review and from the
survey.
This work will require the use of specialist software: N/A
This work will require the use of specialist hardware: N/A
The project is being undertaken in collaboration with N/A
6. References
Please supply details of all the material that you have referenced in sections 4 and 5
above. You should include at least three references, and these should be to high-
quality sources such as refereed journal and conference papers, standards or white
papers. Please ensure that you use a standardized referencing style for the
presentation of your references, e.g. APA, as outlined in the yellow booklet available
from the School of Computing office and
http://www.soc.napier.ac.uk/~cs104/mscdiss/moodlemirror/d2/2005_hall_referen
cing.pdf
[1] Feamster, N, Rexford, J, Segura, E. (2013). The Road to SDN, 11(12), 1-2
[Electronic version]. Retrieved May 8, 2017, from http://dl.acm.org/citation.cfm?
id=2560327.
[2] Azodolmolky, S (2013). Software Defined Networking with Open Flow.
Birmingham: Packet Publishing Ltd.
[3] Open Networking Foundation. (2012). Software-defined networking the new
norm for networks, 2-3 [Electronic version]. Retrieved May 7, 2017, from
https://www.opennetworking.org/images/stories/downloads/sdn-resources/white-
papers/wp-sdn-newnorm.pdf.
[4] Caraguay, A., Lopez, L., & Villalba, L. (2014). Evolution and Challenges of Software
Defined Networking.
[5] Kreutz, D., Ramos, F., Verissimo, P., Rothenberg, C., Azodolmolky, S., & Uhlig, S.
Software-Defined Networking: A Comprehensive Survey, 47-60.
104
7. Ethics
If your research involves other people, privacy or controversial research there may be
ethical issues to consider (please see the information on the module website). If the
answer below is YES then you need to complete a Research Ethics and Governance
Approval form (available on the website:
http://www.ethics.napier.ac.uk).
Does this project have any ethical or NO
governance issues related to working with,
studying or observing other people?
(YES/NO)
8. Confidentiality
If your research is being done in conjunction with an outside firm or organization,
there may be issues of confidentiality or intellectual property.
Does this project have any issues of NO
confidentiality or intellectual property?
(YES/NO)
9. Supervision timescale
Please indicate the mode of supervision that you are anticipating. If you expect to be
away from the university during the supervision period and may need remote
supervision please indicate.
Weekly meetings over 1 trimester Yes

Meetings every other week over 2 trimesters
Other
10. Submitting your proposal
105
Please save this file using your surname, e.g. macdonald_proposal.docx, and e-mail it
to your supervisor and second marker. Your second marker will provide feedback.
When you produce your dissertation, add your proposal as an appendix.
9 Appendix 2
106
107
108
109
110
111
112
113
114
115

Master Project SDN Haider Raza

Uploaded by

Copyright:

Available Formats

Master Project SDN Haider Raza

Uploaded by

Document Information

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Master Project SDN Haider Raza

Uploaded by

Copyright:

Available Formats

Is SDN a Viable Solution to Traditional Networking Architecture Benefits, Challenges, and Existing Solutions

Syed Haider Raza - 40224242 – MSc in Advanced Networking

Is SDN a Viable Solution to Traditional

SYED HAIDER RAZA

Supervisor: Dr. Imed Romdhani

Submitted in partial fulfillment of the requirements of

Type name: Syed Haider Raza

Data Protection Declaration

The University may not make this dissertation available to others.

2 Theoretical Background …………………….……………………………………….……….16

3.1.5 Enhancing Performance…………………….……………………………………….38

4 SDN challenges and Existing Solution…………………….…………………………..….47

6 Evaluation and Discussion…………………….……………………………………….…….80

Additional thanks go to Esam for being my second marker

1.1 Problem and Context

Some of the Recent researchers including (Future Internet Research, Global

 To investigate what is Software Defined Networking and how it contributes

 Does migration to SDN becomes necessary from present network

Project aims will be accomplished by completing the following objectives.

 To achieve the first, aim a comprehensive literature review is required in

 To achieve the third aim, it is necessary to highlight the challenges of SDN

1.4 Thesis Outline

This study is structured as follows:

 Chapter 2 comprised of the theoretical introduction and background of

 Chapter 3 revolves around the benefits of SDN to traditional networks and

 Chapter 4 deals with challenges/barriers of SDN and for each challenge,

 Chapter 5 provides the Research Methodology for conducting the survey is

 Chapter 6 is composed of evaluation of sub research questions in the light of

1.5 Literature Review

2.1.1 Early programmable Networks

Figure 2.1 – Early Programmable Networks

2.1.1.1 OPEN SIGNALING

2.1.1.3 Active Networks

Figure 2.2 – DCAN Design

Figure 2.3 – 4D Architecture

Figure 2.4 – ForCES Architecture

Figure 2.5 – Ethane Architecture

2.2 Software Defined Networking

2.2.1 Tier Architecture

Figure 2.6 – Software Defined Architecture

In this design, every tier has its explicit functionalities

1. In three-layer architecture application layer allows the administrator and

2. The control layer is the hub of “network intelligence”, Author Kreutz et al

3. The infrastructure layer basic functionality is packet forwarding. Through

2.2.2 Comparison of Conventional and SDN Switch

Figure 2.7 – Classical Switch design

Figure 2.8 – SDN Switch Design

Grou Product Type Versio Maker Brief description

Pica8 3920 Switch V1.0 Pic8 Hybrid Ethernet/Open Flow Switch.

2.3 Open Flow Protocol

Figure 2.9 – Open Flow Framework

2.3.1 Open Flow Evolution

Figure 2.10 – Open Flow timeline

Versions Features Reasons Use Cases

Multiple Table To avoid Flow Entry

1.1 - 1.2 OXM Match Improve Matching

Multiple Controller Failover

Meter Table QoS with Diff Services

Synchronized Improve Table Scalability MAC learning and

Bundle/Atomi Improve Switch Multi Switch