Networking Project: Comparing OpenDaylight and Floodlight Controllers

This project analyzes Software Defined Network (SDN) controllers, specifically comparing OpenDaylight and Floodlight. The report investigates the architecture, efficiency, and features of these controllers, evaluating their performance based on factors like delay, loss, and network loads. The study utilizes Mininet to simulate network environments and assess Quality of Service (QoS) parameters. The findings indicate that OpenDaylight excels under lighter network loads, while Floodlight's performance improves with increased load, particularly concerning latency and packet loss. The project also reviews existing literature on SDN and controllers, and the report concludes with a discussion of the project's outcomes, including the identification of suitable controllers for various network scenarios. This research aims to provide insights for resolving data sharing challenges through network infrastructure and promoting the automation of network functions to propose cost-effective network solutions.

Running head: NETWORKING PROJECT
Networking Project
Name of the Student
Name of the University
Author’s Note

1
NETWORKING PROJECT
Abstract
Software Defined Network is considered as a network architecture and controller is one of the
intelligent part of the network. The controllers are of different types such as Floodlight,
OpenDaylight, POX, NOX, Maestro, etc. The performance of the OpenDaylight and Floodlight
controller is evaluated based on the situation it can be applied and given in the report. The
efficiency, architecture and the features of the controllers are evaluated for comparing the
controllers with each other. The two controllers that are popular in the Software Defined
Network architecture is compared based on delay, loss and network loads for choosing the best
controller. The results of the comparison shows that the performance of the OpenDay light is
better than the Flood Light when there is less load on the network but the but the performance of
the Flood light improves with the increase in load in the network based on latency and packet
loss. In the other cases no significant differences are found in Floodlight and Openlight
controllers. The report is developed for resolving the different problems with sharing of large
volume of data using a network infrastructure. An analysis is made on the Software Defined
Network for the configuration of large computer networks and enabling a centralized control on
the network. The layers of the SDN i.e. Application, control and infrastructure is evaluated for
management and operation of the server and managing the request from different users. Different
articles are reviewed for getting the idea about the software defined network and its role in
reducing complexity of the network and discussed in the report. The support of SDN for
automation of the network function is evaluated and a cost effective network solution is proposed
that would support the distributed environment and allow sharing of data between different hosts
located in diverse geographical location. The software defined network can be created easily and

2
NETWORKING PROJECT
it can help in creating new possibility for the organization with the standardization of different
activities.
Table of Contents
Introduction......................................................................................................................................3
Literature Review............................................................................................................................6
Project Methodology.....................................................................................................................12
Outcomes.......................................................................................................................................19
Discussion......................................................................................................................................35
Conclusion.....................................................................................................................................41
Reflection.......................................................................................................................................42
References......................................................................................................................................44

3
NETWORKING PROJECT
Introduction
There are different problems faced by the users while using the traditional network and
thus the programmable network was introduced such that the problems can be resolved easily
and the network can be evolved to the next level. The software defined network thus created a
revolution for the traditional network design and facilitate control of large device, topologies,
services, policies, traffic paths and APIs of the network. Software defined network is a
technology used for separating the control plane from the data plane of a network and forwarding
the network traffic (Truong, Lee & Ghamri-Doudane, 2015). It is used for enforcing
management based on network hardware and use of policy based management for the network.
The statistically defined network complexity can be reduced with the implementation of SDN
and thus help in automating the network functionality and use simpler provisioning and
managing the resources from different areas of the network. SDN can be used for supporting the
remote access and edge computing and helps in distribution of computing power to remote PCs
and moving the data center (Farhady, Lee & Nakao, 2015). The network can be complex or
dynamic and their management and configuration is a difficult task. The network can consist of
wide range of hardware devices such as firewall, switch, router, Access point, etc. It is the
responsibility of the network operator to configure the network hardware such that high level
network policy can be implemented in the system respond against different events such as
intrusion, load balancing, etc. For the application of the high level network policy in the network
device it is important to distribute them with the configuration. The network developed now a
days does not have any mechanism for automatically responding against different events that can
occur in the network (Baktir, Ozgovde & Ersoy, 2017). The network operators are responsible
for the implementation of complex and sophisticated policy with the combination of low level

4
NETWORKING PROJECT
configuration for the devices using the CLI environment of the network device. The report
provides an in-depth analysis of the network problems and the technology that can be applied for
eliminating the problems. Configure and different mechanism of management can be applied in
the network for its improvement of the network and enable changes in the network, supporting
the configuration of network and providing centralized control and visibility of the network for
troubleshooting the issues (Cui, Yu & Yan, 2016). The implementation of the technologies help
in application of wide network policy in the network and identify the source of the error in the
network easily. We have created prototype of the software defined network for the demonstration
of its functionality and improve the network management. With the application of the software
defined network the maintenance cost of the network can be reduced and the network can be
secured from the external agents (Blenk et al., 2015). Different research paper on the software
defined network is evaluated for the creation of the report and identify the different areas the
technology can be applied.
The intelligent part of the network is the controller and the data plane works under the
instruction of the controller plane. There are two other components i.e. the southbound and the
northbound interfaces where the southbound interface is used for connecting the data plane
(switches) with the controller and the north bound interface is used for offering APIs to the
services and controlling the network (Wang et al., 2015). Open flow protocol can be
implemented to the southbound interface that helps in remote controlling the routers, access
points and switches. There are other protocols that is developed on the working principle of
OpenFlow protocol for example POX, NOX, OpenDaylight, Floodlight and Beacon. The
selection of the best controller is a complex task for the researcher and the network administrator
(Arslan, Sundaresan & Rangarajan, 2015). There are different existing researches that can be

5
NETWORKING PROJECT
used for comparing the architecture of the controllers and its efficiency such as availability and
scalability. The feature parameters are also evaluated based on productivity, supported platform,
interface and language. The paper is created for comparing the protocols such as OpenDaylight
and Floodlight with the application of Mininet in SDN emulator based on QoS parameter such as
loss and delay in the network (Yan et al., 2015). The report is prepared for the comparison of
four OpenFlow network controlling that includes Beacon, Maestro, NOX and Floodlight on the
basis of architecture for a machine that have shared memory and multiple core. The main factors
causing the bottleneck for the system includes support of multiple core, partitioning of the
network including switch, task and packet batching. The design of the architecture contains a
static batching and switch partition that can be applied in Beacon, Floodlight and NOX and
application of adaptive and static queue batching in maestro (Tang et al., 2016). The results
evaluation of the performance displays that the design of the network with packet batching and
static switch partitioning provides the best performance for the controllers for a network having
high throughput. For the application that are sensitive to delay such as VOIP the packet and task
batching designs can be applied. The control messages are sent individually for the improvement
of the latency and performance of the network. The results are evaluated for proposing the
controller that have the best performance compared with the other available controllers (Haque
& Abu-Ghazaleh, 2016). There are other controllers also such as Floodlight and OpenDaylight
are compared with each other. The selection of the controller is a Multi Criteria Decision Making
problem because there are several properties present in the controller that are needed to be
considered for selecting it. For reaching the decision analytical hierarchical process can be
applied for getting prioritization based on pairs and applying integrated consistency mechanism.
The available interface, GUI, virtual switch support, REST API support and productivity

6
NETWORKING PROJECT
condition is used for the comparison of OpenDaylight and Floodlight (Akyildiz, Wang & Lin,
2015). From the result of the comparison it has been found that for the priority vector case Ryu
achieves the best value and OpenDaylight, Floodlight, Pox and Trema has the result next to Ryu
(Yan & Yu, 2015). The floodlight and the OpenDaylight have the clos result and can be used as
replacement of Ryu.
Literature Review
There are many works of different authors who have compared the SDN controllers and
used Floodlight ad OpenDaylight for the comparison with achieving similar result. The
controllers are applied in different fields such as cloud computing, multimedia, QoS for
measuring their performance. The performance of the controllers are analyzed based on the
parameters of QoS with the use of Mininet (Wood et al., 2015). The OpenDaylight and
Floodlight is reviewed in this section providing a short introduction of both the controllers.
The floodlight controller is based on Beacon controller developed from Stanford
University and works with the combination of virtual and physical OpenFlow switch. The
controller have some unique feature like apache license, modular, asynchronous framework for
application, event driven, java based and utilization of synchronized lock. The management of
topology is important for the controller and can be applied for the discovery of openflow and non
openflow endpoint. The device management is also important and it includes tracking of IP and
MAC address, computation of best path, developing web access infrastructure, storage of
counter, big data and quantum for interoperating the different agents for providing support to
OpeFlow (Rawat & Reddy, 2016). The components of the Floodlight are loadable services and
the service provider acts as core module for handling the input and output that are received and
send to switch. The module can also be used for translating OpenFlow message in floodlight

