Imagine a time before GPS-enabled smartphones. You get a postcard in the mail from a friend asking you to visit. All you have is the destination address, and you figure, “Sure, why not?” because there’s no social media filling your days. You pack a bag, hit the road, and, because you love adventure, you resolve to complete this thousand-mile odyssey with no maps. Instead, you stop every so often to ask for directions.
Anyone who has lived through this process sees the problem: Directions from strangers can vary from ideal to delusional, and you’re as likely to be on-course as lost on a dirt road with deep ruts and curious cows. Incredibly, this is also how traditional internet packet routing operates.
Internet protocol (IP) packets carry no routing information. Instead, they rely on the routers they meet to make forwarding choices and essentially offer directions to a next stop on the way to the packet’s final destination. Routers accomplish this with a process called IP forwarding. This approach is functional, but far from efficient.
The good news was that one of the internet’s key standards bodies, the Internet Engineering Task Force, devised a technology in 1997 called multi-protocol label switching (MPLS) to improve packet routing. In its first decade of use, MPLS excelled at improving communication speeds and traffic shaping. However, times change, and technologies evolve. MPLS still finds use in a range of applications, but there are now better options. Read on, and we’ll explain what they are and why you should use them.
What is MPLS?
Continuing our analogy, imagine our traveling packet reaches its first stranger/router (named Bob) and presents said router with its destination-bearing postcard. The router looks at that destination IP address and pulls a “routing table” from its pocket. The routing table is a list of possible next hops for the packet. Router Bob considers the problem, points down the street, and says, “I think you should go to router so-and-so, just down that road a mile or two.” The packet runs along, never knowing if its route is “right” or not, asking each new router for instructions from its own routing table. Usually, the packet reaches its destination, but it may have been delayed by construction, storms, or Router Bob’s migraine making him give bad directions. No wonder packets in real-time applications face performance issues.
MLPS adds several enhancements to the conventional IP forwarding model. Most notably, MLPS uses label switching. Imagine our roving packet’s postcard having a color-coded sticky note on its front. The color conveys a specific type of service (called a forwarding class of service, or FCS) that the packet should receive. For example, some traffic can be tagged to follow the lowest-latency path, while others might emphasize bandwidth capacity. In effect, these labels denote customizable quality-of-service levels that help balance traffic and optimize network resources.
Additionally, imagine that each sticky note has a barcode on it that denotes exactly what route the packet should take to reach its destination. Instead of having to haul out that routing table and think through the packet’s next hop, Router Bob simply scans the barcode with his phone and sees exactly (and much more quickly) where to send the packet. This eliminates the need for the router to examine any IP forwarding data. However, for the label to be recognized and have any utility, the packet must encounter an MPLS-compliant label switch router.
IP forwarding functions within layer 3, the network layer, of the Open Systems Interconnect (OSI) model. Layer 3 maintains those routing tables and knows how to convey packets between nodes. MPLS works below this, though, sandwiched between layers 3 and 2 (the data link layer, which handles physical data movement). As a result, you’ll often hear experienced network administrators say that MPLS operates on “layer 2.5.”
MPLS networks generally exist within a larger network, such as the public internet. When a packet enters an MPLS network, it encounters an ingress router that assesses the packet’s destination and picks one of many predetermined, optimal paths through the MPLS network, called a label switch path (LSP). The ingress router tags the packet with a label — the coded sticky note and barcode described above — which denotes the selected LSP. Every subsequent router checks the label against the known LSP table and immediately knows where to send the packet next. If the packet needs to exit the MPLS network, the final stop before exiting will be an egress router.
MPLS improves network performance, bandwidth utilization, and scalability. These factors lead to lower network congestion and an improved user experience.
Common MPLS Issues
MPLS is not built into the global public network. Rather, it exists in islands of various sizes, typically deployed by companies for their own wide-area networks (WANs) or, in the case of smaller organizations, rented from larger network providers. Years ago, MPLS was an excellent method for accelerating WAN traffic, especially when an organization had broadly dispersed branch offices, and the performance was sufficient to compensate for most downsides. With time, though, that balance has changed.
Arguably, first and foremost, recent years have seen the growing prominence of large cloud-based entities, ranging from resource providers such as AWS and Azure to more targeted offerings such as Salesforce and the range of unified communications as a service (UCaaS) providers. These already optimized options deliver a way around (or above) traditional branch-to-data center architectures. Most MPLS solutions are built around hub-and-spoke topology, not point-to-cloud, and are thus unable to directly connect with all cloud options.
Additionally, organizations that rented MPLS network access from providers might find themselves growing beyond the bounds of that provider’s service area. Some locations would be accelerated, and some not. Depending on the economics and local factors, those providers might be painfully slow to roll out MPLS support to requested areas.
Because MPLS requires compliant hardware, it can be difficult and costly for businesses to scale. MPLS also incurs more management overhead, since IT tends to map LSPs for each application. Similarly, MPLS demands more top-level network management, as routers, firewalls, VPN tools, and WAN optimization tools all may require their own management interfaces.
These factors and others add up to MPLS failing to compete on cost against more modern alternatives, such as software-defined WAN (SD-WAN) solutions. MPLS incurs more expenses through required WAN optimization, and because there are relatively few MPLS providers, there’s little competition to drive down costs. Users may be a captive audience to a virtual monopoly.
MPLS Challenges in Real-Time Applications
Within a confined set of circumstances and proper configuration, MPLS can still provide the highest possible packet transmission performance. The trouble is that MPLS quickly fails in total comparative value with many modern circumstances and application types. For instance, software-defined networks have more granular control over quality-of-service (QoS) factors than MPLS tagging, which translates into lower latency, jitter, and packet loss.
Also consider that hub-and-spoke MPLS architecture often requires branch offices to perform U-turn traffic “hairpinning” at the router for application calls, a process that can noticeably impair packet performance. Cloud-based applications alleviate the need for hairpinning in WANs, thus providing superior results for those applications.
SD-WANs excel in self-analysis and self-healing; MPLS lacks those capabilities. Instead, users must submit queries or trouble tickets to their own IT, which may find it needs to pass the issue on to the MPLS provider. What would take an SD-WAN seconds to remedy could take MPLS support hours or days. This echoes how MPLS networks can, like other managed services, be something of a black box to users. In contrast, software-defined solutions provide greater transparency and give users far greater control over integrated QoS features, alarm triggers and thresholds, and reporting. In short, relative to MPLS, SD-WANs put users back in control of their network operations. This can be critical for real-time applications, which demand a higher caliber of precision and near-instant issue remediation.
Not least of all, software-defined solutions frequently integrate a range of security features not packaged with many MPLS offerings. An SD-WAN might include VPN, intrusion protection, unified threat management, and next-generation firewall capabilities, either natively or as part of an easily added options package, and likely all manageable through a single management interface. With MPLS, these functions would likely require separate IP security devices, multiple management consoles, far more complex policy implementation and enforcement, and a markedly higher total cost of operation.
Subspace: Your Path Beyond MPLS and Software-Defined Solutions
The hub-and-spoke architecture in which MPLS thrived was an outstanding fit for how businesses ran in the early 2000s. But corporate network infrastructures changed. Routers are now smarter, faster, and more flexible. According to Flexera, 92% of enterprises not only rely on the cloud, but also now have a multi-cloud strategy. In a direct correlation, Cybersecurity Ventures estimates that by 2025, 100 zettabytes will be stored in the cloud — fully half of the world’s data. The cloud is also instrumental in making the current transition to work-from-home and hybrid office/home labor forces seamless, properly enabled, and successful. A January 2021 report from PwC revealed that “83% of employers now say the shift to remote work has been successful for their company.” This satisfaction will only fuel the move from costly branch offices to distributed workers, and a redefinition of the network “edge.”
No matter how large or small the office or how dispersed an organization may be, companies need the sort of performance leap that MPLS delivered 20 years ago brought to their changing infrastructures. Subspace provides that performance leap today via a parallel network that runs alongside and interoperates with the public internet. It takes Subspace-class speed and utilities to best support today’s real-time applications. With a service that’s 80% software and 20% hardware, Subspace has cutting-edge deployments across hundreds of cities around the world, all coordinating to create a constantly updating, split-second accurate internet traffic weather map. Subspace uses this precision and awareness to instantly route and update packets along their optimal paths, both in-network and across the internet. The resulting boost in end-to-end throughput provides up to 80% lower latencies and less jitter, potentially transforming user experiences in services like video and voice.
Some of the utilities Subspace offers include:
- SIPTeleport – A drop-in SIP proxy solution that provides low latency voice and video calls, while eliminating packet loss - eliminating the need for MPLS.
- WebRTC-CDN – A single-server solution, Subspace’s GlobalTURN eliminates the need to deploy multiple TURN servers.
- RTPSpeed – Provides the highest quality voice and video streaming and includes in-line zero-latency DDoS protection. RTPSpeed also gives global access with a single API call.
- PacketAccelerator – A global IP proxy that provides access to the Subspace network, along with its security and performance enhancements.
From gaming to call centers to metaverse enablement, Subspace optimizations can improve existing real-time applications and open the door to entirely new opportunities, all while adding latency-free DDoS protection. To learn more about tomorrow’s internet and what Subspace can offer, sign up for free here.
