The Internet Core Problem
The glue binding together this complex mesh of IP networks we call the Internet, are the provider relationships guiding how they pass traffic between one another. BGP is a marvel in being able to translate those relationships into the world of Internet peering. But for all of its genius, BGP can’t overcome provider business interests.
With MPLS, providers had a business interest in minimizing latency, in part by optimizing their routing. Failure to do so would upset customers, increasing customer dissatisfaction. Ultimately, providers would see higher customer churn and lost revenue. But Internet-backbone providers seek to maximize the value of their networks not the performance of any one application. Often it can make more sense to dump traffic off on another provider’s backbone than take it across a faster route along their own network. This is how you end up with “hot potato routing” all too familiar to Internet engineers.
Much of the issues with Internet routing occur in the core of the network. When traffic is kept within region, the impact of the Internet core is often minimized. A 20% difference on a 20ms path is insignificant for most applications. But the same variation on a 200ms path can mean the difference between a clear voice call and an unintelligible one.
Recent testing conducted by SD-WAN Experts highlighted the problems of the Internet core. We measured and compared the end-to-end delay across several last mile services, several Internet backbones, and a private backbone (the AWS network). Our testing showed that while as a percentage, last-mile connections might be the most erratic, the sheer length across the Internet core in a global connection makes the middle mile performance a far greater determiner of overall latency. For example the last mile variation for four paths to Bangalore from San Jose, London, Tokyo and Sydney was 5.88ms (3ms was the median). By contrast, the middle miles varied from 36% to 85% — 92ms to 125ms — a 20x greater impact on the connection.
Addressing middle-mile performance issues of the Internet core are essential if enterprises are to eliminate costly MPLS. SD-WAN appliances alone aren’t the answer. An alternative backbone is needed. One that’s more affordable than MPLS, more consistent than the Internet, and, unlike carrier-managed SD-WAN services, does not lock enterprises into one provider’s access network. Three such approaches to an SD-CORE are now available each leveraging local Internet for access.
Independent MPLS Backbones
With independent MPLS backbones, a service provider builds a global, MPLS core network with a its own SD-WAN edge device at the customer premises Aryaka is the classic example of a global MPLS backbone provider.
The L2 MPLS network provides great performance and the use of Internet access makes this approach more affordable and flexible than a classic MPLS service. However, pricing is still higher than other approaches, a fact that I believe stems in part from the hardware-centric nature of building out an MPLS core network. Customers are also limited to the SD-WAN edge offering of the independent MPLS backbone provider.
By contrast, software-defined backbones build overlays across existing IP backbones, Here, the primary differentiations are the capabilities of the overlay, and the nature of the backbone (e.g. private vs. public).
Mode Core from Mode uses Ericsson’s private global IP network as its underlay backbone. The Mode overlay uses a wholly autonomous routing solution called Mode HALO that globally controls and optimizes routing in the Ericsson underlay, every 150ms. The result is a significant increase in network utilization that translates into SLA-backed MPLS-like performance, but with internet economics and end-to-end visibility and control. Beyond Ericsson, Mode Core can add numerous underlay networks side-by-side (for example through partnerships with service providers), “stitching” them together to produce a single, massive and growing, autonomous SD-CORE.
Cato Networks is another example of a software-defined backbone provider. Cato Cloud uses an underlay consisting of multiple, partially optimized tier-1 carriers’ public IP networks. The Cato overlay then selects among them in real-time to chose the optimum carrier. What makes Cato truly different is their approach to SD-WAN: it is a Cloud-based SD-WANs that is very likely the evolution of CPE-based SD-WAN. They use a cloud-scale software stack running in a provider’s PoP to execute most SD-WAN and security functions. The provider’s edge devices are very “thin” with only enough functionality to securely bring traffic into the cloud-based SD-WAN. A cloud-based SD-WAN approach can address both the security and connectivity issues of networking. Cato Cloud replaces the functionality of SD-WAN and security appliances including next-generation firewalls (NGFW), and Intrusion Prevention Systems (IPS).
White both Mode and Cato support access from IPsec devices, Mode Core does not include an SD-WAN, and is designed to work with any third-party SD-WAN device, even Cato’s. On the other hand, Cato’s cloud-centric approach uses its own SD-WAN by default, although it’s technically possible (but unlikely) to point another vendor’s CPE SD-WAN towards a Cato POP.
By leveraging IP, cost savings for core bandwidth are more significant with a software-defined core than with an MPLS backbone. Software-defined backbones also do not lock enterprises into their edge hardware. In Mode’s case, since their SD-CORE is SD-WAN agnostic, companies are free to use any SD-WAN device (or any other device) that can build the necessary IPsec tunnels to the backbone POP, which is within 20ms of most commercial centers.
Global WANs Beyond Managed MPLS Services
The days where global WANs depended on carriers and their managed MPLS services have long past. SD-CORE solutions provide enterprises with a range of alternative approaches that allow organizations to reduce their bandwidth spend without compromising network performance.