Abstract
In traditional networks, the control and data planes are integrated into a single system which makes complicated administrating and managing of these networks. Therefore, Software Defined Networking (SDN) decouples these planes using a single controller component. An SDN controller is a fundamental element that consists of applications, northbound and southbound interfaces. It also creates and manages a general view of the whole network. The increasing attempts to improve the performance of the controller have been performed, which proposed the centralized and distributed architectures for the controllers. In this paper, a service to allocate the resources to an SDN controller is proposed. Resources such as CPU and memory based on demand are allocated. In addition, to efficient use of resources when they are not needed, deallocation of resources is done. This service has been designed based on the XenServer hypervisor OpenStack platform, OpenDayLight SDN controller and their capabilities to change the resources dynamically. The results related to resource usage show that increasing the number of switches increases the number of CPUs, and memory, linearly.
Introduction
The exponential growth of network traffic shows the increasingly significant role of this technology in the recent human life. Based on the capabilities of the involved network they are categorized in three planes. These planes are: data, control and management planes [4]. Data plane is related to the network equipments which performs the forwarding function of incoming packets. Control plane presents the protocols that are responsible for filling and updating of the forwarding tables in the data plane network equipments. Management plane includes the software services to configure and monitor the devices remotely. In traditional networks, the data and control planes tightly is linked together and is embedded in a single networking device. This design method has some limitations such as the absence of non-centralized control of the current network and lack of integrity. Therefore, to decouple the data and control planes, Software Defined Networking (SDN) was proposed [2]. SDN is characterized by five fundamental traits: plane separation, a simplified device, centralized control, network virtualization and openness [4,6]. These characteristics are implemented by the SDN components. These components are SDN devices, a controller and applications. The SDN controller is responsible for abstracting the network of SDN devices. It controls and presents an abstraction of these network resources to the SDN applications running above. SDN controllers are categorized as centralized and distributed [33]. A centralized controller, e.g. NOX [24], POX [2], Mastero [8] and Floodlight [1], is a single entity which controls all networking devices. The main problems in the centralized controllers are single point of failure and scalability. Another type of controller is distributed controllers, e.g. OpenDayLight [23], Onix [12], ONOS [13], and Hyperflow [31] which controls network cooperatively. Distributed controllers overcome the single point of failure, but they cope with compatibility. In both controller types, when the wide range of flows are injected to the controllers, they may crash or create a performance bottleneck. In this condition, virtual machine and network migration may be proposed as a reliable and an efficient solution. On the other hand, the VM migration in the SDN is a complicated problem because of a VM that includes SDN controller is depended on the network conditions. The networking and routing policies, access list control, quality of service, and different networking domains isolation are depended on the virtual network topology and VM place. Therefore, the VM migration needs reimplementation of all mentioned policies that is a complicated task. This means that migration of an SDN controller creates the different challenges. In this paper, a solution to improve the performance of an SDN controller is proposed. The proposed solution, introduces a service that measures the consumed resources, e.g. CPU, and memory. Based on the achieved information and their analysis, the required resources for the controller adaptively are increased when they are needed. In addition, the extra resources are released whey they are not needed. The introduced service is implemented in OpenStack platform, OpenDayLight as an SDN controller and XenServer as hypervisor. To measure the performance, the Cbench and Mininet tools are used. The achieved results show that the increasing number of switches growths the number of CPUs and size of memory linearly. The main contribution of this paper is as follows.
Proposal of an adaptive service to increase/decrease the required resources to/from the controller. Increasing the performance and throughput of the controller by decreasing processing delay of the flows and allocation more resources. Improving of the resource consumption by releasing the extra resources.
The rest of this paper is organized as follows. In Section 2, related works is presented. In Section 3, Cloud-based SDN is described. In Section 4, proposed approach for adaptive resource allocation of SDN controller is explained. Evaluation results is presented in Section 5 and Section 6 concludes paper.
Related works
In this Section, the related researches to the SDN controllers is reviewed. As mentioned before the SDN controller is a fundamental key element in SDN architecture and are categorized as centralized and distributed. The centralized controllers such as NOX-MT [11], Mastero [8], Beacon [10], Floodlight [1] have been designed as concurrent systems to achieve the required performance in enterprise organizational networks and datacenters. These controllers use the parallelism in multi-core systems. The other centralized controllers such as Terma [30], Ryu-NOS [21], and Meridian [28] are designed for Cloud infrastructure and specialised networks. In addition, the Rosemary controller [16] achieved to the specific capabilities such as isolation of the applications, and security features.
A distributed controller can be defined as a centralized cluster of nodes or a set of distributed processing elements. The controller with a centralized cluster of nodes provides a high throughput for the datacenter while the controller with distributed processing elements operates more flexible and reliable when an error is occurred. Onix [12], Hyperflow [31], ONOS [13], DISCO [5], Yanc [19], PANE [17], SMaRtLight [26], Fleet [15] and OpenDayLight [23] are distributed controller instances. These controllers can have a global view of the network. To have this global view, they must coordinate their states to each other. When a local view of a controller is changed, this controller for coordination with other controllers must update its information. Therefore, the distributed controllers need to transfer information to each other. This data transferring consumes the network resources and creates some overheads. Hence, decreasing these overheads and creating the compatibility among controllers are main challenges in the distributed controllers design.
In [22], ElastiCon is proposed. ElasticCon is an elastic distributed controller architecture in which the controller pool is dynamically grown or shrunk according to the traffic conditions. To address the load imbalance, ElastiCon automatically balances the load across controllers thus ensuring good performance at all times irrespective of the traffic dynamics. It also proposed a novel switch migration protocol for enabling such load shifting, which conforms with the OpenFlow standard. In [7], an SDN-based management and control framework for fixed backbone networks is presented, which provides support for both static and dynamic resource management applications. The framework consists of three layers which interact with each other through a set of interfaces. It develops a placement algorithm to determine the allocation of managers and controllers in the proposed distributed management and control layers.
In [3], a control path migration protocol for distributed hypervisors is proposed. The proposed protocol provides the missing procedure that allows a dynamic change of the control connections between virtual SDN networks and the tenants’ controllers. The protocol supports the migration of OpenFlow (OF) control connections. In [20], LIME architecture is proposed. It efficiently migrates a collection of the virtual machines and the virtual switches, for any arbitrary controller and end-host applications. To minimize performance disruptions, during the migration, LIME temporarily runs all or part of a virtual switch on multiple physical switches. Running a virtual switch on multiple physical switches must be done carefully to avoid compromising application correctness. Our proposed service provides resource adaptation of CPU and memory based on their usage for the OpenDayLight SDN controller in XenServer hypervisor and OpenStack Platform. This service can be used in systems like LIME and may make it more efficient because of preventing of unnecessary migrations. In addition, the proposed service can be used with both the centralized and the distributed controllers.
Cloud-based software defined networking
Cloud computing is a new paradigm that provides scalability and flexibility features. Cloud providers prepare their services based on three fundamental models: Infrastructure as a service (IAAS), Platform as a service (PAAS) and Software as a service (SAAS). Providing these services is possible using virtual machines and virtual networking equipments. The existing traditional network architectures are not useful for Could computing environments and could not provide new requirements such as the huge number of VLANs, QoS in peer to peer communication, and load balancing [27]. Resulting the performance of datacenters is decreased. Therefore, the SDN can be used as a powerful solution to provide virtualization, dynamicity, flexibility, and new services in a secure manner. The main capabilities of the SDN in this area are related to the decoupling of the data and control planes, providing the special interfaces, applications and virtualization of the lower network layers [9,18]. In this Section the OpenStack platform, XenServer hypervisor and the OpenDayLight controller as main elements of the environment used in this paper are presented.
OpenStack platform
Regular and simultaneous management of the storage, computing and networking resources is considered as an SDN application. Therefore, the interaction between SDN and Could controller needs a platform. One of the platform that can be used for this purpose is OpenStack. The OpenStack is an open platform which creates and manages different Cloud infrastructures (public, private and hybrid) and provides network as a service using a module that called Neutron [32]. OpenStack consists of a set of building blocks which controls computing nodes, storage resources and networking devices in a datacenter. This platform includes a modular architecture as depicted in Fig. 1.
Main blocks of the OpenStack platform.
The responsibilities of these modules are in the following:
Compute module: this module is the main part of the IAAS which plays a controller role in Cloud computing and manages system resources. It also provides virtual machines and servers based on the users requests.
Swift module: this module stores the objects. Swift is a scalable storage system which stores unstructured data objects using Restfull http-based interface.
Cinder module: this module provides storage devices in block level permanently.
Horizon module: this module is the OpenStack dashboard which provides a GUI for users and administrators.
Keyston module: this module provides authentication and authorization services for other OpenStack services.
Galance module: this module stores and retrieves different disk images of virtual machines.
Neutron module: this module is an OpenStack network module that manages network and IP addresses. It also supports firewall, load balancer and virtual private network services.
A hypervisor or virtual machine manager (VMM) is a part of hardware, firmware or software that creates and runs virtual machines. Hypervisors are categorized as following types [25].
Type 1 hypervisor: these hypervisors are executed on the host’s hardware which controls and manages the guest operating systems. Oracle VM Server for SPARC, Oracle VM Server for x86, the Citrix XenServer, Microsoft’s Hyper-V, and VMware ESX/ESXi are known as type 1 hypervisor. Type 2 hypervisor: these hypervisors are known as host hypervisors which execute similar to a program on a conventional operating system. VMware Workstation, VMware Player, VirtualBox and QEMU are examples of type 2 hypervisors.
XenServer hypervisor is a type 2 hypervisor and provides the possibility of running one or multiple instances of different operating systems on a single host in parallel manner. XenServer hypervisor includes several elements [32]: XenServer hyperviosr, virtual machines, control domain (Dom0), console and toolstack.
OpenDayLight controller
OpenDayLight is an open source project hosted by Linux foundation and implemented in Java [23]. The goal of this project is to accelerate the SDN approval and is supported by 40 different companies (Cisco, Juniper, IBM, …). This controller includes multiple layers and the highest layer consists of networking applications. The middle layer is controller platform that provides a framework with different parts. This layer makes an abstraction of SDN and hosts Northbound e.g. REST API and Southbound interfaces which used by different applications. The lowest layer includes the virtual and physical devices. The architecture of OpenDayLight is depicted in Fig. 2.
Block diagram of the OpenDayLight controller. (VTN: Virtual Tenant Network, oDMC: open Dove Management Console, D4A: Defense4All protection, LISP: Locator/Identifier Separation Protocol, OVSDB: Open vSwitch Data Base Protocol, BGP: Border Gateway Protocol, PCEP: Path Computation Element Communication Protocol, SNMP: Simple Network Management Protocol) [23].
As depicted in Fig. 2, this architecture consists of 3 layers.
Southbound protocols and plugins that organize lower layer. Network service functions that organize middle layer. Network applications and northbound interfaces that organize the upper layer.
The lowest layer or southbound protocols can support different protocols and plugins such as: OpenFlow 1.0, OpenFlow 1.3, BGP_LS, LISP, SNMP, OVSDB, and NETCONF. The middle layer includes a set of management services such as topology manager, statistics manager, host tracker, inventory manager, forwarding rule manager and switch manager. The highest layer includes networking applications that controls and monitors the network behaviour.
Regarding to the large volume of incoming flows into the network, a problem is related to find the optimized paths by the controller in SDN networks. If the controller has not enough resource to handle these requests, then a performance bottleneck is created. In this condition, to achieve the required performance and high scalability, improving performance of the controller by increasing the number of CPU cores in a linear order can be an useful solution. In this paper, the CPU and memory as main resources of the controller are allocated adaptively. In this Section, firstly, the integration of SDN and Cloud is presented then the allocation of resources to the SDN controller in an adaptive manner is described.
SDN and cloud integration
In Cloud computing, the networking is seen as both a shared resource and as a part of the required infrastructure to share the other computing resources. On the other hand, similar to other infrastructures, network in Cloud computing to realize some of its requirements such as compatibility with the requirements of new applications, traffic behaviour management, scalability, and decreasing the manual configuration must be existed. This needs the advanced networking devices that without the network controller, the Cloud can not use the network resources in an efficient manner. The SDN using an abstraction layer with related API can overcome these problems. Therefore, the integration of the SDN and Cloud can prepare a powerful environment to provide the networking services. Both SDN and Cloud have similar three layer architectures, including: infrastructure, control and application layers. The SDN and Cloud can be integrated in three different ways. The first way is parallel execution of the SDN and Cloud stacks. However all applications can be executed in this architecture but it creates an overhead for the applications developers. On the other hand, the application must know the details of both SDN and Cloud which makes the complicated design and implementation of applications. The second way that overcomes disadvantages of the first way is to use a special control subsystem. This control subsystem can check the SDN devices directly. This way has also some disadvantages that limit extension of the SDN. The third way that is used in this work is to assume Cloud control system as an application in SDN. Figure 3 depicts this integrated architecture.
Cloud and SDN integrated architecture.
In Fig. 3, the Cloud control subsystem utilizes modules that translate the Cloud functions to the SDN functions. This system exploits the advantages of the second way and makes the extending of applications easier. This means that the developing of the SDN and Cloud infrastructures is possible separately. To implement the integration of the SDN and Cloud, the OpenStack platform and the OpenDayLight SDN controller is used. In the OpenStack, the Neutron module provides network as a service (NAAS) which includes a driver called ML2. ML2 transfers all the Neutron API calls related to the OpenDayLight SDN controller. The OpenDayLight SDN controller includes a Neutron API service that recognizes all data related to Neutron API calls and prepares them to other OpenDayLight services. Figure 4 depicts the execution flow of this process.
In Fig. 4, inside the OpenDayLight the related request is sent to the Neutron service. This service executes related operations using southbound protocol plugins. The communication between Neutron service and protocol plugins is performed by Service Abstraction Layer (SAL). The southbound protocol plugins implement required communication protocols such as OpenFlow, and OVSDB for the dataplane.
The OpenDayLight and OpenStack integration process is as follows. First, the XenServer hypervisor is installed on a raw physical host. XenServer can execute some number of virtual machines. One of main domains in XenServer hypervisor that is executed as a first virtual machine is DOM0. Other virtual machines are executed as DOMU or as the hosts. It is notable that a virtual machine in XenServer can be executed in either ParaVirtual (PV) or Hardware Virtual Machine (HVM) modes. The host domains that are executed in PV mode know about own virtualization and can communicate with DOM0 or XenServer directly, hence, have the better performance. The host domains that are executed in HVM mode do not know about their virtualization and hardware assumes that they are executed in real environment. After the XenServer hypervisor configuration, preparation required environment to integrate the OpenDayLight SDN controller and OpenStack platform includes the following steps.
Configuration of a virtual machine for OpenStack with all required modules: Kyston, Cinder, Swift, Glance, Neutron, and Compute. Configuration of a virtual machine for OpenDayLight SDN controller. Configuration of a separate virtual machine for execution of Compute module. Configuration of a separate virtual machine for execution of Neutron module.
After the configuration and installation of all modules, they should be tested with different situations. The integration and test of the OpenStack and OpenDayLight are summarized in the following steps.
Installation of the XenServer hypervisor.
Creation of the different virtual machines and their operating systems.
Installation of the OpenDayLight SDN controller and required modules OVSDB, VTN manager, and LISP to implement Neutron APIs.
Execution of the OpenDayLight SDN controller using related configuration.
Installation of the OpenStack with multinode option including controller node, compute node and network node.
Configuration of the OpenStack for integration with the OpenDayLight controller.
Creation and addition of different virtual machines from the OpenStack platform.
Confirmation and observation of same topology in the OpenStack platform.
Figure 5 depicts the basic architecture of required environment that has been implemented in this paper.
OpenStack requests execution flow in the OpenDayLight SDN controller.
As it can be observed in Fig. 5, the XenServer is used as a hypervisor to create the required virtual machines and SDN controller.
Basic architecture of required environment.
Two important challenges in the SDN controller design are performance improvement and scalability. At the same time, resource usage optimization is a main problem in the virtual environments. For this purpose, a service has been designed that based on the traffic load in the SDN controller can allocate different resources such as CPU and memory to the SDN controller or release these resources when they are not need. To improve the performance of controller and preventing of performance bottleneck of the SDN controller, the required resources must be allocated, when the traffic load is being increasing. On the other hand, when the traffic load to optimize resource usage is decreased, the extra resources must be released. When a physical host that XenServer hypervisor is executed on it, the whole memory by default is allocated to DOM0, then this memory is allocated to other created and executed virtual machines. In the XenServer hypervisor, after the definition of a virtual machine and the initial allocation of required resources, it is possible to change these resources dynamically. If the virtual machine is executed in the HVM virtualization mode, there is no way to communicate between the hypervisor and the virtualized kernel resulting hypervisor can not change the current allocated memory. While the virtual machine is executed in the PV virtualized mode, the XenServer hypervisor can change dynamically the allocated memory. It should be noted that in this condition, a minimum memory (512 MB) for the DOM0 must be remained. This is because, if DOM0 crashes or does not execute, then the hypervisor could not operate and memory could not be allocated. Dynamic memory management in the XenServer hypervisor is done by a special memory management unit called DMC. It is notable that this feature is existed in the XenServer hypervisor 5.6 and later. Similar to the memory, the number of allocated CPUs to a virtual machine can be managed dynamically. When a XenServer hypervisor is installed each physical CPU (CPU core) is abstracted as a virtual CPU that divides CPU cycles for each core and multiple virtual machines are allowed to access a physical core by time sharing. This means that if the number of virtual machines that uses a single shared virtual CPU is increased, less CPU cycles can be used by each virtual machine. All VCPUs are managed by a local queue on a physical CPU. This queue is ordered based on the priority of the VCPUs. Each VCPU receives a fair amount of CPU resources. Manager administrates the priorities by changing the values of CAP and Weight parameters. Weight parameter is to determine the number of cycles that a domain or a virtual machine can receive and its value is a relative value. As an example, a VCPU with the weight = 128 can receive two times cycles in comparison to a VCPU with the weight = 64. The next parameter is the CAP that determines the maximum usage rate of CPU cycles by a domain. The CAP parameter is absolute value. As an example, if a CAP value for a VCPU is 100 that means this VCPU may use 100% CPU cycles of a physical host. Using this concept, the adaptive allocation of resources by the XenServer has been implemented. The architecture of adaptive resource allocation is depicted in Fig. 6.
Proposed architecture for adaptive resource allocation.
In this architecture, three steps is performed as follows.
Load measurement by regular monitoring at the particular time slots. Decision making and investigation to suffice of current allocated resources to the SDN controller. Allocation or releasing of resources based on the condition of the previous step.
These steps are presented in Fig. 7. This algorithm, investigates the amount of resources in the SDN controller using a Get_RRD() function and performs related operations to allocate/release the resources.
The resource allocation algorithm.
In this algorithm, Get_RRD() function after the receiving the information related to the resource usage, measures the load. The CheckResizing function checks the allocation/releasing of the resources based on the value of threshold. DoResizing function performs allocation/releasing of the resources. In each iteration, some resources must be allocated or released. At the end of each iteration, it waits for 10 Seconds and then mentioned functions are checked. Subsequently, the details of each function is investigated.
In this approach, to measure the load (amount of consumed resources) the Round Robin database service of the XenServer is used. This database stores the data related to the consumed resources. This database saves the information and statistics of this host and other guest machines hosted by this host. Some information stored in this database are: total allocated memory, free internal memory, utilization of VCPUs, etc. This information can be received using an HTTP call as an XML file. For example, the following URL, can be used to receive an updated information of all executed VMs on a physical host.
This request receives updated information of all VMs on a physical host from time “
As mentioned before, this information is received as an unordered XML file that is not easy to read and interpret. Therefore, to extract the related information and organize them as a table, a parser has been designed. The Load measurement algorithm is depicted in Fig. 8.
Load measurement algorithm.
In this algorithm to measure the load, first the starting time to receive the updated information must be determined. For this purpose, a specified time by a timer that shows time slot of receiving time in the RDD database is decreased from the current time. On the other hand, using this method determines amount of the consumed resources between current time and time measured by the timer. Subsequently, to measure the load, due to this fact that a VM may use several VCPU, the CPU usage of VM is computed as the average usage of all VCPUs as:
Figure 9 presents the decision method to allocate/release of resources.
CheckResizing algorithm.
As it can be observed in this Algorithm, first different values related to the resource usage is received from the table TableR and then based on these values required decision is performed. Subsequently, a maximum and minimum threshold values to make the decision for resource changing is performed. The distance between the maximum and minimum thresholds should be large enough because of the periodic changing and oscillation prevention. After the investigation of amount of resource usage if the changing conditions (based on the threshold values) is confirmed, then the related operation to increase and decrease of CPUs or memory (DoResizing function) is done. The resource changing is as follows. The number of CPUs is increased linearly, because of performance of the SDN controller can be increased by changing the number of CPUs. In the case of memory, both coarse and fine grain methods can be used. In the fine grain method, memory is increased/decreased gradually (256 MB in each step). In the coarse grain, in each step memory is increased/decreased two times. To achieve higher reliability, the coarse grain approach is used, this is because if the required memory for the SDN controller is not sufficient, the controller will be crashed. It should be noted that the maximum and minimum values for the CPU and memory to be assumed.
This step is the last part of the our designed service that is depicted in Fig. 10.
DoResizing algorithm.
The Resizing algorithm tries to control the resource usage between the maximum and minimum thresholds. Each call of the Resizing procedure may either increase/decrease the resources or without any changes. The operations related to the increasing of resources are more important than decreasing, this is because, when the resource usage is more than the threshold, performance of SDN controller is decreased. For example, the packet processing delay may be increased with the CPU shortage, or memory shortage may be caused the crashing of controller and issues of out of memory message. While the resource usage is less than the threshold, there is not a problem with the controller performance. The only problem in this case is the utilization of resources. To execute the related commands to change the resources, an SSH service was implemented that communicates to the hypervisor and transfers the commands by our designed service to the hypervisor. The hypervisor executes related operations to change the resources. The state diagram of the adaptive resource controller service is depicted in Fig. 11.
State diagram of the adaptive resource controller service.
As it can be observed in Fig. 11, the SDN agent as an adaptive resource allocation service requests statistical data related to the resource usage from the RDD database using an HTTP request. In the next step, the related data as an XML file is received, then, for sorting and analysis of these data a parser is used. The parser sorts data as a table and the required data is sent to a function in the decision step. In the decision step, conditions related to the resource usage are investigated and related operation as scale up/down commands is sent to SSH manager. The SSH manager sends resource changing commands to the hypervisor for changing the resources. In this step, it is possible no change in the resources that is shown by No operation in the state diagram. After these steps, the timer goes to wait for a particular duration and then mentioned steps is repeated.
In the XenServer 5.6 and later, after the creation of virtual machine and determining amount of the resources, changing of the resources is possible in a dynamic manner. The XenServer uses a special management system that called DMC to change the memory dynamically. This system can be used to change the allocated memory for a VM if the created VM is in PV mode. In the CPU case, administrator can determine the maximum number of VCPUs (32 VCPUs) that can be allocated to a VM then after the booting of VM the number of VCPUs can be increased to maximum value. Actually, admin based on the information of available resources determines that how much of these resources can be used by particular VM. It should be noted that these cases do not need the rebooting of the VM.
As mentioned before, we have focused the changing of resources without rebooting of the VM that is performed by XenServer. A challenge in the VM migration is related to the working method of networking section. While in this paper the networking section is working with the existing VCPU and simultaneously the number of VCPUs is being increasing. To change the number of VCPUs related to the VM, following script is used.
The increasing/decreasing of the resources is based on the threshold value. It should be noted in the decreasing of resources case, the rescheduling is not preemptive and the packet processing tasks do not need to be rescheduled. This means that the tasks are packet processing functions with the small processing time which are processed quickly. When the load is decreased the idle VCPUs is released or the packets that are forwarded to CPU with the low load is redirected to the other VCPUs without any rescheduling.
It should be noted, in this paper, the approach has been implemented and evaluated based on XenServer. The mapping of VCPU to the physical CPUs are possible in all hypervisors e.g. KVM, VMware and Hyperv. For example, in KVM hypervisor to change the number of VCPUs related to the VM following script is used.
For others hypervisors there are similar scripts.
In addition, the system will be evaluated based on the networking load which are generated by Cbench and Mininet. The Cbench and Mininet are used to evaluate the OpenDaylight controller which is executed on the OpenStack platform. This means that the OpenStack and other modules are evaluated indirectly.
In overall, as it can be observed that the communication between OpenStack and OpenDaylight, the OpenDayLight has been replaced with the Compute node in OpnStack and performs network operations in Cloud environment. This replacement improves the scalability, programmability and flexibility of the OpenDayLight SDN controller.
Empirical evaluation
In this Section, proposed adaptive resource allocation service is evaluated. For this purpose, the performance, memory consumption and CPU usage are evaluated. For these evaluations, networks with different number of switches and the tree topology are investigated. The software and hardware specifications is presented in Table 1.
The Software and hardware specifications
The Software and hardware specifications
Two tools used in this paper are Mininet [14] and Cbench [29]. The Mininet is used to evaluate the memory and CPU usage and Cbench is used to evaluate the performance (latency) of the controller. The Mininet can create a network of the OpenVSwitchs with different sizes using tree topology quickly and these topologies can transfer to a real environment directly. Cbench works similar to the Mininet. It simulates the OpenVSwitchs and sends the packet-in messages to the SDN controller and operates in the latency and throughput modes.
To evaluate the resource usage, different switches and several experiments are tested. The used topology in this evaluation is tree topology that is one of popular topology in datacenters. For example following command in the Mininet command line creates a topology including 7 switches and 8 hosts. Where switches communicate to a controller with the mention IP address via port 6633.
OpenDayLight controller includes a network application that is called Simple forwarding. Simple forwarding allows to use a basic forwarding service that creates decisions related to the packet transferring and inserts related flows in the forwarding table of the network devices. Therefore, this application is used to evaluate the resource usage in topologies with different switches. The steps to evaluate the CPU and memory usage are as follows.
Creation of a topology with 7 switches and 8 connected hosts using the Mininet command line. Investigation of the topology creation confirmation using an OpenDayLight SDN controller GUI. Execution of the simple forwarding application using the OpenDayLight SDN controller console. Execution of the pingall command using Mininet command line (to test the reachability of pair of machines). Investigation of the flows creation confirmation and the machine learning. Evaluation of the CPU and memory usage. Repetition of the previous steps with increasing number of the switches (15, 32, …).
Figure 12 and Table 2 depict CPU usage for different number of switches.
Amount of CPU usage of the OpenDayLight SDN controller for the different number of switches.
CPU usage of the OpenDaylight SDN controller for the different number of switches
As it can be observed in Fig. 12 and Table 2, the number and usage of CPUs for different number of switches are different. For example, when the number of switches in the topology is 31 and tree topology is used, the number of used CPU is 1 and CPU usage is 76.32%. The threshold value has been set to 85%, therefore, the number of used CPU is remained at 1. When the number of switches are increased to 63, the CPU load is also increased and the number of used CPUs growth into 2. In this case, CPU0 and CPU 1 with different amount of usage are used. This procedure is similar for 127 switches and CPU0, CPU1 and CPU2 are used. As mentioned previously, changing in the number of CPUs is occurred when the average usage of all used CPUs is more than the threshold. For example, for 255 switches, the average usage of CPUs is
Amount of memory usage of the OpenDayLight SDN controller for the different number of switches.
As it can be observed in Fig. 13, increasing the number of switches increases the memory usage of the SDN controller. When the number of switches is less than 31, the memory usage is increased slowly. When the number of switches are more than 31 the memory usage is quicker and the slope of the changes is severe. In the overall, the memory usage when all 511 switches are working in comparison to the 7 switches is
As mentioned before, the Cbench works in two latency and throughput modes. Controller latency means that how much time it takes to process a single packet by the controller? In this mode, Cbench sends a single packet from a switch to the SDN controller and waits to receive the response and after the receiving response sends another request. To evaluate the latency, the SDN controller with the related configuration is configured, then the required instructions in Cbench console are executed and finally the latency is measured. Figure 14 depicts the latency evaluation of the OpenDayLight SDN controller with the different number of switches.
The OpenDayLight SDN controller throughput in the latency mode.
As it can be observed in Fig. 14, in 4 switches case 5999.36 responses/Sec is generated by the SDN controller in average. This means that for each switch 1499 responses/Sec is generated. When the number of switches is increasing the number of responses/Sec is also increased. For example, from 5999.36 responses/Sec for 4 switches is increased to 10767.24 responses/Sec for 8 switches. It should be noted that when the number of switches is increasing the number of responses/Sec per switch is decreased. For example, in 4 switches case, the responses per switch is 1499, while it is 1345 responses/Sec per switch for 8 switches case.
Figure 15 depicts the throughput of the controller in throughput mode. In this mode the controller is evaluated for the number of processed packets per Seconds. For this purpose, Cbench generates a huge traffic and sends to the controller and records the total number of received responses then computes the number of received responses per Seconds as the throughput of the controller. Therefore, the throughput is defined as maximum number of flows that controller can handle in the heavy traffic condition. As it can be observed in Fig. 15, in 4 switches case in average 52368.78 responses/Sec is generated that means 13092 responses/Sec for each switch is received by the SDN controller. For 8 switches case, in average 50718.39 responses/Sec is generated that also means 1650 responses for each switch is received. Based on these results, total number of responses for 8 switches are less than 4 switches. In 16, 32, 64 and 128 switches cases the decreasing rate in number of responses/Sec is larger. For example, in 64 switches case, 233 responses for each switch is generated. Therefore, the throughput of the controller is decreased when the number of switches is increased. This is because, increasing the number of switches increases the number of interrupts in the OpenDayLight SDN controller, and increasing the number of interrupts in the SDN controller decreases the number of handled responses by the SDN controller.
The OpenDayLight SDN controller throughput in the throughput mode.
An SDN controller is a fundamental component of an SDN network. Therefore, designing of the controller in an optimized way to improve the performance is a main challenge in the SDN. In this paper, an adaptive service to increase/ release the resources (CPU and memory) to improve the performance of the SDN controller was designed. The main reason to design of this service is because of migration of virtual machines to make an adaptive and scalable SDN controller has some problems such as flow consistency, and migration overheads. However, the proposed service can be used in the migration option in the Cloud systems and makes more efficient these systems because of the preventing of unnecessary migrations. This service has been implemented using XenServer hypervisor, OpenStack and OpenDayLight as a distributed SDN controller. Based on the achieved results, the worries on resource limitations of the SDN controllers as a key component in SDN can be overcome. The implementation results show that the increasing number of the flows causes the growth in the number of CPU cores and memory linearly. To make more efficient this system, the other networking resources such as network bandwidth can be added to the service. The proposed service can be used in other Cloud and distributed computing systems as a public service. In addition, this approach can be tested and evaluated using other hypervisors like KVM, Hyperv and VMware.