7
NETWORKING PROJECT
event. In the controller there are REST APIs that can be used to get and set the state of
controller, notification system of an event, pass that emits Java event (Hakiri et al., 2015). There
are also different sample of application containing learning hub, switch application and pusher,
load balancing and firewall.
The OpenDaylight project was formed in the year 2013 by the Linux foundation and the
project is concerned with creation of a de facto northbound API standard for the management of
the south bound protocols for example OpenFlow, 12RS, NETCONF and its programming. The
controller have different features such as Java based, support multiple protocol and plugin and
modularity. It also has the support of programming of OSGI and REST bidirectional protocol
that provides the support of running different application in the same space of address in the
controller (Zhou et al., 2016). The requests from internal and external sources are mapped using
the service abstraction layer for providing plugin for the southbound and building upon the basic
level of service abstraction for getting higher service levels. The capability of the plugin is
important for providing service to the features. There are other built in services that are offered
by OpenDaylight such as discovery and abstraction of topology, NETCONF, 12RS, OpenFlow
(Wickboldt et al., 2015). The following table is used for comparing each of the two protocols.

8
NETWORKING PROJECT
With the use of Mininet a virtual network is created and Software define network is
implemented in it. The Mininet team uses it for running the controllers, hosts and switches in the
virtual environment for a single computer. The default network created using Mininet have a
OpenFlow switch and it connects with an OpenFlow controller and two hosts (Bertaux et al.,
2015). The hosts connected in the Mininet would be able to run commands of different file
system in Linux, e.g. ipref command can be used for getting the details of bandwidth
consumption between server and client, topo command can be used for creating topologies with
python API and creating customized virtual network. There are different common predefined
network topologies created in Mininet and can be termed as single topology, linear topology and
tree topology (Ali et al., 2015). In the single topology three hosts named H1, H2 and H3 are
connected with a switch S1, in the linear topology the hosts are connected with separate switch
S1, S2 and S3 and each of the switch are connected using serial connection. In the tree topology
a switch S1 is connected with two switch S2 and S5. The switch S2 is connected with S3 and S4

9
NETWORKING PROJECT
in parallel and the host H1 and H2 are connected with S3, H3 and H4 is connected to switch S4.
The switch S6 and S7 is connected to switch S5 and H5 and H6 is connected with S6 and host
H7 and H8 is connected with switch S7.
Feature Floodlight OpenDaylight
Supporters Big switch network Linux foundation
Developer Big switch network HP, Juniper, IBM, VMWare,
Cisco, etc.
Written Language Java Java
REST API Yes Yes
Supporting language Python, Java and any
language that support Rest
API
Java
OpenStack Networking Yes Yes
OpenSource Yes Yes
TLS supporting Yes Yes
OF version 1.0 and 1.3 fully supported
and OpenFlow 1.1 and 1.2 is
experimentally supported
1.0, 1.3 is fully supported
User Interface Java, web Web
Interfaces OpenFlow (southbound),
Java, Rest (northbound)
SB protocol, OpenFlow
(southbound), REST, java
RPC (northbound)
Virtualization Open V switch and Mininet Open V switch and Mininet

10
NETWORKING PROJECT
Platform Windows, Linux and Mac Windows and Linux
Age 4 yrs 3 yrs
Active community Yes Yes
Documentation Good - Existence of
documentation in official
webpage and other sites
Medium – Existence of
documentation in official
website
Mailing list activity Very high Medium
Installation Very easy Easy
Handling mixed non-
OpenFlow and OpenFlow
network
Yes Yes
Loop supporting Topologies OF island and topologies
(Table 1: Features of OpenDaylight and Floodlight)
For the evaluation of the performance Ubuntu 14.0.4 having 4 Gb of available RAM is
used and it is installed with the network instances.
Form the research it has been identified that with the application of software defined
networking the network management can be improved. The management of distributed network
is a challenge for the network administrator and for the operation of a network securely the
network operator needs to implement high level network policies (Katta et al., 2015). There are
different solutions available for the management of the network and eliminate the gaps in the

11
NETWORKING PROJECT
network. The application of SDN helps in introduction of new possibility for the configuration
and management of network. Different articles are reviewed for identification of the problems in
network management based on frequently changing the state and condition of the network,
supporting the network hardware device configuration and getting high level visibility of the
network for troubleshooting and diagnosing the network problem (Duan & Wang, 2015). As a
network controller Procera can be used since it follows the rules of software defined networking
for forwarding the data traffic and updating the low level network routing tables based on the
network policy. The network policy is translated by the network controller such that actual
packet forwarding can be done to the different network devices. The controller helps in
establishment of a connection with the switch capable of OpenFlow protocol with the application
of OpenFlow protocol (Karakus & Durresi, 2017). The network controller helps in insertion,
deletion and modification of the packet forwarding rules in the network switch with the help of
the connection. The packet in and switch join event is used by the controller for taking the packet
forwarding decision. Procera is used as a control framework of the network for expressing the
network policies and reacting against different network policies with the help of functional
programming languages. The Procera can act as an intermediate bond between the network
configurations and the network policies. For expressing the network policies that are event
driven a control domain is set is offered by procera that helps in setting certain conditions and
assigning appropriate actions to forward the packets based on the conditions (Dong et al., 2015).
The application of additional control domain can increase the flexibility of the network operator
and development of a reactive policy for the network. The network operator can also integrate
the control domains such that the quality of the network policy can be improved and automate
some of the operations of the network eliminating the need to rely on event triggered scripts that

12
NETWORKING PROJECT
can generate errors. The control domain Procera supports time, data usage, status and flow of
network traffic (Yang et al., 2015). There are different event sources that are used as a network
component for sending the dynamic events to the controller of Procera. The intrusion detection
system, authentication system and bandwidth monitoring for the network can be used as event
sources. The application of simple network management protocol in the procera can also be a
source of events. The fixed interface protocol between the sources of events and policy is not
defined and thus alternative methodology can be applied. The time control domain is used for the
management of network behavior that is dependent of date and time (Fontes et al., 2015). This
helps in managing the traffic differently while users are present at home since the load on the
network would be higher than the time when the user is not present at home. The data usage
controller is used for specifying the policy and management of the network behavior based on
the data usage amount. The status controller is used for specifying access privilege for different
groups of users and management of changes in the network due to different reasons. The
privilege of access for the network device varies according to the user currently accessing the
device (Rost et al., 2016). The network flow controller is used for specifying the network
behavior dependent on the filed values of the multiple layer of the network that are specified in
the data packet.
Project Methodology
The methodology to be used for the project of Software defined networking is divided
into four phases and are discussed below:
Defining a use case – SDN is used as a muti-faceted technology for finding that if it can
be integrated with the business organization based on the problems that are needed to be solved.
A narrow use case is needed to be identified that can be solved with the application for SDN.

13
NETWORKING PROJECT
This is the preliminary step for the application of SDN (Chen et al., 2015). The problems for
automating the network, agility or security is needed to be solved and the single use case can
help in offering reliability, measurable outcome for the implementation of SDN in an entire
network.
Assembling a cross functional team – For the implementation of SDN a team having
broad skill and well-rounded is needed to be developed. The efficiency of the team can help in
maximizing the benefits of the software defined networking. The network security issues can be
addressed with the application of software defined networking and for this network administrator
having skill of defining or writing security policy is needed to be hired (Sivaraman et al., 2015).
The IT resources are needed to be re grouped but it is a difficult task ad by separating the role
and responsibility it can be achievable and it is the only method for ensuring that SDN is
successfully completed. With defining the roles and responsibility the IT team members can
complete the operational overhead within less duration of time and give more time for enabling
IT infrastructure and engineering such that it meets the goals and objectives of the project (Chen
et al., 2016).
Testing in less complex network – The implementation of software defined networking
does not have the requirement of upgrading the network, it can lead to generate massive risk for
managing the unfamiliar network. During the testing of the limited use case the similar principles
are applied in testing the network. A less complex area is needed to be identified in the network
that can be used for working without affecting the whole network (Sood, Yu & Xiang, 2015).
The implementation of small scale software defined networking helps in testing the use cases
safely without the need the team members and network infrastructure.

