Integrated Intelligent Research (IIR)

International Journal of Communication and Networking System

Volume: 04 Issue: 02 December 2015, Page No. 4 - 9
ISSN: 2278-2427

A Review on Role of Software-Defined Networking (SDN) in

Cloud Infrastructure
Punit Gupta1, Chitrarth Singh2
12

Department of Computer Science Engineering, Jaypee University of Information Technology, Himachal Pradesh, India
Email: punitg07@gmail.com, singhchitrarth@gmail.com

Abstract Software Defined Network (SDN) are used to enhance

Quality of Service (QoS) provided by network in Distributed
environment. SDN based network model and management tools are
being proposed for parallel and distributed , but not all proposed
models fully fit in cloud infrastructure environment. Since the
parameters that have being taken into consideration in these models to
improve QoS , does not fit in the cloud Infrastructure As A Service, a
survey study of proposed SDN model and tools suitable for Cloud
Infrastructure is discoursed in this paper. The aim of this survey is to
find a solution for network virtualization in cloud and maintain the
network traffic load, scalability and QoS in cloud infrastructure using
SDN.

cloud computing. It can be used in data centers and workload

optimized systems. By using SDN, the administrators have the
ability to control the data flow as well as to alter the
characteristics of the switching devices (or routing devices) in
the network from a central location, with control application
implemented as software module without the need of dealing
with each device individually. This gives the network
administrators the ability to arbitrarily change routing tables
(routing paths) in network routing devices. It also allows an
extra layer of control over the network data since the
administrator can assign high/low priorities to certain data
packets or allow block certain packets flowing through the
network. From cloud computing perspective, SDN provides
great benefits. First, it makes cloud provider more easily
deploy different vendors devices. Traditionally the big cloud
providers (such as Google, Amazon, etc.), have to purchase the
high performance switchers/routers from the same vendor in
order to easily re-configure the routing parameters (such as
routing table update period). Different vendors routers have
their own pros and cons. However, it is a headache to
customize each router since each vendor may have its own
language syntax. Now SDN allows a cloud provider to fast repolicy the routing or resource distribution issues as long as
each vendors routers follow the SDN standard. Second, it
enables a cloud user to more efficiently use the cloud resources
or conduct scientific experiments by creating virtual flow
slices. The OpenFlow protocol is compatible to GENI
standard, and this enables a user to arbitrarily create
slices/slivers without being aware of the physical network
infrastructure. No matter the infrastructure is wireless or wired
system, and no matter how the cloud provider deploys different
storage units in various locations, the concept of virtual flow in
a SDN makes data flow transparently route through all cloud
devices.

Keywords- Cloud, QoS, Cloud IaaS, Scheduling, virtual Machine

(VM ), OpenFlow , Software Defined Network (SDN).

I.

INTRODUCTION

Conventional networks utilize special algorithms implemented

on dedicated devices (hardware components) to control and
monitor the data flow in the network, managing routing paths
and determining how different devices are interconnected in
the network. Current network devices lack the flexibility to
deal with different packet types with various contents because
of the underlying hardwired implementation of routing rules.
A possible solution to this problem is the implementation of
the data handling rules as software modules rather than
embedding them in hardware. This method enables the
network administrators to have more control over the network
traffic and therefore has a great potential to greatly improve the
performance of the network in terms of efficient use of
network resources. Such an idea is defined in an innovative
technology, called Software-Defined Networking (SDN).
The goal of SDN is to provide open, user-controlled
management of the forwarding hardware in a network. SDN
exploits the ability to split the data plane from the control plane
in routers and switches. The control plane can send commands
down to the data planes of the hardware (routers or
switches).This paradigm provides a view of the entire network,
and helps to make changes globally without a device-centric
configuration on each hardware unit. The switches in the data
plane just simply deliver data among them by checking the
flow tables that are controlled by the controller(s) in the control
panel. This greatly simplifies the switches tasks since they do
not need to perform control functions.

