The Hype and Reality of SDN – Part 2

In the first part of the blog, I reviewed the need to understand the foundational challenges that gave birth to the Software Defined Network (SDN) movement. In particular, I briefly highlighted the absence of a well-defined abstraction as a fundamental problem that exists in today’s complex networks.

In this blog, I’ll review what abstraction means and how SDN realizes it.

Abstraction is the process of representing a system in a way that reveals only the relevant information, while suppressing irrelevant details. The main goal is to derive usable “high-level” information without getting involved in the underlying “low-level” details that are often layers of additional complexity.

This paradigm moves network closer to other fields such as programming. For example, a software developer does not have to re-write a program just because the company upgraded the RAM on all its servers. This is possible because information such as parity bits and memory addressing are abstracted from the programming language.

The figure below shows an example of a network topology and its corresponding abstracted view. Assuming the processing server hosts mission critical applications and the links in blue are ultra-low latency links.  The organization might have a business  need to map these mission critical   flow to-and-from the server to the blue links. Without abstraction, we will need to consider all the  low-level details (e.g. protocols to use,link information etc)  to accomplish the goal.

Abstracted network topology

To understand how SDN realizes abstraction, it is imperative to briefly review the DNA of a typical network system. Most network devices today are divided into two functional planes; Data plane and Control Plane

The Data plane (also known as the forwarding plane) is responsible for moving  transit packet, based on pre-populated information. The information needed to get the job done in this plane is completely local, having been populated by the control plane. Because the information is local, results in this plane happens at milli-seconds timescale.

On the other hand, the Control plane is the part of the network responsible for computing the forwarding state .It is the brain of the box  used for routing protocols,traffic engineering, policy controls etc . Compared to the data plane, it is much slower because the information needed to build the forwarding state is usually non-local (usually received from external sources such as neighboring router) and have to be computed by an algorithm .

These two planes have dissimilar characteristics, yet they are closely coupled together in the current implementation on network devices. Additionally, most network devices have a one-to-one relationship between the control plane and data plane. For example, a network consisting of 10 routers, is made up of 10 data and 10 control planes.

The OSI layer provides a reasonable form of abstraction for the data plane. Unfortunately, today’s control plane has no form of abstraction. In the absence of well defined abstraction, several bags of protocols have been designed to address business needs. These creative “band-aids” have increased the overall complexity and cost of the control plane.

In order to address this fundamental problem, SDN introduces the separation of the control plane from the data plane, while also consolidating the number of control planes in the network. So a network with 10 routers can now have a single centralized control plane that manages 10 data planes . The separation of control and data plane allows sufficient abstraction to be introduced in the control plane, thus achieving flexibility and addressing business demands in very simple manner.

The control plane in SDN differs from the current implementation of control planes in the following ways;

  •  A logically centralized controller that can operate at a higher layer, thus able to interact with applications through well defined APIs.
  • Control program that receives user defined information and expresses them to other layers. The control program is not responsible for implementing the detail information needed to accomplish the user task.
  •  A virtualized layer that provides a condensed network view to the control program. For example, if the control program needs to compute a QOS related task, then the virtualized layer would  only provide network related info that are needed to accomplish QOS tasks. (e.g. network link speeds, buffer value etc, but omit IP address, since that is not needed for QOS configurations).
  •  Network Operating System (NOS) layer that provides a global network view of the network , thus shielding low-level information that are otherwise irrelevant. This layer also has a well defined interfaces that hands out forwarding instructions to the data plane via standard southbound protocols such as open flow or even legacy protocols like SNMP. (SDN does not necessarily mean open flow !)

 

The figure below shows the hierarchy  between the layers in the control plane.I choose to represent it this way, because the higher you go in the pyramid,  the more encapsulated  the information becomes.

 

sdn pyramid

This model ensures a layered approach with well defined interfaces between the abstracted layers. By hiding the complexity from the user, SDN aims to provide simplicity in network that will ultimately result in customized business-relevant innovations, that can then be used to provide competitive advantages for organizations.

In conclusion, it is worth noting that SDN is an innovative tool at the disposal of small and large organizations. It simplifies how we solve new and existing business challenges, but by itself does not solve any particular problem.