Skip Links

OpenFlow, Software-Defined Networking and the Enterprise WAN

Handicapping where OpenFlow will flourish when, and why

By Andy Gottlieb on Fri, 04/27/12 - 11:34am.

Context is everything. In our next column, we’ll resume the discussion of the details behind the Next-generation Enterprise WAN (NEW) architecture.

Here, with the recent Open Networking Summit, and the excitement around Software-Defined Networking in general, and OpenFlow in particular, let’s take a look at the adjacent topic of what’s going on in data center (LAN) networking, and whether and how it relates to the Enterprise WAN.

Server virtualization and cloud computing – public, private and eventually hybrid - are obviously revolutionizing the world of computing and are having huge knock-on effects on storage. Almost as clearly, the rise of server virtualization and cloud computing is undeniably having a big effect on the data center LAN.

Into this void, researchers from Stanford and Cal Berkeley introduced OpenFlow, a programmable network protocol designed to manage and direct traffic among switches from various vendors, which separates the networking data plane and hardware from the controller which tells the hardware where to forward which packets.

OpenFlow is a Layer 2 technique targeting LAN switches. LAN switching is the largest revenue market in networking, and data centers are the fastest growing segment of LAN switching and the place where the most change is going on, and thus the most ripe target for a new technology - and for startups - to unseat the incumbent vendors. Unsurprisingly, then, the data center LAN is where almost all the attention about OpenFlow is directed.

Software-Defined Networking (SDN) is a generally new network design concept that changes the way network traffic is managed by uncoupling the software that directs the traffic from the physical hardware-based network elements. We’ll come back to SDN at the end when we get back to the implications for the Enterprise WAN.

OpenFlow is the hottest instance of a protocol for SDN, and specifically one where an attempt is being made to have a standard, interoperable solution, not a vendor proprietary one.

Let’s also be honest about the motivation of most of those promoting OpenFlow. There are lots of words and ideas thrown about in discussions of OpenFlow, but I’d argue that they fundamentally boil down to two: 1) the ability to increase the number of vendors that have a chance at a big chunk of the enormous LAN switching market, by toppling the Cisco near-monopoly and so Cisco’s extremely high margins, thereby lowering the cost of equipment to the end user, and 2) the value of programmability of the network – for both improved functionality / efficiency / “performance,” as well as ease of network management and provisioning (i.e. lower OpEx).

"Predictions are hard, especially about the future,” Yogi Berra is supposed to have said.

With that caveat, let’s handicap how likely OpenFlow is to succeed in the short (0 – 2 years), medium (2 – 4 years), and long (4+ years) term in various network equipment markets. We do this by analyzing for each of seven different market segments (or networking sub-markets, if you will) how OpenFlow is likely to be valued by customers on our two key axes – cost savings potential and programmability – as well as how much inertia / pushback that adoption of the new technology will likely get from vendor (read mostly: Cisco) power and inherent customer conservatism.