Where we stand with SDN

One gauge of industry progress on the software-defined networking front is the momentum of the Open Networking Foundation (ONF), the user-lead group that is spelling out the core SDN standards and championing the cause.

According to Marc Cohn, chairman of the ONF Market Education Committee and senior director for market development at Ciena, the ONF now has close to 110 members, vendors have released more than 60 products that support the ONF's OpenFlow protocol, and some 30 million Open- Flow-enabled ports have shipped.

Progress indeed.

But don't confuse that with activity in production shops. "One of our clients said, 'If SDN was a baseball game, we haven't finished singing the National Anthem yet,'" says Joe Skorupa, vice president and distinguished analyst at Gartner. "A lot of folks are trying to come to terms with what they need to do and how to get there."

Not that these folks are laggards.

[ALSO:Planning for SDN]

After all, the standards are still evolving and the strategic direction of the leading network vendors is still coming into focus. Regarding the former, the ONF just ratified version 1.4 of the OpenFlow protocol in August, even as the ONF board called on the industry to focus their efforts on version 1.3 in an effort to get everyone on the same page and provide industry stability.

OpenFlow is the standard way

SDN controllers communicate with and control OpenFlow-compliant network devices in these newly bifurcated environments. Bifurcated in that, with SDN, the network control plane is separated from the data plane, meaning control of the network is pried out of the devices that forward the packets and centralized on a server, what the ONF calls a controller. See: Understanding SDN

Rather than the classic approach of each network device forwarding traffic based on knowledge about adjacent devices, centralizing intelligence makes it possible to see the network end to end so decisions are based on a bigger picture and can take more variables into account, such as the needs of a certain application at a given time of day.

And when it comes time to make network changes, you do it at the controller and the configuration changes and policy updates are pushed out to the individual components instead of requiring you to update each link in the chain.

This is the broad view of SDN, where all resources, physical and virtual, play together in a softwarecontrolled world. While it may take some time to reach that nirvana given the huge installed base of legacy gear, the lower hanging fruit is network virtualization, which involves overlaying a software controlled network in a hypervisor environment to stitch together virtual server assets. This is the approach being driven by VMware using technology picked up in its 2012 acquisition of Nicira.

Network virtualization

For the most part, the industry views network virtualization/overlays to be an application of SDN and, given the broad and rapid adoption of virtualization, where early adoption can be found.

"That's really where all the action is because that's where the pain is right now," says Nick Lippis, a long time industry observer and co-founder of the Open Networking User Group (ONUG), an SDN user group he formed with Fidelity Investments.

Skorupa agrees. An overlay "is certainly the easiest insertion strategy because theoretically you can run it over your existing IP infrastructure. The reason I say theoretically is there are a number of asterisks that go along with it. You can run it over your existing IP infrastructure, but then it is a net incremental expense because you're still paying for the expensive, brittle, hard-to-manage, inflexible IP infrastructure. When something breaks in a pure overlay you've got to figure out, 'Where's the problem?' "Yes an overlay will deliver packets," he says, "but it won't necessarily pick the best path across the network. It doesn't mean you'll get appropriate load distribution. It doesn't mean the most important traffic will necessarily get treated the way you want it to in the face of a failure."

The good news about the overlay model, Skorupa says, is it's opaque to the underlying infrastructure. "It doesn't know it's there. The bad news is not being able to correlate between [the physical and the virtual] can cause significant problems."

VMware and other proponents of the overlay approach are trying to work around the limitations by partnering with equipment vendors to link the environments in a meaningful way. Juniper and HP, for example, say they will tie their SDN tools to VMware's NSX "network hypervisor," which was announced in August.

These and other legacy equipment suppliers are choosing their own paths to SDN. HP, for example, has gone all in with OpenFlow, adding support for the core ONF protocol to a full range of its switches. But it is also partnering with VMware to integrate its SDN tools with NSX, which perhaps gives it the best of both worlds.

Juniper, which has also partnered with VMware on NSX, just announced its Contrail SDN controller, positioning it as an SDN overlay tool that can also control physical network devices. "The Contrail controller provides an excellent bridge between the virtual world of hypervisors and the actual network," writes Zeus Kerravala, founder and principal analyst with ZK Research.

"The product uses XMPP to send messages for the control of a virtual switch inside a hypervisor. However, it also uses MPLS to control the network stack, giving the network manager control of the virtual network and the physical network."

Contrail does not, however, support OpenFlow, choosing instead to wait and see if that protocol is widely adopted.

Cisco, which has long partnered with VMware, now seems to be at odds with the company as both jockey for position in the software controlled network world.

"We've been very clear for the past three years that we see no way this partnership can survive," says Gartner's Skorupa. You can't have two companies partner when both are trying to become the leading vendor in the data center, he says. "The gloves came off at [the Cisco Live conference] when John Chambers stood up and essentially said, 'No one else in the industry understands these problems; we are the only viable choice.'

But VMware has a pretty good understanding of the problems and they have some very good partnerships. This is going to be a real battle."

Cisco's large network infrastructure installed base gives it a leg up on that front, but Cisco also believes customers that need to support multiple hypervisor environments will be reluctant to sign on with VMware. That may give pause to some users, but Skorupa points out that VMware "will support its hypervisor, Xen and KVM in the first release, and add Hyper-V in a subsequent release," so he's not sure that gives Cisco much leverage.

Cisco hasn't yet laid out all of its SDN cards, but has shown some. The Cisco ONE architecture, for example, introduced new infrastructure programmability capabilities, and the company has been talking up its new Application Centric Infrastructure architecture, which is "designed to support a data center that has applications that are nonvirtualized, virtualized and cloudbased," says Kerravala.

