Software Defined Networking: Why it matters?

We have been seeing IT for the past 20-30 years and how it has evolved. Many new applications coming up in the recent past and more and more things moving towards the internet. Business needs have grown dynamically. But is our network agile enough to support it? Has it changed over this period? Somewhat yes as the vendors have focused more on building new and powerful devices to meet the needs, but that comes with a heavy CAPEX and OPEX for the clients. Has the management of those devices changed yet? The answer is NO.

Consider you have 10, 100 or 1000 nodes in your company network that means you are managing equal number of control planes. This leads to problems like that if anything has to be changed in the network then time for execution is very high extending up to weeks or months in some cases. Moreover the network is vendor dependent i.e. if the network requires a certain feature to be present and the vendor does not provide that feature in the existing devices it leads to an increased investment thereby increasing CAPEX and reducing profitability. The network architecture needs to change.

Back in 2007 Stanford University started a program called the Clean Slate. The idea behind this was to make the participants think of how they would have designed the internet starting from scratch. Software Defined Networking or SDN was born then. The idea was to decouple the control plane from the data plane. The control plane should be implemented on a centralized server and all the applications can access it directly to program the network behavior or to extract network information. The control plane in turn programs the data plane of each devices leading to decreased time for execution. Moreover SDN is an open network having open source network devices thereby reducing the vendor dependency immensely. 

The figure below shows how a Software Defined Network is different from a traditional network.  Applications communicate with Controller which resides on a central server using NorthBound APIs (eg. REST). The controller then communicates to the programmable network element using some SouthBound protocols (eg. Openflow). The network elements fulfill the request from the controller. One thing to mark here is that Openflow is a part of the SDN story and not the whole story.

This type of network architecture gives us two important benefits:

  • Simplifying the network so that a network engineer has to maintain few control planes for many devices rather than one control plane per device.
  • Improving the efficiency of an application by making network provisioning  automated and related configuration simpler.

Many companies and open source communities have their individual approaches in SDN implementations. VMWare’s NSX platform, Cisco Application Centric Infrastructure, Juniper Contrail, Open Networking Foundation have their controllers to support SDN implementations and even have designed approaches for design of SDN. As per IDC market value of SDN is predicted at $13.8 billion by 2021. As per another survey of network professionals 49% are considering deployment of SDN solutions in 2018 and 18% have already implemented SDN in their networks.

To sum this up I can say that network engineers have to improve from being CLI jockeys to SDN experts in order to meet these requirements of SDN. Skillset needs to upgrade as never before to sustain in this rapidly changing world of IT or just sit and watch, and risk your future.

Leave a Reply

Your email address will not be published. Required fields are marked *