Software Defined Networking (SDN) is the new buzzword in IT today.  It has become synonymous with things like cloud, cyber security, CDN, and yes even IPv6.  The curious thing is that they are all inter-related.  Open Flow, which is a specification of the Open Network Foundation, has defined this new phenomenon as something that, “enables networks to evolve, by giving a remote controller the power to modify the behavior of network devices, through a well-defined “forwarding instruction set”. The growing OpenFlow ecosystem now includes routers, switches, virtual switches, and access points from a range of vendors.”

Whoa, sounds revolutionary right?  I know what you’re thinking – yes we can already pre-select policies to govern service paths (i.e. RSVP, DiffServ, route-maps, PBR, etc) that makes it to where we can change the network based on current conditions.  I said the same thing, in fact, most network engineers will.  However, you have to think differently here.  This isn’t about the network, it’s about the application – most notably it’s about the cloud (that other buzzword that’s been poorly defined).

Using Open Flow as a model, the control of the network is no longer under your (network operators) control.  Think of it this way, Application WhizzBang (I am totally trademarking this) started offering services on a network with a QoS policy that restricts or limits bandwidth for the subnet of the cluster it is part of.  The application will have access through Open Flow’s switch specification API to change the DiffServ policing policy in order to increase bandwidth or adjust it altogether.  How is it even able to do this?

With the Open Flow specification, there are control plane functions that must be available to compliant applications.  As of Open Flow Switch Spec v. 1.1, the table below outlines all the functions the control plane of a switch/router can be changed, updated, or optimized by Application WhizzBang. Only one problem I see in the version 1.1 spec: no IPv6 support in table lookups.  Blows my mind why this isn’t part of Version 1?  At least it looks like Version 1.2 may have it?  More to follow on this…

But what does this have to do Cisco ONE –> www.cisco.com/go/one

http://tachyondynamics.com/blog/oftable.pdf

Cisco ONE and Open Flow

At this week’s Cisco Live, Cisco stated not only their support behind Software Defined Networking (SDN), but added features that go above and beyond the Open Flow standard.  Cisco releases their version of the Open Flow API called onePK.  The supported infrastructure components for onePK are their IOS, IOS-XR and NS-OS platforms.  So this is basically everything that’s not End Of Life.  So here’s the high-level architecture:

It appears on the surface to incorporate all the values of Open Flow; plus some. If you are doing cloud things in your enterprise – meaning more than just have a hosted data center – then having some level of SDN could actually be a great tool for provisioning, network tuning and optimization!

However, I will temper my optimization with  dose of reality: there’s still only one functional implementation of Open Flow out there in the wild, and that is from HP’s E Series (AKA Procurve)  “K” train.  If you have HP’s E-Series switch line I highly encourage you to check it out and see what Open Flow looks like now.

Let’s just hope this effort by Cisco doesn’t turn out to be how Microsoft answered Open Document by doing OpenXML (*cough* not really open).  I can’t wait to break this functionality open.  Standby for future blog entries once I am finally able to play around with it!