1. technology and computing
2. networking
3. network monitoring and management

Can an SDN-based Network Management System use
northbound REST APIs to communicate network changes to
the application layer?
Group 6 – Capstone Research Project
Abha Kondwilkar
Parth Shah
Sreenath Reddy
Yash Mankad
Advisor: Dr. David Reed
Interdisciplinary Telecom Program TLEN 5710 Capstone
University of Colorado Boulder
Date: April 25, 2015
possible to move the control plane from network devices into
an abstraction layer. This allows better centralization of
control as a single SDN controller can control multiple
network elements.
Abstract—Network management systems can be
simplified by integrating the capability of an SDN
controller of communicating with multiple network
elements to better orchestrate several network functions.
With the help of the service abstraction layer (SAL), it is
possible to allow the network controller to establish
bidirectional communication with the application, thus
building the foundation for a ‘reactive’ network. This
paper attempts to define a reactive network and address
the possibility of integrating the reactive flow-provisioning
mode of an SDN controller into a network management
system to build an SDN-based network management
solution. This paper also includes a brief overview of
traditional network management systems currently
deployed in industrial networks. Further, this paper also
definitively compares the parameters network topology
discovery time and network change detection time for a
SDN-based network to that of an SNMP-based network
and concludes the superiority of an SDN-based network
management system.
Network operators and Network Operation Center
(NOC) teams that maintain and sustain nation-wide networks
face daily challenges such as grappling with different vendor
specific configurations to implement intricate network
policies. With the advancements in the field of software
defined networking (SDN), which centralizes network
functions in a software-based abstraction layer while
withdrawing the data plane to simple packet forwarding
functions, introduces new possibilities to managing the
network. A typical deployment of SDN architecture is shown
in figure 1. The ultimate test of a successfully implemented
software-defined network is its ability to dynamically react to
changes in the network. Also, the network controller should be
able to adapt to those changes without losing network
functionality.
Most of the network controllers available in the
market today are rigid in terms of the features they offer and
lack the ability of controller interoperability to address their
shortcomings. Despite all the virtualization and abstraction
provided by an SDN controller, the truth is that the network
still has to run on a physical infrastructure and we need to
understand the needs of the underlying network in terms of
network configuration, bandwidth requirements, and policy
adherence. Also, the current technology of network controllers
has limited ability to communicate with the application. The
importance of research in this area is that, with the help of
REST (Representational State Transfer) APIs, it is possible to
allow the network controller to communicate with the
application, thus building the foundation for a ‘reactive’
network. There has been a recent surge to the adoption of
either an API-driven Service Abstraction Layer (AD-SAL) or
Keywords—Reactive network, software defined
networking (SDN), network management system, RESTful
APIs, Service Abstraction Layer (SAL).
I. INTRODUCTION
A. Statement of the Problem
The concept of an abstraction layer is not new. It has
been around for almost two decades when virtualization was
introduced onto an x86 Linux machine. But with rapid
development in the processing powers of network on chips and
the development of high-level coding languages, it is finally
1
Model-driven Service Abstraction Layer (MD-SAL) support
for network controllers due to the rising demand for
programmatic application interfaces on network controllers.
The push for this approach can be attributed to the rapid
adoption of open source network controllers such as
OpenDaylight, Floodlight, Pox and Ryu. Similar open-source
community driven projects have sped up the adoption of the
SDN technology and research around the capabilities of an
SDN controller in various fields of networking technologies.
Those who do support northbound communication are
restricted due to vendor proprietary protocols or software.
Using open source technology such as the OpenDaylight
controller along with cloud orchestration platform services
such as OpenStack, it is possible to introduce a level of
dynamic-programmability into a network management system
that would perform more efficiently during times of network
disruptions caused by several worst-case scenarios when
compared to a traditional protocol-based network management
system.
network management system. After the protocol is agreed
upon, there has to be a silicon-on-chip (SOC) manufacturer
willing to build a SOC circuit that is adhering to the
requirements of the protocol and satisfies the stringent
parameters by the standardizing body towards the performance
of the protocol. This stage takes another 1-2 years. After the
SOC is developed, a network vendor has to agree to build a
product around the SOC and market and distribute the new
protocol-based network management system. This stage takes
an additional 1-2 years. Once the product is market-ready,
either a large service provider or backbone network operator
has to buy it, and test the product in their lab before it gets
deployed in their production network. The entire process is
drawn-out for the rate at which the network is growing and its
need for a better solution than a protocol-based network
management solution.
With the advent of open source technologies, it is our
estimate that building a network management system using
open source technologies will reduce the time-to-market for
such a technology from almost a decade to less than half that
time given the rapid growth of the online support community.
This is due the fact that for an SDN-based system, as there are
no hardware chips and vendors involved, the entire system can
be deployed as a software project on a virtual machine and it
would be ready to test in an ISP’s network. If it performs
admirably, manufacturers will be more than willing to
incorporate an open source solution and vendors will be able
to cut the time to deploy from a couple of years to couple of
months. Also, with development of continuous integration
technologies and growth of DevOps technologies, building a
network management system that can evolve with every
release to meet the demands of an ever-changing market is the
need of the hour. The real promise of NMS is its ability to
support network programmability - the ability to create
adaptive networks that can be configured spontaneously to
accommodate changing business demand.
B. Research Question
Our research problem is to look into the feasibility of
an SDN-based network management system to implement a
reactive network that has the ability to communicate with both
the network and application using northbound RESTful APIs.
Fig.1 – Software Defined Networking (SDN) Architecture [19]
In our interactions with industry advisors on the
subject of network management system, we learnt that the life
cycle of a traditional protocol-based network management
system is about 8-10 years from the protocol being conceived
to the system being deployed in a live production network.
This is broken down into several stages of development. The
protocol that is to be used in the system takes around 2-3 years
to be standardized and to be mature enough to be used in a
The scope of our research problem is to research into
software-controllable network behavior and to determine the
suitability and maturity of a network controller to build a
reactive network that has the ability to communicate with both
the network and application while taking advantage of the vast
potential of northbound APIs. Our research problem also looks
into the field of controller benchmarking parameters for an
2
SDN controller and how these parameters can be used to have
a comparative study between the parameters used for timingtolerances in traditional network management systems. We
will also have a use case that tests these parameters in a
virtualized environment.
The third research sub-problem is implementing an
open-source network management system. Most of the
implementations of network management systems make use of
proprietary protocols. The drawbacks of using proprietary
protocols are that they do not address the needs of the research
and there is a possibility of the research being directed to
specific segment of the industry where the vendor wants to
focus. Also the source code is not openly available and might
hamper the prospects of further research without support from
the vendor. Keeping the research open source has a lot of
benefits. The major advantage of using open source
technology is that it would equally benefit big and small
service providers and encourages widespread adoption for a
technology without increasing an organization’s capital or
operational expenses.
In this paper, we focus on four major sub-problems of
the current network management systems – (i) defining the
nature of a network that is able to react and adapt to frequent
changes in network state, (ii) explore the different types of
programmable northbound interfaces that provide better
visibility to applications and turn over the control to the
application to facilitate better network diagnosis and
troubleshooting [1], (iii) using open source technologies within
the scope of our research problem to implement an SDN-based
network management system and lastly (iv) finding out the
state-of-art in current network management systems and
running a comparative study of its parameters
The final research sub-problem is to compare
relevant performance parameters of an SDN controlled
network to those of a protocol-based network management
system. There has been significant research done to test
performance parameters in a traditional network management
system, however not much work has been done to test
performance parameters of an SDN controlled network. Our
research will identify and test certain key performance
parameters in an SDN controlled network, which will help
highlight the importance of our research.
The first research sub-problem is to define the
characteristics of a reactive network. A standards body has not
defined the term reactive network. Thus, it is important to
characterize the attributes of a reactive network within the
scope of our research problem. One of the benchmarking
parameters for an SDN controller is a reactive flowprovisioning mode as defined in a draft published by the IETF
working group in March of this year [15]. An SDN control
plane is usually an orchestration of flows that contains several
packet header fields. The network path is selected by installing
the corresponding flow into the forwarding table [2]. In this
paper, we are interpreting the term reactive network as its
ability to re-route traffic based on congestion in a particular
network path and update the flow table with a new flow that
would reduce congestion in the network without affecting the
state of other flows while adhering to the network policies that
might be in place.
II. LITERATURE REVIEW
It is important to know the work already done in the
field of reactive networks, SDNs’ and network management to
develop our research. Our work takes reference from a few of
the related works mentioned in this section. Greenberg and
Hjalmtysson [8] proposed four dimensions of network
management and control. These are decision, dissemination,
discovery and data. This work gives us insights in the
fundamentals behind present network management systems
and what are the fundamental requirements of network
management.
The second research sub-problem is to develop a
northbound API that supports the reactive nature of the
network. There has been a growing interest within the
networking community to look into the potential of
northbound APIs. The Open Networking Foundation (ONF)
believes that the northbound API space should be kept free for
vendors to innovate and design open APIs [1], as this will
allow a user’s application system to make full and effective
use of their control plane and take full control of their network
without being tied down by a vendor proprietary API [3].
Based on the requirements of the northbound API and its
successful implementation, we can push for the adoption of a
common implementation of the API, which will lead to faster
adoption towards using programmable northbound APIs in
network management systems.
The term reactive networking was coined by Oracle
in 2011 and they define a reactive network configuration as a
system, which automatically adapts to any change in network
condition and network configuration without requiring manual
reconfiguration. For example, if your wired network interface
becomes unplugged or if a new wireless network becomes
available, the system adapts accordingly. With the primary
focus on mobility, a reactive configuration policy allows the
system's configuration to be changed dynamically, in response
to different network events or at a user's request [2]. This gives
us a basis to define the term reactive network in our research.
3
Kim and Feamster [1] had looked into the areas of
enabling a network for frequent changes, using high level
language for network configuration and providing network
visualization while troubleshooting network issues. This work
has helped us to understand the expectations from software
defined networking management. Samaan and Ciavaglia [9]
[10] have highlighted the need for autonomics in network
management for next generation networks. These works give
research directions to bring in autonomics and also to establish
the need of dynamic and auto actions for software defined
networks. J. Mueller, et al. [12] proposed a novel approach for
traffic engineering in software-defined networking. This work
can be referred in order to understand how
network management can dynamically adapt the changing
behavior of network configurations. These papers gave us
insight into industry expectation of a reactive network and our
definition of a reactive network as discussed in the first
research sub-problem is based on the findings from these
papers.
working group and a timeline of their deliverables [4]. This
paper aided our understanding of the importance of
northbound APIs and the current state of a standards body in
its work towards standardizing the northbound interface of
network controllers.
T. Feng, et al. [13] proposed software defined
networking oriented architecture for network operating system,
which can manage open devices, understand network status
cognitively and process packets. Since there is no current
implementation of an open source network management
system, the volume of research in this field is limited. Our
research aims to make a significant contribution to this field by
successfully implementing our third research sub-problem.
These papers, taken together, indicate the vast possibilities of
implementing network management functions using
northbound APIs over software-defined based networks.
The current application of an SDN-based network
management system does not utilize northbound APIs and it
also uses proprietary technologies, which limits it capability to
work with different vendors. Our research advances the current
understanding of the problem by implementing a network
management system that uses open source technology, which
will reduce the costs of building network management
systems. It also harnesses the potential of northbound
interfaces of network controllers that will help future network
management systems perform with a higher efficiency.
Dusi, et al. have elaborated in their paper on one of
the ways to establish the ‘reactive’ nature of an SDN controller
by dynamically configuring forwarding policies and they plan
to further their work in the field by updating the capabilities of
the flow table and a fine-grained flow definition [3]. Their
work was built on the work of Ferguson, et al. who worked
with the API implementations within SDN to advocate an
explicit communications channel between applications and
software defined networks [5]. This research is in lines with
our first research sub-problem of implementing a reactive
network.
III. RESEARCH METHODOLOGY
Keeping in mind the sub problems that were
addressed earlier in the paper, the following section will
describe the steps followed to address each of the subproblems.
B. Vengainathan, et al. [15] in their research on
Benchmarking SDN Controller Performance have defined
reactive flow setup where the controller can “add, update or
delete flow entries in flow tables of a switch in response to
packets received from the switch”. Also in their research, they
have tested for various performance related parameters for a
SDN controller, which can act as a benchmark for evaluating
the importance of our research. This research addresses our
fourth research sub-problem of comparing performance
parameters.
A. The following research methodology addresses the subproblem of defining the ‘reactive’ nature of our network
management system.
The linchpin of our research was proposing a standardized
definition for the term ‘reactive’ network. During the first
phase of our research we defined this term based on the
definition of a reactive network configuration coined by
Oracle, which explained the concept of a reactive network in
two components – a reactive network configuration
component, which was defined as any network which is
capable of automatically adapting “to any change in network
condition and network configuration without requiring manual
reconfiguration” and the second component was reactive
network policies, defined as a configuration policy that
“allows the system's configuration to be changed dynamically,
The
Open
Networking
Foundation
(ONF)
standardized the Open Flow protocol as the southbound
protocol for communication between the network controller
and network devices. In October 2013, they brought together a
working group to put forward a document summarizing the
need of the SDN controller for a Northbound API and
presented the findings of the northbound study group. In this
paper, they define the northbound interface and discuss the
implementations of the API, the goals and the scope of the
4
in response to different network events or at a user's request.”
[2].
During the second phase of our research, we came
across a IETF working group that published a draft about
‘Benchmarking SDN Controller Performance’ and it defines
the reactive flow provision mode of an SDN controller as
“programming flows in SDN nodes based on the traffic
received from SDN nodes through controller's southbound
interface” and in the discussion section, it is further mentioned
that in the reactive flow provisioning mode, “the SDN
controller dynamically decides the forwarding behavior based
on the incoming traffic from the SDN nodes. The controller
then programs the SDN nodes” [15].
Data adaptations are all statically defined at compile or build
time. In the MD-SAL, the SAL APIs and request routing
between consumers and providers are defined from models,
and data adaptations are provided by plugins. The difference
between southbound and northbound plugins is that the
southbound plugins talk protocols to network nodes and
northbound plugins talk application APIs to the controller
applications. As far as the SAL is concerned, there is really no
north or south. The SAL is basically a data exchange and
adaptation mechanism between plugins. The plugin SAL roles
(consumer or producer) are defined with respect to the data
being moved around or stored by the SAL. A producer
implements an API and provides the data of the API; a
consumer uses the API and consumes the data of the API [16].
Our definition of a reactive nature is based on our
understanding of the reactive configuration of a network and
reactive flow-provisioning mode of an SDN controller and is
discussed later in the paper.
While 'northbound' and 'southbound' provide the view
of the SAL of a network engineer, 'consumer' and 'producer'
provide the view of the SAL of a software engineer, and are
shown in the following figure:
B. The following research methodology will focus on the
northbound interface of the controller and address the sub
problem of the northbound interface.
Northbound interface abstraction is popularly
measured in terms of how many standard controllers or
network management systems can interface with it. In simple
terms, it is the measure of northbound API manageability of
the network management system. We were encouraged to push
for the standardization of the northbound API due to the shift
of the service abstraction layer (SAL) from an API-driven
approach (AD-SAL) to a model-driven approach (MD-SAL).
Fig 3 – SAL as viewed by Network and Application [16]
We wrote a python script that uses a combination of
several existing AD-SAL APIs for the OpenDaylight
controller including the flowprogrammer, staticroute,
switchmanager, and topology APIs. On the southbound
interface, we will be using the OpenFlow protocol version 1.3
since all OpenFlow enabled switches do not support the newer
version of OpenFlow, 1.4.
To realize our sub problem of developing a
northbound API that supports the reactive nature of the
network, we implemented a Python REST API framework and
wrapped our reactive logic in it to expose the reactive nature as
a single RESTful API to the application layer. The following
figure illustrates the working of the RESTful architecture:
Fig 2 – Service Layer Abstraction (SAL) Comparison [16]
As seen in the figure above, in the AD-SAL, the SAL
APIs request routing between consumers and providers, which
are terms used by software engineers while accessing the SAL.
5
attribute of platform support is very important and it addresses
the issue of flexibility of a network management system being
able to support different software platforms or operating
systems, and also different types of hardware such as several
versions of firmware.
As discussed in one of the points above, current
distribution of open source network management systems do
not have support for a model-driven approach to SAL, which
restricts its wide-spread adoption.
Fig 4 – RESTful API design [21]
D. The following research methodology addresses the subproblem of comparing some performance parameters of an
SDN controlled network versus those of a real network
management system.
C. The following three research methodologies address the
sub-problem of implementing an open source network
management system
During the course of research, we had the opportunity
to interview industry experts in the field of network
management system. In our interactions with them, we asked
them to describe their version of an ideal network management
system. This would allow us to understand the industry
requirements and we would be able to rate the outcome of our
network management system against the expectations of the
industry. We also discussed performance metrics and fault
management characteristics of existing network management
systems. We found that most traditional protocol-based
network management systems in the Cable modem industry
make use of the FCAPS (Fault, Configuration, Accounting,
Performance and Security) network management model
implemented with the help of Converged Cable Access
Platform (C-CAP) configuration theory and distributed
Converged Cable Access Platform (DC-CAP) technologies
along with the DOCSIS specifications for Cable Modem
Termination Systems (CMTSes).
Open source technologies such as the OpenDaylight
controller, Open vSwitch, docker and OpenStack have been
gaining widespread popularity in the industry and support for
these technologies will push for adoption of the open-source
network management systems. The paper on CloudNaaS [14]
showcases the OpenStack and NetCONF support and hence,
adaptability to cloud and other open systems. We looked into
available open-source network management systems and the
most popular is OpenNMS [17]. However, OpenNMS uses
open source tools to build a traditional SNMP-based network
management system and it does not provide support for a
dynamic route provisioning. OpenNMS is comparable to
existing network management solutions such as HP Openview
or IBM Tivoli Netcool.
For our implementation, we have made use of
completely open source software’s such as the OpenDaylight
controller, which is quickly gaining support from the
networking industry and already has a fairly large open source
community based around it. With releases scheduled twice a
year, the OpenDaylight community is able to add several key
features with every new release and with the help of other
open source tools such Github, Gerrit, Jenkins and Bugzilla, it
is able to address bugs and issues swiftly. Another major factor
behind using OpenDaylight was its support of using RESTful
APIs and JSON payloads. OpenDaylight also has large
support for the migration of AD-SAL APIs to MD-SAL APIs,
which helps us in addressing our second sub problem of
standardizing northbound APIs.
Our goal for this sub-problem was to compare the
performance of protocol-based network management systems
to an SDN-based network management system. We narrowed
down to two parameters for a comparative study between a
protocol-based network management system and an SDNbased network management system. Network Topology
discovery time and Network change detection time are
identified as two benchmarking parameters for an SDN
controller and there have been extensive measurement based
studies on the topology detection capabilities of SNMP and
SNMP-based network management systems.
Apart from the OpenDaylight controller, we use
Virtualbox, which is an open source virtualization tool
developed by Oracle, mininet, which is a open network
emulator tool developed at Stanford and we have setup this
environment on both Linux and Windows platforms. The
For our project, we used the open source
performance-benchmarking tool called WCBench, which is a
wrapped version of the popular open source tool for controller
benchmarking (CBench). Cbench was developed to perform
6
scalable testing and analysis for computing systems. The tool
WCBench was developed by Red Hat and it tests an existing
OpenDaylight installation for performance parameters such as
flows/second, increasing load and changing network topology
on the OpenDaylight controller while the test is running.
APIs to take advantage of the reactive flow-provisioning mode
to support the reactive network.
We created a test-bench network to run our tests and
also verify the reactive nature of our network. It consists of 4
OpenFlow enabled switches forming a mesh network,
connected to two clients and two servers. Clients 1 and 2 are
requesting data from Servers 1 and 2 respectively. We
examine the behavior of the network for the case where one
switch goes down and another case where an additional switch
is added to test the how the network reacts to change in the
topology.
We were successfully able to implement a network
management system using only open-source software that
includes the OpenDaylight controller, mininet, and Virtualbox.
C. Implementing open source network management
system
D. Comparison with traditional protocol-based network
management system.
For this sub-problem, we referred to a test run on a
64-node network that used SNMP for network topology
discovery and used a combination of a proprietary probing tool
and SNMP to test for network change detection times [18].
We ran WCBench on the native installation of OpenDaylight
that we were using to run our reactive network and we had to
modify the source code to be compatible with the version of
OpenDaylight we were running. As WCBench natively only
supports OpenDaylight Helium, whereas we were using
OpenDaylight Hydrogen to test our network. WCBench stores
the results into CSV format and also allows creation of graphs
from the stats.py file as seen in the figure below:
Fig 5 – Test-bench setup
IV. RESEARCH RESULTS
A. Defining a reactive network
Based on our understanding after both phases of our
project, we would define a ‘reactive’ network as –
A system that automatically adapts to different network
events by dynamically provisioning flows in the network
using the SDN controller’s southbound interface while
adhering to any network policies that might be in place.
B. Develop a northbound API that supports the reactive
network
As discussed in the earlier section, we used the
Python RESTful API framework to develop a northbound API
by writing a Python script that uses several existing AD-SAL
Fig 6 – Output of WCBench running on OpenDaylight
7
The first graph shows us the number of flows that the
OpenDaylight controller can install per second. This graph
helped us the understand the time that it would take for new
flows to be installed into the network in case of a network
event. We can also use WCBench to get controller information
like used RAM, which can be used for performance
management.
driven, MD-SAL approach. This, by itself, solves the issue of
standardization of northbound APIs.
When the ONF proposed to keep the northbound API
space open for vendor development, this caused a lot of stir in
the northbound application space with every organization
coming up with their proprietary APIs that support a wide
variety of network functions. However, this brought up the
similar issue of a cross-platform and cross-vendor API lock-in.
The proprietary APIs would not work across all vendors
defeating the purpose of standardization, the reason for which
the northbound space was kept open.
We looked at a research done on timing tolerances for
a SNMP-based network to detect network changes in a 64node network and we will comparing those times against the
time required for our SDN controller to detect network
changes in a virtualized 64-node network. The results of the
test can be seen in the table below:
Test Case
SNMP-based
system for 64hosts [18]
SDN-based
system for 64hosts
Network Topology
Discovery Time
~ 4 seconds
0.533
milliseconds
Network Change
Detection Time
1.42 seconds
~ 0.1
milliseconds
However, with the acceptance of a model-driven
approach, the issue seemed to solve itself, as the MD-SAL
does not assume any model. All models are provided by the
plugins. The MD-SAL only provides the infrastructure and the
plumbing for the plugins. Thus, the vendors were free to
design their own models and APIs as long as they adhered to
the plugins defined by the controller for the specific
southbound plugin. The MD-SAL approach removed the 1:1
mapping between the northbound and the southbound plugin
and rather provided an instance-based request routing service
between multiple provider plugins.
In the third sub-problem, we built an open-source
SDN–based network management system using open source
software. During our meetings with several industry experts on
network management systems, we asked them the question of
whether they think an SDN-based solution would scale to meet
the needs to some of the largest ISPs and also why they think
that the adoption of the open-source technology into
production networks is not as rapid as envisioned.
Table – 1: Output of test results
V. DISCUSSION OF RESULTS
As discussed in one of the earlier sections of the
paper, the time to market for a traditional protocol-based
network management solution is almost 8-10 years and that
time can be cut to half by using an SDN-based approach.
However, that is not the case, as we found out through our
discussions, due to the fact that using SDN for network
management is still in its very nascent stages. Apart from B4,
which is Google’s own deployment of SDN in its backbone
network [20], no other organization has publicly
acknowledged having such a large-scale SDN deployment.
What SDN promises is efficient performance, but it also
increases risk. With a traditional network, you can have
performance management, fault management, and high
availability by using redundant systems and backup resources;
the concept was to eliminate a single-point of failures from the
network. On the other hand, SDN promises centralization of
resources into a single point, the performance and fault
management capabilities far exceed those of a traditional
In the first sub-problem, we defined the term ‘reactive
network’, which was a key part of our research, taking into
consideration the lack of any standardized definitions. During
the course of our research, we were able to better understand
the need for a definition as it aids in the interpretation of the
research sub-problem and research problem as a whole.
In the second sub-problem, we developed a RESTful
northbound
interface
that
enables
bi-directional
communication between the network and the application,
building the foundation of a reactive network. We would like
to discuss here that one of the goals was also to push for the
standardization of the northbound API. When we started this
project, the older versions of OpenDaylight and other open
source controllers, had extensive support for the AD-SAL
approach towards API abstraction. However, since that time,
there has been a huge push, especially within the
OpenDaylight community, to port those APIs to a model-
8
network, however, the SDN controller itself becomes a single
point of failure. And historically, software systems in large
networks have always been prone to bugs and systems failures,
not to mention cyber-attacks by malicious hackers. No
software system can be made completely secure.
We discussed the sub-problems and defined the
characteristics of a ‘reactive’ network. We also discussed the
shift in approach from an AD-SAL to MD-SAL for
northbound APIs, which will help in the standardization of
northbound APIs. We discussed our findings on the slow
adoption of this technology into the service providers’ network
based on our discussions with industry experts and finally, we
were able to show that an SDN-based network management
system outperforms an SNMP-based system for the parameters
network topology discovery and change detection.
Moving forward with this discussion on the opensource front. There has been extremely rapid growth of opensource technologies, however, we do not see the technologies
being adopted into the production of the larger organizations.
OpenStack is probably the most widely deployed open-source
solution in production networks, however, organizations have
only now started integrating it into their networks after 5 years
and 12 stable releases. What we discovered while talking to
the experts is that open-source is highly tempting for
organizations to deploy as it reduces their capital and
operational expenses significantly, however, most of these
networks have stringent SLAs to follow and loss of every
second of connectivity could cost them millions of dollars in
liabilities. The lack of a support environment for open-source
projects turns out to be the major factor in its sluggish
adoption. Open-source projects enjoy a vast support in terms
of community and forums, but neither of these sources are
dedicated to support, which results in the larger organizations
shying away. Although, this does not hamper smaller
organizations form taking complete advantage of these
technologies.
Scope of future research for this topic lies with the
development of northbound interface. AD-SAL to MD-SAL
migration can be sped up with the help of the data-modeling
language Yang. Yang is an upcoming data-modeling language
that helps defines models and data structures for the MD-SAL
APIs and most of the OpenDaylight modules are now written
in Yang.
Additional work can be done in the field of traffic
engineering based on SDN-network management systems.
Templates and static configurations restrict current
implementations of traffic engineering. The basic necessity of
the network management system of the future will be a more
dynamic and non-configuration based approach. Another
interesting avenue is policy-based networking in a network so
that various kinds of traffic - data, voice, and video - get the
priority of availability and bandwidth needed to serve the
network's users effectively. As the popularity of software
defined networks (SDN) and OpenFlow increases, policybased network management has received more attention.
Manual configuration of multiple devices is being replaced by
an automated approach where a software-based, networkaware controller handles the configuration of all network
devices
In the fourth sub-problem, we ran a comparative
study of our current deployment of an SDN-based network
management system with the measurements taken from the
study of an SNMP-based network management system. The
SNMP-based network management system takes several
seconds to discover the network topology, on the other hand,
the SDN-based systems takes only milliseconds. This is due to
the fact that an SDN-based system, just needs to access its
database to fetch the network and any addition to the network
is also an entry into the network device database and hence
will be significantly faster than a traditional SNMP-based
system.
With round the clock on-going development, carriergrade open-source controllers, like the ONOS network
controller, hold the true promise of SDN of the future which
will allow service providers to build truly software-defined
networks.
VI. CONCLUSIONS AND FUTURE RESEARCH
VII. ACKNOWLEDGEMENTS
In this paper, we proposed a new approach to
traditional network management systems, by incorporating the
reactive nature of an SDN controller into protocol-based
network management systems and using the reactive nature of
SDN controllers to dynamically provision flows to SDN nodes
within the network thus creating the foundation of a ‘reactive’
network.
We would like to acknowledge with thanks Dr. David
Reed, Director of the Interdisciplinary Telecommunications
Program for agreeing to take up this capstone project and
become our advisor to guide us and support us as we seek to
achieve our goals towards the completion of the project.
9
[9]
We would like to thank Mr. Chris Luke, Principal
Engineer at Comcast, Mr. Kevin Luehrs, Project manager at
CableLabs and Mr. Jason K. Schnitzer, founder and CEO,
Applied Broadband, for taking time out of their schedules to
help us better understand the current state of network
management systems.
[10]
[11]
VIII. REFERENCES
H. Kim and N. Feamster, "Improving network management with
software defined networking”, Communications Magazine,
IEEE, vol. 51, no. 2, pp. 114-119, 2013.
[2] “What is reactive network configuration?”, Connecting systems
using reactive network configuration in Oracle Solaris 11.1,
online,
avaliable
at:
https://docs.oracle.com/cd/E26502_01/html/E28988/nwamover.html
[3] M. Dusi, R. Bifulco, F. Gringoli, F. Schneider, “Reactive logic
in software-defined networking: measuring flow-table
requirements”, NEC Laboratories Europe, Germany, online,
avalaible at:
[1]
[12]
[13]
[14]
[15]
http://www.ictmplane.eu/sites/default/files/public/publications/947paper.pdf
[4]
[5]
[6]
[7]
[8]
[16]
S. Raza, D. Lenrow, Open Networking Foundation North Bound
Interface Working Group (NBI-WG), v 1.1, October 6 2013,
https://www.opennetworking.org/images/stories/downloads/wor
king-groups/charter-nbi.pdf
A. D. Ferguson, A. Guha, C. Liang, R. Fonseca, and S.
Krishnamurthi, “Participatory networking: an api for application
control of sdns,” in Proceedings of the ACM SIGCOMM 2013
conference on SIGCOMM, ser. SIGCOMM ’13. New York, NY,
USA: ACM, 2013, pp. 327–338.
Sasidharan, Sreekanth; Chandra, Saurav Kanti, "Defining future
SDN based network management systems characterization and
approach," Computing, Communication and Networking
Technologies (ICCCNT), 2014 International Conference on ,
vol., no., pp.1,5, 11-13 July 2014
doi: 10.1109/ICCCNT.2014.6963137
Gorlatch, S.; Humernbrum, T.; Glinka, F., "Improving QoS in
real-time internet applications: from best-effort to SoftwareDefined
Networks,"
Computing,
Networking
and
Communications (ICNC), 2014 International Conference on ,
vol., no., pp.189,193, 3-6 Feb. 2014
doi: 10.1109/ICCNC.2014.6785329
A. Greenberg, G. Hjalmtysson, D. A. Maltz, A. Myers, J.
Rexford, G. Xie and H. & Zhang, "A clean slate 4D approach to
network control and management," ACM SIGCOMM Computer
Communication Review, vol. 35, no. 5, pp. 41-54, 2005.
[17]
[18]
[19]
[20]
[21]
10
N. Samaan and A. & Karmouch, "Towards autonomic network
management: an analysis of current and future research
directions.," Communications Surveys & Tutorials, IEEE, vol.
11, no. 3, pp. 22-36, 2009.
L. Ciavaglia, C. Destre and &. others, "Realizing autonomics for
future networks," In Future Network & Mobile Summit
(FutureNetw), pp. 1-9, 2011.
A. Lara, A. Kolasani and B. & Ramamurthy, "Simplifying
network management using Software Defined Networking and
OpenFlow," IEEE International Conference on Advanced
Networks and Telecommuncations Systems, pp. 24-29,
December, 2012.
J. Mueller, A. Wierz and T. & Magedanz, "Scalable OnDemand Network Management Module for Software Defined
Telecommunication Networks," IEEE Conference on Future
Networks and Services (SDN4FNS), pp. 1-6, 2013.
T. Feng, J. Bi and H. Hu, "TUNOS: A Novel SDNoriented
Networking," Network Protocols (ICNP), 2012 20th IEEE
International Conference, pp. 1-2, 2012.
T. Benson, A. Akella, A. Shaikh and S. & Sahu, "Cloudnaas: a
cloud networking platform for enterprise applications," 2nd
ACM Symposium on Cloud Computing, p. 8, October, 2011.
B. Vengainathan et al., “Terminology for Benchmarking SDN
Controller Performance draft-bhuvan-bmwg-sdn-controllerbenchmark-term-00”, Network-Working Group, IETF, March
23, 2015.
“OpenDaylight
Controller:
MD-SAL:
FAQ”,
wiki.opendaylight.org,
available
at:
https://wiki.opendaylight.org/index.php?title=OpenDaylight_Co
ntroller:MD-SAL:FAQ&oldid=25320
The OpenNMS Group, “OpenNMS”, available at:
http://www.opennms.com
Yun-Sheng Yen; Tung-Lung Chan; Chia-Yi Liu; Chwan-Yi
Shiah, "Topology discovery service in the universal
network," Computer Research and Development (ICCRD), 2011
3rd International Conference on , vol.1, no., pp.319,323, 11-13
March
2011
doi: 10.1109/ICCRD.2011.5764028
The Tech, “SDN Architecture”, Dec 25,2012, available at:
http://www.thetech.in/2012/12/sdn-architecture.html
A. Vahdat et al, “B4: Experience with a Globally-Deployed
Software Defined WAN”, Google Inc, SIGCOMM 2013, April
12 2013,
available at:
http://cseweb.ucsd.edu/~vahdat/papers/b4sigcomm13.pdf doi:10.1145/2486001.2486019
Read The Docs, “The Job of an API-Designer”, 2011, available
at: http://restful-api-design.readthedocs.org/en/latest/scope.html