Taxonomy

Previous work in the area of controller load distribution are all implemented within the control plane and can be divided into two sections: centralized and distributed decision making.

Centralized Decision Making: Centralized controller load balancing systems use a hierarchical approach which involves a decision-making controller selected out of the pool of controllers. In each case, this lead controller is tasked with balancing the flow request load among the other controllers as best as possible to ensure the imbalances are kept as small as possible. Each switch in [168] is connected to one controller. The head controller here, monitors each controller’s load and the traffic in the network. It then dynamically maps and remaps as necessary the switch- controller pairings to ensure one controller is not receiving an unreasonably high number of flow requests while another is idle. Rather than remapping switches and controllers, Balanceflow [169] handles its load balancing at the flow level providing a far more fine-grained approach. Its head controller here monitors the number of flow requests received by each controller and rectifies imbalances by placing rules in each switch with instructions for distributing its flow requests to various controllers. The flow requests here are differentiated by IP address with the rules indicating to which controller flow requests involving a certain IP address should be sent. By load

balancing via distribution of flow requests rather than distribution of switches, the methodology here allows for more precise load balancing.

While a centralized intelligence within a distributed control plane allows for ef- ficient co-ordination among the controllers, it may be less practical in the face of a sudden onset high volume attack. An inherent problem is that such systems are only as good as the head controller’s ability to react. If the head controller polls the other controllers repeatedly, there is a tradeoff between reaction time and the number of messages in the system. If it polls often, it may be able to react quickly but the number of messages between the controllers increases drastically as the rate of polling increases. If the polling is infrequent, the head controller may not react quickly enough and network performance is reduced.

Distributed Decision Making: Several other systems perform load balanc- ing without the use of a centralized authority [170][171][172][134]. The preferred method of load balancing in each is to dynamically find the best controller switch pairing in the network to ensure all the controllers manage similar loads. [172] uses a one-to-many matching game to calculate optimal pairings, considering a mini- mum utilization of processing capacity that each controller must achieve and the maximum possible processing capacity of each controller as factors in the game. Switches can dynamically vary the controller they attempt to connect to but con- trollers have the final say on whether they will allow a switch to connect based on the switch’s load and their current capacity. This system does not include inter- controller communication as each controller operates independently of the others. This raises questions about the controllers each keeping a consistent view of the network which the others solve by including a communication system. Both [170] and [171] use JGroups to send messages between controllers. [170] collects load infor- mation about other controllers in the network when under high loads and hands off switches to under-loaded controllers to relieve itself and rebalance the network load. By contrast, the controllers in [171] proactively and periodically inform each other about their loads to allow for a faster handover when overloaded rather than polling when they exceed a given threshold. Instead of a one-to-many mapping, [134] uses a many-to-many mapping in which each switch has several controllers connected to it in a MASTER-SLAVE configuration. In the event of a switch’s master controller becoming overloaded, the MASTER controller initiates a process to swap with one

of its SLAVE controllers.

With the exception of BalanceFlow, the solutions aim to balance the load on the controller by remapping the switches and controllers. While this may work under benign traffic surges, the problem with this under an intentional high-volume attack aimed at overloading the controller is that it may simply transfer the attack from one controller to another without actually relieving the problem. This methodology either causes the new controller in charge of the switch in question to be overloaded or in a worse scenario, causes a high amount of churn in the network as the switch under attack is passed from controller to controller, causing each new controller to be attacked in turn. Another problem with controller based solutions is that high volume attacks cause congestion in the controller-switch channel making passing instructions to switches very difficult. For example, [134] takes 12 messages to com- plete its controller exchange. None of these are sure to be delivered if the attack is clogging the channel. Depending on the controller to issue instructions to the switch while under attack itself may as well prove to be problematic. In either case, the problem with the solution is that it may never arrive where it is needed.

With these issues in mind, we propose to place the load balancing solution in the switch. Deploying defenses at the switch level provides an opportunity to tackle saturation attacks earlier and provide better defense. Our load balancer is inserted directly into the switch and distributes the flow requests among the available con- trollers. Similar to BalanceFlow, our load balancing is performed at the level of the flow request, rather than at the switch level. It does not add further control messages to the network to poll the statuses of controllers, nor does it require a centralized decision maker as each switch is capable of distributing its loads independently.