First take on SDN
I have been very quiet when it comes to the topic of SDN (Software Defined Networking). However, these days you can hardly go through your day without spotting an article about it.
The reason I have been quiet is pretty simple. I wanted to understand it a bit better before writing anything about it.
So what do I have to say about it? Well, in my first rant about it, I will try and clarify a few things that you might be wondering. With that, lets dig into a few of the fundamental concepts surrounding SDN.
Terminology and concepts
Controller. A controller in an SDN network, controls the programming of the hardware forwarding platforms. It might tell switch–1 to take data coming from port 1 and forward it out port 30. However, it might also instruct the switch to do more sophisticated things such as resetting a DSCP value depending on the policy defined for that individual flow. Another example would simply be to drop the flow altogether.
Its important to understand the difference between an SDN network to what we have today. Today we rely on a hop by hop forwarding architecture where each hop along the path toward the destination treats each packet by itself (using certain characteristics of the packet). Usually it does this by utilizing a routing protocol such as BGP or OSPF which only takes the destination (routes/prefixes) into account.
By using a centralized model where the packet forwarding is decoupled from the control plane, a more granular approach can be taken to route and alter our traffic.
Openflow is a protocol used by a controller to “speak” to hardware on how to process flows. Currently its in version 1.3.1 (with 1.3.2 being ratified). It is a standard from the ONF (Open Networking Foundation).
Northbound/Southbound API’s is often mentioned. It all depends from what viewpoint you are at. From the controller perspective, a northbound API is an interface that allows your policy applications to program your controller. In our example above, a policy application could use this northbound API to instruct the controller to implement the drop on certain flows. A southbound API would then be the interface used to instruct the hardware device to perform the actual forwarding. Such a southbound API could be Openflow.
The Hardware implications on running an all SDN network are pretty substantial. One of the common threads is that you can use commodity Openflow (to name one proposed standard) switches with your favorite SDN controller. This means that big players such as Cisco, HP and Juniper could loose out to smaller players as long as Openflow is supported. However, this has already sparked quite a development in controller code, since its pretty obvious thats where the $$$ will be in the SDN world (along with policy applications).
The Open Daylight project is an Open Source project aimed at creating standards in the SDN space. Interestingly, its a project under the Linux Foundation. It is a pretty new consortium, having been officially announced in April 2013. Its a group of very diverse players ranging from Cisco to Redhat and a lot of different vendors and interested parties in between.
Opportunities
All of this SDN will allow us as network engineers to have a more agile “product” to offer our customers. Yes, our daily tasks will change, but they will be replaced by something else. I do not believe for a second that the world will need fewer network engineers in 5 years. Quite the opposite in fact.
My hope is that in 5 years we will have some management systems in place that will allow us to model our networks. That will allow us to create policies in a uniform manner and push to our controllers. Something that will allow us to provision services without having to go onto each device and manually perform a platform-centric command.
As I mentioned above, the hardware implications are pretty significant. However this also presents an opportunity for us as network engineers to create a network with best-of-breed hardware. It could be possible to have a mix of HP and Arista switches, controlled by a Juniper controller with a network management system from Cisco. As long as everyone agrees on the API’s involved (Fx. Openflow), its possible.
Summary
This concludes my first rant about SDN. Its surely not the last, but I hope it contained some useful information as a primer to SDN. If I have misunderstood something I hope you will let me know in the comments, so I can modify the post. Thanks!