QoS Guaranteed Network Resource Allocation via Software Defined Networking(SDN)

Quality of Service (QoS) Guaranteed Network Resource Allocation via Software Defined Networking (SDN)Anand V Akella2 and Kaiqi Xiong11College of Computing and Information Sciences 2Cisco Systems, IncRochester Institute of Technology 170 W Tasman Dr.Rochester, NY14623 USA San Jose, CA 95134 USAAbstract - Quality of Service (QoS) – based bandwidth allocation plays a key role in real-time computing systems and applications such as voice IP, teleconferencing, and gaming. Likewise, customer services often need to be distinguished according to their service priorities and requirements. In this paper, we consider bandwidth allocation in the networks of a cloud carrier in which cloud users’ requests are processed and transferred by a cloud provider subject to QoS requirements. We present a QoS-guaranteed approach for bandwidth allocation that satisfies QoS requirements for all priority cloud users by using Open vSwitch, based on software defined networking (SDN). We implement and test the proposed approach on the Global Environment for Networking Innovations (GENI). Experimental results show the effectiveness of the proposed approach.I.I NTRODUCTIONCloud computing has been one of the emerging technologies in the field of computer science and engineering. Cloud computing has varied offerings in terms of computing and data storage services [1, 2]. As per the NIST National Institute of Standards and Technology, there are different types of service models defined for the cloud: Infrastructure as a Service (IaaS), Software as a Service (SaaS) and Platform as a Service (PaaS) [3]. Cloud service providers allow cloud users to access their infrastructures without owning physical servers and data storage devices. Moreover, with the rapid growth of Internet and high-speed network devices, cloud users can access their data on the cloud from any geographical location. The benefits of cloud computing are resource sharing through virtualized infrastructures, increased storage, the high availability of resources, and the ease of resource management [4]. A typical cloud service model is shown in Figure 1.The use of multimedia applications has increased tremendously over the past few years. Internet users share the multimedia data on the cloud. Such multimedia data may come from the applications: voice over IP, video conferencing, and online gaming [5]. These multimedia applications need high computation power since the data is accessed by millions of users [5]. Cloud providers encounter several grand challenges in processing the multimedia applications [5]. One of the most important is to meet QoS requirements for each multimedia user or each user application. A multimedia application can be identified and distinguished from others based on its common characteristics such as protocol type TCP/UDP and well-known source destination port numbers [6]. However, multimedia applications are subjected to variable delays and packet drops [6]. Hence, a cloud service provider should allocate enough resources to meet QoS requirements.Figure 1. A Typical Cloud Service ModelVarious techniques have been proposed to enhance the overall QoS of multimedia applications in data centers. The proposed solutions for the QoS for multimedia applications include QoS routing algorithms [7-8]. They can be classified in the following two types: dynamic routing algorithms in which a routing path selection is done based on network link characteristics such as available bandwidth and link utilization, and static routing algorithms in which real-time link characteristics is not considered in packet routing. In both cases, very few studies have been done for end-to-end QoS guaranteed routing. In this research, we propose an approach for ensuring the end-to-end QoS guarantee of each cloud user services. The approach sufficiently considers the service characteristics of each user. It requires us to compute the end-to-end delay of each user’s service requests for the dynamic change of bandwidth allocation. We realize and test the proposed approach via Open vSwitch that is a software-based OpenFlow switch based on SDN. The resulting solutions of our approach are applicable to a variety of cloud applications and services including multimedia applications.The paper is organized in the following manner. Section 2 gives an introduction to Open vSwitch and the two queueing techniques supported by Linux and Open vSwitch. It also describes an overview of the Global Environment for Networking Innovations (GENI) testbed used in our test experiments. Related work is given in Section 3. Section 4 presents our new QoS-guaranteed routing approach. In Sections 5 and 6, we briefly discuss the methodology for our experiment design and validation based on the proposed routing approach. We finally conclude our discussion and givefuture work.2014 IEEE 12th International Conference on Dependable, Autonomic and Secure ComputingII.B ACKGROUND I NFORMATIONA. Open vSwitchThe Open vSwitch is an OpenFlow enabled software-based switch. It is open source multilayer switch software and ideally suitable for virtual environments [9]. The Open vSwitch has three main components consisting of ovsdbserver, ovs-vswitchd and openvswitch_mod.ko. The ovsdbserver is a database that contains all the switch configurations. The ovs-vswitchd is a daemon used for querying the ovsdbserver to obtain a switch configuration and interact with openvswitch_mod.ko, a kernel module. As shown in Figure 2, the ovs-vswitchd is responsible for flow lookup, port mirroring, and VLAN. The openvswitch_mod.ko is responsible for packet lookup, flow modification and forwarding. The openvswitch_mod.ko is the kernel module to perform task tunneling encapsulation and decapsulation [9]. Open vSwitch supports different features such as VLAN trunking 802.1Q, Link Aggregation Control Protocol (LACP) 802.3ad, QoS, and Netflow. Furthermore, Open vSwitch also supports limited QoS features, the Hierarchical Token Based (HTB) queueing technique, and the Hierarchical Fair Sequence Curve (HFSC) queueing technique.Figure 2. The Components of Open vSwitchB. The Hierarchical Token Based (HTB) Queueing Technique HTB [10] is a replacement for the Class-Based Queueing (CBQ) technique. Both CBQ and HTB are used to control the outbound traffic of a switch on a network link. In both of them, the lower bound and upper bound of available bandwidth is fixed in every queue. In this way, it avoids the monopolization of bandwidth by a single cloud service. HTB ensures us to allocate minimum bandwidth to every service queue and permits us to allocation the rest of bandwidth to each user’s queue based on the priority of each cloud user. For the presentation purpose, we assume that the smaller index a cloud user, the higher priority the user service. That is, a queue with the lower priority value will get the less chunk of the remaining bandwidth and vice-a-versa. The total bandwidth allocated to a queue should be within the defined bandwidth boundary.C. Hierarchical Fair Sequence Curve (HFSC) Queueing TechniqueHFSC [11] is very similar to HTB, except for the process of allocating excess bandwidth differently. It permits the proportional distribution of bandwidth as well as controls latency. The priority-type bandwidth allocation scheme in HTB is not supported in HFSC. D. Global Environment for Networking Environment (GENI) GENI is a virtual laboratory that allows researchers to conduct experiments on at-scale networks [12]. As per the cloud service model, GENI is an Infrastructure as a Service (IaaS). It allows researchers to allocate resources such as servers and storage from different geographical locations. ProtoGENI is part of the GENI implementation that allows researchers to allocate all the supported GENI resources [13]. Flack tool is a graphical user interface (GUI) framework that allows users to allocate resources from ProtoGENI. The INSTOOLS is used to monitor the network traffic of cloud services.III.R ELATED W ORKIn the network of a cloud service provider, multiple paths exist to reach a particular destination. Some paths may be underutilized. In order to meet the desired QoS requirements [7, 8, 13], we hope that the routers along the path should be able to decide whether the path is highly congested so as to efficiently utilize all available network resources in the path. The QoS routing algorithm in [7] is used to make a decision based on following two criteria: (a) Select a path with a minimal cost and, (2) perform load balancing based for available bandwidth in the routers along the path. In [8], the congestion of a network path is identified based on the end-to-end delay and Round-Trip Time (RTT) calculation of the path.A router switches network traffic onto an alternate path in case of congestion in which RTT is more than a predefined threshold.Moreover, the best QoS routing algorithms should be based on the type of application requests and the routing optimal path selection should be done such that the number of packet drops as less as possible [14]. In order for us to achieve better QoS for multimedia applications such as scalable video coding (SVC) [15], the application requests of users called layers can be split and sent through selected paths on multiple path networks. The SVC consists of two layers: base and enhancement. The enhancement layers can be sent on the network path with minimal packet drops. The base layers can be sent on the path with no packet drops. In [16], the authors suggest a QoS routing scheme for those applications that have QoS requirement without affecting the performance of the best effort traffic. The proposed approach in [14] keeps polling each and every resource to check the percentage utilization of links. Hence, this approach leads to excessive use of available resources. In our approach, we present an efficient QoS routing algorithm by taking into consideration the congestion level for the entire path such as delay, available bandwidth and a number of hops.IV.T HE P ROPOSED Q O S-GUARANTEED A PPROACHWe present the mathematical expression for a path election so as to meet QoS requirements in the cloud that serves multiple cloud users. Current studies focus on a single cloud user’s service applications. Instead, in this research we consider multiple cloud users’ service applications.Theproposed QoS-guaranteed approach consists of the following two components: (1) introduce a new metric based on bandwidth, path length or the number of hops, and RTT, and (2) the queueing techniques or policies for multiple cloud users.IV-1. The Metric for Path SelectionLet B0 be the minimum bandwidth allocated to serve a cloud user’s services and B the measured bandwidth that is actually allocated to the user. Furthermore, let T0 be the minimal RTT of cloud services and T the real-time measured RTT of a cloud service. Moreover, denote L0 the minimal length of the path to reach the destination of a cloud service from the source of a user and L the real-time measured length of the path in terms of the number of hops in the path whose value can be determined by using traceroute.We propose a new QoS-guaranteed approach for path selection by introducing the following metric:r = a * (B0 / B) + b * (T / T0 ) + c * (L / L0 ) (1) where a, b and c are constants and their range is between 0 and 1, and a + b + c = 1. The values a, b, and c are determined depending on each cloud service application. For example, for time-sensitive applications, b may be chosen as 1, and a and c may be chosen as 0. Conversely, for multimedia applications, bandwidth becomes very important. Thus, a, b, and c may be chosen as 1, 0, and 0, respectively.IV-2. Queueing Techniques and PoliciesEach cloud user may have different needs. Thus, each router need treat the network packet of each cloud user differently for ensuring the QoS guarantee of all cloud users. Thus, we propose queueing techniques or policies to consider each cloud application type, protocol type, and network ports. We classify cloud user service traffic flows as the two types: QoS service flow and best-effort service flow (simply referred as QoS flow and best-effort flow). We distinguish the best-effort flow from QoS-flow since the best-effort flow is served as the best-effort basis rather than any QoS requirement. Furthermore, QoS flow can be classified as three sub-types in this research, QoS flow-1, QoS flow-2, and QoS flow-3 that represent cloud users to make different levels of payments for their QoS requirement. We assume that the larger number, the higher priority the QoS flow is. For example, QoS flow-3 has a higher priority than QoS flows 1 and 2. At every hop, a router/switch assigns available bandwidth to serve each cloud user’s service according to the queueing techniques in Section II and the user’s network flow priority policies inside a technique by applying them at ingress ports [6]. Most existing studies focus on hop-by-hop bandwidth allocation due to the complexity of end-to-end bandwidth allocation. However, they cannot ensure end-to-end performance guarantee for cloud users. In this research, we use Open vSwitch to control and monitor the end-to-end performance of cloud user services. Therefore, our approach can dynamically adjust and allocate available bandwidth to meet the need of each cloud user. Our performance metrics include bandwidth, end-to-end delay, and the number of hops. When at least one of them does not meet predefined values in the SLA, an alternative path should be calculated via Open vSwitch. Subsequently, the cloud user’s QoS flow should be switched into the alternative feasible path where the cloud user‘s QoS can be guaranteed. In the next section, we shall investigate the performance of the proposed approach.Figure 3. Network Topology. Path 1: nodes 1, 2, 3, 4, and 6, and Path 2: nodes 1, 2, 5, and 6. This paper focuses on the research studies of Open vSwitch for resource allocation rather than a network topology. A complex topology can be similarly discussed by using the proposed approach here.A sample network topology is shown in Figure 3 where Node 1 is considered as a sender and Node 6 as a receiver. The intermediate nodes, Nodes 2, 3, 4, and 5, are switches running Open vSwitch software. There are two paths that connect the sender with the receiver. Path-1 consists of Nodes 1-2-3-4-6, and Path-2 consists of Nodes 1-2-5-6. These two paths are configured with each link speed of 100 Mbps. Generally speaking, in cloud service provider networks, network paths are often highly congested due to a large number of cloud users. The cloud service provider applies policy based on the service requested by the user and accordingly allocates resources within the network. The cloud service provider can allocate minimum amount of bandwidth to certain groups of users. If the user is willing to pay more for the service, the cloud service provider allocates the excess bandwidth. Hence, the above mentioned equation (1) checks whether the QoS flow gets the minimum assured bandwidth by generating traffic using Iperf and Netperf [16, 17] traffic generator, using ping to measure the congestion in the path and finally measures the length of the path using traceroute.V.E XPERIMENT V ALIDATIONSThe goal of this section is to implement and test our approach presented in Section IV. As shown in Figure 3, a six nodes testbed was set up to evaluate performance of the proposed QoS-guaranteed routing approach. We conducted our experiments in the Utah Emulab that is a part of GENI program [12, 13]. As shown in Figure 4, Open vSwitch, a software-based OpenFlow switch, was installed at intermediate nodes. We used Linux based traffic generators Iperf, and Netperf to write a Perl script for catching traffic performance characteristics in the experiments. We implemented a framework called flow monitor consisting of flow controller and flow client. The basic functionality of the flow controller is to fetch data from the flow client. Based onthe data received from the flow client, the flow controller will decide whether to switch a particular QoS flow on to a feasible path or not. A feasible path is such a path that sufficient bandwidth along the path is available to serve the particular QoS flow. The Flow controller selects the path using a greedy algorithm. In our experiments, we continue to search a new path until the path satisfies the QoS requirement of the QoS flow.The purpose of the flow client is to measure the bandwidth used in the particular QoS flow, congestion level and length of the entire path. That is, measured values are fed into equation (1). Based on the final value of (r), the flow controller makes a decision whether the QoS flow should use either the same service path or a new service path.Figure 4. Flow Monitor Consisting of Flow Controller andFlow ClientThe flow controller and flow client code/program are running on the Open vSwitch (OVS1) node and sender node as shown in Figure 4. The flow controller is the acting as the server waits for the flow client to connect onto the TCP port 9000. We conducted experiments to measure the performance of Open vSwitch for the testbed shown in Figures 3 and 4. Initially, we implemented three different QoS flows denoted as QoS flows 1-3 (refer to Section IV-2 for detail) for clients 1 to 3 on Nodes OVS1, OVS2 and OVS3. On intermediate nodes that are running the Open vSwitch, flows were matched with IP destination addresses and associated with certain queues id’s. Below is the command to be added to a flow. ovs-ofctl add-flow br0priority=65500,in_port=LOCAL,dl_type=0x0800,nw_proto=6 ,nw_src=ANY,nw_dst=30.0.0.13,actions=enqueue:1:2 (3) The ovs-ofctl [19] uses a default priority 65500 to match the flow. The field, in_port, represents that port where packets are ingress. Furthermore, a physical interface is part of the virtual bridge interface that is br0. The field, dl_type, matches the ether type and nw_proto matches the protocol id. In this case, TCP packet is matched. Finally, the action field indicates that the packet should be associated with a specified queue and outgoing. We generated service traffic to simulate the real-time environments for three different cloud clients with QoS flows 1, 2, and 3 and a cloud user with the best-effort service traffic. In QoS queueing policies given in Section IV-2, the minimum bandwidth of each client should be less than the overall total bandwidth of the capacity of the link along the service path, and its maximum bandwidth should be more than the capacity of the link. The link capacity of our experiments is 100 Mbps. In our experiments, the minimum bandwidth for Clients 1, 2, and 3 is chosen as 50 Mbps, 30 Mbps, and 10 Mbps, and the maximum bandwidth for Clients 1, 2, and 3 is chosen as 70 Mbps, 50 Mbps, and 20 Mbps. In Figure 3 and 4, Path 1 is highly congested with the three different QoS flows and the best-effort service traffic. Iperf [16] is used to generate service traffic.In what follows, we present a comparison of our experiment results by using the proposed approach with the ones without a use of the proposed approach. As shown in (1), our proposed approach can be realized through either delay or hop information. While the results in Figures 10 and 14 were obtained using delay as a metric or path selection, Figures 6, 9, 13, and 16 are based on per-hop information. Figures 5 and 6 show how much bandwidth is allocated to each client without and with a use of our proposed algorithm, respectively. As shown in Figure 5, the allocated bandwidth to each client except Client 2 is less than its minimum bandwidth when the proposed algorithm is not used. In this case, no QoS can be guaranteed for all clients except Client 2. We further generated TCP and UDP streams by using Netperf [17] to confirm the accuracy of the result.There are a large number of routers between cloud users and cloud providers. It is necessary to measure the per hop bandwidth of each intermediate router/hop instead of measuring the bandwidth of an entire path from client to server to ensure QoS guarantees. Measuring the bandwidth of each hop helps us to find a network bottleneck at an intermediate router. There are two open-source tools called Pathnek and STAB [20, 21] to measure per-hop bandwidth. In our experiments, we used Pathnek to measures the RTT and bandwidth at each node. Figure 6 shows the bandwidth measured at each hop for Path 1 including the intermediate nodes of OVS1, OVS2, and OVS3 between the sender and the receiver. The total bandwidth of link between sender and the OVS1 is 100 Mbps, so each client should have the same bandwidth of 100 Mbps at OVS1 node. From Node OVS1 to OVS2, different flow policies given in Section IV-2 are applied to different QoS flows. Similarly, these QoS flows policies are applied to the link from OVS2 to OVS3. As shown in Figure 6, higher bandwidth is allocated to a higher priority flow. We also conducted the experiments for Path 2. Per-hop bandwidth is shown in Figure 9.Furthermore, we measured the number of packets (i.e., throughput) that each node can achieve at a given point. Both TCP and UDP traffic are generated to represent different user applications in a real-world environment. Figure 7 shows the number of packets per second for Clients 1, 2, and 3 with different TCP flows and the client with the best-effort traffic. In the experiment, Iperf is used to generate TCP traffic for different clients in a duration of 120 seconds. The proposed algorithm is used to automatically switch available path to those clients with higher priority clients to ensuretheguarantee of QoS including bandwidth, RTT, and the number of hop. Figure 10 gives the throughputs of different TCP flows in which our proposed approach is used. For Client 1, the average number of packets per seconds was increased from 5000 in Figure 7 to 8200 in Figure 10. Similar results for other flows are observed in Figures 7 and 10. Allocated bandwidth to each client is shown in Figure 8. Furthermore, Figures 12 and 15 present the end-to-end delay of the transfer of a frame with varied sizes on TCP and UDP without and with a use of our proposed approach, respectively.Moreover, we also perform UDP traffic for Client 1 and TCP traffic for the rest of clients. As shown in Figure 13 without a use of our proposed approach, minimum bandwidth is not ensured for Clients 2 and 3 while Client 1, it is not for Client 1. Figure 11 further shows throughputs for Flows 1, 2, and 3, and best effort traffic. It clearly indicates that the average number of packets per second for Client 1 with UDP traffic was around 8000 with a frame size of about 1024 bytes. In the scenario, we also used the proposed algorithm to monitor bandwidth, RTT, and length for Flows 2 and 3 that permits us to switch Client 2 to Path 2 while Flow 1 is still kept in Path 1. Figure 14 gives a comparison of throughputs for UDP and TCP flows. As shown in Figure 14, the number of packets per second for Client 2 is increased from 1500 to 6000 when a frame size is 1514. As depicted in Figure 16, the bandwidth allocated to Clients 2 and 3 are increased as well.VI.C ONCLUSION &F UTURE W ORKIn this paper, we have studied QoS-guaranteed bandwidth allocation by using Open vSwitch. Such studies are necessary to a variety of cloud applications including voice IP, teleconferencing, and gaming. Cloud services are usually priced on a pay-per-use basis. Thus, customer services often need to be distinguished according to their service priorities and requirements. In this research, we have proposed QoS guaranteed approach to allocating bandwidth for all cloud users by introducing queueing techniques and considering the performance metrics of response time and the number of hops. We have implemented and tested our approach on GENI via Open vSwitch. The proposed approach permits us to select a path to ensure end-to-end QoS guarantees. Experimental results have shown the effectiveness of our approach. In our further study, we will implement and test our approach by using OpenFlow physical switch in at-scale networks.A CKNOWLEDGMENTWe gratefully acknowledge the partial support from National Science Foundation under grants #10656665 and #1303382 and NSF/BBN under grants #1125515 for project #1895 and #1346688 for project #1936. We are also thankful to Praveen Iyengar from RIT, Niky Riga in the GPO at BBN, and Robert Ricci at University of Utah for their helps.R EFERENCES1.R. Buyya, C. S. Yeo, and S. Venugopal, “Market- OrientedCloud Computing: Vision, Hype, and Reality for delivering IT Services” Proceedings of the 10th IEEEInternational Conference on High Performance Computing and Communications Computing Utilities, (HPCC), 2008, pp. 5 –13.2. C. N. Hoefer and G. Karagiannis, “Taxonomy of cloudcomputing services,” Proceedings of GLOBECOM Workshops (GC Workshops), IEEE, 2010, pp. 1345 –1350.3.P. Mell and T. Grance, “The NIST definition of cloudcomputing (v15),” National Institute of Standards and Technology, Technical Report, 2009.4.Craig A. Lee. “A perspective on scientific cloudcomputing” Proceedings of the 19th ACM International Symposium on High Performance Distributed Computing (HPDC). ACM, New York, NY, USA, 451-459.5.W. Zhu, C. Luo, J. Wang, and S. Li, “Multimedia CloudComputing,” Signal Processing Magazine, IEEE, vol. 28, no. 3, pp. 59 –69, May 2011.6.R. Braden, D. Clark, et.al. “Integrated services in theInternet architecture: an overview,” RFC 1633, Jun. 1994.7.J. L. Marzo, E. Calle, C. Scoglio, and T. Anjah, “QoSonline routing and MPLS multilevel protection: a survey,”IEEE Communications Magazine, vol. 41, no. 10, pp. 126 – 132, Oct. 2003.8.S. Fowler, S. Zeadally, and F. Siddiqui, “QoS pathselection exploiting minimum link delays in MPLS-based networks,” Proceedings,of Systems Communications, 2005, pp. 27 – 32.9. “Openvswitch.” [Online]. Available:/10.M. Devera, “HTB Linux queuing discipline manual - userguide.” [Online]. Available: http://luxik.cdi.cz/~devik/qos/htb/manual/userg.htm11.K. Rechert, P. McHardy, M. Brown “HFSC Schedulingwith Linux.” [Online]. Available: /articles/hfsc.en/12.“GENI” [Online]. Available: /13.“ProtoGENI” [Online]. Available:/trac/protogeni14.S. Civanlar, M. Parlakisik, A. M. Tekalp, B. Gorkemli, B.Kaytaz, and E. Onem, “A QoS-enabled OpenFlow environment for Scalable Video streaming,”Proceedings,of GLOBECOM Workshops (GC Workshops), 2010, pp. 351 –356.15.H. E. Egilmez, B. Gorkemli, A. M. Tekalp, and S.Civanlar, “Scalable video streaming over OpenFlow networks: An optimization framework for QoS routing,”Proceedings of the 18th IEEE International Conference on Image Processing (ICIP), 2011, pp. 2241 –2244.16.S. L. Spitler and D. C. Lee, “Integration of ExplicitEffective-Bandwidth-Based QoS Routing With Best-Effort Routing,” IEEE/ACM Transactions on Networking, vol.16, no. 4, pp. 957 –969, Aug. 2008.17.“Iperf ” [Online]. Available: /18.“Netperf” [Online]. Available:/netperf/19. “ovs-ofctl manual page” [Online]. Available:/cgi-bin/ovsman.cgi?page=utilities%2Fovs-ofctl.820. N. Hu, L. Li, Z. Mao, P. Steenkiste, and J. Wang.“Locating Internet bottlenecks: Algorithms, measurements,。