Day 18: Analysis and Results of Network Simulation

So far, we've seen how to simulate what I've claimed as a master slave distributed SDN architecture. But today, I learnt something very interesting through an SDN survey paper. What we've been simulating the past week was not only a master slave architecture, but it was also a hierarchical network of distributed SDN controllers. This will become clear to you once you read the gist of the paper that I've written below. Summary of "Distributed SDN controller system: A survey on design choice":

1. The paper summarizes different techniques used to build distributed SDN controllers. The paper starts by specifying why it is important to shift from a single SDN controller to a distributed controller architecture. The two main reasons for the same remain - scalability and robustness. Different distributed SDN controller architectures have different strengths and weaknesses. The paper summarizes each approach along with its pros and cons.
2. Many researchers right now are also looking at dealing with single point failure in a single SDN controller architecture. When this happens, the OpenFlow compliant SDN switch can temporarily be converted into a normal legacy switch and forward packets when it loses connection with its controller.
3. Distributed SDN controller architecture is characterized by how many OpenFlow packet in messages are sent from the switch to the controller for one way communication from end to end. Suppose there are two switches s1 and s2 connected to two different controllers. When s1 receives a packet, it contacts its controller with a packet in openflow message. The same procedure repeats when the packet reaches s2 which contacts c2 now. The controller installs flow tables twice for the same end to end transaction. This violates the principle of SDNs. Thus we need an architecture where once s1 pings c1, all controllers in the distributed controller architecture install their respective flows onto their switches.
4. Properties of SDN distributed network - Each controller has a network domain it administers. In case of distributed controllers, not all controllers are connected to all switches. In such a case, the controllers have to take up an extra responsibility of updating each other of the information they need to know to enable one-time Openflow table installation for end to end communication. The controllers need to share with each other the following 4 properties of the network -
1. Static properties of the network like the links and nodes
2. Dynamic properties of the network like flow tables, flow rules
3. Cross controller events - which controller is up/down, SDN application information
4. Inventory - the list of SDN applications and list of connected switches
5. East-west bound protocol APIs serve the above purpose to enable communication between controllers. This helps the controllers in the distributed network to build a global network topology from the local topology that they are aware of. They also help in load balancing in general cases and when a single point of failure in one of the controllers occurs.
6. For load balancing and other SDN network properties that demand dynamic switch-controller connection that does not need manual reconfiguration, there are two ways to achieve this. One is IP aliasing, the other is by deploying a master/slave architecture.
7. We can use a hierarchical model or a flat model to distribute the network information among SDN controllers. In the flat model each controller needs to know the global network. In a hierarchical network, only few controllers need to know the global topology.
8. Next, coming to controller coordination strategy, we can either use a leaderless mode or a leader-based mode. In a leaderless mode, each controller needs to communicate with the respective controller to coordinate the flows that each of them install in their respective switches. In a leader based approach, we can assign this task to the leader and thus it can be asymmetrical. It is essentially a cluster based architecture.

To refer to an in-depth analysis into each of these above points, I recommend you to go through the paper.

After considering the above architectural choices and their pros, cons and applications, I wanted to check how each of these architectures are resistant towards DoS attacks. Hence, through the simulation on Mininet, I have managed to extract the below graphs:

The above graph depicts # of packets seen per second vs time. The single controller architecture could sustain the attack only for less than 20s. By looking at the graph we can also come to know that since the number of packets grows very rapidly, the compute and network capabilities of the controller drop drastically. This is the reason why the sudden drop can be observed. And physically, the system almost stopped responding after 16-17s.

The above graph is plotted for a flat SDN controller architecture where there are 4 controllers, each of which are connected to 4 switches. Thus all of them possess the global view of the network. As can be observed, the number of packets flowing in from the switch to controller and vice-versa is not as high since there are 4 controllers in the network to deal with the attack packets. The system does not crash even after 540s. The observation was stopped since the parameter that mattered more - the frequency of packets was already recorded. Please note that the average no. of packets per second on an average is above 6000.

Now, we tried a hierarchical architecture in the above graph. The system starts becoming slow at around 560 - 600s, we did not wait until it crashes as we did not want to go through the recovery process each time. The number of packets per second is greater than the previous case(in the first peak) since one switch is only connected to 2 controllers. Although on an average, the no. of packets seem lesser than 6000. The extra packets in the previous architecture can be attributed to the TCP packets sent between controllers. The two controllers in the above architecture have different purposes. One controller that has a local view, the other one that has a global view. Thus the performance of the current architecture is relatively good considering the fact that we have not connected all switches to all controllers. Considering the overhead of switch-controller and controller-controller communication in a flat model, the hierarchical model can be declared a winner. The single controller was the first to be eliminated from the race, due to obvious reasons.

Thus from literature and simulation, we have observed that the hierarchical model is optimal. But when considering the switch migration, load balancing and other such activities which involve communication between various controllers, it is good to have a master to ease the process and reduce controller - controller traffic. Thus we shall use hierarchical model, where 2 controllers would know the global topo, 3-4 controllers would be limited to local domains. The 2 global controllers also act as a master to the 3-4 controllers to help in switch migration, load balancing and protection against DoS attacks. If you want a visual of this network topology, refer to the below diagram.

Figure: Hybrid Distributed SDN Controller Architecture

From the next article, we shall be talking about the hybrid network architecture in more detail. Since we have already simulated the same, we shall be looking into what east-west bound APIs should we use, what algorithms we need to run on controllers and masters to ensure smooth running of the controller network and so on.