Data centre and campus networks are where Juniper sees the immediate short-term benefits of SDNs because the infrastructure is geographically concentrated
Juniper is working with other industry players on an open source-based controller for software-defined networks (SDN) that would be an alternative to proprietary offerings from VMware and Cisco.
Juniper hopes to have an open source SDN controller emerge as a de facto standard that's broadly supported by the industry, much like Linux, Apache and Hadoop have become in open source operating system, Web server and big data analytics, said Bob Muglia (pictured), executive vice president of Juniper's Software Solutions Division. He does not consider current open source SDN controllers, like Floodlight, Nox, Trema and others, to have attained that status yet.
"We think the likely thing and the best thing for the industry is to have an open source controller emerge that becomes a third standard controller," Muglia said in an interview with Network World this week. "One that is available broadly across companies and supports the broad set of capabilities that are needed. That has yet to emerge. And we are looking closely and working with a number of players in the industry to determine how it is likely to emerge."
A couple of the other participants Muglia mentioned are IBM and Microsoft. Muglia was a longtime Microsoft executive before moving to Juniper a year ago.
Isolating that de facto open source controller standard seems to be a priority for the company because VMware and Cisco, with their leadership positions in server virtualisation and data centre switching, and major investments in programmable networking, will have significant market positions in SDNs .
VMware just bought network virtualization startup Nicira for $1.26 billion, and Cisco funded startup and potential spin-in Insieme Networks with $100 million, and may acquire it for $750 million more.
SDN is a significant growth opportunity for Juniper
"We're actually working kind of hard on it," Muglia says of the open source SDN controller effort. "It's sensible for Juniper because we want to be disruptive in this space."
Juniper recently laid out its SDN strategy, which includes adding OpenFlow support to specific products next year. The company considers SDN, which makes multi-vendor networks programmable through software, a significant growth opportunity for Juniper because it's coming from a small installed base of LAN and data centre switching. Juniper has about a 3 percent share of the $20 billion Ethernet switch market, good for a No. 3 position behind Cisco and HP, but small enough to have "a lot of upside," Muglia says.
And the data centre and campus networks are where Juniper sees the immediate short-term benefits of SDNs because the infrastructure is geographically concentrated. Programming a network is harder when the elements are geographically dispersed.
"When a disruptive thing comes in like SDN, there's a significant opportunity to change some of the dynamics of the market share," Muglia says. "So we see this as being very, very positive for us."
Yet, while working on a standard open source controller, Muglia also says Juniper will support whatever VMware does in SDNs due to its market influence and intrinsic technology.
Juniper's SDN controller will not be based on OpenFlow
"They're an important part of the data centre hypervisor and orchestration market and in the cloud space," he says. "We will support what they do."
Support does not, however, imply fully embracing a technology or direction or strategy. Muglia did characterise the VMware/Nicira controller as proprietary; open source code is renowned for being just that: open and freely accessible.
Still, Muglia could not say whether Juniper will brand its own SDN controller or source another. One thing is for sure though - while it will support the OpenFlow protocol, it will not be based on it.
"OpenFlow is one of the protocols for this controller to support," Muglia says. "There are scenarios in the WAN case where OpenFlow has provided a benefit," such as Google's data centre interconnection application. "When we look in the data center domain, and in particular in the switching aspects of the data centre, it is not clear that OpenFlow will be the key protocol. OpenFlow is about controlling the networking services, the Layer 2/Layer 3 services of the switches. And we're not at all clear that there's a lot of control that needs to be done there. We certainly don't believe that control has to be done on a per flow basis.
"On the other hand, when you deal with the policy that has to be set on a given application, for a given tenant in a cloud, that's interesting. And that needs to get established probably between the virtual switches and the hypervisor. That seems to be the way the industry is going, with Layer 2 overlay services sitting on top of a Layer 3 routed network. There, the protocols that seem to be more relevant to us, that have emerged thus far, are VXLAN and NVGRE. "
No comments:
Post a Comment