Design and Implementation of a Load Balancing Algorithm for a Clustered SDN Control Plane - Slides

Editor's Notes

• #2: Good morning. My name is … I am goning to present…. My supervisor is professor
• #3: My thesis is part of TNOVA project co-funded by the European Commission under the Seventh Framework Program TNOVA promotes supports the Network Functions Virtualization that make use of SDN architetecture. Some of the partners involved in the proj are Our University, University of Milan, University of Zurich and big companies like HP and Intel
• #4: What is Software Defined Networking? It is an architecture that decouples the control logic and the forwarding logic. Thanks to that a single controller may control multiple network devices, in this way the the control becomes centralized. The network devices are programmed using specific API. On the right side there are the main components of the SDN architecture. The data plane contains all the network devices. The control plane provides basic functionalities and abstracts the undelaying layer. Finally, in the application plane there are the applications that make use of the functionalities provided by the control plane to provide enhanced network serviced. These applications may communicate with the control plane using RESTfull APIs. one of the most used standard and southbound API is OpenFlow. It is mainly used to install flow entries in all network devices. Every entry instructs the device what to do when it receives a data packet. While Openflow ……OVSDB is an example of management protocol that is able to create, remove and configure virtual devices.
• #5: This is an example of use of SDN. All switches may connect to a single controller using OpenFlow. In this example suppose that the host in the red box sends a packet to another host. Suppose that the switch it is connected to does not know what to do with the packet. Hence it encapsulates the packet in a control packet called packet-in and sends it to the controller. This one sends to the some application that wants to receive this kind of asynchronous messages and then that application will answer with a message that requests the install of a entry that will be used for data forwading. We may have a problem because these asynchronous messages are often unpredictable and may overload the controller. For this reason
• #6: We may want to have multiple controllers. A solution could be a static assignment of the switches based on some statistics. However overprovisioning may be need, and a better solution that avoids this is to move one switch(and its generated load) from one controller to another one. For this reason I devise a load balancing algorithm.
• #7: The following will be the main steps of my balancing algorithm. Initially one cluster controller collects statistics from all controllers about the last interval of time(e.g 4 sec). The statistics about one controller include: the average CPU load and the number of messages received from every switch connected to it. Next the algorithms computes the average CPU load of the entire cluster. Using this avg divides the controller in overloaded and non overloaded. After this it divides all switches connected to the overloaded controllers in classes of load. Finally, it fills every non overloaded controller up to the cluster average load with the best switches that fit that space. I used 2 thresholds to minimize the number of migrations . “Threshold minimum transferred load” is used to block the migration of switches that generate a load smaller than the threshold. “Threshold imbalance margin” is used to increase the avg cluster load when the controller are divided in overloaded and non overloaded.
• #8: For a better understanding this is an running example. Here there are 4 controllers. For the sake of simplicity I assume that all controllers have the same computational resources. This is not a requirement since load conversions are not difficult. The blocks inside each controller represent the switches connected to it. The block size and the number between parenthesis indicate the load generated by that switch to its controller. The cluster average load is about 46 and c1 and c2 are the overloaded controllers. The switches connected to them are divided in classes of load: for example in the class 30 there is the sw3 and sw6. In the next step for c3 the algorithm finds the best fit class load. This is 10. Hence sw4 will be moved to c3. In the same way for the lack of c4 25 is the best class and Sw7 will be moved to c4. The output of this algorithm are the migration that have to be executed. For this reason we need a good migration algorithm.
• #9: I propose a migration algorithm for OF 1.0 that is the most diffused version. We want a seamless migration of a switch X from controller A to controller B. This means that we want to avoid message losses and don’t want that the switch receives duplicated responses. X is initially connected to A that is also its master(namely the one that should replay to its packet-in messages). Since we want to migrate X to B, X should connect to B. The problem is that in OpenFlow 1.0 X sends the packet-in to all controllers it is connected to. The default default behavior of the controller is to answer to the request. But this generates duplicated responses. To solve this I used a distributed cache that stores the master controller for every switch. Here the master of X is A. Changing the cache entry is not enough because we may have both losses and duplicates. Here are the main step of my migration algorithm.
• #11: This is the testing environment. I use 3 quad core computers and a gigabit switch. A and B have been used to run OpenDaylight controller and Mininet to emulate a network. Here there is the logical topology. I created an application that generates data packets. It runs on every host. Each data packet triggers a packet-in message that is sent to the controller. In the upper layer there is a controlling application that answers to packet-in messages.
• #12: Here I measured the benefits of load balancing. For the sake of simplicity, every switch sends the same number of packet-in. I choose a 6 – 2 imbalance because this is common. In the test I vary the number of messages and I measure the 95-percentile response time before balancing and after balancing. The black line is the response time before activation and the blue one after activation.
• #13: In a future work I should deal with
• #15: Add a new controller
• #17: Selective ,all