Cisco and OpenDaylight: The SDN Application Land Grab

There's a some skepticism about Cisco's intentions in participating in the OpenDaylight project, which aims to build an open source controller and APIs for software defined networks. Cisco is contributing code to OpenDaylight from its ONE Controller.

So is Cisco really embracing open source? In a call with investors earlier today, David Ward, Vice President, CTO of Engineering and Chief Architect at Cisco said "This is the largest contribution by Cisco into the open source community. It's a sign Cisco is embracing open source and transitioning into a more open environment."

But then you have to weigh that against this comment. "We'll innovate within the Daylight context and alongside the Daylight context," said Colin Kincaid, VP of Product Management in Cisco's Network Operating Systems Technology Group, in an interview with Network Computing. "We sometimes innovate outside standards bodies, but then bring that technology back into standards bodies."

Inside and outside? Is this all just a smokescreen? What is Cisco really up to?

In fact, Cisco's intentions are clear: to get access to as many SDN-based applications as it can by encouraging the growth of a developer community, and to protect its market share to the best of its ability by adding proprietary extensions wherever necessary. But if SDN is going to take off, somebody had to do it. Here's why.

The primary value proposition of software defined networking is that an entity, be it a business user or an application, can request network resources and associated service levels and get them provisioned without having to deal with a bunch of complicated, messy networking protocols.

This not only speeds deployment, it also opens the door to a host of potential new applications and services that can be written to take advantage of the abstraction layer provided by the APIs (in SDN parlance, the northbound APIs). But those applications and services won't emerge without the efforts of a robust developer community. And the only way to build a robust developer community is to have a standard set of APIs.

Cisco is one of a few companies in the market that could release a proprietary set of northbound APIs and be fairly confident in attracting developers. VMware, also an OpenDaylight participant, is another.

So why participate in OpenDaylight? Two reasons. First, OpenDaylight puts a stake in the ground that says "Here's a controller that's going to have the backing of a bunch of big names." It's a message to the major players in the L4-L7 space that they can begin to dedicate developer resources to building applications to the controller and its APIs (which Cisco says may be available as soon as the third quarter of this year).

Second, Cisco is hedging its bet. It wants access to as many developers as it can, from as many sources as possible. That includes major players in the L4-L7 space, but Cisco also opens the door to a wider audience.

"The individual developer drives innovation today," said Kincaid. Now imagine that individual developer coming up with Next Big Thing while she plays around with an open source distribution. Cisco can grab that innovation, do a bit of testing, then pop a support contract around it and ship it to customers, confident that it will operate in Cisco's open-but-extended platform.

So does this mean Cisco believes in the open source model? Yes--but only as far as that model serves Cisco's interests. When and where Cisco wants to add proprietary add-ons to its controller, it will do so. Whether this strategy succeeds in the long run is another question. First we have to see if OpenDaylight gathers significant momentum from application developers.