II.

RELATED

WORK

Alex galis proposed a scalable SDN in general for networks[1].

This paper presents an architectural design for the open source
software-designed network infrastructure that enables fast
services and their execution in an efficient manner by taking
into account better shared network resources provided by
network virtualization. Deployed services in the future network
should be network aware i.e. services are aware of the
properties and state of network environment. This enables
services to self adapt according to network context. In recent
years, network virtualization techniques have gained a lot of
attention due to their flexibility for creating computing clouds,
and creating separate and independent virtual networks on top
of physical network infrastructures. Virtualized network

SDN results in improved network performance in terms of

network management, control and data handling. SDN is a
potential solution to the problems faced by conventional
network and is gaining more acceptance in applications such as
4

Integrated Intelligent Research (IIR)

International Journal of Communication and Networking System

Volume: 04 Issue: 02 December 2015, Page No. 4 - 9
ISSN: 2278-2427

environments are highly dynamic as links and nodes may be

reconfigured quickly. Virtual routers may migrate on demand
based on resource availability. This paper describes the
architectural model and the validation results of European
Union Autonomic Internet (AutoI) project which proposes
open source software-defined networks as part of future
networks.
III.

resources. A key advantage of separating the control and data

planes is to provide increased isolation for an application or set
of applications. Each AMS includes interfaces to a dedicated
set of modules and interfaces to one or more DOCs. Mapping
logic enables the data stored in models to be transformed into
knowledge and combined with knowledge stored in ontologies
to provide a context-sensitive assessment of the operation of
one or more virtual resources.

AUTOI ARCHITECTURAL FRAMEWORK

AND SYSTEMS

Distributed Orchestration Component

The AUTOI framework consists of a software-defined network

described with the help of five abstractions:

Mapping logic enables the data stored in models to be

transformed into knowledge and combined with knowledge
stored in ontologies to provide a context-sensitive assessment
of the operation of one or more virtual resources.

Orchestration plane (OP)

Service enablers plane (SP)
Knowledge plane (KP)
Management plane (MP)
Virtualization plane (VP).

Service enablers plane (SP)

It consists of functions for the automatic (re)deployment of
new management services, protocols, and resource-facing and
end-user-facing services. It includes enablers to allow code to
be executed on the network entities. This functionality is
implemented by the autonomic network programming interface
(ANPI), which supports large-scale network programmability
in deployed virtual networks.

The main purpose of the OSKMV planes is to make future

networks capable of self-knowledge and, ultimately, fully selfmanaging.
Orchestration plane (OP)

This approach has the following advantages:

Automatic service deployment, allowing a significant number
of new services to be offered on demand.
Flexible network configuration capabilities.
Special management functions and services easily enabled
locally for testing purposes before they
are automatically
deployed network-wide.
Flexible support for service migration, for both consumerfacing and resource-facing services.

It is a control framework into which any number of

components can be plugged in order to achieve the required
functionality. Basically, it controls one or more autonomous
management systems (AMS). It acts as control workflow for
AMSs ensuring their bootstrapping, initialization, dynamic
reconfiguration, optimization, organization, and closing down.
It is functionally integrated by one or more distributed
orchestration components (DOCs).

Virtual infrastructure is the possibility to support networks

with different network protocols hardware protocols on the
same hardware. Programmability in network and services
encompasses the study of decentralized enablers for dynamic
(de)activation and reconfiguration of new/existing services,
including management services and network components.
AutoI has taken the challenge to enable trusted parties (users,
operators, and service providers) to activate managementspecific service and network components into a specific
platform. Dynamic programming enablers will be created as
executable service code, which can be activated into the
systems elements to create the new functionality at runtime.
Network and service enablers for programmability can
therefore realize the capabilities for flexible management
support. So we can conclude that current communication
networks are composed of a set of heterogeneous resources.
Vitalizing resources have served two purposes: managing the
heterogeneity through introduction of homogeneous virtual
resources and enabling programmability of central network
elements. The flexibility gained through this approach helps to
adapt the network dynamically to both unforeseen and
predictable changes in the network. Another paper proposed by
Hilmi.E [2] discussing the use of SDN in distributed

Fig. 1 AUTOI architectural model: software-defined network

Autonomic Management System
The advantage of this architecture is that it can provide a
programmable mix of isolation and sharing of networking
5

Integrated Intelligent Research (IIR)

International Journal of Communication and Networking System

Volume: 04 Issue: 02 December 2015, Page No. 4 - 9
ISSN: 2278-2427

environment for multimedia streaming. This proposal can be

utilized in Virtual machine (VM) live migration by decreasing
the network bandwidth and network delay using SDN. It has
been foreseen that large-scale SDNs shall be managed by a
distributed control plane consisting of multiple controllers,
where each controller performs optimal QoS routing within its
domain and shares summarized (aggregated) QoS routing
information with other domain controllers to enable interdomain QoS routing with reduced problem dimensionality. To
this effect, this paper proposes (i) topology aggregation and
link summarization methods to efficiently acquire network
topology and state information, (ii) a general optimization
framework for flow-based end-to-end QoS provision over
multi-domain networks, and (iii) two distributed control plane
designs by addressing the messaging between controllers for
scalable and secure inter-domain QoS routing. In this paper to
allow the network to support some level of Quality of Service
(QoS) for multimedia traffic, the Internet Engineering Task
Force (IETF) proposed several QoS architectures such as
IntServ and Diffserv , yet none has been truly successful and
globally implemented. This is because, they are built on top of
the current Internets distributed hop-by-hop routing
architecture lacking the end-to-end information available
network resources. Moreover, Internet is divided into domains
called autonomous systems (AS) where each AS is owned by a
single entity, and to enable end-to-end QoS, both intra-AS and
inter-AS routing protocols have to be QoS aware.

This architecture offers several advantages to develop

innovative networking solutions including new QoS
mechanisms:
Network Resource Monitoring and End-to-End QoS Support:
OpenFlow enables complete network resource visibility for
effective network management.
Application-Layer Aware QoS: By centralizing network
control and making the network state information available up
to the application layer, an OpenFlow-based QoS architecture
can better adapt dynamic user needs.
Virtualization: OpenFlow enables to virtually slice a network
for creating special purpose networks, e.g., file transfer
network, delay-sensitive multimedia network.
Differential Services: More granular network control with
wide ranging policies at session, user, device, application
levels will allow service providers to apply differential pricing
strategies.
The proposed QoS-enabled controller in Figure 2, offers
various interfaces and functions to be implemented over a
standard controller.
The main interfaces of the QoS-enabled controller are:
ControllerForwarder Interface: This interface is defined
by the OpenFlow standard and is implemented by a typical
OpenFlow controller.
ControllerController Interface: This proposed interface
allows multiple controllers to share the necessary information
to cooperatively manage the whole network.
ControllerService Interface: The controller provides a
secure interface for service providers to set flow definitions for
new data partitions and even to define new forwarding (e.g.
routing, queuing) rules associated with these partitions.
Topology Management: In addition to discovering network
connectivity and maintaining the visualization of the topology,
this function is also responsible for generating aggregated
network topology information to be advertised through
controllercontroller interface.

Fig. 2 OpenFlows routing architecture

OpenFlow [7, 18] is a successful Software Defined
Networking (SDN) paradigm that decouples the control and
forwarding layers in routing. This is achieved by shifting
routing control functions from network devices to a centralized
unit, called controller, while data forwarding function remains
within the routers, called forwarders. The forwarders are
configured via the OpenFlow protocol, which defines the
communication between the controller and forwarders. Fig. 1
illustrates the OpenFlows flow-based routing architecture
where the controller makes per-flow decisions based on
network state information acquired from forwarders, and then
the controllers decisions are pushed to forwarders as flow
table updates.