14
NETWORKING PROJECT
Reviewing the test case – The SDN is needed to be used for a specific time duration and
enough data is needed to be gathered for the measurement of outcome against the goals of the
network. The effectiveness of the SDN is needed to be thoroughly reviewed such that it can be
used for solving the current problems, it can be used as a wise investment for the expansion of
SDN. The availability of the infrastructure for the maintenance of software across the platform is
needed for reviewing the SDN application (Chen et al., 2015). The performance, security, budget
and efficiency is needed to be evaluated for understanding the result of SDN.
Gaining maturity before the expansion of deployment – Even if the test result of the
SDN is working beyond expectation one final step is needed to be performed for managing the
expansion of the network. The project footprint is needed to be increased slowly such that the
maturity can be gained before expanding the network (Jararweh et al., 2015). There is a limited
scope for the application of SDN and in a smaller part of the network and the rest of the network
might not be ready for its application.
The QoS parameters for a network are given below:
 Latency – It is the delay or the amount of time taken by a packet for travelling along
network from source to destination address.
 Jitter – The latency variation Loss – The failed packet percentage for reaching the destination. The loss ration of the
packet is measure as: number of lost packet / number of sent packets.
 Throughput – The network ability for carrying data for a unit time.
For the analysis of the performance of the different SDN controllers an experimental
setup is created and shown in the following figure.

15
NETWORKING PROJECT
A PC that runs Mininet emulation program is used along with a virtual machine. The
software specification of the PC is tabulated below and the VM and PC are needed to be
connected with the internet with the Ethernet LAN cable.
VM PC
Hardware Processor 2 core Intel Core i7-6000u
RAM 4 GB 8 GB
Software OS Ubuntu 16.04 Ubuntu 18.04
Oracle VM Virtual
Box
6.0.12
MININET 2.3.0
POX 0.2.3
ODL 0.6.1
Floodlight 1.2
(Table 2: System Specifications)
The following topology is created in GNS3 for setting up the OpenFlow enabled network
running the Mininet and GNS3 devices.

16
NETWORKING PROJECT
The following is the screenshot of the OpenFlow switched and Nodes that are created
using HP VAN SDN controller
The following is the screenshot for the demonstration of details of switch with Address,
version, manufacturer, H/W version, S/w Version and serial

17
NETWORKING PROJECT
The following screenshot shows the configuration of hosts in the network
In the network innovation the software defined networking is the latest revolution and
components of network industry looks forward to the different aspects of SDN. There are four
innovation of SDN such as separating the data and the control planes, control plane
centralization, programming the control plane and standardizing the APIs (Foukas et al., 2017).
The application of the software defined networking can help in increasing the agility, automation

18
NETWORKING PROJECT
and security of the network and saving large money and time. The adoption of SDN is
overwhelming since it is a new technology ad there are few application.
Separating control and data plane – The protocols of the network are arranged in
management, control and data plane. The messages that are generated by the user are present in
the data plane. Some housekeeping works are needed to be done for transporting the messages
such as using layer 3 or layer 2 protocols for finding the shortest path such as OSPF and
spanning tree. The messages are also termed as control messages and is important for different
network operation (Ordonez-Lucena et al., 2017). For keeping track or monitoring the live
network statistics and management of different network devices is important. The logic of
control is needed to be separated and integrated with the controller for the development of the
forwarding table.
Centralization of control plane – The centralization of the network system can help in
improving the visibility and control of the network. Enforcement of a centralized management is
also a challenge for the management of the network. Managed service are needed to be
implemented such as security and compliance, faster troubleshooting, upgrades of hardware and
better visibility and management of the wireless network (Canini et al., 2015). The services
offered to the students are needed to be scalable and should be able to current needs of the users.
The increased number of users should not have any effect on the network and the network is
needed to provide best performance, reliability and security. The selection of the network device
is an important factor for delivering wifi signals to all the locations and increasing the reliability
of the wireless network (Liang, Yu & Zhang, 2015). The network can face scaling issues with
the application of distributed methodology but it can be achieved with by dividing the network
into subnet and enforcement of a common control strategy.

19
NETWORKING PROJECT
Programmable control plane – It is the most important part of the software defined
network and it helps in dividing the network into multiple virtualized system. Different network
policy is needed to be set for the virtualized network having shared infrastructure for the network
hardware.
Flow based control – There are six steps for troubleshooting they are identification of the
problem, establishment of a theory for the probable cause of the problem, the verification of the
theory for determination of the cause, planning of an action to resolve the problem, verification
of the system functionality thoroughly and lastly keeping track of the actions, findings and
outcomes (Nakao et al., 2017). The process of recognition of the source of an issue in a system is
referred to as troubleshooting. All sort of problems with the software, hardware and several other
systems can be fixed with the help of troubleshooting.
Outcomes
This project is regarding the Software Defined Network controllers which has been used
for the OpenDaylight and for the Floodlight. From this project a brief idea regarding the software
defined network has been gained. In this aspect it has been assessed that original SDN network
has actually proposed decoupling of the network controls from the packet forwarding and from
the direct type of programmability of the network control functions (Li et al., 2017). Within the
SDN controllers the network intelligence is centralized logically. Through this global view of the
network can be maintained. Through this way the network appears as policy and application
engines as a single and logical switch.
In this project the software defined network has been used for two different things which
are the OpenDaylight and the Floodlight. Regarding this various of things has been found from

20
NETWORKING PROJECT
this project. The OpenDaylight is currently an open source project and it is supported by Juniper,
Cisco, VMWare and IBM (Wang, Xu & Gu, 2015). There are some other networking vendors
also who are related with this open source project. From this project it has been assessed that
OpenDaylight is a SDN (Software Defined Network) platform which is implemented in java.
Thus, the OpenDaylight can be also deployed on any other types of OS and hardware platforms
which is supported by the Java.
From the research some important finding has been assessed in this context. For
performing the research Mininet networking simulation tool has been utilized in this case. By
using the Mininet simulation tool it is possible to test these SDN controller within a real time
scenario and the test can be performed considering various of metrics including variance,
throughput, round trip delap, latency and more. Through this all of the metrics can be also
calculated quite effectively. The Mininet testing tool is capable of creating straightforward type
of affordable network test bed for creation of the OpenFlow type of applications. In this way it
actually helps the developers to operate simultaneously and separately on similar type of
topology. Due to this factors Mininet has been used here for the simulation purposes.
Here the software defined network has been implemented in the Mininet and for that
some important steps has been followed in this report. In this case for arranging the environment
of testing first of all it is important to download the Mininet. Next, depending on the operating
system the Mininet need to be configured accordingly. In this case for the implementation
purpose Linux environment has been used and to configure the Mininet within Linux
environment some specific type of commands has been used here. In the following step of
configuration virtual network has been established within Mininet. After this in the
implementation phase arrangement for both of the OpenDaylight and the Floodlight has been

21
NETWORKING PROJECT
done. Both of the OpenDaylight and the Floodlight has been loaded in the virtual machine
offered by the Mininet. In this way implementation has been done in this project and the further
tests has been executed.
Here overall from this project basic architecture of the SDN or the software defined
network has been understood properly. It has been properly assessed that the basic architecture is
consisting three layers which are the application layer, infrastructure layer and control layer.
Here the research has found that infrastructure layer is consisting several of networking
equipment and it is having the capability of forwarding the network traffic. The control layer is
considered as the control plane land where intelligent logics present in SDN controllers would
present there controlling the infrastructure of the network. The application layer is the open area
here, where development of the application will be done. Application layer and the control layer
communicates through northbound interface and control layer and the infrastructure layer
communicates through southbound interface.
This project has also analyzed OpenDaylight and the Floodlight SDN controllers. Within
this project efficiency of the OpenDaylight and the Floodlight SDN controllers has been also
assessed and for that some benchmarking tools has been used CBench, HCprobe and WCBench.
Ideal scenario for the data transfer purpose has been also created in this project and for that
Mininet simulation network has been utilized in this case project.
Tools License User
Interface
Availabilit
y
Advantages Limitations
OFNet Open
Source
GUI On Request Traffic generator
and self-defined
Dependent on
topology

