Software Defined Networking (SDN) - A primer

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

Software Defined Networking or SDN  is defined as the physical separation between network control plane and user plane.

This architecture decouples the network control and forwarding functions enabling the network control to become directly programmable and the underlying infrastructure to be abstracted for applications and network services.

The basic building blocks of a SDN based solution will have the above layers.

The infrastructure layer or the networking layer which will have all the switches and routers. This could be physical or virtual devices.

The control layer which will have all the SDN controllers. This can be virtual machine or installed on an entire x86 server.

The application layer which will have the applications written by application developers which will interact with SDN controllers over what is called as Northbound APIs.

As the original definition of SDN suggests, there is a physical separation of control and forwarding plane. This means unlike the traditional routers and switches, the brain of these devices are removed and housed at the control layer in a different device typically in a x86 server.

The SDN controller will interact with the routers and switches over the southbound interface using various protocols. Some of the examples of the southbound protocols include the much talked about OpenFlow, configuration protocols such as NETCONF, SNMP and many others.

Why SDN ?

Let us consider a router as an example. A router typically contains three layers to it. The management plane, the control plane and the user or forwarding plane.

Management, Control and Data Planes.

You can login to router using telnet or ssh and configure it. This is the management plane.

A routing protocol such as BGP, OSPF or static populates the routing table which is software based and determines the path of the packet using the routing table.  This is the control plane which determine the forwarding path.

The user or forwarding plane forwards the packets based on the decision from the control plane.

In a network, we might have many such routers and switches. This might be in the ranges of hundreds which means we are looking at hundreds of management, control and forwarding planes. From a configuration perspective, we might have to login to each of these routers or switches individually to make any changes. Even though protocols like SNMP are present, vendors prefer having their own CLI or EMS. Incase of a  multi vendor network, configuring the devices individually would be difficult. This is very inefficient and  cumbersome.

This is where SDN will be very useful. The management plane interaction can be supported on the SDN controller directly using NETCONF and SNMP protocols.

From a control and forwarding plane point of view, a routing protocol,such as OSPF, running on these routers, determines the path of the packet. For this to happen, each of these instances should have a full visibility of the network. A complex protocol running on these hundreds of routers may not do a good job.

To address the above problems, SDN advices to move the control plane of all these devices to a centralized layer called the Controller which will control a set of physical or virtual switches or routers and hence have a centralized view of the network. By centralizing the the control plane, the interoperability problem would be solved to a great extent. For example if all the different vendor devices use protocols such as OpenFlow and a OpenFlow based SDN controller is used to control them.

Since the controller has been designed to run on any x86 based servers, it can be scaled independently of the user plane.

Below figure shows an example where  many applications talk to the controller to utilize the forwarding plane. To handle the traffic from the northbound applications, we need more controllers probably with a load balancer in the front. All this can happen while the forwarding plane is still doing its job without any changes.

The other main benefit SDN brings in is the programmability of the network. Applications on the application layer can manipulate the flow of traffic and the controller in the control layer abstracts the application from the complexity of programming the network by using Northbound APIs and lets you manipulate the network. For example, an application developer can use a language like Python to program the flows on a router via the SDN controller. The application developer is masked from the complexity of the network element.