Resource Management: This function is responsible for

determining availability and forwarding performance of
forwarders to aid route calculation and/or queue management.
Route Calculation: This function is responsible for
calculating and determining routes (e.g., shortest path and QoS
routes) for different types of flows.
In addition, a QoS-enabled controller should support the
following functions:
Flow Management: This function is responsible for
collecting QoS-flow definitions received from the service
provider through the controller-service interface.
6

Integrated Intelligent Research (IIR)

International Journal of Communication and Networking System

Volume: 04 Issue: 02 December 2015, Page No. 4 - 9
ISSN: 2278-2427

Queue Management: This function provides QoS support

based on prioritization of queues. One or more queues can be
attached to a forwarders physical port, and flows are mapped
to pre-configured queues.

carried by IP path (IP), the restoration of such service

consumes extra resources in IP stratum, so that some IP router
nodes are blocked due to the queue overflow when the network
is loaded heavily. Note that IP network and EON carrying
services have different advantages in various network traffic
scenarios. Compared to the EON, IP network is more suitable
for supplying low-bandwidth flows due to its flexibility and
convenience of packet switching. Under heavy traffic load
scenario, EON can offer highly-available and cost-effective
connectivity by provisioning a sub- or super-wavelength level
spectral path. If parts of IP network nodes process the traffic
flows busy in the queue, the services can be provided through
optical bypass partially to take advantage of EON with large
bandwidth. Thus, the path uses both IP and optical resources
through Global resource integrated resilience algorithm
(GRIR), which is called mixed path (MP). It performs more
effective data center service provisioning, i.e., utilizing less
resources and enhancing network performance.

Call Admission: This function denies/blocks a request when

the requested QoS parameters cannot be satisfied (e.g., there
may be no feasible QoS routes), and the controller takes
necessary actions.
Traffic Policing: This function is responsible for determining
whether data flows agree with their requested QoS parameters
and applying the policy rules when they do not
Hui Yang Proposed a reliable SDN taking into consideration
resilience of SDN in datacenters [3]. This paper proposes an
algorithm that provides resilience using the multiple stratums
resources and enhances the data center service resilience
responsiveness to the dynamic end-to-end recovery demands in
case of the converged optical node failure.

Global resource integrated resilience algorithm (GRIR)

In case of a converged optical node failure, the resilience
request Ri(s, d, b, ar) arrives at the network, a corresponding
auxiliary graph is established according to current network
state in recent time to. Note that the edge weights are
calculated following the above equations to reflect the network
resources utilization. Based on the auxiliary graph, Dijkstras
shortest path algorithm is computed from source to destination
nodes in multiple stratums network to select the path candidate.
If the chosen path is mixed path (MP) (i.e., go through IP and
optical paths), it determines which optical node should be the
new converged optical node to offload the traffic, and whether
and how we should setup new light paths. The new light path
can be established according to the selected spectrum edges
including corresponding weight, and go through the fiber links
with spectrum continuity constraint. GRIR can utilize multistratum resources effectively and enhance end-to-end resilience
responsiveness of data center services, while leading to a
reduced blocking probability coupled with cost savings.

Fig. 3 OpenFlow controller and interfaces

As data center services are typically diverse in terms of
required bandwidths and usage patterns, the network traffic
shows high burstiness and high-bandwidth characteristics,
which poses a significant challenge to the data center
networking for more efficient interconnection with reduced
latency and high bandwidth. The architecture of IP over elastic
optical network (EON) has been widely studied as a way to
construct economic networks, which reduces the pressure and
cost of power-hungry core routers by bypassing them with
elastic optical paths. This architecture can be achieved by the
multi-flow transponder, which is proposed to offload the IP
traffic into elastic optical paths at arbitrary bandwidth
granularity. To support the operational flexibility, the IP over
EON using multi-flow transponder can be used to interconnect
data centers and provide the required bandwidth in a highly
dynamic and efficient manner. If a node failure occurs in the IP
over EON interconnecting data centers, the network restoration
guaranteeing QoS will become more complex. This study
considers the simple case of a single node failure inter- data
center networks. If a failure occurs in a converged optical node
(i.e., the first optical node where the flow is offloaded into
optical network), the traffic cannot be shifted from the IP
router to EON. It means the service is difficult to be restored
just considering the optical stratum resources. If the service is

Wang wending proposed an automated SDM management

system which can be utilized in cloud infrastructure to manage
the network traffic while VM migration [4]. Software-Defined
Networks and Autonomic network technologies can be
combined together to construct a software defined selfmanaging solution for the future network. An autonomic QoS
management mechanism in software defined network
(AQSDN) is proposed in this paper. In AQSDN, the various
QoS features can be configured automatically in an OpenFlow
switch through extending the OpenFlow and OF-Config
protocols.The QoS management is an important part of
network management. Currently, different services or
applications want to obtain the different network resource for
fulfilling their requirements. So the self-configurable QoS
models and mechanisms based on the context- aware are
highly expected. Software Defined Network (SDN) separates
the control plane and the data plane, some network control and
management functions could be implemented through the
software instead of updating huge numbers of network
7

Integrated Intelligent Research (IIR)

International Journal of Communication and Networking System

Volume: 04 Issue: 02 December 2015, Page No. 4 - 9
ISSN: 2278-2427

Table 1: SDN Tools

In the proposed mechanism, the controller undertakes the
function of analysis and decision in the autonomic control
loop, while the switch acts as collector of the context and
executive of the behavior. This mechanism controls adaptively
the QoS rules according to the context from data plane and the
policy from the operator. In addition, for improving the quality
of multimedia service, we also propose the Packet Contextaware QoS model (PCaQoS), which processes packets
according to their semantic precedence level.
A survey is proposed by Fei Hu on SDN and OpenFlow [5]. A
number of protocol standards exist on the use of SDN in real
applications. One of the most popular protocol standards is
called OpenFlow. OpenFlow is a protocol that enables the
implementation of the SDN concept in both hardware and
software. An important feature of OpenFlow is that scientists
can utilize the existing hardware to design new protocols and
analyze their performance.
The controller communicates with the OpenFlow switch and
manages the switch through the OpenFlow protocol. An
OpenFlow switch can have multiple flow tables, a group table,
and an OpenFlow channel (Fig. 2). Each flow table contains
flow entries and communicates with the controller, and the
group table can configure the flow entries. OpenFlow switches
connect to each other via the OpenFlow ports. Initially the data
path of the OpenFlow routing devices has an empty routing
table with some fields (such as source IP address, QoS type,
etc.). This table contains several packet fields such as the
destination of different ports (receiving or transmission), as
well as an action field which contains the code for different
actions, such as packet forwarding or reception, etc. This table
can be populated based on the incoming data packets. When a
new packet is received which has no matching entry in the data
flow table, it is forwarded to the controller to be processed.
The controller is responsible for packet handling decisions, for
example, a packet is either dropped, or a new entry is added
into the data flow table on how to deal with this and similar
packets received in the future. SDN has the capability of
programming multiple switches simultaneously; but it is still a
distributed system and, therefore, suffers from conventional
complexities such as dropping packets, delaying of the control
packets etc. Current platforms for SDN, such as NOX and
Beacon, enable programming; but it is still hard to program
them in a low level. With new protocols (such as OpenFlow)
becoming more standard in industry, SDN is becoming easier
to implement. The control plane generates the routing table
while the data plane, utilizing the table to determine where the
packets should be sent to. Many companies utilize OpenFlow
protocols within their data center networks to simplify
operations. OpenFlow and SDN allow data centers and
researchers to easily abstract and manage the large network.
The OpenFlow architecture typically includes the following
1) Switches
2) Controllers
Tools for SDN - Flooflight ,Indigo, LoxiGen ,OpenStack
Networking Neuron, Beacon ,Maestro ,OMNI , Trema [ 6-20]