22
NETWORKING PROJECT
topology
PktBlaste
r
Open
Source
Web UI Yes Better accuracy
compared with
CBench and
customized type if
switch groups
Customized
topology not
available
CBench Open
Source
CLI Yes Platform
independent and
faster analysis of
execution
Length of flow is
limited.
(Table 3: Benchmark Tool Comparison)
In this project brief analysis of the OpenDaylight has been done from there it has been
assessed that OpenDaylight SDN controller is having several of layers (Akhunzada et al., 2015).
The top layer of the OpenDaylight is consisting network and business logic applications. Middle
layer of the OpenDaylight is consisting framework layer and the bottom layer is consisting the
virtual and the physical devices.
Name Archit
ecture
Progra
mming
Langua
ge
Supp
orted
Platfo
rm
Inter
face
Docume
ntation
Consis
tency
Modu
larity
Lice
nse
Multithr
eading
Floodli Central Java Wind Web Good Yes Fair Apa Yes

23
NETWORKING PROJECT
ght ized ows
Linux
,
MacO
S
UI,
CLI
che
2.0
OpenD
aylight
Distrib
uted
Flat
Java Linux
,
MacO
S,
Wind
ows
Web
UI,
CLI
Good Yes High EPL
1.0
Yes
(Table 4: Feature Comparison Table of SDN Controller)
From this research it has been also assessed that OpenDaylight is formed in relation with
an objective for reducing vendor. In this way it locks therefore for supporting protocols rather
than OpenFlow. For the OpenDaylight the interface at the southbound is can support multiple
types of protocols which includes BGP-LS and OpenFlow (Sharma, Chen & Park, 2017). Both
of them are used as a separate plugins. This research has also determined that the SAL is capable
of determining how the requested services can be full filled irrespective of the protocols that are
underlying and utilized among network devices and controller.
From the outcome of the project it has been also assessed the main architecture of the
OpenDaylight is the Model Driven Service Abstraction Layer which is also known as MD-SAL.
The MD-SAL is also considered as the core of the OpenDaylight (Su et al., 2015). Within the

24
NETWORKING PROJECT
OpenDaylight the network devices which are underlying and all the applications for the network
are represented as the models or the objects of which interactions are processed within the SAL.
For the OpenDaylight the SAL is actually data adaption and data exchange mechanism among
the YANG models (Sama et al., 2015). Through this network applications and devices can be
represented. The YANG models are capable of providing generalized type of descriptions of an
application or a device without required to know specific type of implementation details of the
others (Liu et al., 2015). Rather than from the perspective of SAL models are defined very much
simple way by respective roles of them within a given interaction. In this aspect it has been also
determined that protocol plugins and the models that are associated with this can be a producer
of the information regarding network which is currently underlying. All the instructions
regarding it are received through the SAL.
Specification
of Testbed
Evaluated
Controller
Used
Evaluation
Tool
Evaluation
Metrics
Lessons
Learned
Optimization
Objectives
5 × Server
with Core i5
CPU
OpenDaylight
and
Floodlight
CBench Failure,
Latency,
Throughput
Memory
leakage can
be suffered
by controllers
Not Specified
Quad-Core
Xeon Server
POX, NOX,
Floodlight,
Beacon
Open
vSwitch,
CBench
Throughput,
Threading,
Latency
Performance
improvement
offered by
HT for
controllers
Hyper-
Threading,
Python
Interpreter

25
NETWORKING PROJECT
based on
java.
Separate
Xeon
Servers 8
Gbps Link
Speed
Beacon,
Floodlight,
Maestro
CBench Scalability,
Latency,
Throughput,
Delay
Sensitivity
Throughput
is impacted
by switch
batching and
switch
partitioning
Packet
Batching,
Switch
Partitioning,
Task Batching
Dual Core
Virtual
Testbed
ONOS,
OpenDaylight
HTTP
Generator,
Open
vSwitch,
Cluster
Testbed,
REST Client
Flow
Reading
Rate, Flow
Installation
Rate
Cluster size
impacts
installation
rate flow.
Customization
of controllers
is done for the
WAN
environment
(Table 5: Benchmark Studies Analysis)
In this project it has been also determined that for the OpenDaylight the SAL framework
is capable of matching consumers and the producers from the data stored by them and it is also
capable of exchanging the information. In this way this framework can help a consumer to find a
provider that is currently interested (Liu et al., 2015). In this aspect the producer is capable of
generating the notifications while the consumers are capable of receiving the notifications. The
consumers are also capable of issuing the RPCs so that they can get the data from the providers.

26
NETWORKING PROJECT
It has been assessed that a producer is capable of inserting the data into the storage system of
SAL while the consumer is able to read all the data currently available at the storage of the SAL.
The platform of OpenDaylight is designed in some specific way that it allows the solution
providers and downstream users extreme flexibility so that they are able to build a controller
fitting their needs. The modular design of the OpenDaylight is responsible for that. This design
of the OpenDaylight allows any of the users within the OpenDaylight ecosystem for leveraging
the services which created by some others (Zheng et al., 2016). This design of the OpenDaylight
also allows the OpenDaylight ecosystem users to write and incorporate by their own. The
OpenDaylight also supports broadest protocol sets in any type of SDN platform including
OVSDB, OpenFlow, BGP and others. It is capable of improving the programmability of the
modern networks and in this way it can help to solve the needs of various of users.
Measurable Metrics Benchmarking
Tools
Description
Groups Parameters OF
Net
PktBl
aster
CBe
nch
Flow
Related
Flow Installation Time ✓ ✓ ✓ Controller efficiency is
determined for installing
flows.
Path Provision Time ✓ ✓ ✕
Load Balancing ✕ ❍ ✕
Flow Reading Rate ❍ ✕ ✕
Threading I/O Impact ✕ ✓ ✓ Utilization efficiency of
controller is determinedvSwitch CPU
Utilization
✓ ✕ ✕
Thread Capability ✓ ✓ ✓

27
NETWORKING PROJECT
Control Session
Capability
✕ ❍ ✕
Latency Round Trip Time ✓ ❍ ✕ Delay time is calculated
from the vSwitch and
response received back
Sync Message
Processing Time
✓ ✓ ✓
Async Message
Processing Time
✓ ✓ ✓
Throughput Sync Message
Processing Rate
❍ ✓ ✓ Flow request number is
determined
Async Message
Processing Rate
❍ ✓ ✓
Send and Response
Rate
✓ ❍ ✕
Topology Topology Change Time ✓ ✓ ✕ Capability of discovering
topology is determinedTopology Discovery
Time/Size
✓ ✓ ✕
Others Network Re-
provisioning Time
✕ ✕ ✕ Miscellaneous types of
parameters is measured
Ping Delay Time ✕ ✕ ✕
Controller Failover
Time
✕ ❍ ✕
Forwarding Table ✕ ✓ ✕

28
NETWORKING PROJECT
Capacity
(Table 6: Benchmark Metrics and Tool Metrics)
Latency with no cross traffic (Low load on the network <=1000bytes)
Single Linear Tree
Min (ms) Floodlight 0.079 0.221 0.077
OpenDaylight 0.078 0.221 0.116
Max (ms) Floodlight 9.593 78.808 9.767
OpenDaylight 1.824 11.848 2.078
Average (ms) Floodlight 0.476 3.279 0.545
OpenDaylight 0.188 0.749 0.254
0.278,0.298 1.83,3.22 0.219,0.363CI of Averages Difference
Latency when there is half of bandwidth cross traffic (medium load on the network <=5000
bytes)
Single Linear Tree
Min (ms) Floodlight 0.409 1.8 2.244
OpenDaylight 0.418 2.013 0.577
Max (ms) Floodlight 15.142 302.562 134.093
OpenDaylight 10.99 253.266 17.107
Average (ms) Floodlight 2.31 52.778 16.38
OpenDaylight 2.019 45.831 3.656
(-0.393,0.975) (-3.246,17.139) 10.124,15.32CI of Averages Difference
Latency when there is full bandwidth cross traffic (high load on the network <= 100000 bytes)
Single Linear Tree
Min (ms) Floodlight 1171.316 1143.583 1065.705
OpenDaylight 1165.575 1159.357 1205.207
Max (ms) Floodlight 1357.046 1488.846 1634.719
OpenDaylight 1450.293 1995.651 1235.842
Average (ms) Floodlight 1232.739 1306.647 1235.627
OpenDaylight 1213.287 1623.714 1212.662
(-7.802,46.706) (-409.314,-224.793) (-16.609,62.539)CI of Averages Difference

