services from multiple providers using a generic gateway. The cloud networking gateways are managed by the CNG Manager that handles allocation and ...
SDN for Inter Cloud Networking Marouen Mechtri†, Ines Houidi‡1 , Wajdi Louati‡1 , Djamal Zeghlache† †Institut Mines-Telecom, Telecom SudParis, UMR CNRS 5157, Evry, France ‡National Engineering School of Sfax, Tunisia †Email: {marouen.mechtri, djamal.zeghlache}@it-sudparis.eu ‡Email:{ines.houidi, wajdi.louati}@gmail.com
Abstract—This paper presents a Software Defined Network (SDN) controller, called Cloud Networking Gateway (CNG) Manager, that enhances networking of distributed cloud resources and provides authorized customers with the ability to control and configure networks. The CNG Manager interconnects virtual machines acquired from distributed heterogeneous resources and services from multiple providers using a generic gateway. The cloud networking gateways are managed by the CNG Manager that handles allocation and configuration of the gateways according to connectivity requirements. Our implementation of the CNG Manager and the gateway is combined with an exact splitting algorithm and integrated in a cloud services provisioning system. The CNG Manager and the associated gateway extend the current state of the art by applying the SDN principle to connectivity control of distributed and networked cloud resources. Index Terms—Cloud Networking Gateway Manager; CNG; cloud broker; request splitting and provisioning
I. I NTRODUCTION This contribution addresses the networking of distributed cloud resources and services from multiple providers. The networking of virtual resources dedicated to applications, end users or tenants needs more attention to facilitate and automate the establishment of inter providers links and more specifically the control, configuration and instantiation of connectivity to take full advantage of compute, storage and network virtualization. The cloud community started to address networking requirements in OpenStack Neutron [1], for instance, but continues to put the priority on intra data center networking. Cloud users can control and manage their applications but have no control on the connectivity and networking of their dedicated and distributed cloud services. Network providers, users and tenants need more flexibility in deploying, configuring and instantiating cloud networking services to manage more easily and efficiently their resources. To provide this desired control of connectivity, a Software Defined Networking (SDN) solution is proposed to handle inter cloud networking. SDN [2] is a network architecture and design that decouples data-plane forwarding from control and management plane functions. The SDN paradigm enables the transparent integration of applications provisioning in clouds and networks via programmable interfaces and automation. 1 Ines Houidi and Wajdi Louati contributed initially to this work while at Telecom SudParis and more recently as faculty members of National Engineering School of Sfax.
The proposed networking architecture can be seen as an SDN controller built around two main components: a) an SDN controller called Cloud Networking Gateway Manager (CNG Manager) and b) a virtual and generic appliance acting as a gateway between user resources (named Cloud Networking Gateway, CNG). The CNG Manager deals with physical and virtual network resources to establish connectivity between virtual machines acquired from distributed cloud providers. The CNG Manager establishes connectivity between user resources regardless of connectivity type (data centers connected via a dedicated link or using the Internet). The CNG Manager ensures the connectivity in a non-intrusive way that preserves the network configuration of cloud providers. The CNG Manager and the gateway appliance, the CNG, are evaluated through an integration with a brokerage and provisioning system that decomposes user requests (expressed in the form of resource graphs) into sub-requests (or subgraphs) across selected candidate providers via a splitting algorithm. The broker first splits the request and indicates how the subgraphs should be individually build and linked to the CNG Manager that takes care of the instantiation in the second step. The goal in this paper is to assess this second step, the instantiation phase of the networking of the selected distributed resources from the providers. The providers process the portion of the request they receive by building the required VLANs corresponding to their respective subgraphs using existing cloud managers such as OpenStack [3], OpenNebula [4],... This is depicted in Figure 1 that also shows that the CNG Manager controls and configures CNGs to establish the inter data center connectivity to compose the overall graph corresponding to the original user request. As previously mentioned, the focus of this paper is on the inter-domain, inter-provider or inter data center networking, especially on the required CNG appliances deployment and configuration and finally the instantiation needed to fulfil the inter-domain links establishments. The organization of this paper follows the steps depicted in Figure 1, starting from the cloud broker framework description in section II. A short version of an exact request splitting algorithm originally presented in [5] is described in more details and evaluated in section III. This min-cut maximum flow algorithm splits the user requested graphs into smaller graphs to be hosted by the selected providers that use cloud managers to establish their corresponding VLANs (that achieve
Fig. 1.
Cloud Brokerage Architecture
interconnection of the subgraphs nodes or service components). This intra-domain networking is found in section IV while section V focuses on the cloud networking architecture proposed in this paper for deploying and interconnecting the user distributed service instances. Related work is discussed in section VI. II. C LOUD B ROKER F RAMEWORK Cloud service brokerage is a promising concept for enhancing service delivery over large scale heterogeneous cloud environments [6]. Cloud Brokers act as intermediaries between cloud providers and customers to negotiate and allocate resources among multiple data centers [7], [8], [9], [10], [11], [12]. This creates a marketplace where cloud providers can offer their services with different capabilities and pricing models. Customers (clients, enterprises, etc) allocate services from the marketplace using unified interfaces and APIs offered by the Broker. Since similar services may be offered by the same marketplace, the broker assists customers in selecting and choosing the cloud platform that best suits their requirements and needs. This is referred as the cloud service arbitrage [6] offered by the broker to provide flexibility and opportunistic choices to customers. Figure 1 depicts the broker framework and describes a scenario where a Cloud Broker interacts with two Cloud Providers for cloud services provisioning. Each Cloud Provider uses a Cloud Manager (such as OpenStack [3], OpenNebula [4], etc) installed in its data center to allocate and manage their cloud resources. A Software Defined Networking approach using the CNG Manager is used to interconnect the cloud providers over network infrastructures.
The user, asking for infrastructure cloud services (or IaaS), formulates and sends requests to the Cloud Broker in step 1 in Figure 1. The Cloud Broker in co-operation with the Cloud providers responds to the cloud request. The request may have a complex topology composed of a set of requested nodes and their desired interconnections (i.e. requested links). The request is modeled in this work as a weighted undirected graph Gr = (Nr , Lr ), where Nr is the set of required nodes and Lr is the set of required links. Each node nr ∈ Nr is associated with a set of node requirements such as compute capacity, amount of memory, type of OS desired, imposed location, etc. Each requested link lr ∈ Lr is associated with a set of link requirements like minimum bandwidth, link type, QoS constraints, etc. The Cloud Providers should first advertise, to the Cloud Broker, properties and characteristics of their offered resources including their prices, type, locations, availability, etc. The broker will match user queries with cloud resources published and offered by the cloud providers. The broker then splits the request across the cloud providers, acquires the required resources from each provider and sets up the inter-cloud networking via some networking system (the CNG Manager Framework in our case). As shown in Figure 1, the brokerage framework is composed of three main components: •
Cloud Request Splitting: that splits the Cloud request graph into subgraphs to acquire from selected providers while satisfying performance, quality objectives and costs imposed by the initial user request. The optimization criteria may include prices, revenues, QoS and security aspects. Our contribution focuses on reducing cost for
customers, or equivalently minimizing prices proposed by the broker. The splitting is part of the Cloud Broker arbitrage function that decides where and how to distribute services related to the users’ requests across providers. • Resource Provisioning: that interacts with providers’ Cloud Managers to compose their subgraphs. • CNG Manager: that sets up and configures the intersubgraph links over the network infrastructure. the CNG Manager establishes and controls the required inter-cloud networking to assist the Broker aggregation function . The request splitting and the provisioning phases (steps 2 to 6 in Figure 1) are described in sections III and IV.
Fig. 2.
Request Splitting
III. C LOUD R EQUEST S PLITTING We describe here one possible splitting algorithm, being aware that there is a plethora of methods of approaches to achieve splitting - a facet that is out of scope of this paper. We limit ourselves to our own algorithm to show how splitting can be performed. Recall, that the focus of this work is the configuration and instantiation of the network graphs. Upon receiving the user’s request, the Cloud broker finds for each requested node nr several matching candidates in the multiple data centers. The same cloud service can be offered by several providers with competitive prices and the goal of the broker and the splitting is to select the most appropriate ones to compose the solution. The cloud broker thus decides to which cloud provider each requested node should be sent for matching and selection. The aim is to efficiently split the request graph into sub-graphs that will compose the request for each target cloud provider. The Request Splitting module finds the best and optimal request splitting among the multiple cloud providers while minimizing the cost for the users. The price proposed for a given request is equal to the sum of the prices of the nodes and links provided by the selected cloud providers.
that satisfies the user requirements with a minimum price can be modeled using a 0-1 quadratic program where a variable xi is considered for each requested node i. Variable xi equals to 1 (or 0) if i is allocated by p1 (or p2). The quadratic program for graph splitting is expressed as: ⎧ min (xi Pi1 + (1 − xi )Pi2 ) + (xi xj Pij11 + (1 − xi ) ⎪ ⎪ ⎪ i∈N (i,j)∈N r r ⎪ ⎨ i
