With a new industry organisation to promote it, routing protocol OpenFlow is about to give users unprecedented ease of control over the way their networks operate.
OpenFlow enables software-defined networking, which means that users can define flows and determine what paths those flows take through a network, regardless of the underlying hardware. Last month, this approach was embraced by a wide range of big-name industry players as they formed the Open Networking Foundation (ONF) to push the protocol.
OpenFlow is an open source project borne of a six-year research collaboration between Stanford University and the University of California at Berkeley. OpenFlow can take control of how traffic flows through a network out of the hands of the infrastructure - the switches and routers - and put it in the hands of the network owner, individual users or individual applications. This capability could allow users to craft policies that find paths with available bandwidth, less latency or congestion and fewer hops.
Though it's useful, it's not as revolutionary as some might think, says Scott Shenker, a founding board member of the ONF and a professor at UC Berkeley.
"This approach doesn't let you do anything you couldn't do on a network before," Shenker says. "[But] it gives you a programmatic interface - it lets you program what you want to have happen in the network, how you want to route packets, how you want to do load balancing, how you want to do access control. So it's really that generality that drove us."
"It lets you create and run a multi-tenant network," says Zeus Kerravala, an analyst at the Yankee Group. "It's more than a VLAN; it's a true virtual network."
Kerravala says OpenFlow's open source roots allow users to experiment with it, too, by quickly creating and implementing new features and functions and customising the network to specific requirements. As an example, users could use OpenFlow to program switches to conserve power consumption by disabling unused links and switch ports.
OpenFlow has a lot of backers, a veritable Who's Who in the industry, in the ONF. Founders include Deutsche Telekom, Facebook, Google, Microsoft, Verizon and Yahoo; non-founding members include Cisco, Brocade, Juniper Networks, HP, Broadcom, Ciena, Riverbed Technology, Force10, Citrix, Dell, Ericsson, IBM, Marvell, NEC, Netgear, NTT and VMware.
Brocade will offer OpenFlow on its switches later this year, says Ken Cheng, vice-president of service provider products at the company. The company is exploring the technology as a way to manage "hyperscale" in a data centre that has hundreds and thousands of racks of equipment. Brocade is also evaluating OpenFlow as a method for flow management on the WAN, and to better control virtualisation in a data centre.
"We have MAC addresses in the millions, potentially" from virtualisation, Cheng says. "That scale is beyond what any reasonably constructed switches can comprehend."
However, some Brocade competitors and fellow ONF members are a bit more bearish on OpenFlow. Force10 is waiting for the technology to mature a little bit more before offering it in its switches, says chief marketing officer Arpit Joshipura.
"We have to make sure that all the specifications that were originally not scalable are scalable," Joshipura says. "Big network users are more interested in this today than traditional enterprises."
And still others outside the ONF say OpenFlow may be reinventing the wheel.
"We did 'experiment' with such an architecture already in the early 90s, where we tried to centralise flow setup decisions centrally with a system called SecureFast VNS Virtual Network Server," says Markus Nispel, chief technology strategist at Enterasys Networks, a Siemens Enterprise Communications company. "Due to scalability problems this ended up in a released product/architecture called SecureFast which used a distributed flow setup and was also connection-oriented switching leveraging 'OSPF on L2' as the topology protocol. Which gave us ... active Layer 2 meshing in 1996.
"The main concern here is trying to externalise the flow setup," Nispel says. "10G Ethernet could bring you up to 15 million flows per second per interface. How could an external system cope with that? We do have hardware assistance internally to the system to manage flows in the system. External [would be] challenging."
Nevertheless, Enterasys is investigating a hybrid approach where only selective flow setups are done externally for application awareness and tracking, Nispel says. The rise of cloud services requires more intelligence and visibility into flows for security purposes, to enforce application policies and for more advanced application delivery services, he says.
But Nispel considers OpenFlow more of a service provider or specialised data centre protocol than a general-purpose mechanism for the enterprise. There are enough established protocols available for separation of services in the enterprise, he says. Adding OpenFlow to the mix would overly complicate and confuse matters.
"I do see technologies like VLAN, VRF, MPLS and tunneling like GRE as established," he says. "You could add OpenFlow, but will it make it easier? I do not see that OpenFlow-based solutions are easier to deploy."
The ease of deployment comes with the protocol's programmability, says Berkeley's Shenker.
"You program switches through scripting, the same way you can program everything else," Shenker says. "The technology is not limited at all; it's just providing programmatic control. You can manage the network so that each specific need is met."
Programmability was problematic before because vendors opened up their control plane functionality on routers and switches to varying degrees. Programmability was vendor-specific and device-specific, Shenker says.
ONF serves as a vehicle to ensure that this programmability remains consistent, easy to use and easy to access across various network devices from various vendors.
"We needed to standardise OpenFlow" for this to occur, Shenker says. "There needs to be an industrial-strength standards body. A few vendors offer it now but there will be more by the end of the year."
Other observers feel external programming of routers and switches through OpenFlow and SDN could help IT shops better manage their data centres. In a post on his "OpenSource Fact and Fiction" blog, Alan Shimel writes that it could make it easier to traffic around hardware failures.
"It could also be used to allow energy savings by identifying underused devices and shut them down when they are not needed," Shimel blogs.
He notes that with the strong backing, its chance of success might seem pretty high. But Shimel also states that other widely supported standards efforts have been derailed before.
"Microsoft and even Cisco are well known for 'embracing and extending' such standards to make them less than globally interoperable," Shimel blogs. "However, with so many lined up behind this one, I don't think that will be the case here. At least I hope not."
OpenFlow was demonstrated late last year at the ninth GENI Engineering Conference (GEC9) in Washington, DC. NEC was showing off its implementation and an OpenFlow switch startup, Big Switch Networks, recently received almost $14 million in funding.
An open-source switch company called Pica8 also plans to include it in its products for data centres and cloud-computing environments. Those are two areas that could benefit immediately from OpenFlow, Shenker says, due to the proliferation of virtual machines in those environments.
"The data centre market will be first, where people have the most pain," he says. "It's a place where this technology is needed the most."