29
NETWORKING PROJECT
Average loss of measurement for high network load
Single Linear Tree
Floodlight 41.6 41.3 34.4
OpenDaylight 15.8 32.4 47.2
(15.659,35.941) (-5.397,23.197) (-25.349,-0.251)CI of Averages Difference
Best controller for different situation
Latency Loss (high load network)
Single Low Load OpenDaylight OpenDaylight
Mid Load Same
Heavy Load Same
Linear Low Load OpenDaylight Same
Mid Load Same
Heavy Load Floodlight
Tree Low Load OpenDaylight Floodlight
Mid Load OpenDaylight
Heavy Load Same
Throughput 1000 bytes
Single Linear Tree
Min (Mb/sec) Floodlight 101.2658228 36.1991 103.8961
OpenDaylight 102.5641026 36.1991 68.96552
Max (Mb/sec) Floodlight 0.833941416 0.101513 0.819085
OpenDaylight 4.385964912 2.439768 3.849856
Average (Mb/sec) Floodlight 16.80672269 10.68091 14.6789
OpenDaylight 42.55319149 10.68091 31.49606
Throughput 5000 bytes

30
NETWORKING PROJECT
Single Linear Tree
Min (Mb/sec) Floodlight 97.799511 22.22222 17.82531
OpenDaylight 95.6937799 19.87084 69.32409
Max (Mb/sec) Floodlight 2.641658962 0.132204 0.2983
OpenDaylight 3.639672429 0.757892 2.338224
Average (Mb/sec) Floodlight 17.31601732 0.872772 2.442002
OpenDaylight 19.81178801 0.872772 10.94092
Throughput 10000 bytes
Single Linear Tree
Min (Mb/sec) Floodlight 0.068299246 0.069956 0.075068
OpenDaylight 0.068635652 0.502017 0.066379
Max (Mb/sec) Floodlight 0.058951576 0.053733 0.048938
OpenDaylight 0.055161267 0.061225 0.064733
Average (Mb/sec) Floodlight 0.064896138 0.04927 0.064744
OpenDaylight 0.065936584 0.04927 0.065971
The OpenDaylight can be considered as primary place for the testing and developments
of different types of approaches to policy and the intent which includes group based policy,
ALTO and network intent composition (Li, Meng & Kwok, 2016). There are several of
advantages of using the modular type of framework. The modular framework is capable of
installing the protocols and services which are required, is capable of combining multiple type of
protocols and services for solving the complex problems, and it also assists the developers to
develop custom type of value added features quickly for some of the highly specialized uses
cases.
The project has also identified that security is very much important for the OpenDaylight.
Here, this platform is capable of providing an authentication framework, accounting framework
and the authorization framework (Aydeger et al., 2016). The OpenDaylight is having a major
advantage from the security perspective due to the reason that it is open source in nature. Thus,

31
NETWORKING PROJECT
in this way any type of security issues within the OpenDaylight can be addressed very much
easily.
With the OpenDaylight, Floodlight has been also discussed in this case. From this project
is has been assessed that Floodlight controller is a type of SDN controller that has been
developed by open community developers (Li & Chen, 2015). Here, most of them are the Big
Switch Network and it uses the OpenFlow protocol. In this way traffic flow can be orchestrated
within the software defined networking environment.
In this aspect the importance of SDN controller has been assessed. It has been determined
that the software defined networking controller is currently taking the responsibility of
maintaining all of the network related rules. With that it also provides important instructions to
the infrastructure that is currently underlying regarding how the traffics can be handled (Chen &
Hao, 2018). In this way the SDN helps the businesses to adapt the changes in much more better
way and with that it also provides a better control over the network. The Floodlight controller
originally offered by the Big Switch which is the part of the OpenDaylight project. Currently,
this Floodlight controller is an open source project in nature.
In this report a proper architecture for the Floodlight has been also elaborated. For
describing the architecture of the Floodlight the term modular architecture can be used in this
context (Hong et al., 2015). The core architecture of the Floodlight is consisting various types of
modules. These modules include end station management, topology management, web access
infrastructure, route computation and stating the storage system.
In this aspect it has been also assessed that Floodlight currently uses some of the
application which currently uses exposed rest APIs. The rest APIs are used by the Floodlight so

32
NETWORKING PROJECT
that a path can be established between any of two IP addressable devices (Porras et al., 2015).
This is done by adding the flow entries among all the switches that is present within the path.
Also, it has been assessed that Floodlight can be utilized run as the network backend for
openstack and for that neutron plugin is used.
The Floodlight also includes various of applications within the distribution of it. These
applications are very much useful for the developers for understanding usage of the API for
development of the SDN applications. It is very much applicable for all types of SDN controllers
including the Floodlight also (Wan et al., 2016). The project has defined that there is a
forwarding application which is capable of forwarding the packets among any of the two devices
which might be connected through OpenFlow type of switches. In this case the static flow entry
pusher mainly adds a proper type of OpenFlow entry within any of the specified switches. For
that flow mode message of the OpenFlow is utilized. In the Floodlight there is a firewall
applications also which is capable of applying the ACL rules. These rules are actually some
conditions set for control of the traffic depending on several of polices.
The main mechanism of the Floodlight includes the RestAPI server and this includes the
Restlets library. With consisting the restlets, any of the module that has been developed is
capable enough to expose the REST APIs through the IRestAPI service (Alsmadi & Xu, 2015).
This modules actually depends on the REST server. In this aspect the REST API is the
recommended interface for development of applications using the features supported by the
Floodlight. While the Floodlight is functional and running with the normal procedures, it is
capable of using the APIs that are supported within the controller.
End to End Throughput Value for OpenDaylight

33
NETWORKING PROJECT
End to End throughput value for Floodlight
From this project various of services offered by the Floodlight has been also assessed.
Currently there are different types of services offered by the Floodlight and one of the important
one in this case is the Floodlight provider service. The service of the Floodlight provider is very
much important in this case as it capable of managing a secure type of connection for the
available switches (Liu et al., 2016). This service is capable of translating the OpenFlow
messages into some event. Order of the received messages is also ensured by Floodlight
provider. Here, the link discovery manager is also crucial. The link discovery manager is
important due to the reason that for the detection of the links it utilizes the LLDPs. In such of the
cases where link is established among two switches, the LLDP is sent out of a single port of a
switch (Goransson, Black & Culver, 2016). The LLDP which is sent out in this case is received
on the other port of the other switch. Topology services is also offered by the Floodlight and this

34
NETWORKING PROJECT
topology services are useful for computation of the topologies which is dependent on the link
information from the link discovery manager. With the topology services device manager
services is also important in this case. From this project it has been found that the device
manager service of FloodLight is capable of tracking the devices. For the tracking purposes it
uses packetin requests instead of packetin information. The packet streamer service of the
FloodLight is has been also assessed in this report (Leng et al., 2015). The packet streamer is
capable of forwarding the OpenFlow packets to the any of the connected device in the network
which is specifically used for the monitoring purposes. The packet streamer also provides a
specific type of interface for specifying the OpenFlow messages which are interested in nature.
This are also known as the filter. For this reasons, from this project it has been also founded that
OpenFlow based FloodLight controller is consisting a rich set of modules. In this aspect each of
the module is capable of providing services which can be accessed by the use of REST API or a
simple Java API.
Discussion
From the above section several of important things has been noticed. In this aspect a
proper literature has been done on both of the OpenDaylight controller and the Floodlight
controller. In this aspect various of studies has assessed that both of the OpenDaylight and the
Floodlight has been compared with each other for achieving a same type of results. In this aspect
it has been assessed that the current Floodlight controller is based on the Beacon controller
(Abdelwahab et al., 2016). This Floodlight controller is having many unique type of features.
The Floodlight currently uses the REST API for setting the state of the controller and performing
various of other things. Other than the Floodlight, the OpenDaylight project formed in the year
of 2013 and it was initiated by the Linux foundation.

35
NETWORKING PROJECT
In this aspect the first section of this report has discussed about the software defined
network or the SDN. From this part it has been assessed that in the traditional type of networks
there are several kind of problems and to this reasons the programmable type of network has
been implemented (Kobo, Abu-Mahfouz & Hancke, 2017). Here focus has been given on the
programmable type of networks as in this type of networks the existing problem of traditional
type of program can be solved easily. With that there are several of other importance due to
which the programmable type of networks has been introduced and here the software defined
network created a revolution in the within the traditional type of network system (Scott-
Hayward, Natarajan & Sezer, 2015). Thus, this section of the report has discussed a brief about
the SDN or the software defined network. The discussion that has been made regarding the SDN
is quite important in this case for creating the base of this report. This section has deal with the
importance of the SDN in the present situations. Due to this reason the initial section of this
report is quite vital and holding a greater importance towards this project.
Following section of this reports has performed a literature survey. This section of this
report is currently crucial and currently consisting a greater importance towards the whole
project. In the section of literature studies simple summary of the key sources has been done
(Olivier, Carlos & Florent, 2015). This summaries are actually consisting some of the important
benefits for the project. Through the literature new interpretation of the old materials can be done
or the new can be combined with the old types of interpretation. In this section by performing the
literature review, literature gaps has been identified and how the problems has been researched
till the date has been analyzed (Jin et al., 2015). Due to this fact, the section of the literature
review is important here and it has provided some crucial importance to the project. Through the
literature review section contribution of each of the studies has been identified and the problem

36
NETWORKING PROJECT
regarding the research has been studied (Foukas et al., 2016). With that, the literature review is
also having some other importance also towards this project. The literature review section has
successfully described the relationship of every to the others under some consideration. This
literature review section has also resolved the conflicts that which is contradicted with the old
studies and with that it has also identified need of some additional researches (He, Cao & Liu,
2016). Due to all of these reasons the literature review section here is having a greater
importance towards this project.
The following section of this report has discussed methodology used for the project. In
this aspect the methodology of the project also consists importance towards the project. In this
case the methodology of the project has aimed to structure, standardize and organize the methods
for the work need to be done for this project (Dhawan et al., 2015). In this case the works defines
the steps that need to be executed for successful completion of the project. Here the project
methodology section will be helping the project that proper focus on the project can be made. By
following the research methodology of the projects in a proper way learnings can be gained from
mistakes done previously which will be helping in a continuous type of improvements for this
project (Sun et al., 2015). Thus, in an overall perspective this project methodology will be
helping to make this project quite efficient which is the main significance of project
methodology towards the project.
Describing the outcome of the project is also important in this case. In this project it is
important that the outcome of the project is identified and the outcome is tracked. Tracking the
outcome of the project is actually a good practice as it properly ensures that the benefits of the
project that is currently executing are actual (De Oliveira, Gabriel & Margi, 2015). In this case
the outcome of the project is also crucial that is explains properly that how the benefits can be

37
NETWORKING PROJECT
identified in this case which mainly remains in the form of critical success factors. In this project
also, the outcome of the project has been tracked and has been mentioned. Thus, in this case the
outcome section of this projects will be ensuring that the execution of the project has become
successful or not and depending on that what need to be revised here (Tuncer et al., 2015). Thus,
the outcome section of this report is also having greater importance in this context.
Like the other projects this research is also having some important strengths and
limitations. Here, the main strength of this project is that it has identified the main and important
benefits of the software defined networks and why it is a perfect replacement of the traditional
type of networks (Zeng et al., 2016). In this context the main limitation of this project is that it is
vastly dependent on secondary type of data resources. Thus, this research is also depending on
the previous researchers and this is the main limitation for this project.
Test Setup and Round Trip Time for the Packet Flow
The experimental setup is prepared for performing the performance test and different
types of topologies are used for performing the test. The first test is done on the tree topology
with floodlight controller, followed by the second test with Tree topology and opendaylight
controller. The third and fourth test are also done on Mesh topology with Floodlight and
OpenDaylight controller respectively. 50 packets having size of 1000 bytes and 3000 bytes are
sent using the ping test from host H1 to H8 for the measurement of round trip time and the data
gathered is tabulated below:
Topology Controller RTT (packet
size 1000bytes)
RTT (packet
size 3000bytes)
Test1 Tree Floodlight 119 164

38
NETWORKING PROJECT
Test2 Tree ODL 124 136.2
Test3 Mesh Floodlight 34.2 45.1
Test4 Mesh ODL 40.2 53.6
(Table 7: Measurement of Round Trip Time and the Data)
The following graphs are generated from the table and showing a comparison between
the test results.
Floodlight ODL Floodlight ODL
Tree Tree Mesh Mesh
Test1 Test3 Test4
0
20
40
60
80
100
120
140
160
180
Test Comparison Graph
Series1 Series2
The following graph is created for tree topology showing the RTT of packet flow for
different controllers

39
NETWORKING PROJECT
RTT (packet size 1000bytes) RTT (packet size 3000bytes)
0
20
40
60
80
100
120
140
160
180
Tree Topology
Floodlight ODL
The following graph is created for Mesh topology showing the RTT of packet flow for
different controllers
RTT (packet size 1000bytes) RTT (packet size 3000bytes)
0
10
20
30
40
50
60
Mesh Topology
Floodlight ODL

40
NETWORKING PROJECT
Conclusion
From the above discussion it can be conclude that software defined network or the SDN
is very much important in the current situation considering its advantages over the traditional
type of network. This report comprises various areas of software defined network and it has been
discussed in this report. In this report first a brief literature has been provided regarding the
software defined network. This report has provided some extra focus on the software defined
network controller including the OpenDaylight and Floodlight. The literature section has
discussed important areas of the software defined network. The methodology that has been used
for this project is briefly discussed in the project methodology section of this report. This project
is also having some important outcome regarding the project and it has been briefly discussed
within this report section. Discussion has been also done regarding the project in this report. In
this aspect it has been assessed that framework layer, which is the middle layer can manifest the
SDN abstraction. Both of the south bound and the north bound APIs are hosted by this layer.
Here the controller is capable of exposing the northbound APIs which are utilized by the
applications. Currently, OpenDaylight is capable of supporting bidirectional REST and OSGi
framework for the APIs of northbound. Business logic is consisting within the application which
is actually above the middle layer. The applications utilizes controller for gathering network
intelligence, perform analytics by execution of the algorithms and utilizes the controller to
orchestrate the any type of new rules available and this is done throughout the network. From the
project it is learned that main architecture of the OpenDaylight is the Model Driven Service
Abstraction Layer which is also known as MD-SAL. This report has also described that
OpenDaylight the SAL framework is capable of matching consumers and the producers from the
data stored by them and it is also capable of exchanging the information. From this project the

41
NETWORKING PROJECT
REST API is the recommended interface for development of applications using the features
supported by the Floodlight. These are the main outcome that has been assessed from the project.
The discussion part has discussed important advantages of this project and the limitations of the
project. Significance of the project has been also described within this report. The comparison
graph for the tests has been also presented within the discussion section of this report. With the
test comparison tree topology graph has been also presented in this report.
Reflection
From the above report it can be concluded that computer network configuration is
becoming complex since the network operator has increased usage of sophisticated management
task for the network. The main reason that causes difficult to manage the current network is
continuous change in the state of the network and maintaining low level for the configuration
management of the device. The methodology of state of art for configuring the network does not
supports network operators to configure the network policy such that the network can react
automatically for the low level events occurring in the network. With the application of software
defined network the abstraction level in the network can be improved and design languages can
be used for development of the controllers for automatically reacting against the network
changes and management of the state of the network. We have used mininet emulator for the
creation of the virtual network and analysis of the performance of both the opendaylight and
floodlight controller. By default the topology created in Mininet consists of an OpenFlow switch
and it is connected with two hosts and a controller (OpenFlow). The hosts in Mininet have the
capability to run Linux operating system and commands. Three types of topology are used for
measuring the performance of both the controller and the results are attached with the report i.e.
Single, linear and tree. All the instances of the hosts are installed with Ubuntu 14.0.4 and they

