Cisco Subnet An independent Cisco community View more

OpenFlow, Software-Defined Networking and the Enterprise WAN

Handicapping where OpenFlow will flourish when, and why

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.

The market segments we’ll cover are:

  • Cloud Services Providers / large website data centers
  • Universities and research campus networks
  • Metro Area CSP data center interconnect 
  • Enterprise data centers
  • Internet service provider core routed networks
  • Campus LAN
  • Enterprise WAN 

We’ll do them in rough order of likelihood of meaningful market adoption of OpenFlow. By “meaningful,” I’m not trying to characterize market acceptance precisely, but rather, to use terminology made famous by Geoffrey Moore, when OpenFlow is likely to “cross the chasm” and reach the pragmatic majority (as opposed to a few early adopters) for each market segment.

You’ll note that I’m fairly bullish on OpenFlow overall, but I think the rate of adoption will vary dramatically based on market segment.

Cloud Services Provider / large website data centers

  • Customer value of equipment cost savings (through lower vendor margins): high 
  • Customer value of programmability: high
  • Cisco relative power over customer: low 
  • Customer conservatism / installed base issue: low 
  • Prediction: Short-term success (90%+ probability), medium-term dominance (85%+ probability)

Within a single physical data center, for Cloud Services Providers (CSPs) and those running large-scale websites, all the stars align here, in terms of the value to the customer of lower equipment cost and greater programmability, and the relatively low power Cisco or any incumbent vendor has over the customer, combined with the fact that the scaling issues customers face dealing with growth mean that they are highly motivated to be innovators rather than conservative. Google alone could almost single-handedly ensure that this portion of the market happens, but there are many more than Google who will adopt it fairly quickly.

Universities/research campus networks

  • Customer value of equipment cost savings: high 
  • Customer value of programmability: moderate - high 
  • Cisco relative power over customer: low - moderate 
  • Customer conservatism / installed base issue: low 
  • Prediction: Short-term success (90%+ probability), medium-term dominance (75%+ probability)

This is the smallest market segment covered here, but the barriers are low and the research value alone, combined with being from where the technology originates, makes this a likely “bowling alley” in which OpenFlow will flourish.

Cloud Services Provider data center to data center interconnect

  • Customer value of equipment cost savings: low - moderate 
  • Customer value of programmability: high 
  • Cisco relative power over customer: low - moderate 
  • Customer conservatism / installed base issue: moderate 
  •  Prediction: Short term (I don’t have one!), medium-term success (50%? probability), long-term success (65%? probability)

This is the hardest one of them all for me to predict. To the extent CSPs are connecting data centers to each other over short distances (a few hundred miles, ~10 ms or less one-way latency) and connecting the locations using point-point connections of their “own” (i.e. layer 1 fiber or optical wavelengths), then this is a no-brainer that will happen. To the extent that it’s about a solution for connecting data centers over long distances worldwide, and/or connecting using public Internet connections or connections from a third-party service provider, it’s much less clear that OpenFlow will succeed here, as the latency, QoS and billing issues are considerable.

Google’s already done this for its internal WAN, but clearly spent lots of high-powered resources on it and has enough specialized needs that I don’t think this generalizes much in the medium term for service provider global WAN implementations. That said, no doubt some kind of SDN solutions will be available for this and at minimum interoperate with intra-data center OpenFlow implementations.

Enterprise data centers

  • Customer value of equipment cost savings: moderate 
  • Customer value of programmability: moderate+ 
  • Cisco relative power over customer: moderate+ 
  • Customer conservatism / installed base issue: varies 
  • Prediction: Short term will barely happen (80% probability), medium-term success (40% - 50% probability), long-term success (90%+? probability)

While there will of course be some early adopters, especially those F200 companies migrating most quickly to hybrid cloud computing or large private cloud computing, the combination of Cisco’s incumbency, some conservatism, and the fact that for most the benefits are neither huge nor insignificant but rather somewhere in the middle, makes this one of the easier predictions, at least for the short term and the long term. Widespread adoption will track just ahead of Cisco’s serious acceptance of OpenFlow.

Specifically, there won’t be much adoption in the short term, just a lot of trials. Long term, it will happen, because the benefits will be significant enough and because Cisco, no matter how much they drag their feet over the next couple years, will eventually support it (see Insieme) and even promote it as a way to entice their customers to upgrade equipment years from now, and because the installed base of non-OpenFlow capable hardware will eventually be repurposed to the campus LAN or written off.

Only the “medium” term is hard to predict in terms of whether it is three, four or five years from now that OpenFlow-enabled data center switches “go tornado” and dominate the enterprise market. The exact timing will depend on how well Cisco’s competitors execute, the timing and quality of Cisco’s initial OpenFlow products and whether Cisco does too much “embrace and extend” for its own and its customers’ good, and to a lesser extent on how quickly the move to enterprise private cloud computing goes mainstream. It also may end up being just like “the year of the LAN” in the late 1980s; there never really was a single year that it “happened,” just an every-year increase until almost everyone was using them by about 1992.

