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

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: [email protected], [email protected]

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 vendor’s 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 system’s 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 Internet’s 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: • Controller–Forwarder Interface: This interface is defined by the OpenFlow standard and is implemented by a typical OpenFlow controller. •Controller–Controller Interface: This proposed interface allows multiple controllers to share the necessary information to cooperatively manage the whole network. •Controller–Service 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 controller–controller 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 OpenFlow’s flow-based routing architecture where the controller makes per-flow decisions based on network state information acquired from forwarders, and then the controller’s 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 forwarder’s 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, Dijkstra’s 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://openflow.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]

8

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.

9