Two Competing Visions Of SDN
While the ONF approach is most commonly associated with SDN, there are two other emerging visions for software-driven networks. The second approach also separates the control and forwarding planes, but it does so by leveraging a virtual switch such as Cisco's Nexus 1000v, VMware's DVS or IBM's DVS 5000v. In this approach, the virtual switch functions as a forwarding engine that is programmed by a device that is separate from the virtual switch. This functionality is used as part of an overlay network that rides on top of the existing network infrastructure using protocols such as Virtual Extensible LAN or Network Virtualization using GRE.
This approach may appeal to existing customers of Cisco and VMware--the dominant vendors in the networking and server virtualization markets, respectively. However, it's only applicable for hypervisor-based virtual switches, not physical switches. In addition, support for functionality such as VXLAN and NVGRE is only now emerging.
The third approach uses direct programmatic interfaces via APIs into network devices, which are broadly defined to include devices that operate at Layers 2 through 7 of the OSI-defined network stack. In this case, the control and forwarding planes aren't separated, nor is the control plane centralized.
Many network vendors, including Cisco, are adopting this approach. This summer, Cisco announced that as part of its SDN approach it will offer APIs into multiple Cisco platforms, including its IOS, IOS XR, IOS XE, and NX-OS operating systems. Cisco says this will allow for tight integration with software applications and provide better control of the network infrastructure.
Along with Cisco, Arista, Extreme Networks, and Juniper Networks all provide direct access to their platforms via APIs.
One advantage of this approach is that it enables very detailed access and control when it comes to network devices. It also avoids the interoperability shortcomings that are associated with the OpenFlow protocol. Because this approach doesn't rely on a centralized controller, it also avoids the availability and security problems that can be associated with a controller-based architecture (that is, if the controller dies, so does the ability to move traffic through the network).
On the downside, this approach is vendor-specific. In a multivendor network environment, this approach would result in "islands of control" whereby the operator would have differing levels of control of the network equipment based on the provider of that equipment.