Although multipath label switching (MPLS) has served the enterprise well for years, it can no longer adequately meet the demands of global enterprises. Now, over 50 percent of global WAN traffic now reaches the cloud, but MPLS was designed for point-to-point connections not point-to-cloud and Software-As-A-Service (SAAS). And, there are number of other limitations to MPLS.

No. 1 — No single provider can deliver MPLS end-to-end around the world. Global MPLS networks are cobbled together using a range of service providers. This can lead to serviceability problems when it comes to issue resolution, and it complicates the job of providing adequate network redundancy.

No. 2 — MPLS is a dynamic, shared medium. While MPLS is traditionally viewed as a private network service, it is actually a shared medium that does carry some risk. Security conscious buyers will, instead, gravitate toward dedicated bandwidth to close that loophole.

No. 3 — Not all “private networks” are secure. If no single provider owns the MPLS network around the world, and the traffic is simply differentiated with an MPLS label, how hard is it to SPAN a port and sniff the traffic? Also, if you have to break out cloud/SaaS traffic over the internet, you open up new attack vectors.

No. 4 — MPLS wasn’t designed for the speed of business today. Change orders can take weeks and new installs can take months, while companies today need to be able to add locations in days and make service changes on the fly.

No. 5 — Costs are lopsided. MPLS pricing is from a bygone era when bandwidth needs were a fraction of what they are today, so the premium pricing was tolerated. Bandwidth requirements are growing at a 26 percent compound annual growth rate (CAGR), by some accounts, and MPLS is simply too expensive to use for everything.

The shortcomings of MPLS have forced enterprise shops to consider other options, all of which address pieces of the problem, but leave the planning, procurement, and management of the parts in the hands of the enterprise, which complicates problem resolution efforts.

Let’s examine some of the standard point solutions that customers naturally gravitate to when they find MPLS can no longer meet their needs. Each of the point solutions below  — internet, WAN optimization, redundancy, security, and SD-WAN — provides a fix to a set of problems versus the greater problem as a whole.

Internet. The first option most organizations consider when their bandwidth needs change or when a requirement to deploy fast dictates finding a way to supplement MPLS, is use of the internet. With the internet, you gain what you can’t achieve with MPLS, but lose out on MPLS’ latency and bandwidth guarantees.

While inexpensive and fast to deploy, WAN internet links are susceptible to latency and packet loss. The problem of stable latency has always plagued things like Voice-over-IP (Voice Over Internet Protocol (VOIP)) — and has given rise to latency optimization options at the network and protocol levels — but is even more of a concern given companies are now trying to use these links to access mission critical cloud and SAAS services. The internet lacks stability and doesn’t offer service level agreements (SLAs) across the middle mile and long distances.

And the same goes for packet loss. Although packet loss has been a problem even when apps and services resided on premises or in a couple of physical locations, with cloud/SaaS/UCaaS you can have services homed practically anywhere in the world. If one of the layers supporting these services is the internet, end-to-end stability, packet loss recovery algorithms and protocol enhancements are a necessity, not a nice to have.

WAN Optimization. Whether you are trying to dress up MPLS to meet new requirements or using the public internet to supplement MPLS, you’ll need to add additional optimization tools along the WAN routes if you want to try to deliver consistent user experiences regardless of where users are located. That will involve significant capex investment and leave you with still more network resources to manage. Even then it might not adequately address the performance issue, especially for international scenarios.

Redundancy. Given the fact you are looking to use the internet to support links to mission-critical applications, you have to build in some redundancy. We are not just talking here of multiple devices, but the ability to use dual links at the edge and in the network core. The redundancy should also include service provider diversity, being able to route on both sides of the Earth – in other words, the best possible undersea and terrestrial cable redundancy. There should also be software-defined features that enable further redundancy such as point-of-presence redundancy and data center redundancy.

Security. Internet Protocol Security (IPSEC) is a must, not just at the edge but also in the core or in the middle mile. You’ll also have to compliment that by deploying and managing a host of the usual network security tools to ensure no one can find a way into your network through the many tendrils of your WAN.

SD-WAN. Software-defined WAN is a requirement today, but most SD-WAN tools just provide a software overlay and use the internet for long-haul transport. So, while SD-WAN makes it possible to use the internet to supplement MPLS and set policies that spell out how traffic is to be handled, all the concerns outlined above apply.

If you only have a few locations and they are in the same region and you don’t use a lot of cloud and SAAS services, this type of SD-WAN might be the answer you’re looking for. But if you are a larger shop with many geographically distributed locations and using (or considering migrating to) many cloud services, the do-it-yourself SD-WAN kits will leaving you wanting more, not to mention the integration headaches. But you do have a choice: you could construct and get stuck, or consume and scale rapidly.

There needs to be a better way to address all of these issues. The ideal WAN should:

• Optimize transmission control protocol (TCP) – this has a triple effect on your flows. Packet payload sizes are bigger, packets are closer together, throughput ramps up much faster, and your first byte transfers faster. For any data application, TCP optimization is a must.
• Address packet loss recovery using a full set of SD-WAN algorithms, not just one or two.
• Provide optimal agility to facilitate moves, add or change sites, and disconnect quickly.
• Deliver built-in redundancy at all levels in the infrastructure.
  Optimize bandwidth and thereby optimize the dollars spent on the network.
• Provide 24/7 support.
• Deliver detailed visibility through a portal, not just in/out bandwidth, but application level usage and performance metrics and statistics.
• Provide one throat to choke for all of these services to avoid finger pointing.

All of which points you toward SD-WAN delivered as-a-service, which you consume instead of building yourself. Instead of point solutions that address different pieces of the problem, SD-WAN as-a-service relieves you from figuring out how to: accommodate rampant bandwidth growth; support corporate digital transformation initiatives; and migrate your services to the cloud. And it does all of that while simplifying the network and freeing up IT resources to focus on opportunities that grow the business.

The time for SD-WAN is now, and the only SD-WAN to address your evolving needs is one that is delivered as-a-service.