Cisco and Juniper Reveal SDN Strategies

When VMware splashed out $1.26 billion for software defined networking (SDN) startup Nicira last summer, it confirmed SDN’s status as Something Significant. And when Big Switch Networks came out of stealth mode a few months later with its Big Network Controller and application platform, the announcement solidified SDN’s status as one of the hot topics for 2013. A hot topic, but not necessarily actionable…yet.

SDN is still a relatively immature technology. It likely won’t be ready for significant enterprise adoption for three or four years at the earliest. But when its time comes, enterprises will look to established networking hardware vendors, like Juniper and Cisco, for confidence. Only when the major players present credible SDN offerings will many organizations consider the technology mainstream enough to deploy.

So what are Cisco’s and Juniper’s SDN plans?

Cisco: Proprietary hardware and protocols to support SDN

Earlier this year, Cisco announced its Open Network Environment (ONE) controller, the foundation of its SDN strategy. Targeted for availability in the second quarter of the year, the ONE controller will act as a platform for network applications and services. Northbound, the controller will be exposed to these applications using REST and Java, with other protocols made available over time. Cisco has already announced three applications for network slicing, network tapping, and custom forwarding.

It’s southbound where things get really interesting, though. When the controller wants to talk to routers and switches on the network, it can use the open-source OpenFlow protocol. But there’s another option: Cisco’s own ONE Platform Kit, known as onePK, which provides a set of APIs for communicating with the company’s hardware. Cisco may also add other protocols in the future.

Shashi Kiran, senior director of open networking at Cisco, explained to Enterprise Networking Planet that “if you look at OpenFlow, it’s limited in the things that it can do. It can expose four or five APIs. OnePK exposes about 700 APIs, giving access to anything built in to the hardware or software. For a company like Cisco, this exposes the intelligence built in to our ASICs.”

That’s especially interesting in light of the sense that SDN puts Cisco in an awkward position. Cisco enjoys high margins on its existing traditional hardware business, so it’s natural that the vendor doesn’t want to throw that away. At the same time, however, SDN almost certainly represents at least a part of the future, so the company must articulate a strategy around it. Pushing a proprietary alternative to OpenFlow, an alternative which still requires Cisco hardware, provides an attractive solution.

So far, Cisco hardware support for SDN is limited to the ISR G2, ASR 1000, and Nexus 3000 for onePK by the middle of this year and the Catalyst 3000 and Nexus 3000 in the same period for OpenFlow.

Brad Casemore, an analyst at IDC, believes Cisco is following Microsoft’s “embrace and extend” strategy of adding a proprietary element to a standard like OpenFlow. “I can see Cisco trying to protect their current product, while having a Plan B, SDN, which may become Plan A,” he told Enterprise Networking Planet.  “They will try to evolve with the market by adopting virtualization and programmability without using OpenFlow.”

Timing the transition to SDN may become a problem for Cisco, Casemore said. “Too early and they sacrifice their margins on existing hardware products. Too late and they sacrifice market share.”

Juniper: Controller acquisition, platform plans, but no clear timeframe

Juniper’s strategy is less clear. The company bought controller maker Contrail in December 2012 for $176 million, a purchase that’s key to Juniper’s strategy, according to Brad Brooks, the vendor’s vice president of marketing and business strategy for its software solutions division.

“Contrail will form the basis of a Juniper controller, and that will plug in to the company’s JunosV App Engine,” Brooks told Enterprise Networking Planet. JunosV App Engine runs on standard x86 servers and can currently add services directly to Juniper hardware. Moving forward, Juniper plans to use the software slightly differently, as an applications and service platform that can talk to network hardware via the putative Juniper controller.

But when will this controller, and Juniper’s other SDN offerings, see the light of day? “The time scale—that’s the 64 billion dollar question,” said Brooks. “We hope to have prototypes out over the next year, but when will SDN go mainstream? That’s anyone’s guess.”

Like Cisco, Juniper expects to support other protocols in addition to OpenFlow—probably extensions of BGP and XMPP, used to control many of Juniper’s existing hardware products. Brooks also hinted that Juniper’s approach would preserve the need for customers to buy Juniper hardware. “It will still be important to have brains on the devices themselves and outside, in the controllers,” he said.

Andre Kindness, a Forrester analyst, told Enterprise Networking Planet that this is to be expected. “Obviously, vendors like Cisco and Juniper don’t want to make their hardware into a commodity. They want to give the message to their customers that they still need to buy hardware from them,” he said. “But standards never cover everything, so you are always going to get proprietary extensions. They will all put more on top of OpenFlow.”

So far only one heavyweight—HP—has really championed OpenFlow, and that’s because HP sees OpenFlow-based SDN as a way of dislodging Cisco from its position in the networking hardware market, Kindness believes.

There’s no doubt that Cisco’s SDN strategy is more advanced than Juniper’s, which remains very much in the planning stage. But if SDN becomes commonplace in the enterprise data center five years from now, Juniper’s and Cisco’s strategies will both help determine the direction these implementations will take.

Paul Rubens
Paul Rubens
Paul Rubens is a technology journalist specializing in enterprise networking, security, storage, and virtualization. He has worked for international publications including The Financial Times, BBC, and The Economist, and is now based near Oxford, U.K. When not writing about technology Paul can usually be found playing or restoring pinball machines.

Latest Articles

Follow Us On Social Media

Explore More