SDN Controller Architecture

This site has been moved to https://cloudifynetwork.com/

     

In the SDN primer blog post, we touched upon the basic building blocks of SDN. In this post we will try to outline how an ideal controller should look like taking a high level look at the SDN controller architecture. Please note that this is just a high level schema and a lot can be implementation specific. We will try to go through some examples as well.

As shown in the above figure, SDN spans multiple layers. Given below is a snippet of the different layers which forms the SDN.

Forwarding Plane - Handles the packets in the data plane based on instructions from the control plane. The forwarding plane can decide if the packet has to be dropped, if not which next hop to send or at what priority the packet should be sent out etc.

Operational Plane - Manages the operational state of the network device. For example, whether the device is active or inactive, the number of ports available, the status of each port and so on. It is debatable if this can be considered as a plane or a function within the forwarding plane.

Control Plane - Makes decisions on how packets should be forwarded by one or more network devices and pushing such decisions down to the network devices for execution. While control plane focusses more on forwarding plane and fine tuning the forwarding tables, it may be interested in operational plane information as well. However, it is fair to say that control plane focusses more on forwarding plane and less on operational plane. It uses southbound protocols such as OpenFlow, BGP, PCEP or XMPP to provision the forwarding plane.

Management Plane - Responsible for configuring, monitoring and maintaining network devices. The management plane focusses more on operational plane. The management plane may be used to configure the forwarding plane but this could be more a bulk provisioning than the ones done by the control plane. This is generally achieved by using  protocols such as NETCONF, SNMP, CLI, etc.

Application Plane - Customer applications and services reside in this plane. This generally talks to the control plane over northbound APIs using protocols such as REST, RESTCONF, NETCONF etc. Applications can span across both control plane and management plane and thus utilise both control plane southbound interface and management plane southbound interfaces. Applications can also receive analytical data from the Control plane and use it in their business logic and algorithms.

In addition to the above planes, Abstraction layers between these planes enables the smooth interaction between them. It hides the complexity of the infrastructure layer and controller from the applications. We can consider the below abstraction layers as part of the SDN implementation.

The Device and resource Abstraction layer (DAL) abstracts the resources of device’s forwarding and operational planes to the control and management planes.

The Control Abstraction layer (CAL) abstracts the control plane southbound interface and the DAL from the application plane.

The Management Abstraction layer (MAL) abstracts the management plane southbound interface and the DAL from the application plane.

The figure below gives a more simpler architectural view of the SDN controller.

Any production implementation of SDN controllers will expect High Availability,Resiliency, scale-out and performance. Building an SDN controller should be done keeping in mind such distributed system architecture. This alone does not solve the problem.

The controller should also be able to support a diverse set of devices on the southbound and be able to accommodate customer and application developer use cases without compromising on the above said parameters. Controllers, such as Opendaylight, have a plugin architecture, making it easy to support multiple southbound protocols.

SDN Implementation Models

Pure vs Hybrid SDN

The switches and routers can process packets in 2 ways.

• Pure: Where every packet is sent to the controller and controller explicitly makes all forwarding decisions.
• Hybrid: Where controller may push some specific flows for specific applications. For all other packets, the switch will take it’s own decisions based on its ip routing and switching tables.

Hybrid SDN allows heterogenous SDN networks, wherein the network would be a mixture of openflow supported and unsupported devices. Initial implementation of SDN will likely be a part of such heterogeneous architectures.