SDWAN To The Rescue.

Sofware-Defined WAN (SD-WAN) technologies are a hot topic right now in the networking world. Here we have a case of two extremes coming together. One extreme is the WAN, which has seen little fundamental development in roughly a decade. The other extreme is Software-Defined Networking (SDN), which has been a focal point for massive development over the last few years. So what does it mean to bring these two extremes together into a Software-Defined WAN?

To many network professionals the term “WAN” does not refer to the Internet, but refers exclusively to enterprise WAN services such as Frame Relay, ATM or MPLS. The distinction is that enterprise WAN services were designed primarily to connect a given enterprise’s branch offices and data centers while the Internet provides connectivity to a huge range of resources with myriad owners. To me that is an arbitrary distinction that is quickly losing relevance, and as a result the term “WAN”, to me, refers to either an enterprise WAN service, the Internet, or any combination of those two services.

Expanding what is thought of as a WAN has some ramifications because, as documented in The 2014 State of the WAN Report, network organizations have somewhat different concerns with an enterprise service such as MPLS than they do with the Internet. In the case of MPLS, those concerns are cost, uptime, and the lead time to implement new circuits. In the case of the Internet, those concerns are security, uptime and latency.

While some organizations continue to make use of WAN services such as Frame Relay and ATM, the use of those services is quickly diminishing. The result is that we are rapidly approaching a time when IT organizations will have two WAN services to choose from: MPLS and the Internet. So the question is how to design a WAN using those two services.

A couple of WAN design options

One approach to designing a branch office WAN, which I will refer to as the traditional approach, is to have T1 access to a service provider’s MPLS network at each branch office, and a higher speed link, such as a T3 link, at each data center. In this design, Internet traffic is backhauled to a data center before being handed off to the Internet. One of the limitations of this design is that since the Internet traffic transits the MPLS link this adds cost and delay.

An alternative to the traditional approach described above is to supplement the T1 access link in each branch office with direct Internet access, and to also leverage technology such as Policy Based Routing (PBR). PBR allows network administrators to create routing policies to allow or deny paths based on factors such as the identity of a particular end system, the protocol or the application.

This alternative design does have an advantage, in that it enables network administrators to take Internet traffic off the relatively expensive MPLS link and put it on the relatively inexpensive Internet link. However, one disadvantage of this approach is that configuring PBR is complex, time consuming, and error-prone. Another limitation is that this approach creates a static allocation of traffic to multiple links, which means that it isn’t possible to reallocate the traffic when the quality of one of the links degrades.

The Promise of SD-WAN

The promise of a Software-Defined WAN is that it will leverage the underlying principles of SDN to automate the configuration of WAN edge routers. SD-WAN technology also promises the ability to enable a WAN with multiple links to automatically reallocate traffic based on changing network conditions, overcoming the limitation of static traffic allocation you would see with PBR.