Name
NOX/POX

Platform
Python

Beacon

Java

Floodlight / LoxiGen

Java

Ryu

Python

Maestro

Java

OMNI

Python

Indigo

C++

Trema

Ruby

OpenDaylight

Java

OpenStack Networking Neuron

Python

NodeFlow

Java script

RouteFlow

C++

Flowvisor

Java

SNAC

C++

Wakame VDC

Ruby

Wakame VDC [20] is only a SDN supporting Cloud

Infrastructure as a service but it is only basic implementation
of SDN
IV.
CONCLUSION
Software Defined Network provides the capability to
implement network control and management functions by
software. Automatic network management help to provide
higher QoS and network load balancing on the other hand
GRIR increases the fault tolerant capability of SDN. In this
paper different type of SDN models are been discussed with
their advantages and how SDN can be used in cloud
infrastructure network virtualization.
REFERENCES
Rubio-Loyola, Javier, Alex Galis, Antonio Astorga, Joan Serrat, Laurent
Lefevre, Andreas Fischer, Alexandru Paler, and H. Meer. "Scalable
service deployment on software-defined networks." Communications
Magazine, IEEE49, no. 12 (2011): 84-93.
[2] Egilmez, H., and M. Tekalp. "Distributed QoS Architectures for
Multimedia Streaming over Software Defined Networks." (2014): 1-1.
[3] Open Flow: https://www.opennetworking.org/ja/sdnresources-ja/onfspecifications/openflow
[4] Wang, Wendong, Qinglei Qi, Xiangyang Gong, Yannan Hu, and Xirong
Que. "Autonomic QoS Management Mechanism in Software Defined
Network."Communications, China 11, no. 7 (2014): 13-23.
[5] Fei Hu ; Qi Hao ; Ke Bao. A Survey on Software-Defined Network and
OpenFlow: From Concept to Implementation." Communications Surveys
& Tutorials, IEEE Volume: 16 ,Issue: 4 (2014): 2181- 2206
[6] NOX/POX : http://www.noxrepo.org/
[7] Beacon : https://openow.stanford.edu/display/Beacon/Home
[8] Floodlight / LoxiGen : http://www.projectfloodlight.org/ floodlight/
[9] Ryu: http://osrg.github.io/ryu/
[10] Maestro : http://code.google.com/p/maestro-platform/
[11] OMNI : http://www.gta.ufrj.br/omni/
[12] Indigo:http://www.openflowhub.org/display/Indigo/
[1]

Integrated Intelligent Research (IIR)

International Journal of Communication and Networking System

Volume: 04 Issue: 02 December 2015, Page No. 4 - 9
ISSN: 2278-2427

[13] Trema: http://trema.github.com/trema/

[14] OpenDaylight : www.opendaylight.org/
[15] Open
Stack
Networking
Neuron:
https://www.openstack.org/software/openstack-networking/
[16] NodeFlow : http://garyberger.net/?p=537
[17] RouteFlow : http://sites.google.com/site/routeflow/
[18] Flowvisor:https://openflow.stanford.edu/display/DOCS/Flowvis
[19] SNAC : http://www.openflow.org/wp/snac/
[20] Wakame VDC: http://wakame.jp/
[21] Xia, Wenfeng, Yonggang Wen, Chuan Heng Foh, Dusit Niyato, and
Haiyong Xie. "A Survey on Software-Defined Networking." (2014): 1-1.
[22] Nunes, B., Marc Mendonca, X. Nguyen, Katia Obraczka, and Thierry
Turletti. "A survey of software-defined networking: Past, present, and
future of programmable networks." (2014): 1-18.