APIs and messaging protocols, including some that are standards, can let users build software-defined networks today. The key issue, though, is that not everyone implements the same ones or implements them the same way. Will OpenFlow get us all on the same path to SDN nirvana?
OpenFlow is an open source API defined to enable multivendor switches and routers to be programmable through software on a central control element -- hence, "software-defined networking." It's designed to manage and direct traffic among routers and switches from various vendors by separating the programming of routers and switches from underlying hardware in order to provide consistency in flow management and engineering.
ALTERNATIVES: 6 ways to build SDNs without OpenFlow
OpenFlow proponents say the API and protocol, and SDNs in general, will open up networks to more innovation by providing a level of abstraction, or virtualization, between network control and the physical infrastructure.
"Most of the applications that we're looking at that are really useful around SDN (such as virtualized, multitenant data centers) are things that I just can't picture building without OpenFlow," says Kyle Forster, co-founder of Big Switch Networks, a maker of OpenFlow controllers.
"We all recognize that managing networks that span multiple data centers, that may or not be owned by the company, is becoming too complex regardless of all the other advancements being made," says Derek Silva, an analyst at Info-Tech Research Group in London, Ontario. "Network management needs to be easier, and I feel that the vision developed by the SDN movement and [OpenFlow evangelist Open Networking Foundation] is probably the best way to make it happen."
But there are other considerations at play as well, such as where to physically locate the flow controllers, and these considerations are leading some to look beyond OpenFlow.
"The OpenFlow discussion assumes the controller is on a separate device," says Peter Christy, co-founder of the Internet Research Group, a Los Altos, Calif., consultancy. "A reasonable SDN configuration is to distribute the controller software onto each of the switches. In the case where the SDN controller is distributed to each of the switches it wouldn't make engineering sense to literally implement a formal communication protocol within the box."
Christy says an SDN that distributes the controller to the switches would improve the performance of communication between switch and controller, and improve the operation of the SDN. He says Juniper's QFabric architecture is an example of an SDN with a distributed control plane.
Arista Networks says its switch customers can implement SDNs using either controllers or distributed network control. The company says there are pros and cons to both approaches, but that both are required to implement a comprehensive SDN.
Arista defines four "pillars" of software-defined cloud networking: cloud topology, distributed control, network virtualization and management/automation. OpenFlow is one API among several that can be used in the management/automation pillar if the SDN is controller-based, according to Arista. Others are existing CLIs, SNMP, XMPP, Netconf, OpenStack, and APIs in VMware's vSphere virtualization software, Arista says.
There are use cases for each, says Jayshree Ullal, Arista CEO. For OpenFlow, she sees the use case as dynamic packet redirection for network tap aggregation, lawful intercept/CALEA, and topology-agnostic network segmentation deployments.
Whether that translates into broad adoption remains to be seen.
"The more use cases it can be deployed in, the stronger its applicability long term," she says.
Software-defined networking has the opportunity to be ubiquitous, she agrees. But whether OpenFlow will be the one API, or OpenStack, or Netconf, or XMPP, or VMware or another hypervisor is difficult to predict. Ullal says they all promise topology-agnostic network virtualization optimized for application and workload mobility.
At VMworld, Arista demonstrated how to build clouds with one-touch provisioning of virtual machines and up to 50,000 network nodes using the tools in its EOS operating system software and CloudVision interface. XMPP is the API in CloudVision. [Also see: "Ex-Cisco exec drawn to startup Arista's software architecture"]
"There's no reason tomorrow it couldn't be an OpenFlow or OpenStack API," Ullal says. "But here's a well-defined interface. Today we do Netconf and XMPP because it was easy to implement, well-defined specs and we had some customer interest there."
Ullal says Arista's EOS will support a suite of APIs for different "use cases" that customers demand. Right now, Arista is detecting initial demand for OpenFlow among research institutions, and in data centers to redirect flows to taps and tap aggregators.
"One new technology does not preclude the pragmatic approach of also enhancing existing technologies," she says with regard to SDNs. "In operational environments where legacy prevails, enhancing existing technologies is even more important than innovation."
Rather than OpenFlow driving SDNs, SDNs will drive OpenFlow, Ullal believes.
"The combination of OpenFlow with broader SDN APIs is vital for OpenFlow to be more broadly deployed," she says.
Big Switch's Forster says SDNs would not have the buzz or momentum in the market today were it not for OpenFlow. And with myriad APIs each tailored for a specific "use case," that means there needs to be fewer to program to.
"In many of the programmability approaches that vendors are trying the APIs become so incredibly specific that it's simply not profitable for a third-party vendor -- and really barely worth the customer's time -- to write on top of these incredibly specific APIs," he says. "There's a fairly broad consensus of folks realizing that unless there's a baseline of standardization, there's some that will never create an ecosystem of third-party applications for this."
With respect to XMPP, Forster says it's "clever" but doesn't mask the complexity of automation scripts written to it.
"XMPP doesn't let you write a Perl script that can roll back (unintended commands)," he says. "The Perl scripts that you write on top for automation still end up being pretty complicated."
But what's not debatable is the visibility OpenFlow is bringing to SDNs, and vice versa.
"OpenFlow is critical, and not because it's the answer," says Andre Kindness, an analyst with Forrester Research. "It's one of the answers. But it's the only one getting a lot of play because there are a lot of communities working on it. It's a huge amount of brainpower working on it. It's driving a lot of discussions and new ways of thinking. We got a good horse race going on here."
Read more about lan and wan in Network World's LAN & WAN section.
This story, "OpenFlow not the only path to network revolution" was originally published by Network World.