- Silicon Valley's 19 Coolest Places to Work
- Is Windows 8 Development Worth the Trouble?
- 8 Books Every IT Leader Should Read This Year
- 10 Hot Hadoop Startups to Watch
Network World - 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.