SDN is like teenage sex: everyone talks about it, nobody really knows how to do it, and everyone thinks everyone else is doing it, so everyone claims they are doing it… –Spoof of an existing saying
About less than 2 years back I read a blog post what the hell is SDN ? The concept was still in its budding phase with ONF and founding members working on software control of the network operation by standardization of Openflow and related technologies.
This approach by the Networking industry should have been taken long back .Since SDN concept to the Networkers is what Server guys started 10 years back. Imagine a Virtual server being decommissioned and created somewhere else. Using VSphere this would hardly take 10 minutes for a basic VM with minimal downtime. However for a network guy to ensure traffic to and from the server remains is carried the same way, may take a long time to plan and execute the activity.
However the networking community has come along a long way since then. About 150 member companies are now contribution to the SDN research, improvement and implementation. Openflow v1.3 is now supported by many switches by big and small players. From being a lab project to supporting network infrastructure of the biggest ISPs
Here is a Crash Course for people who have recently woken up to the SDN call.
The below mentioned architecture is Openflow based, however concept in same for various implements across industry.
SDN technology has three main components.
Application Layer: Which defines what exactly has to happen? Various API are built which define the behavior of the network traffic. These APIs interact with the control layer to implement the logic.
Control Layer: Maintains a centralized and global view of network resources and utilization, hosts network service logic, and pushes network state, configuration and traffic treatment information to network devices in the infrastructure layer using OpenFlow. The controller platform lies at this layer.
Infrastructure Layer: These are switches which Support Openflow and on receiving instructions from the controller using the control protocol (Openflow in this case) would create various flow tables. These flow tables contain various rules,actions and stats which may be manipulated to achieve the desired outcome.
There are Various SDN offering and deployment across the industry, which may not may not be directly marketed as SDN but are somehow derived from it are as below.
1.Cisco’s Application centric infrastructure (ACI) offering.
ASR9K (V5.1.1) and Nexus 9000 are being sold with support for Openflow and onePK.
Taking example of ASR9K (one on which I could get hands on from a white paper) ,Openflow acts as an agent running on the RSP on top of OnePK. It connects the external Openflow controller and converts the messages to the onePK APIs residing on the IOS-XR.Cisco recommends using their devices in a Hybrid mode so that both Openflow and normal switching/routing options can exist simultaneously.
This is also an excellent approach for the traditional service provider networks to migrate to the SDN.
2.Facebook datacenter network
Facebook’s datacenter has considerably reduced in size and increased in performance after it took on the core and pod approach. Using micro-cluster of multiple switches a pod is created which connects to redundancy network core fabric switches. The pods are connected to the Data Centre Fabric which configures the switches as per traffic requirement. For example it may modify the BGP parameters to create dynamic routing paths on the array of switches.
3.Google’s B4 SDN Network
Google has deployed sets of Network Controller Servers (NCSs) alongside the switches, which run an OpenFlow agent with a ‘thin level of control with all of the real smarts running on a set of controllers on an external server but still co-located.
Many companies have followed the similar approach to SDN at their own scale and sometimes combining with Network functional visualization (NFV).Openflow is still not a perfect protocol and is into standardization,however taking help from proprietary solutions from various OEMs services providers can easily increase performance as well as save on CAPEX.
For engineers,their meetings with the server guys would be of a different layout so they better get hands on to some programming stuff and pick up certifications in this field So for SDN,Yes it is !
Comments