OpenFlow's Impact: The Industry Debate Rages

Is OpenFlow just the latest attempt to centralize network control, or is it something wholly new? People across the industry have been debating whether OpenFlow is really an industry game-changer.

"The 'new thing' in my mind is the timing," says Kyle Forster, co-founder of Big Switch Networks, a startup developing a network controller based on OpenFlow. "The first leg of this is silicon trends--merchant silicon is changing the rules around who makes what. The second leg is supply chain trends. Server vendors must react to the Cisco UCS by expanding into networking. Last, customer requirements are changing. Networks for VMs and for the increasingly disparate types of mobile and embedded devices on a campus LAN are different from networks of five and 10 years ago."

OpenFlow itself is just a definition of instruction and messaging sets between a server-based controller and a group of switches. It's how the controller uses the instruction set that will determine how disruptive the protocol becomes to the networking industry.

Ivan Pepelnjak, chief technology adviser at NIL Data Communications, has written a number of blog posts (at blog.ioshints.info) questioning whether the expectations being set around OpenFlow are overblown. "I can't see a single area where a TCAM download protocol--which is what OpenFlow is--can do things that a router or switch could not do. There are things that can be done with OpenFlow that cannot be done with current protocols. But then one has to ask oneself: Why has nobody yet developed a protocol to address those things?"

Pepelnjak does see the protocol as a means of consolidating and streamlining the way networks are controlled. He says OpenFlow will make it easier to implement customized functionality, and it will give third-party software lower-level control in multivendor networks.

Forster counters that OpenFlow will make a lot of difficult networking problems easier to solve. "Automating move-add-change requests, virtual network overlays, multipath forwarding, and automated provisioning are all relatively straightforward engineering initiatives with an OpenFlow-style centralized control plane," he says. "While they can be done with a distributed control plane or, practically speaking, with a classic set of networking features and a lot of Expect scripts, these classic approaches tend to be a fragile set of scripts that open up a Pandora's box of corner cases."

Martin Casado, one of OpenFlow's developers and currently CTO of Nicira Networks, says he's seen some "pretty cool stuff" built on OpenFlow, like network connectivity managed by a high-level language that plugs into an existing, proprietary security framework. The key points are that OpenFlow gives network mangers programmatic control of their networks using industry standards, he says, "using the same distributed system libraries and packages they use to orchestrate the rest of their infrastructure."

Ultimately, the success or failure of OpenFlow--and, more widely, of software-defined networking--depends on how well controllers integrate with switches and how widely available OpenFlow-capable switches become. "I think we're a long way out," Casado says, "before a controller vendor can support an OpenFlow-capable switch without a fairly close partnership between the two companies."

Dave Ward, CTO of Juniper Networks' Infrastructure Products Group, says the biggest benefit of OpenFlow is giving IT more visibility and control in virtualized data centers. "As endpoints move around in the ever-expanding network footprints, we think that flexible methodologies are needed to enable and disable certain traffic conditions or to enable and disable certain types of traffic," Ward says. "Having such functionality via a common interface could prove very valuable for anyone operating an infrastructure that is experiencing high rates of change."

So far, Cisco and Juniper have supported OpenFlow, and Juniper has demonstrated support in some of its products. "The real question about OpenFlow," Ward says, "is not if it provides additional capabilities in any one device, but whether it can deliver those capabilities across a heterogeneous network."

All Articles In This Cover Story: