Juniper's SDN Strategy Looks Beyond OpenFlow

2013 may be the Year of the Snake on the Chinese calendar, but in the networking world it's the Year of SDN. As I wrote last week, "2013 should mark the point when SDN moves from being a debate topic to a serious technology alternative for network upgrades and redesigns."

This week, Juniper Networks added fuel to the SDN fire by announcing its SDN strategy, although the company emphasized vision over concrete details. One element is clear, however: Juniper's interpretation of SDN decidedly at odds with the conventional wisdom that's accrued around OpenFlow. Although the networking cognoscenti largely agree about SDN in the abstract--it's all about separating networking functionality into distinct, conceptual and easily disaggregated layers--in reality there are several different approaches.

In his keynote at Juniper's Global Partner Conference, Bob Muglia, executive VP of software solutions and ex-Microsoft heavyweight, described what the firm sees as the four planes of networking, which OpenFlow devotees will immediately notice is twice as many as they are accustomed to: packet forwarding, flow control, network services and system management.

While OpenFlow addresses the first two, Juniper, like Cisco with its onePK vision, sees the realm of SDN more holistically. In fact, both in his prepared remarks and at a later press conference with Juniper founder and CTO Pradeep Sindhu, Muglia was quite dismissive toward OpenFlow. Stating that "OpenFlow is just a protocol, and probably not the most important one," Muglia claimed that OpenFlow doesn't solve the more important problems a broader SDN approach can address. Although both executives paid lip service to Juniper's commitment to OpenFlow in its routers and switches, the L2 packet processing protocol is clearly not central to its strategy.

Sindhu was equally disparaging, characterizing OpenFlow as an interesting early attempt, a nice research project if you will, but something he expects to evolve into a more complete, and presumably more useful, protocol in the future. In the meantime, he said, Juniper's recently acquired Contrail SDN controller will use, and extend, BGP and XMPP, which are already supported in most of Juniper's hardware as control protocols.

It shouldn't come as a surprise that Juniper rejects the OpenFlow-fueled notion of dumb, commoditized, merchant silicon switches as nothing more than packet-pushing marionettes manipulated by a master brain in the sky. Like Cisco, it still derives almost 60% of its revenue from routing and switching hardware. And while its strategy does acknowledge the need for centralized control, as Muglia highlighted in his keynote, Juniper's SDN approach isn't primarily about centralized flow control. Muglia claimed that networks are inherently decentralized and that, in Juniper's SDN world, considerable intelligence will stay at the edge.

Next Page: SDN's Challenge to IncumbentsHerein lies the challenge of SDN to the big incumbent network equipment vendors, who have grown used to years of 20% profit margins and fat annual product maintenance fees. By converting networking from a hardware-to a software-centric environment, where more of the value and product differentiation is in easily portable code running in a virtualized private cloud, it's disruptive to the core.

Every Silicon Valley exec is acutely aware of what commodity hardware and operating software in the form of x86 CPUs and the open source catalog--from Linux and Apache to MySQL and Hadoop--have done to the server market. No one wants to be the next DEC, Sun or SGI. This explains why, conceptually at least, the SDN strategies of Cisco and Juniper have a lot in common. Both want to do as little damage to their switching and routing cash cows, while at the same time not utterly ignoring what Muglia himself called "one of the biggest things we will ever see." Hence, the emphasis on higher-level network services, management and custom hardware like Juniper's programmable Trio ASICs, not new ways of wiring and controlling data center fabrics.

Indeed, the hallmarks of Juniper's strategy are at the application and management layers, where Muglia described a suite of virtualized network services, centrally controlled and orchestrated into what he terms an "SDN service chain" using standard APIs and protocols. It's a concept that's already given rise to a new buzzword: network function virtualization (NFV). Yet what's still unclear is how Juniper intends to integrate this notion of virtual network appliances assembled like so many Unix commands piped together, with L2/3 features like vSwitches and OpenFlow (or comparable) packet control.

Presumably, that's where Contrail comes in, but neither Muglia nor Sindhu offered any details on that front. In emphasizing the importance of network management, Step 1 in Muglia's four-stage journey to SDN Nirvana, Juniper also seemed to be taking a page from the onePK playbook. However, he was quick to salute the flag of open standards, saying that Juniper expects to play a leading role in defining the required service chaining protocols. Indeed, Muglia mentioned that an ETSI-sponsored working group is meeting this week to start the task of NFV standardization.

One area where Juniper could play a constructive role in the collective SDN transformation is in rewriting the rules for network software licensing, and here the news was positive. Muglia announced a new licensing and maintenance model that breaks the link between hardware and software. Starting this year, its products will be priced based on total capacity and usage, giving customers the flexibility to slice and dice the total pool among multiple virtual or physical devices. "Licensing for networking is so messed up and SDN gives us an opportunity to reboot it," Muglia said, a view undoubtedly shared by most in the convention hall.

Although Juniper's big SDN coming-out party was long on vision and concepts, while short on details and timelines, there was a lot to like. I anxiously await these specifics and to see how the company resolves the awkward "competitive cooperation" with OpenFlow, while integrating Contrail's technology to complete the lower layers of its SDN framework.

Kurt Marko is an IT pro with broad experience, from chip design to IT systems. He writes for Network Computing, InformationWeek and InformationWeek Reports.