Data centers

09:20 PM
Connect Directly
LinkedIn
Google+
Twitter
RSS
E-Mail
50%
50%
Repost This

Cisco and OpenDaylight: The SDN Application Land Grab

Cisco is using the open source OpenDaylight initiative to spur application development to make its own SDN platform more valuable.

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
cbabcock
50%
50%
cbabcock,
User Rank: Apprentice
4/18/2013 | 11:27:39 PM
re: Cisco and OpenDaylight: The SDN Application Land Grab
View warily, as Andrew recommends, any big vendor-initiated open source project, such as Open Daylight. The vendors are using open source code practices for their own purposes. The result, nevertheless, is open source code, with all its attendent benefits. To me, the SDN approach threatens upheaval to existing, physical device product lines and established vendors are trying to find a way to participate, without abandoning those product lines. One of their few options is to lead an open source project that both attracts developers and keeps the door open to their proprietary, OnePK protocol, which can address and extract information from Cisco switching gear. Why would independent developers bother to do this? Why not stick with unfettered OpenFLow and forget OnePK? Because the huge established base of Cisco network gear isn't going away overnight, and applications that make use of it, possibly in more flexible and innovative ways, will find a market. Both VMware and Cisco are refusing to fight open source, the way Microsoft did. They're giving it aa lukewarm embrace. Charlie Babcock, InformationWeek editor at large
omarsultan
50%
50%
omarsultan,
User Rank: Apprentice
4/14/2013 | 10:44:15 PM
re: Cisco and OpenDaylight: The SDN Application Land Grab
@kmarko:

Big picture, onePK can be used a couple of ways. An app developer can write to onePK libraries that directly control and pull info from the infrastructure. In this context, where we are talking about controller-based SDN, onePK would be a peer to OF. If you look at the diagram from my post ( http://blogs.cisco.com/datacen... ) a onePK plugin could fit into the dotted-line box for vendor specific interfaces all the way to the right. Why would you want to do this? Well, onePK exposes different, complementary things in the switch than OF and if you have a switch that runs in hybrid mode, you have the ability to write apps that take advantage of both. With OpenDaylight, our own own Cisco Controller, for that matter, you would still drive this via whatever the defined NB interfaces to the controller are (i.e. REST or OSGI).

Regards,

Omar (@omarsultan)
Cisco
kmarko
50%
50%
kmarko,
User Rank: Apprentice
4/14/2013 | 1:32:28 AM
re: Cisco and OpenDaylight: The SDN Application Land Grab
I don't understand how an API like onePK is a "SB protocol". What protocol is onePK using to control packet flows? I thought onePK was more about configuring devices and orchestrating applications. Please explain how onePK relates to OpenFlow and the Cisco One controller since I'm confused by the SB protocol statement.
omarsultan
50%
50%
omarsultan,
User Rank: Apprentice
4/12/2013 | 2:54:07 PM
re: Cisco and OpenDaylight: The SDN Application Land Grab
Andrew:

Thanks for taking time to write about OpenDaylight.

Perhaps I can add to the discussion a bit. Regarding the NB interfaces, remember, OpenDaylight is a community driven project. The technical direction for NB interfaces is decided by the TSC, where decisions are driven by consensus. I can talk about the technical direction for Cisco's Controller and the two NB interfaces we have already committed to are REST and OSGI and I would expect us to support a similar direction for open, published NB APIs with OpenDaylight.

To answer @kmarko's question, onePK would be a SB protocol, not NB, so you theoretically have a SB plugin for OpenDaylight that spoke onePK to Cisco gear. However, the first SB plug-in you will see from OpenDaylight is for OpenFlow--what happens after that is really up to the TSC and individual companies.

I know that Cisco and "open source" generates cognitive dissonance for some folks, but this is not our first foray into open source-we have been active with OpenStack and the Quantum API for a while and we are working to bring our Nexus 1000V virtual switch to the Xen and KVM platforms (an example of outside-in)--I realize this is a modest start, but expect to see more from Cisco both in terms of commitment and code.

Regards,
Omar @omarsultan
Cisco

kmarko
50%
50%
kmarko,
User Rank: Apprentice
4/12/2013 | 3:55:18 AM
re: Cisco and OpenDaylight: The SDN Application Land Grab
Good analysis, however at least in the near term, this move by large vendors like Cisco is about marginalizing commercial OpenFlow controllers so that they can claim that southbound, all controllers are more or less the same. Thus I think it's largely a L2-L3 play for now.

Where I see Cisco adding proprietary IP is by bolting onePK on top, northbound. If Cisco can get developers and applications hooked into its extensions, the equipment sales will follow. In contrast, IBM's play is all about services. It wants a reasonably consistent core infrastructure that it can install and then customize for each client. It knows the typical enterprise will be completely befuddled by all this SDN stuff, which is IBM's chance to come in and save the day.

Basically Open Compute Daylight seems to be aopest strategy for marginalizing SDN startups like Big Switch, Midokura, et al by standardizing in just the areas they have been building unique IP.
More Blogs from Commentary
SDN: Waiting For The Trickle-Down Effect
Like server virtualization and 10 Gigabit Ethernet, SDN will eventually become a technology that small and midsized enterprises can use. But it's going to require some new packaging.
IT Certification Exam Success In 4 Steps
There are no shortcuts to obtaining passing scores, but focusing on key fundamentals of proper study and preparation will help you master the art of certification.
VMware's VSAN Benchmarks: Under The Hood
VMware touted flashy numbers in recently published performance benchmarks, but a closer examination of its VSAN testing shows why customers shouldn't expect the same results with their real-world applications.
Building an Information Security Policy Part 4: Addresses and Identifiers
Proper traffic identification through techniques such as IP addressing and VLANs are the foundation of a secure network.
SDN Strategies Part 4: Big Switch, Avaya, IBM,VMware
This series on SDN products concludes with a look at Big Switch's updated SDN strategy, VMware NSX, IBM's hybrid approach, and Avaya's focus on virtual network services.
Hot Topics
3
Converged Infrastructure: 3 Considerations
Bill Kleyman, National Director of Strategy & Innovation, MTM Technologies,  4/16/2014
2
Heartbleed's Network Effect
Kelly Jackson Higgins, Senior Editor, Dark Reading,  4/16/2014
White Papers
Register for Network Computing Newsletters
Cartoon
Current Issue
Video
Slideshows
Twitter Feed