On Scalability of SDN - by Preethi PY

In SDN, Control is moved out of the individual network nodes and into the separate,

centralized controller. The controller can, therefore, have a  complete knowledge of the network to optimize flow management and support service-user requirements of scalability and flexibility.

For example, bandwidth can be dynamically allocated into the data plane from the application. Dynamic topology control (i.e., adjusting switch usage depending on load and traffic mapping) becomes possible with the global network view. Furthermore, the network programmability possible in SDN allows seamless communication at all levels, from hardware to software and ultimately to end users (network operators).

SDN challenges :                                             

                                 

                 

                                                       

Why Scalability a challenge ?

Since the SDN controllers (which are either centralized or partially distributed ) interface the

data plane located across multiple devices, they could possibly become a bottleneck to the

network. This occurs when the network is huge and many the devices try to send requests to

the controller. The scalability challenges of SDN are neither caused by nor unique to SDN. They can be solved without losing the benefits of SDN.

Control Plane Scalability :

An SDN control plane is scalable if the control plane architecture will adapt to handle more

network event requests with the increasing complexity and scale of the network without

compromising on the quality of service. There are two solutions possible :

• shift some of the intelligence of the controller to the switches so that the switches send only necessary requests to the controller. For this the switches which previously had no intelligence will be requiring a special IC's called the application specific IC ASIC). Example: Diffane and Devoflow, in which the hardware of the switch is to be modified to some extent to meet the requirements.
• Use a distributed control plane architecture so that the load is distributed over multiple controllers which communicate and coordinate with each other. Example :
• Hyperflow: it is a decentralized structure in which the controllers are arranged without ant hierarchy and each and every controller has the global view of the network.

                   

• Onix: the network view is distributed among multiple controller instances in Onix. The lower tier controller and its managed network will be aggregated as a logical node in upper tiers in a hierarchy of Onix controllers. 

                     

• Kandoo: Kandoo is a hierarchical structure. There are two classes of controllers: the root controller and the local controller. The local controller which has no knowledge of network-wide state manages one or a few of switches. And the root controller which has a global network view manages all the local controllers and can run the applications that need to access network-wide state. The local controllers are the switch proxies for root controllers.

               

Control plane scalability issues :

• Separation of Control Plane and Data Plane: When we separate the control plane and the data plane, the data plane now does not have any intelligence to make any decisions. Hence the controller and the data plane need to communicate, which brings in an extra burden of messages. Hence the control plane becomes a bottleneck.
• Distributing network state among local controllers in the same domain does not necessarily deal with security issues. However, the Internet consists of many networks managed by different authorities. Therefore, the logically centralized control model of SDN must be extended to account for inter-domain traffic. However, this distribution has to be secure, private, and consistent.
• The quantity of Events/Requests Handled by a Controller: This problem pertains more to the single controller designs than to the distributed, hierarchical or hybrid designs since it results from the centralization of computation at a single central entity. As the network grows the number of control messages sent by data plane devices to the controller becomes one point to be addressed because the controller may not be able to handle all the incoming requests.
• Controller-Switch Communication Delay: The controller's placement is also one of the reasons for the latency of the flow setup time. Flow setup time includes : 
• Switch’s packet processing time. 
•  Round trip time ( RTT ) between the controller and the data plane.
• Controller’s packet processing time. 

Hence the well-defined placing of the controller and the switches can reduce the RTT

significantly. Which in turn reduces the flow setup latency and also the time taken for

the insertion, deletion and updating of rules in the switches. The proactive mode

does not impose any latency in the flow rule setup from the controller’s point of view. In

the reactive mode, the controller response time is crucial.

Performance evaluation of a scalable SDN :

There are two important approaches towards analytical performance evaluation of computer networks:

queuing theory: it generally concerns about the average quantity at the equilibrium. Calculating the accuracy is the main target.

Network calculus: unlike the queueing theory, the network calculus deals with the worst case scenarios. It is observed that the upper bounds of the queue lengths in the local and root controllers mainly depend on upper bounds of the arrival processes and those of the local SDN controller and the root SDN controller. Given the parameters of the cumulative arriving processes and the flow control functionality of the SDN controller, the network architect or designer is able to compute an upper bound estimate of the delay and buffer requirements of SDN controllers.

An evaluation :

link: Analytical performance evaluation using network calculus

References:

1. Stefano Vissicchio, Laurent Vanbever, Olivier Bonaventure, "Opportunities and Research Challenges of Hybrid Software Defined Networks" 
2. Bruno Astuto A. Nunes, Marc Mendonca, Xuan-Nam Nguyen, Katia Obraczka, and Thierry turlett, "A Survey of Software-Defined Networking: Past, Present, and Future of Programmable Networks". 
3. Diego Kreutz, Fernando M. V. Ramos, Paulo Verissimo, "Towards Secure and Dependable Software-Defined Networks",  
4. Sakir Sezer, Sandra Scott-Hayward, and Pushpinder Kaur Chouhan, CSIT, Queen’s University Belfast; Barbara Fraser and David Lake, Cisco Systems Jim Finnegan and Niel Viljoen, Netronome; Marc Miller and Navneet Rao, Tabula, "Are We Ready for SDN? Implementation Challenges for Software-Defined Networks" 
5. Soheil Hassas Yeganeh, Amin Tootoonchian, and Yashar Ganjali, University of Toronto, "On Scalability of Software-Defined Networking"  
6. Veeramani Shanmugam, I Murray, J A Leong and Amandeep S Sidhu, "Software Defined Networking Challenges and Future Direction: A Case Study of iIplementing SDN features on OpenStack Private Cloud  
7. Hrishikesh Arun Deshpande, "Software Defined Networks: Challenges, Opportunities and Trends",