Openflow and Vendor Lock-In

Openflow is really just one piece in a much broader architecture known as Software-Defined Networking (SDN).  The concept of SDN is actually very simple and is explained quite clearly in a number of presentations by Nick McKeown from Stanford - amongst others.  See http://tinyurl.com/4ekzb9w

The basic idea is that today's networking products mirror the mainframe computer industry of decades past.  Vendors deliver packages of proprietary hardware, operating systems and applications bundled together.  Unlike the PC industry of today, you cannot choose to buy network hardware from one vendor, an operating system from another vendor and applications from a third vendor.   In fact, in many cases it becomes difficult to distinguish a product's hardware from it's operating system from it's applications.

So the idea of SDN is to create open interfaces between these layers so the networking market resembles the PC market with competition at each layer of the stack.  Openflow is the open interface between hardware and the network operating system - perhaps roughly analogous to x86.  As network operating systems develop, as several currently are, there will hopefully be open APIs that application developers can use to build functionality on top of the operating systems.  In theory, this should be good for the consumers of networking products because they should have more options and more competition should lead to reduced costs.  As a consumer of networking products, I'm all in !   But will theory and reality actually match up or will something get lost in between ?

I'm a firm believer in learning from history, so let's take a look for a minute at what happened in the world of wireless controllers to see if we can glean any useful knowledge from that experience.

Of course there was CAPWAP which, in some ways, is analogous to Openflow in that it was meant to be an open interface between controllers and APs.  As I understand it, if CAPWAP had achieved success as a multi-vendor interoperable standard, you could have had a controller from vendor A and APs from vendors A, B, and C and they would have played nicely together.  Of course this didn't happen and consumers have to purchase APs and controllers from the same vendor.

However, the lack of controller-to-AP interoperability is not the most troubling interoperability problem associated with controller-based wireless systems.  What happens when I have 30 controllers and 4,000+ APs deployed on a large university campus and then decide to switch wireless vendors ?   Sure, the fact that there's not competition at both the AP and controller layer means I'm probably paying more than I otherwise might.  But, technically,  it's not really a problem deploying the new controllers and having the new APs associate with the new controllers.   That's easy enough.

The real problem is that the controllers from vendor A and vendor B do not interoperate in any meaningful way.  Sure, because they both do basic IP forwarding, a wireless client on one system can communicate with a client on the other system.  But none of the features (ie applications) that drove me to choose a controller-based system over stand-alone APs in the first place are supported across both systems.  Features like RF management and layer-3 roaming do not work across wireless systems.  So, if during the transition between vendors, two adjacent buildings are on different systems, users can't roam seamlessly between buildings, there can be RF interference issues, and captive portal logins aren't maintained forcing users to re-authenticate simply because they moved from one building to another.  As a result, many organizations have become locked-in to their current controller-based wireless vendor.  The amount of effort required to switch vendors is high enough, that they're willing to stay with their current vendor unless they're REALLY unhappy with them or can save a TON of money by switching.  Anecdotally, I hear lots of people complaining about their wireless systems and almost none of them are considering changing vendors !!

So what does this have to do with Software-Defined Networking and Openflow ?   Well, there are in fact a lot of similarities.  Openflow allows a single, software-based network operating system to control potentially hundreds or thousands of hardware devices - not unlike a wireless-controller.   Novel new applications can be rapidly developed on top of the network operating system to allow new functionality and more efficient management of networks - not unlike wireless controllers.  But, if the applications are tightly coupled to the network operating system (as is the case with wireless controllers) and if customers do not sufficiently compel the software vendors to make their products interoperate at an "application" level, consumers could be left in the same vendor lock-in situation they're currently experiencing with controller-based wireless systems.

At this point, those of you who know me are probably thinking, "Man, when did Matt get so down on Openflow ?".   Certainly it's not all gloom and doom.  The SDN product space is developing much differently than the controller-based wireless market.  Open-source projects are flourishing which will hopefully help drive the market is an open-standards direction.  But we, the consumers of networking equipment, need to be vigilant.  Don't just assume that creating competition at both the hardware and operating system layer is going to be good for the consumer.  What happens at the layers above that - the operating system and application layers - is probably much more important in the long run !!