SDN Interest Shifts Toward The WAN

Even though it seems we have been talking about software-defined networking (SDN) for a long time, only a small number of companies have actually implemented it. That could produce cynicism among networking professionals about the likelihood of SDN ever being widely deployed.

However, to put SDN's adoption cycle into perspective, take a look at the adoption of virtual machines (VMs). VMware was founded in 1998, but it took virtualization until the late 2000s to really get traction.  So it's fair to say it took roughly a decade from when the concept of VMs began to gel until significant adoption took place.

It is debatable when the concept of SDN began to gel. However, in a 2012 Gartner report, analysts Joe Skorupa and Mark Fabbi listed OpenFlow as one of the technologies triggering interest in SDN. Since the origin of OpenFlow can be traced back nine years to 2006, that seems to indicate that SDN is following an adoption curve similar to that of VMs.

Given that SDN is proceeding along its adoption curve at a realistic pace, it's reasonable to ask: What's driving the adoption of SDN? An Information Week report I wrote in 2012 included the results of a survey asking that question. The number one response was that SDN would improve network utilization and efficiency. My more recent report, The 2015 Guide to SDN & NFV, asked that question again and got the same answer.

A reasonable person could deduce that the intended use of SDN hasn't changed during the last three years. That reasonable person would be wrong.

In 2012, virtually all of the discussion of SDN centered on it being deployed in a data center, and the two most common use cases were centralizing configuration and provisioning and supporting the dynamic movement of VMs. It's true that the data center remains the most likely place that SDN will be deployed. But in addition to previous use cases, others have emerged. As I discussed in the 2015 Guide, they include:

Unlike the situation in 2012, today there is significant interest in deploying SDN both in campus networks and the WAN. Some of the most popular SDN use cases in the campus include:

In 2012, the only discussion of SDN in the WAN focused on how Google had implemented SDN on the backbone links that connected its global data centers. This use of SDN in the WAN enabled Google to achieve much better network utilization.

To understand the growing interest in applying SDN more broadly in the WAN, it's helpful to understand that a common approach to designing a branch office WAN is to implement both a high-speed Internet link and an MPLS access link in each branch office, using policy-based routing (PBR) to balance traffic over the two links. While this design has many advantages, a disadvantage is that it creates a static allocation of traffic. That means it isn't possible to reallocate the traffic when the quality of one of the links degrades.

The software-defined WAN, on the other hand, will enable a WAN with multiple links to automatically reallocate traffic based on changing network conditions. This capability will allow network organizations to maximize the positive aspects of both MPLS and the Internet, while minimizing the negative aspects of those services.

It shouldn't be a surprise that over the last few years the key components of SDN's value proposition, such as improving network utilization and efficiency, haven't changed. It also shouldn't be a surprise that as we get closer to broad adoption of SDN that additional use cases are rising to the forefront.

Want to learn more about SDN in the WAN? Attend sessions like How the Software-Defined WAN Changes Everything For The Better and Software-Defined Networking and Network Virtualization at Interop Las Vegas this spring. Don't miss out! Register now for Interop, April 27 to May 1, and receive $200 off.