Guide: Vendors take alternatives to OpenFlow SDN

OpenFlow may be the darling SDN protocol, but network vendors are taking alternate approaches to SDN and network programmability.

For a while, the terms "OpenFlow" and "software-defined networking" (SDN) were nearly interchangeable. The networking protocol was enjoying a lot of hype, and network engineers saw it as the answer to SDN. But that attitude is slowly changing, led in large part by networking vendors' efforts to differentiate their own SDN offerings -- and to maintain their market share. This guide provides an overview of OpenFlow SDN opinions and how vendors are responding to the SDN protocol.

Table of contents:

Why OpenFlow SDN matters

In a software-defined network, switches and routers take some form of direction from a centralized software management element. In the context of OpenFlow, the control plane is abstracted from the data forwarding plane. A centralized controller, which maintains a real-time, holistic view of the network, defines network paths as "flows" and distributes this flow data to individual switches and routers. With these flows, the controller coordinates the forwarding of data across all network devices.

OpenFlow has been well received by the networking community because it enables the automation and granularly managed dynamic provisioning necessary in virtualized environments and cloud networks.

In the article about the OpenFlow protcol hype and SDN, SearchNetworking News Editor Shamus McGillicuddy further explores these benefits.

SDN is about network programmability, not necessarily OpenFlow

However, an OpenFlow network requires an OpenFlow controller and a network switch vendor that supports the protocol. And networking vendors are hesitant to jump on the bandwagon. Companies such as Cisco, Nicira and VMware posit that SDN is about network programmability, not necessarily OpenFlow. It's worth noting that all of these companies are actively involved in the development of OpenFlow through the Open Networking Research Center and the Open Networking Foundation. So while each company wants to promote and maintain its own approach to SDN to differentiate, they're all keeping OpenFlow SDN in the mix.

See why vendors say OpenFlow and SDN aren't synonymous.

Cisco SDN strategy aims for network programmability, not OpenFlow

While most SDN strategies separate the control and forwarding planes in order to make networks more programmable, Cisco asserts that organizations want programmability from the transport layer all the way up to Layers 4-7 and the orchestration/management plane. The Cisco Open Network Environment promises to open up the entire network stack for programmability, but focuses more on network overlays and opening APIs than on centralizing network control and management with a controller.

Cisco plans to address the demand for programmable networks in three ways. The company will offer an OpenFlow controller and agent to be deployed on its Catalyst 3750-X and 3560-X switches for universities and research institutes that are working on SDN research. For its customers, Cisco will support virtual network overlays, such as LISP and Virtual Extensible LAN (VXLAN), to bridge physical and virtual worlds. In addition, it will introduce a software-development kit that makes all of its routers and switches programmable through a universal API.

Read about Cisco's SDN plans to learn more.

VMware goes overlay instead of OpenFlow SDN

VMware has chosen to protect its own technology model by creating overlays for network virtualization -- completely bypassing OpenFlow SDN.

VMware first tackled network virtualization with its VXLAN protocol, which is a Layer 2 tunneling technology that promises to eliminate VLAN limits that can cripple a virtual environment.

Then, in 2012, VMware acquired startup Nicira Networks, which developed a Network Virtualization Platform (NVP) that creates an abstraction layer between a physical network and the virtual switches deployed on hypervisor hosts. It uses controller software to provision and manage network services for virtual server workloads regardless of the underlying network hardware. NVP achieves this by deploying its own flavor of the Open vSwitch on host servers. It's unclear how the competing virtual switch technologies from Nicira and VMware will coexist, but VMware says it is committed to staying on course with all of Nicira's technology.

Nicira has moved away from OpenFlow use despite the fact that founder Martin Casado is one of the protocol's inventors. When he created OpenFlow, Casado sought to transform the operational model of networking so it could keep up with the automation that server virtualization brought with the data center. He has since said that decoupling the control plane and the data plane in networking hardware is the wrong approach to this problem. Instead of managing packet forwarding, which is handled well by legacy networks, OpenFlow is used to better address traditionally manual processes that have become unwieldy in a virtual environment: specifically, the implementation of access control lists, VLANs, network isolation, billing and accounting. These operations are moved to virtual switches in Nicira's SDN model.

To learn more about Nicira's stance on OpenFlow in software-defined networks, read Why Nicira abandoned OpenFlow.

Making OpenFlow SDN work on top of traditional hardware

SDN startup Big Switch Networks is a big OpenFlow proponent, but the company also aims to make it possible for enterprises to build SDNs on top of any underlying physical infrastructure, whether or not they're OpenFlow-friendly. In doing so, Big Switch hopes to enable network virtualization that will easily rival VMware. Big Switch offers an OpenFlow controller, and it enables an OpenFlow network overlay technology as part of its Big Virtual Switch network virtualization application.

The network overlay technology uses OpenFlow-enabled hypervisor virtual switches at the server access layer of a network to create a virtual network on top of an existing physical network. This network overlay tunnels through the physical network, enabling enterprises to build OpenFlow-based SDNs on top of traditional equipment from Cisco or any other networking vendor that does not yet support OpenFlow.

While Big Switch's network overlay allows a gradual migration to an OpenFlow-based SDN, it does have its drawbacks.

Learn more about the Big Switch network overlay app and its downsides.

OpenFlow's merits still recognized by networking community

Despite some networking vendors' efforts to shift focus away from OpenFlow, the protocol continues to have its advocates among the networking community. Greg Ferro, Fast Packet blogger and co-creator of the Packet Pushers podcast, asserts that OpenFlow applications work where network management tools fail. He writes that OpenFlow applications go well beyond the capabilities of network monitoring or management tools by enabling a centralized view of the entire network configuration along with control, even in a dynamic virtual environment.

Read Ferro's take on the use of OpenFlow SDN in network management.

Plenty of future for OpenFlow applications

As vendors develop their own approach to SDN in response to OpenFlow, the protocol continues to evolve and its capabilities continue to expand. With the "southbound" functionality of OpenFlow established, the Open Networking Foundation is focusing on the protocol's northbound functionality.

In August 2012, the ONF acknowledged that developers of network-control applications wish to write "for the northbound edge of an OpenFlow controller." It also announced an initiative to catalog and characterize existing APIs in a first step toward assessing market requirements.

This effort is goes in direct opposition of Cisco, as further described in the article how Northbound OpenFlow apps are up next.