Day 5 Part 3: Elastic Distributed SDN Controller

Elastic distributed controller architecture can be described as the architecture in which the controller pool is dynamically grown or shrunk according to traffic conditions and the load is dynamically shifted across controllers.

This paper achieves the following:
  • A basic distributed controller architecture
  • A protocol that helps in switch migration for elasticity
The basic architecture proposed here is very similar to the one presented by the cluster based distributed controller paper. But here are the differences:
  • Each switch has many equal controllers and many slave controllers
  • Each controller node maintains a TCP channel with every other controller
  • A controller may use this channel to send a message to a switch connected to another controller
  • This is how the migration is made easier
  • application state is maintained in each controller to facilitate switch migration and fail over recovery

The Unique Switch Migration Mechanism

The mechanism is as follows:
  • check and make the new master controller as an equal controller if it wasn't already
  • current master controller adds a dummy flow and deletes it. When the flow gets deleted, the delete message goes to both current and new master controller and thus communication as equals is established
  • something called a barrier request and reply is made between the current master and switch to say that they will end communication as master - switch. 
  • a role request from the new master is sent to switch to establish the fact that it is the new master
The normal way of first associating the new master as equal and then terminating the old master controller communication might not work. This is because once the new master takes over, the switch can override the commands sent by the old master controller.

Comments

  1. As I understood from earlier description, the job of master controller is just to keep mapping of switches to controllers. If it is keeping flow table entries, then I am unclear on how the hierarchy will work as this master controller would become a bottleneck in terms of resources/

    ReplyDelete
    Replies
    1. Earlier I had thought that master would maintain only the mapping. But since communication from one controller domain to another is not possible without another controller that knows the whole network, I have added the feature to the master controller from here on. So, the conclusion is: yes, the master controller will receive OpenFLow PCK_IN in cases of cross controller domain. This is the reason it will act like any other controller in the architecture. Only, it has access to all switches and not restricted to one domain.

      Delete
    2. In the further articles, I have accounted for bottlenecks in the master controller as well.

      Delete

Post a Comment

Popular posts from this blog

Day 12: Master Slave SDN Controller Architecture

Day 1: Understanding Ransomware and how to detect them?

Day 50: Tcpreplay and tcpliveplay approach