Over the last couple of weeks, I spent a lot of time reading and thinking about SDN. We are watching the SDN space for its impact on Network Management. From what I see, SDN is actually reinventing the wheel of network management as part of its evolution. In the near future, traditional network management protocols may find its exit and the new SDN based architecture will help build more dynamic and flexible network management solutions.

In my previous blog on SDN, I wrote about challenges that seeded this new direction. This blog tries to throw more light on the SDN architecture and it’s components.

What is SDN?

          SDN depicts a new architecture that enables users to create on-demand abstract network models using a software on top of any physical network topology. Having this programmatic control using a well defined communication protocol allows users to create a logical, high performance and low latency network circuit in no time. This network could span around different geographical locations. In a later stage, it can also be decommissioned and the underlying resources can be reused for different logical entity. In order to achieve this, the network control plane and data plane is separated and the network control plane functions are exposed as programmable interfaces.

If you take look at the above graphic, in a traditional network system, the control and data plane is tightly integrated into the same hardware.  The control plane is responsible for network discovery and mapping. Control plane computes the path based on the device configuration and neighbor discovery protocols.  Once the path computation has been done, the routing table is pushed to the data plane’s programmable ASIC chip where the routing table is called forwarding table. This is a kind of static architecture where the control plane functions are limited and very proprietary to the hardware vendor.

The most preferred definition of SDN lies in the ONF(Open Networking Foundation) white paper.

           In the SDN architecture, the control and data planes are decoupled, network intelligence and state are logically centralized, and the underlying network infrastructure is abstracted from the applications.

The below graphic represents the SDN architecture. As you see the control plane is separated from the data plane and the data plane just functions as a forwarding plane. This data plane could be on any merchant silicon ASIC or custom silicon ASIC based on your requirements.

Components of SDN: Controllers and OpenFlow

Controller

   The whole SDN ecosystem is framed around a concept of SDN controller. SDN centralizes the network intelligence in the controller which maintains the logical view of the network. Physically, controller is a software that runs on a regular computer and connects through a dedicated logical network to the routers or switches.

Functions

•  Provides a UI for configuration

•  Exposes APIs for various network services like routing, switching, device integration etc.

•  Runs Path determination/Neighbour discovery algorithms and builds RIBs (Routing Information Base)

•  Delivers the computed paths as FIBs to network devices using a communication protocol like OpenFlow.

“Because the Controller must calculate the flow path in software, this is usually known as “Software Defined Networking”

– Greg Ferro, EthrealMind.

Controller also exposes a set of northbound APIs for upper layer  applications to interact with it and pass application specific metadata to the underlying network. This interaction makes the network more application aware and helps optimize the network resources for specific application needs.

OpenFlow

     OpenFlow was started as a research project to run separate logical networks on production networks, thereby enabling users to  test experimental protocols. OpenFlow group founded a formal administrative body called ONF (Open Networking Foundation) backed by most of the leading American companies like Google, Microsoft, Facebook etc and started pushing the commercial vendors to add OpenFlow support. Later the term SDN was coined and all the bits and pieces were tied together for commercial promotion.

One of the best definitions I have seen in the community is,

OpenFlow = Forwarding table (TCAM) download protocol

– Ivan Peplenjak, IOSHints.

As we saw earlier, the controller computes the forwarding data and constructs an OpenFlow message to push the FIB down to the data plane’s ASIC. This message can add, modify or delete FIB entries in the table.

 SDN Vs Conventional Design

By decoupling the control plane and data plane, SDN turns the underlying physical network into an abstract and programmable model. Control plane functions are moved to a software and all the control plane functions are exposed through an API.

SDN is a new start and there are missing pieces. It is too early to compare it with the  current proven models.  We are not going to do a technical deep dive on the missing pieces. However I would like mention some of the weaknesses of the SDN architecture

•  Controller availability / redundancy mode is not addressed well

•  Controller network bandwidth issues on a WAN deployment

•  Interoperability between controllers

•  Network Convergence

•  No rich set of Northbound APIs

 The current scenario is, SDN has to co-exist with the traditional design for it’s missing pieces and no one has witnessed a true SDN driven network model in the industry at enterprise scale. Ofcourse, there are early adopters like Google, Rackspace etc and they are using it for a specific problem where traditional or commercial models cannot solve their hyper scale problem.

IMHO, SDN solves a set problems in the current networking system and not all of them. There is still a long way to go to see operational SDN networks as a commodity.

The post ManageEngine Thoughts: Software Defined Networking #2 appeared first on ManageEngine Blogs.

You Can Learn More About the ManageEngine Product Line By Going to manageengine.optrics.com

The original article/video can be found at ManageEngine Thoughts: Software Defined Networking #2