OpenFlow At The Core
The SDN approach that's most well known separates a network's forwarding and control planes, which typically reside in a switch, and moves the control plane to a separate device. This device, called a controller, calculates the best path through a network for particular workloads and programs the forwarding behavior of the switches (see diagram, below). The controller can be an appliance, a virtual machine, or a physical server.
A core concept of this approach to SDN is that the OpenFlow protocol is used between the network elements and an SDN controller to program the forwarding behavior of the switch. Thirty-three percent of survey respondents say they're very familiar or familiar with the OpenFlow protocol, and another 38% say they are somewhat familiar. The controller also has a northbound API, which is an interface for applications that want to use OpenFlow data. A number of vendors have announced their intention to ship OpenFlow-enabled switches, including Brocade, Cisco, Extreme Networks, Hewlett-Packard, and Juniper Networks.
The Open Networking Foundation (ONF), a nonprofit group that oversees the development of the OpenFlow protocol, advocates a controller-based architecture using OpenFlow. The foundation has more than 70 members, including telecom companies, Internet giants such as Google and Facebook, some of the world's largest network device manufacturers (including Cisco), and startups.
Though OpenFlow is the best-known interface, there are alternatives to it as the communications protocol between a controller and network devices. In addition to Java, C, Python, and REST APIs, the alternatives include the Extensible Messaging and Presence Protocol, the Network Configuration Protocol, and OpenStack from Rackspace and NASA. However, our survey shows that OpenFlow is closely associated with SDN.
One of the implications of the ONF-backed approach is the likelihood that switches and routers would become low-cost commodities, which could potentially cut costs for companies that adopt this approach. While vendors such as Cisco and HP have downplayed the dumb-switch concept, companies such as Dell, IBM, and NEC are more supportive of it. For instance, NEC sells both a controller and switches that support OpenFlow. IBM has also released a line of switches that support OpenFlow, and partnered with NEC to make sure IBM switches work with NEC's controller. A startup called Big Switch Networks is also developing a controller that supports OpenFlow.
The disagreement on the relative role of the controller and the network elements between members of the same class of products is one of the many factors driving the confusion that surrounds SDN.
Our survey respondents aren't convinced SDN will result in a dumbing down of switches and routers: just 29% say it will, 37% say it won't, and a third don't know.
When evaluating SDN, IT organizations need to take a position on this question of the switch's role. Is reducing the relative value of switches and routers a desired outcome of implementing SDN? An acceptable outcome? An unacceptable outcome? The position that an IT organization takes will influence which vendors they consider using and which ones they should avoid.
The primary advantages of the ONF approach to SDN is that it is based on industry-standard protocols and has growing vendor support and momentum. It may also reduce costs because switches would become single-function commodity devices.
However, one disadvantage of this approach is that vendors are just in the early stages of implementing OpenFlow, which means interoperability among vendors isn't assured.
An example of that lack of interoperability can be seen back in the diagram below: The northbound interface shown on the previous page isn't standardized. This means any company or vendor that writes an application to communicate with a controller has to ensure that the application works with APIs from myriad controller vendors. Note that the Open Network Foundation recently announced an initiative intended to make it easier for application providers to use various APIs.
Other possible downsides include the fact that companies would have to rearchitect their networks to incorporate the controller-based system. However, our survey suggests this may not be a significant barrier. Of those with or planning to have SDN in production, 88% are moderately to completely willing to make significant changes to get SDN benefits.
Discover the benefits of scalable backbone and network services for application and cloud providers.
Network automation is gaining momentum. Here's how you can drive this powerful technology to its full potential.
Subsea cable alternatives can provide a level of comfort for those concerned about disruptions. Realistically, they will continue to play a small, but critical role in the short term.