42
NETWORKING PROJECT
are provided 2 GB of RAM. As a result of the performance evaluation it has been found that for
the tree topology the Floodlight controller can be used for getting the best performance from the
network while for the multimode network or mesh topology the open daylight controller can
outperform and provide the best output. With the implementation of the software defined
network the management process of the network can be simplified and help in evolving the
network to the next level. The aspects of the management and network operation can be
simplified and analysis is made for the implementation of the event driven framework for
network control depending on the software defined network. There are four domain of controls
that are used by the network controllers such as data usage, traffic flow, time and authentication
status for enforcement and implementation of network policy using the programming language.
It can help in implementing new network policy set and apply different types of settings for the
network for application of wide range of policies to meet the current needs of the user. The
software defined networking helps in building this type of system as the logic of SDN can be
applied in the back end server and routers and switches in the home network can be used as a
simple device to forward the data packet to different destination address. For the network having
low loads the OpenDaylight can perform better for any topologies and they both have similar
performance when the load on the network is about 50% of the bandwidth available without the
tree topology because here the OpenDaylight gives better performance than Floodlight. For the
network that has heavy traffic flow OpenDaylight defeats Floodlight only in single topology
since the performance is better based on the loss. Thus it can be concluded that OpenDaylight
can be a better choice for its application in tree topology having different types of loads in the
network without considering the traffic that are sensitive to loss.

43
NETWORKING PROJECT
References
Abdelwahab, S., Hamdaoui, B., Guizani, M., & Znati, T. (2016). Network function virtualization
in 5G. IEEE Communications Magazine, 54(4), 84-91.
Akhunzada, A., Ahmed, E., Gani, A., Khan, M. K., Imran, M., & Guizani, S. (2015). Securing
software defined networks: taxonomy, requirements, and open issues. IEEE
Communications Magazine, 53(4), 36-44.
Akyildiz, I. F., Wang, P., & Lin, S. C. (2015). SoftAir: A software defined networking
architecture for 5G wireless systems. Computer Networks, 85, 1-18.
Ali, S. T., Sivaraman, V., Radford, A., & Jha, S. (2015). A survey of securing networks using
software defined networking. IEEE transactions on reliability, 64(3), 1086-1097.
Alsmadi, I., & Xu, D. (2015). Security of software defined networks: A survey. computers &
security, 53, 79-108.
Arslan, M. Y., Sundaresan, K., & Rangarajan, S. (2015). Software-defined networking in cellular
radio access networks: potential and challenges. IEEE Communications Magazine, 53(1),
150-156.
Aydeger, A., Akkaya, K., Cintuglu, M. H., Uluagac, A. S., & Mohammed, O. (2016, May).
Software defined networking for resilient communications in smart grid active
distribution networks. In 2016 IEEE International Conference on Communications
(ICC) (pp. 1-6). IEEE.

44
NETWORKING PROJECT
Baktir, A. C., Ozgovde, A., & Ersoy, C. (2017). How can edge computing benefit from software-
defined networking: A survey, use cases, and future directions. IEEE Communications
Surveys & Tutorials, 19(4), 2359-2391.
Bertaux, L., Medjiah, S., Berthou, P., Abdellatif, S., Hakiri, A., Gelard, P., ... & Bruyere, M.
(2015). Software defined networking and virtualization for broadband satellite
networks. IEEE Communications Magazine, 53(3), 54-60.
Blenk, A., Basta, A., Reisslein, M., & Kellerer, W. (2015). Survey on network virtualization
hypervisors for software defined networking. IEEE Communications Surveys &
Tutorials, 18(1), 655-685.
Canini, M., Kuznetsov, P., Levin, D., & Schmid, S. (2015, April). A distributed and robust sdn
control plane for transactional network updates. In 2015 IEEE conference on computer
communications (INFOCOM) (pp. 190-198). IEEE.
Chen, M., & Hao, Y. (2018). Task offloading for mobile edge computing in software defined
ultra-dense network. IEEE Journal on Selected Areas in Communications, 36(3), 587-
597.
Chen, M., Qian, Y., Mao, S., Tang, W., & Yang, X. (2016). Software-defined mobile networks
security. Mobile Networks and Applications, 21(5), 729-743.
Chen, M., Zhang, Y., Hu, L., Taleb, T., & Sheng, Z. (2015). Cloud-based wireless network:
Virtualized, reconfigurable, smart wireless network to enable 5G technologies. Mobile
Networks and Applications, 20(6), 704-712.

45
NETWORKING PROJECT
Chen, T., Matinmikko, M., Chen, X., Zhou, X., & Ahokangas, P. (2015). Software defined
mobile networks: concept, survey, and research directions. IEEE Communications
Magazine, 53(11), 126-133.
Cui, L., Yu, F. R., & Yan, Q. (2016). When big data meets software-defined networking: SDN
for big data and big data for SDN. IEEE network, 30(1), 58-65.
De Oliveira, B. T., Gabriel, L. B., & Margi, C. B. (2015). TinySDN: Enabling multiple
controllers for software-defined wireless sensor networks. IEEE Latin America
Transactions, 13(11), 3690-3696.
Dhawan, M., Poddar, R., Mahajan, K., & Mann, V. (2015, February). SPHINX: Detecting
Security Attacks in Software-Defined Networks. In NDSS (Vol. 15, pp. 8-11).
Dong, X., Lin, H., Tan, R., Iyer, R. K., & Kalbarczyk, Z. (2015, April). Software-defined
networking for smart grid resilience: Opportunities and challenges. In Proceedings of the
1st ACM Workshop on Cyber-Physical System Security (pp. 61-68). ACM.
Duan, X., & Wang, X. (2015). Authentication handover and privacy protection in 5G hetnets
using software-defined networking. IEEE Communications Magazine, 53(4), 28-35.
Farhady, H., Lee, H., & Nakao, A. (2015). Software-defined networking: A survey. Computer
Networks, 81, 79-95.
Fontes, R. R., Afzal, S., Brito, S. H., Santos, M. A., & Rothenberg, C. E. (2015, November).
Mininet-WiFi: Emulating software-defined wireless networks. In 2015 11th International
Conference on Network and Service Management (CNSM)(pp. 384-389). IEEE.

46
NETWORKING PROJECT
Foukas, X., Nikaein, N., Kassem, M. M., Marina, M. K., & Kontovasilis, K. (2016, December).
FlexRAN: A flexible and programmable platform for software-defined radio access
networks. In Proceedings of the 12th International on Conference on emerging
Networking EXperiments and Technologies (pp. 427-441). ACM.
Foukas, X., Patounas, G., Elmokashfi, A., & Marina, M. K. (2017). Network slicing in 5G:
Survey and challenges. IEEE Communications Magazine, 55(5), 94-100.
Goransson, P., Black, C., & Culver, T. (2016). Software defined networks: a comprehensive
approach. Morgan Kaufmann.
Hakiri, A., Berthou, P., Gokhale, A., & Abdellatif, S. (2015). Publish/subscribe-enabled software
defined networking for efficient and scalable IoT communications. IEEE
communications magazine, 53(9), 48-54.
Haque, I. T., & Abu-Ghazaleh, N. (2016). Wireless software defined networking: A survey and
taxonomy. IEEE Communications Surveys & Tutorials, 18(4), 2713-2737.
He, Z., Cao, J., & Liu, X. (2016). SDVN: Enabling rapid network innovation for heterogeneous
vehicular communication. IEEE network, 30(4), 10-15.
Hong, S., Xu, L., Wang, H., & Gu, G. (2015, February). Poisoning Network Visibility in
Software-Defined Networks: New Attacks and Countermeasures. In NDSS (Vol. 15, pp.
8-11).
Jararweh, Y., Al-Ayyoub, M., Benkhelifa, E., Vouk, M., & Rindos, A. (2015). SDIoT: a
software defined based internet of things framework. Journal of Ambient Intelligence and
Humanized Computing, 6(4), 453-461.

