OpenFlow and SDNs Raise Many Questions

Recent discussions about software-defined networks (SDNs) and OpenFlow - an emerging open communications protocol allowing server software to determine the forwarding path data packets take through a network of switches - imply that you can't have an SDN without OpenFlow or vice versa. Both technologies offer potential value, but what exactly is the relationship between them? And does implementing SDN and OpenFlow mean an IT organization will need only "dumbed-down" switches and routers one day soon?

Potential for Increased Flexibility

Switches and routers have two fundamental components: the control plane and the data plane. The control plane provides the intelligence to make decisions, while the data plane provides the functionality to forward packets. In an SDN, the network device's control plane runs in software on commodity servers separate from the network devices. In addition, the data plane becomes more programmable.

The hope is that virtualized, programmable networks will make it significantly easier to introduce new functionality into the network. In fact, many of the concepts that underlie an SDN are not new; Asynchronous Transfer Mode (ATM) LAN Emulation, for example, was an earlier attempt to separate the control and data planes.

A previous TechNote discussed alternatives to the Spanning Tree Protocol, which has been used for decades to eliminate data-forwarding loops in bridged Ethernet LANs. These alternative protocols include shortest path bridging (SPB) and Transparent Interconnection of Lots of Links (TRILL). Because the control plane of an SDN has a global view of the network topology, it allows the SDN to avoid loops without having to resort to protocols such as TRILL or SPB.

The OpenFlow application programming interface (API) can function as a "network hypervisor" by providing a common instruction interface between the network operating system (NOS) and the packet-forwarding hardware. This abstraction layer allows OpenFlow-enabled switches from different vendors to be mixed and matched without impacting the NOS. The OpenFlow Switch Consortium had maintained the OpenFlow specification until recently, when the Open Networking Foundation announced that it would assume this responsibility.

Building an SDN with OpenFlow

There are two requirements for building an SDN with OpenFlow:

• A NOS that supports OpenFlow. This NOS could be a modification of an existing proprietary NOS or possibly an open-source NOS.
• Packet-forwarding hardware that supports OpenFlow. In principle, the SDN could be based on a physical network built with OpenFlow switches from a number of different vendors.

A major potential benefit of an SDN with OpenFlow is that multiple independent virtual networks can share a common physical infrastructure. Virtual networks would be based on segmenting flows. Within OpenFlow, flows are defined using a 10-tuple of header fields including Ethernet source and destination address (SA/DA), IP SA/DA, TCP/UDP ports, and VLAN ID. This could be used to provide enhanced security via firewall-style granular control of traffic flows within virtual networks.

In a recent Webtorials discussion about OpenFlow, six leading data center LAN switch vendors were asked if OpenFlow would relegate switches and routers to being merely "dumb" forwarding devices and move all network intelligence to be hosted in commodity servers. Not surprisingly, none of the six vendors thought that outcome was likely.

The reality, though, is that it is much too soon to tell. Despite all the interest in SDNs and OpenFlow, networks implementing these two technologies have not yet been widely deployed. As a result, it is impossible to say whether routing decisions, for example, can be handled successfully in a centralized server or if that would introduce too much delay, requiring that routing continue to take place inside the routers.

While OpenFlow is the approach that currently has the greatest momentum, it is not the only way to implement an SDN. A half-day workshop on SDN and OpenFlow will examine the alternatives and issues at the Interop Las Vegas Conference and Expo, to be held at the Mandalay Bay May 6-10, 2012. I will co-moderate the session on Monday, May 7, along with Mike Fratto of Network Computing. Please attend, learn more about this important topic and provide your input.