Benefit Evaluation

To evaluate the benefits of having a Distributed Control Plane across a cluster of SDN controllers, a testbed was deployed, and experimental tests performed in order to benchmark the proposed solution. In the following text, the testbed is briefly described, and the performance evaluation results presented and discussed, for more details please refers to the contributing author publication “Distributed control

in virtualized networks”.

Figure 11 Testbed Architecture

To evaluate different distributed Control Plane scenario’s performances, different configurations are deployed. A first test is performed to evaluate the benefit from adopting a Distributed Control Plane with a cluster of 2 controller instances against a single Controller scenario.

When multiple controllers are available a switch may connect to all. For example, a cluster with two controllers can be arranged in the following testing scenarios:

▪ Single Connection: all the switches are connected to one instance of Controller (see Figure 12); ▪ All Connection: all the switches are connected to all the instances of Controller (see Figure 13); ▪ Selective Connection: there are two Controllers and the first 13 switches are connected to the

34

The second scenario is the more interesting from a control point of view. Using the default implementation of the distributed control plane provided by the OpenDaylight we are evaluating the behaviour when every switch sends the packet-in control message to more than one controllers; just one controller should answer to the request while the other one should ignore it.

Figure 12 Single Connection Testing Scenario

35

Figure 14 Selective Connection Testing Scenario

3.2.1.1.

Testbed Setup

The following software components are integrated into such testbed:

▪ OpenDayLight [8], the SDN controller most adopted and supported by the industry and Open Source community;

▪ Mininet [22] a networking testing suite that provides Python APIs able to virtualize custom networks;

▪ Open Virtual Switch (ovs) [23], "a production quality, multi-layer virtual switch licensed under the open source Apache 2.0 license".

▪ Open vSwitch Database Management Protocol (OVSDB) [24] for the operation management of the virtual switches.

The testing environment (see Figure 11) is composed by a SDN controller cluster of 2 instances and 26 virtual switches. Every switch Si is connected to the Si+1 switch and to the host Hi that incorporates a data traffic generator. To stimulate the switches to generator control traffic, each host generates ARP requests.

The control traffic is generated by the switch when there is no flow entry for an incoming data packet (the ARP request) that the host wants to send. Hence, the switch encapsulates the data packet in a control packet (Packet-In message) and sends it to its controllers. Then, exactly one controller should send a message containing the flow entry (the Flow-Mod message) that the switch will install in its table. The performance is then evaluated by counting the packet-in and flow-mod messages exchanged between the switched and the SDN Controllers.

36

3.2.1.2.

Evaluation Results

Figure 15 depicts the 95-percentile response time of the 3 cases described above. As expected, the difference between a cluster with one controller and one with two is noticeable as the number of packet- in increases. The difference between the All connection and the Selective connection case becomes relevant when the number of packet-in/s is greater than 40,000. From 50,000 the last connection scheme clearly outperforms the first.

Similar results are reported in Figure 16. When the network load is high the throughput of the Selective test is the highest one, being 66% greater than the one in the All test scenario and 100% greater than the one in the Single test scenario.

The results clearly highlight the benefits of the multi-controller configuration, and particularly of the selective connection configuration. In the case of single connection, the unique controller instance saturates at approx. 20.000 pin/s. When adopting the all connection configuration, the two controller instances receive the requests from all the switches, which causes a performance saturation at approx. 30.000 pin/s, that is a +50% performances against the single connection configuration. It is worth to note that adopting the selective connection configuration, the performance saturation goes beyond the 40.000 pin/s, that is a +100% performance against the single connection configuration and a +33% performance against the all connection configuration).

We can explain these results considering that in single connection configuration we have half of the computation power, since just one instance of the controller is operative. Increasing the number of operative controllers, influences the performance, but the switch-to-controller association strategy makes the real difference in performance. Indeed, with an all connection configuration, even if there are two controllers operating at the same time, each controller receives requests from all the switches. In the selective connection configuration, each controller receives requests only from a subset of the switches, so each controller can handle a higher number of requests.

On the light of the above results, we can make some considerations:

▪ increasing the cluster size may improve the performance but this has relevant results only in congested situations, when the load of control plane requests saturates the single controller processing capabilities. The drawback of increasing the number of CP instances is the need of more computation power and related increased operational cost;

▪ the load of control plane is variable and often unpredictable, being strongly related to the amount of control messages exchanged between switches and controllers. Therefore, a dynamic mechanism able to keep balanced the traffic across the whole control plane is needed.

37

Figure 15 95-percentile response time comparison between the Single, All and Selective configurations

38