47
NETWORKING PROJECT
Jin, X., Gossels, J., Rexford, J., & Walker, D. (2015). Covisor: A compositional hypervisor for
software-defined networks. In 12th {USENIX} Symposium on Networked Systems Design
and Implementation ({NSDI} 15) (pp. 87-101).
Karakus, M., & Durresi, A. (2017). Quality of service (qos) in software defined networking
(sdn): A survey. Journal of Network and Computer Applications, 80, 200-218.
Katta, N., Zhang, H., Freedman, M., & Rexford, J. (2015, June). Ravana: Controller fault-
tolerance in software-defined networking. In Proceedings of the 1st ACM SIGCOMM
symposium on software defined networking research (p. 4). ACM.
Kobo, H. I., Abu-Mahfouz, A. M., & Hancke, G. P. (2017). A survey on software-defined
wireless sensor networks: Challenges and design requirements. IEEE access, 5, 1872-
1899.
Leng, J., Zhou, Y., Zhang, J., & Hu, C. (2015). An inference attack model for flow table capacity
and usage: Exploiting the vulnerability of flow table overflow in software-defined
network. arXiv preprint arXiv:1504.03095.
Li, S., Hu, D., Fang, W., Ma, S., Chen, C., Huang, H., & Zhu, Z. (2017). Protocol oblivious
forwarding (POF): Software-defined networking with enhanced programmability. IEEE
Network, 31(2), 58-66.
Li, W., Meng, W., & Kwok, L. F. (2016). A survey on OpenFlow-based Software Defined
Networks: Security challenges and countermeasures. Journal of Network and Computer
Applications, 68, 126-139.

48
NETWORKING PROJECT
Li, Y., & Chen, M. (2015). Software-defined network function virtualization: A survey. IEEE
Access, 3, 2542-2553.
Liang, C., Yu, F. R., & Zhang, X. (2015). Information-centric network function virtualization
over 5G mobile wireless networks. IEEE network, 29(3), 68-74.
Liu, J., Li, Y., Chen, M., Dong, W., & Jin, D. (2015). Software-defined internet of things for
smart urban sensing. IEEE communications magazine, 53(9), 55-63.
Liu, J., Zhang, S., Kato, N., Ujikawa, H., & Suzuki, K. (2015). Device-to-device
communications for enhancing quality of experience in software defined multi-tier LTE-
A networks. IEEE Network, 29(4), 46-52.
Liu, K., Ng, J. K., Lee, V., Son, S. H., & Stojmenovic, I. (2016). Cooperative data scheduling in
hybrid vehicular ad hoc networks: VANET as a software defined network. IEEE/ACM
Transactions on Networking (TON), 24(3), 1759-1773.
Nakao, A., Du, P., Kiriha, Y., Granelli, F., Gebremariam, A. A., Taleb, T., & Bagaa, M. (2017).
End-to-end network slicing for 5G mobile networks. Journal of Information
Processing, 25, 153-163.
Olivier, F., Carlos, G., & Florent, N. (2015). New security architecture for IoT
network. Procedia Computer Science, 52, 1028-1033.
Ordonez-Lucena, J., Ameigeiras, P., Lopez, D., Ramos-Munoz, J. J., Lorca, J., & Folgueira, J.
(2017). Network slicing for 5G with SDN/NFV: Concepts, architectures, and
challenges. IEEE Communications Magazine, 55(5), 80-87.

49
NETWORKING PROJECT
Porras, P. A., Cheung, S., Fong, M. W., Skinner, K., & Yegneswaran, V. (2015, February).
Securing the Software Defined Network Control Layer. In NDSS.
Rawat, D. B., & Reddy, S. R. (2016). Software defined networking architecture, security and
energy efficiency: A survey. IEEE Communications Surveys & Tutorials, 19(1), 325-346.
Rost, P., Banchs, A., Berberana, I., Breitbach, M., Doll, M., Droste, H., ... & Sayadi, B. (2016).
Mobile network architecture evolution toward 5G. IEEE Communications
Magazine, 54(5), 84-91.
Sama, M. R., Contreras, L. M., Kaippallimalil, J., Akiyoshi, I., Qian, H., & Ni, H. (2015).
Software-defined control of the virtualized mobile packet core. IEEE Communications
Magazine, 53(2), 107-115.
Scott-Hayward, S., Natarajan, S., & Sezer, S. (2015). A survey of security in software defined
networks. IEEE Communications Surveys & Tutorials, 18(1), 623-654.
Sharma, P. K., Chen, M. Y., & Park, J. H. (2017). A software defined fog node based distributed
blockchain cloud architecture for IoT. IEEE Access, 6, 115-124.
Sivaraman, V., Gharakheili, H. H., Vishwanath, A., Boreli, R., & Mehani, O. (2015, October).
Network-level security and privacy control for smart-home IoT devices. In 2015 IEEE
11th International conference on wireless and mobile computing, networking and
communications (WiMob) (pp. 163-167). IEEE.
Sood, K., Yu, S., & Xiang, Y. (2015). Software-defined wireless networking opportunities and
challenges for Internet-of-Things: A review. IEEE Internet of Things Journal, 3(4), 453-
463.

50
NETWORKING PROJECT
Su, Z., Xu, Q., Zhu, H., & Wang, Y. (2015). A novel design for content delivery over software
defined mobile social networks. IEEE Network, 29(4), 62-67.
Sun, S., Kadoch, M., Gong, L., & Rong, B. (2015). Integrating network function virtualization
with SDR and SDN for 4G/5G networks. IEEE Network, 29(3), 54-59.
Tang, T. A., Mhamdi, L., McLernon, D., Zaidi, S. A. R., & Ghogho, M. (2016, October). Deep
learning approach for network intrusion detection in software defined networking.
In 2016 International Conference on Wireless Networks and Mobile Communications
(WINCOM) (pp. 258-263). IEEE.
Truong, N. B., Lee, G. M., & Ghamri-Doudane, Y. (2015, May). Software defined networking-
based vehicular adhoc network with fog computing. In 2015 IFIP/IEEE International
Symposium on Integrated Network Management (IM) (pp. 1202-1207). IEEE.
Tuncer, D., Charalambides, M., Clayman, S., & Pavlou, G. (2015). Adaptive resource
management and control in software defined networks. IEEE Transactions on Network
and Service Management, 12(1), 18-33.
Wan, J., Tang, S., Shu, Z., Li, D., Wang, S., Imran, M., & Vasilakos, A. V. (2016). Software-
defined industrial internet of things in the context of industry 4.0. IEEE Sensors
Journal, 16(20), 7373-7380.
Wang, B., Zheng, Y., Lou, W., & Hou, Y. T. (2015). DDoS attack protection in the era of cloud
computing and software-defined networking. Computer Networks, 81, 308-319.

51
NETWORKING PROJECT
Wang, H., Xu, L., & Gu, G. (2015, June). Floodguard: A dos attack prevention extension in
software-defined networks. In 2015 45th Annual IEEE/IFIP International Conference on
Dependable Systems and Networks (pp. 239-250). IEEE.
Wickboldt, J. A., De Jesus, W. P., Isolani, P. H., Both, C. B., Rochol, J., & Granville, L. Z.
(2015). Software-defined networking: management requirements and challenges. IEEE
Communications Magazine, 53(1), 278-285.
Wood, T., Ramakrishnan, K. K., Hwang, J., Liu, G., & Zhang, W. (2015). Toward a software-
based network: integrating software defined networking and network function
virtualization. IEEE Network, 29(3), 36-41.
Yan, Q., & Yu, F. R. (2015). Distributed denial of service attacks in software-defined
networking with cloud computing. IEEE Communications Magazine, 53(4), 52-59.
Yan, Q., Yu, F. R., Gong, Q., & Li, J. (2015). Software-defined networking (SDN) and
distributed denial of service (DDoS) attacks in cloud computing environments: A survey,
some research issues, and challenges. IEEE Communications Surveys & Tutorials, 18(1),
602-622.
Yang, M., Li, Y., Jin, D., Zeng, L., Wu, X., & Vasilakos, A. V. (2015). Software-defined and
virtualized future mobile and wireless networks: A survey. Mobile Networks and
Applications, 20(1), 4-18.
Zeng, D., Gu, L., Guo, S., Cheng, Z., & Yu, S. (2016). Joint optimization of task scheduling and
image placement in fog computing supported software-defined embedded system. IEEE
Transactions on Computers, 65(12), 3702-3712.

52
NETWORKING PROJECT
Zheng, K., Hou, L., Meng, H., Zheng, Q., Lu, N., & Lei, L. (2016). Soft-defined heterogeneous
vehicular network: Architecture and challenges. IEEE Network, 30(4), 72-80.
Zhou, X., Li, R., Chen, T., & Zhang, H. (2016). Network slicing as a service: enabling
enterprises' own software-defined cellular networks. IEEE Communications
Magazine, 54(7), 146-153.