This fall Cisco is expected to fill in more of the blanks with the introduction of new hardware being developed by Insieme, a startup the company funded and will likely spin in.

While it is unclear what capabilities Cisco and some of the other legacy players will end up with, there is likely to remain discernible differences between the overlay/network virtualization camps and vendors advocating a hybrid approach that also takes into account direct control of data center hardware resources.

Network virtualization "is a subset of what you can do with SDN," Skorupa says. "It is an interesting application, but it's only one of them, and there are other things you can do."

One of those things is use SDN to control WAN and metro networks. "I've seen a lot of this in universities," says ONUG's Lippis, "while in the enterprise it has been basically experimentation."

The poster child of SDN controlled WANs is early ONF backer Google, which has already deployed an SDN backbone that is paying dividends. Google, of course, operates on a different plane than other enterprises (it even builds its own network gear), but there are some other early adopters out there. Skorupa says he has talked privately to an HP customer that is running five locations around the globe with a network operations staff of four, "and they reconfigure daily. They are very, very happy."

Somewhere down the road when enterprises and carriers alike have adopted SDN tools it may be possible for your SDN controls to influence service provider infrastructure.

One of Cohn's colleagues at Ciena is leading the ONF's Optical Transport Working Group, whose charter is to "extend OpenFlow and the OpenFlow substrate to support optical and transport networks," Cohn says, ostensibly giving enterprise applications control down to the optical layer.

"What's the most expensive bandwidth?" Cohn asks. "The WAN interconnecting data centers. So why shouldn't we virtualize that? That's one of the applications and use cases for the optical transport activities within the ONF. Another one is to provide what we refer to as performance on demand, the ability to provide elastic network bandwidth."

OpenDaylight impact

We are, of course, a ways away from realizing that capability. After all, many shops aren't even actively investigating SDN yet, although pilot tests may be picking up.

Lippis says that, at the first Open Network User Group meeting held in Boston last February, he was surprised to learn how few pilot tests were under way. But based on ongoing conversations with ONUG members, he thinks that will be different when the group gets back together in October in New York. "I think we're going to find a marked uptick in both pilots and deployments."

Why? "There's a lot of technology here but it's really all about one thing: how to reduce the cost of delivering IT," Lippis says. "A lot of the thinking is that SDN becomes part of a software defined data center strategy or a cloud infrastructure strategy, and it gets networking on the same path as computing and storage in terms of automation. That's the big motivator here."

One other change between the February ONUG meeting and this coming one -- the shifting fortunes of OpenDaylight, a Linux Foundation project developing an open source SDN controller that the vendor community can rally around.

OpenDaylight board member Inder Gopal, vice president for networking development at IBM, says OpenDaylight was started as a Linux Foundation project because "we needed a community that was familiar with community code development." Why not grow this within the ONF? Gopal says the ONF charter doesn't involve code development, nor did the group want to head in that direction.

Unlike the ONF, which was founded by large user organizations, Open Daylight was founded by vendors, early members including Arista Networks, Big Switch Networks, Brocade, Cisco, Citrix, Dell, Ericsson, Fujitsu, HP, IBM, Intel, Juniper, Microsoft, NEC, Nuage Networks, Plumgrid, Red Hat and VMware.

The effort started with code bases contributed by Big Switch and Cisco, but an effort to combine the two ultimately irked Big Switch, which withdrew from the group, leaving the project to build on the Cisco code base, and leaving some in the industry questioning the group's agenda. In fact Juniper, a Platinum member of the OpenDaylight project, has since made its Contrail controller available as open source and says it won't build product around OpenDaylight.

Lippis says it is too early to tell how much of an influence OpenDaylight will have on the SDN movement, but perceptions are changing. "When news of OpenDaylight leaked at the ONUG meeting in February, a lot of folks were rolling their eyes into their heads and saying, 'Oy vey,' because they viewed it as just another vendor-led consortium. By June no one was rolling their eyes anymore. I don't know what its overall impact is going to be -- we won't see the first version of their stack until around December -- but it is now at least getting consideration.

Getting there from here

Asked what he advises clients that are just now expressing interest in SDN, Skorupa says, "We advise them not to start with the technology. Start by identifying the business issues you're trying to address. What is it you want to do? Then from there start thinking about the things you need to achieve. Then set up a lab, pull together a team, begin the education process, bring in your incumbent and bring in at least two or three companies you haven't been working with, including startups."

Building the business case won't be a lay up, Skorupa warns: "The real question is, where does the incremental money come from? Because the last I heard, none of the vendors involved are charities. And you can't just stand up and say, 'Well, it will all be operational savings.' No, it won't. Unless you're going to cut a massive amount of staff. Somewhere you've got to come up with the dollars, and they're hard dollars, not soft dollars. These are not, 'We achieved business agility and it will let us enter a market sooner and take additional market share.' That's great, and the business gets a benefit, but where do the hard dollars up front come from?" Is failure still an option for SDN?

"There are enough people who have built enough to prove that it is possible," Skorupa says. "There will certainly be failures. There have been failures in the past when any new technology comes out. And it doesn't mean that the large incumbents will get it right. But they are several, very credible companies already benefiting from SDN."

Trouble is, few are yet willing to share their experiences, presumably because they want to leverage the technology in private for as long as they can here in the early goings.

Dix is editor in chief of Network World. Contact him at jdix@nww.com, follow him on Twitter at @JDNWW, or join the Network World communities at: LinkedIn, and Facebook.

Read more about lan and wan in Network World's LAN & WAN section.