Internet service provider core routed networks

  • Customer value of equipment cost savings: moderate - high?
  • Customer value of programmability: moderate+
  • Cisco relative power over customer: moderate
  • Customer conservatism / installed base issue: moderate - high 
  • Prediction: Short term will not happen (95% probability), medium term will not happen (70% probability), long-term success (???)

While the shorter term is pretty clear, whether or not OpenFlow succeeds here in the long term is the other one I find hard to predict. In the short term, it just won’t happen: the benefits aren’t high enough for the providers to take the big risk of moving to it, especially given their large installed base of equipment. I also don’t think it will happen much in the two-to-four-year timeframe, as I think the vast majority of effort on the part of both vendors and service providers will come in deploying OpenFlow in service provider data centers, rather than for the routed backbone.

Longer term, it’s not clear to me whether the benefits of the prospect of more vendor competition and so lower equipment costs coupled with additional programmability advantages will outweigh the fact that OpenFlow is really designed for low-latency campus and data center environments rather than for the latency issues faced by global WANs or the routing table issues of the entire Internet. While it’s clear to me that SDN of some sort will prosper in this segment in the long term, my crystal ball is cloudy on whether or not OpenFlow will be the way this happens. My bet sitting here today in 2012 would be no, but I’m much less sure of this than of all my other predictions in this column.

Campus LAN

  • Customer value of equipment cost savings: low - moderate
  • Customer value of programmability: low - moderate
  • Cisco relative power over customer: moderate - high
  • Customer conservatism / installed base issue: moderate - high
  • Prediction: Short term will not happen (98% probability), medium term will not happen (75% probability), long-term success (85% probability)

By contrast, this prediction seems pretty easy to me. The value in the short term is too low, and the Cisco lock-in and customer conservatism are too high, for OpenFlow to happen in the campus LAN in a big way short term. Conversely, in the long term, since all the LAN switching vendors including Cisco will adopt it and there are some benefits for the enterprise campus, it is going to happen.

As with the enterprise data center, adoption will track Cisco’s serious acceptance of OpenFlow, but widespread adoption in the campus will be about two years behind adoption in the enterprise data center, meaning for most customers it’s not likely to occur in the medium term (next four years), although no doubt there will be at least some campus deployments in that timeframe.

Enterprise WAN

  • Customer value of equipment cost savings: low 
  • Customer value of programmability: moderate 
  • Cisco relative power over customer: high 
  • Customer conservatism / installed base issue: high 
  • Prediction: Short term will not happen (100% probability), medium term will not happen (95% probability), long term will not happen (75% probability)

As you can see, if you compare the incentives and barriers here to those for service provider data centers, they are almost diametrically opposed. The value to the customer is fairly low, the inertia factor is fairly high, and OpenFlow itself wasn’t designed and really isn’t suited to the issues facing the enterprise WAN manager.

Remember, the question addressed here is whether OpenFlow will be the solution for the Enterprise WAN. To me the answer to that question is a clear no. That said, there will likely be an indirect impact on the Enterprise WAN from OpenFlow’s ability to cost-effectively enable the migration to private cloud computing to happen that much more quickly; cloud computing will of course directly impact the Enterprise WAN, and is one of the drivers for the need for a NEW architecture for the WAN.

The questions of when software-defined networking will be embraced for the Enterprise WAN, and what form(s) it might take, are very different. SDN almost certainly will happen in the enterprise WAN. In fact, WAN Virtualization is a form of software-defined networking. Where OpenFlow leverages (cheap) switches to build and control a reliable, scalable “self-managed” LAN network fabric for a data center or campus, WAN Virtualization leverages (cheap) Internet connectivity to augment or replace an MPLS WAN, building and controlling a reliable “self-managed” WAN network fabric to connect remote locations to private data centers, private clouds or public cloud services.

OpenFlow is a Layer 2 technique optimized and focused on changing the paradigm of LAN switches and in particular data center LAN switching. As with most things in IT, it is most likely to succeed in the areas for which it is most suited and optimized. Software-defined networking likely is in the cards for the enterprise WAN over the next few years, but it isn’t going to be OpenFlow-based; that market’s needs and the technology’s focus are simply too different.

A leading expert in WAN/LAN switching and routing, Andy founded Talari Networks, a pioneer in WAN Virtualization technology, and served as its first CEO. Andy is the author of an upcoming book on Next-generation Enterprise WANs.

From CSO: 7 security mistakes people make with their mobile device
Join the discussion
Be the first to comment on this article. Our Commenting Policies