# Dynamic SDN Controller Load Balancing
## 2 Related Works  
The problems of how to provide enough controllers to satisfy the traffic demand, and where to place them, were studied in [4; 12; 13]. The controllers can be organized hierarchically, where each controller has its own network sections that determine the flows it can serve [14; 15; 16], or in a flat manner where each controller can serve all types of incoming requests [17; 18; 19]. In any case, every switch needs a primary controller (it can also have more, as secondary/redundant). In most networks \(N>>M\), where \(N\) is the number of switches and \(M\) is the number of controllers, each controller has a set of switches that are linked to it. The dynamic requests rate from switches can create a bottleneck at some controllers because each controller has limited processing capabilities. Therefore, if the number of switches requested is too large, the requests will have to wait in the queue before being processed by the controller which will cause long response times for the switches. To prevent the aforementioned issue, switches are dynamically reassigned to controllers according to their request rates [18; 20; 21]. This achieves a balance between the loads that the controllers have. In general, these load-balancing methods split the timeline into multiple time slots (TSs) in which the load balancing methods are executed. At the beginning of each TS, these methods propose to run a load balancing algorithm based on the input gathered in the previous TS. Therefore, these methods assume the input is also relevant for the current TS. The load-balancing algorithm is executed by a central element called the Super Controller (SC). Some of the methods presented in the literature are adapted to dynamic traffics [18; 19]. They suggest changing the number of controllers and their locations, turning them on and off in each cycle according to the dynamic traffic. In addition to load balancing, some other methods [6; 18] deal with additional objectives such as minimal set-up time and maximal utilization, which indirectly help to balance loads between controllers. (The reassignment protocol between switches and controllers is out of the scope of this paper. Here we focus on the optimization and algorithmic aspects of the reassignment process. More details on reassignment protocol can be found in [22]. For instance, switch migration protocol [22] is used for enabling such load shifting between controllers and conforms with the Openflow standard. The reassignment has no impact on flow table entries.) Changing the controller location causes reassignment of all its switches, thus, such approaches are designed for networks where time complexity is not a critical issue. However, in our work, we do consider time sensitive networks, and therefore, we adopted a different approach that causes less noise in the network, whereby the controllers remain fixed and the reassignment of switches is performed only if necessary in the ongoing TS (as detailed further in this paper). In [18; 20; 21] the SC runs the algorithm that reassigns switches according to the dynamic information (e.g., switch requests per second) it gathers each time cycle (finding the optimal time cycle duration is the goal of our future works and is not considered in this paper) from all controllers,and changes the default controllers of switches. Note that each controller should publish its load information periodically to allow SC to partition the loads properly. In [20] a load balancing strategy called \"Balance flow\" focuses on controller load balancing such that (1) the flow-requests are dynamically distributed among controllers to achieve quick response, (2) the load on an overloaded controller is automatically transferred to appropriate low-loaded controllers to maximize controller utilization. This approach requires each switch to enable to get service from some controllers for different flow. The accuracy of the algorithm is achieved by splitting the switch load between some controllers according to the source and destination of each flow.