The controller is the backbone of the software-defined network (SDN). So neuralgic that different approaches exist with ceaseless innovations in terms of proposed solutions. The separation of the data and control planes is an integral part of the notion of SDN. The emergence of this concept constitutes an incredible breakthrough in the field of networks with notions of efficiency, flexibility, responsiveness, value for money and automation. All these advantages are intrinsically linked to the controller. The latter is indeed the cornerstone of the SDN so much so that it is essential to define its boundaries.
Software Defined Network (SDN) makes networks programmable through a controller and API (Application Programming Interface). By virtualizing the network, SDN de facto adds a level of abstraction to the functionality of devices, such as routers and switches, to optimize deployment and performance. Intelligence is therefore pushed into the controller, the real backbone of the virtuality network.
Network plasticity
The SDN controller embeds “pluggable” modules capable of performing various tasks, such as device inventory, collection of network statistics, etc. Extensions can also be added in order to offer even more advanced functionalities: execution of algorithms to perform analyzes or orchestrate new rules across the network.
The controller thus makes it possible to orchestrate a myriad of tasks on the network. This results in a very high speed of deployment of these. If the flexibility and responsiveness provided by the controller are therefore the prerogative of the SDN, the controller also results in a very high plasticity of the network which can be modified on the fly to support more loads.
It’s safe to say that the SDN controller takes on the role of the operating system (OS) of the network. By removing intelligence from the equipment and running it as software, it facilitates automated network management as well as the integration and administration of business applications. An SDN controller is therefore a real virtual brain of the network and offers administrators a better view of all processes. It helps reduce operational costs, increase reliability and operating stability, and improve overall efficiency.
Southbound and northbound API
The interaction between the controller and deployed equipment is commonly referred to as the southbound application programming interface (API), the most popular open source protocol being OpenFlow. The first SDN controller was called NOX, originally developed by Nicira Neworks with OpenFlow precisely. Other protocols that can be used by a network controller also include OVSDB, YANG, and NetConf.
At the opposite end of the spectrum is the northbound API, which oversees the communication from a business application to the controller. Northbound interfaces offer enormous possibilities for network programming, such as building applications that can automate all networking tasks.
Manufacturer solutions vs Open Source
Based on Java and derived from the Beacon design, OpenDaylight (ODL) is the controller of the Linux Foundation. It upholds OpenFlow and other southward APIs (like Cisco OpFlex) and incorporates basic highlights like high accessibility and bunching. Other players are working on alternative solutions. For example, an Internet Engineering Task Force (IETF) working group called i2rs is developing an SDN standard that allows a controller to use proven traditional protocols, such as OSPF, MPLS, BGP, and IS-IS.
A battle rages on between network vendors, who want to provide their own SDN controllers to deploy their equipment (and potentially third-party equipment), and open source controllers, designed so that all vendors can support them.
Be aware that the type of protocols supported can greatly influence the overall architecture of the network. For example, while OpenFlow attempts to completely centralize packet forwarding decisions, i2rs splits decision making by leveraging traditional routing protocols to perform routing in a distributed fashion and allow applications to change decisions by matter.
Distributed control path
The network industry has widely debated the advantages and disadvantages of highly centralized network architectures as opposed to highly distributed ones. In general, the concept of centralization is synonymous with speed and simplicity in management. Decentralization comes with scalability and redundancy.
The first approach is the centralized controller. In this specific case, a controller manages all the routing elements of the system and maintains a global view of the entire network. The second approach is the distributed control path. In this case, a local controller runs on each compute node and manages the transfer element directly and locally. Thus, the control plane is distributed over the network. However, the virtual network topology must be synchronized across all local controllers, which is done using a distributed database.
While the centralizing option was the norm in the early days of SDN, several factors are now leading organizations to consider the other option. In particular the issue of high availability. This is a critical point because, in SDN, any failure of the controller (if it oversees the entire network) becomes critical. Indeed, if an attack compromises the single controller, all network management is then potentially lost.
Field Engineer is an online marketplace that connects businesses who have jobs with Telecom Engineers who have the skills and availability to complete them.
