Questioning MPLS

Praised for their QoS-enhancing and traffic-engineering capabilities for IP telephony networks, multiprotocol label switching (MPLS), resource reservation protocol (RSVP) and DiffServ technologies complete only a portion of the traffic engineering and quality of service (QoS) picture for delivering voice over IP (VoIP) that mirrors the incumbent standards of the public network. A larger understanding of the benefits and limitations of MPLS and related technologies for voice delivery is critical to ensure that the proper technology, or combination of technologies, address the required level of QoS.

READ OUR STORY IN THE NOVEMBER 19 ISSUE Packet tagging takes its time by Liane H. LaBarba

To determine whether MPLS and related technologies are suited for VoIP applications and network environments, it is necessary to first consider MPLS’ capabilities. At the most basic level, MPLS provides a traffic engineering capability that enables the creation of fully defined, fixed paths through a network. Of course, this model also means the benefits of MPLS extend only as far its deployment; an end-to-end solution is only possible if an entire network is MPLS-enabled.  In other words, MPLS is domain-specific.

Because of this specificity, MPLS naturally finds its greatest strength in core networks. In addition to its ability to facilitate basic traffic engineering as opposed to uncontrolled routing, it is a scalable way to provide VPN services over the core IP network. A provider can facilitate multiple virtual private networks, with different QoS levels, running over its actual MPLS-enabled network.

While the total amount of traffic carried over MPLS networks is currently limited, many deployments are being announced among the major networks. As of October 2001, AT&T, Bell Canada, British Telecom, Cable & Wireless, Deutsche Telekom, Global Crossing, Level 3, NTT, Telecom Italia, Time Warner Telecom, UUNET/Worldcom, Williams and others had all publicly announced MPLS deployments. For these carriers, deploying MPLS in their network enables them to improve QoS (although guaranteed QoS is still elusive) by segmenting customers and applications by path and empowering them with greater confidence to provide the service level agreements (SLAs) that their customers are demanding. 

MPLS’ glaring weakness resides in its inability to provide application-level routing intelligence, a fundamental component for voice delivery.

However, along with the momentum MPLS has generated through these deployments is a considerable amount of marketing buzz. A closer look at MPLS’ limitations reveals fundamental domain scalability and intelligence issues that will continue to stymie its adoption, at least with respect to voice delivery and the management of voice traffic over the Internet. 

MPLS’ glaring weakness resides in its inability to provide application-level routing intelligence, a fundamental component for voice delivery.  For example, MPLS is not able to provide alternate routing on the call level to prevent latency, delay, packet loss and jitter for VoIP packets. To provide the uncongested (low latency, jitter and packet drop) label switched path (LSP) crucial for VoIP traffic, the MPLS network must be able to recognize the VoIP packets and distinguish them from data packets on the network. 

This level of intelligence is not found in MPLS. Just as important, most VoIP traffic today is long-distance, and much of it is international long-distance, meaning these calls typically traverse multiple networks (domains). As discussed at the beginning of this article, MPLS deployments are domain-specific and are therefore not a feasible solution for voice traffic traversing multiple domains.

The domain specificity and scalability issues present in MPLS deployments are perhaps most evident when we consider MPLS’ viability for the delivery and management of voice traffic over the Internet. Currently, the largest pure-play VoIP carriers, such as ITXC, iBasis, and Net-to-Phone, leverage their business based on use of the Internet. And with Microsoft’s focus on VoIP in Windows XP, which includes an SIP agent, it has never been more evident that the Internet is a significant and rapidly growing carrier of voice traffic.  

Clearly, enabling this network of networks for MPLS would be an immense task. Economic modeling indicates that this is a very distant prospect.  Even if this task is one day accomplished, issues exist around the number of “owners” of the Internet. How do you get one LSP across it? How can such a huge inter-domain problem be solved? Quite simply, MPLS’ inability to scale seamlessly makes it inappropriate for the Internet and especially unsuitable for voice traffic management over the Internet. 

RSVP and DiffServ enhancements

DiffServ and RSVP are sometimes coupled with MPLS to solve some of MPLS’ shortcomings.  DiffServ, which is also sometimes used independently of MPLS, stands for “differentiated services” and refers to the concept of providing a different priority for different classes of traffic.  DiffServ is implemented by using an available IP header field to indicate the priority (or, more generally, the per hop behavior) that a packet should receive. DiffServ, used without MPLS, merely enables prioritization of one packet type over another, with no guarantee that even high-priority packets will not be affected by congestion.

Unless the entire path being traversed is controlled by a single entity, DiffServ will not deliver an end-to-end solution. Most importantly, DiffServ does nothing to solve the static route problem of MPLS.

DiffServ can be used with MPLS, with the DiffServ priority, or type-of-service (TOS) bits being used to prioritize packets on specific LSPs.  However, no standards exist to designate which types of traffic should be marked with which TOS bits.  And just like MPLS by itself, unless the entire path being traversed is controlled by a single entity, DiffServ will not deliver an end-to-end solution. Most importantly, DiffServ does nothing to solve the static route problem of MPLS.  If the QoS on a route degrades, MPLS plus DiffServ will not change the route.     

RSVP was once envisioned as a technology to reserve bandwidth on a path in much the same way that a call is set up on a circuit-switched network. In addition to encountering other problems, this concept received such severe backlash that it had been discarded almost completely.  However, it is currently gaining momentum as a tool to reserve bandwidth for the LSPs of MPLS (and a flavor of it even forms one of the main label distribution protocols, the other being CR-LDP).  

One problem with MPLS is that setting up an LSP through a router won't guarantee that the router will be able to handle its bandwidth requirements, which are increased by other LSPs traversing that same router and competing for the same resources. RSVP, when used with MPLS, enables the reservation of bandwidth on a router for each LSP.  In this way, it is possible to prevent overbooking a router from the start.  RSVP is therefore a useful tool for static reservation of bandwidth but is ineffective and impractical for solving the fluctuating demands of VoIP.

Next-gen traffic engineering

The inadequacy of MPLS for large-scale VoIP, even when deployed in conjunction with DiffServ and RSVP, is evident. The next evolution of VoIP traffic engineering and the next generation of VoIP technologies must account for the inherent differences in voice vs. data applications and the networks across which those applications are deployed.   

Voice-aware traffic engineering that works with the existing routing infrastructure and can scale up to the Internet across multiple domains is the only real solution (see table). Such an approach to traffic engineering, made possible through a new class of VoIP traffic management technologies and solutions, will influence the route that traffic takes over the Internet itself, providing the ability to avoid network congestion and improve end-to-end QoS.

MPLS enables basic static traffic engineering.  The static and non-application-aware nature of MPLS is well suited to the core of major networks.  This is because most major networks are over-provisioned with bandwidth, which covers up problems that would otherwise surface, and the core has fewer network elements to manage than out on the edge. MPLS, in general, is suited to deployment in single-domain environments, where an entity that controls the entire domain can ensure that all the routers are MPLS-enabled, and that there will be no disagreements about the composition and use of particular label-switched paths.        

MPLS VS. VOICE-AWARE TRAFFIC ENGINEERING
	MPLS	Voice-Aware Traffic Engineering
Traffic engineering support	Yes	Yes
Functions  across domains/ISPs	No	Yes
Works over Internet	No	Yes
Requires entire infrastructure be enabled	Yes	No
Efficiency improvement for routers handling high data rates	Yes	No (doesn’t modify underlying routing architecture)
Availability	Mostly in backbones, primarily for VPN’s	Today (over  managed/non-managed networks and Internet)
Guaranteed QoS	Yes, with RSVP	Depending on underlying network
VoIP classification, labeling and admission control	No	Yes
Per call routing decisions	No	Yes
Call level load balancing (vs. packet level)	No	Yes
Dynamic creation and teardown of LSPs based on demand, quality, etc.	No	Yes
Per call traffic policing	No	Yes

Along with MPLS’ advantages come limitations, which are particularly significant to long-distance and Internet voice traffic.  Long-distance voice traffic typically traverses several different network domains.  And because of the scaling issues previously discussed, it is not possible to designate a single end-to-end label-switched path, nor even ensure that all the domains traversed are even MPLS-enabled.  

MPLS traffic engineering is not a viable option today in providing end-to-end QoS for carrying VoIP over the Internet.  However, there is an end-to-end QoS solution for VoIP traffic carried over the Internet, and it is available today through VoIP traffic management. While VoIP traffic management provides a solution without MPLS, it also scales and works with MPLS by using the built-in capabilities of an underlined network in case it is MPLS-enabled. 

The VoIP-aware traffic management solution provides the missing pieces required to make a network, even an MPLS network, more aware of VoIP traffic, which is a mandatory requirement for any successful VoIP deployment.

Shai Mohaban is co-founder and chief technology officer of Kagoor Networks.  He can be reached at shai@kagoor.com.

---

FOR YOUR INFORMATION...

LUCENT LOOKS FOR A WAY OUT WITH NEW PRODUCT PORTFOLIO
Nov 12, 2001, Telephony, by Vincent Ryan
Lucent Technologies hopes to follow a revamped product road map to profitability in 2002, but the inertia...

Lucent’s gameplan
Nov 7, 2001, TelephonyOnline.com, by Liane H. LaBarba
For three and a half hours today, Lucent tried to explain to investors why they should not lose faith in the struggling company. Company executives outlined...

Picking packets
Nov 7, 2001, InFocus
The business drivers for voice over packet are clear—the promise of reduced capital expenses, lower operational costs, optimization of network resources...

Moving to MPLS: Right Strategy Can Minimize Risk
Oct 30, 2001, Online Exclusive, Global Telephony
Internet protocol (IP) and multiprotocol label switching (MPLS) are poised to drive next-generation public networks...

GMPLS: Intelligence for the Optical Network
Oct 3, 2001, InFocus
For long-haul service providers, the network core is that part of the network that interconnects multiple metro networks. For metro service providers,...

Gaining an Edge: Living Up to Service-Level Expectations
Aug 29, 2001, Online Exclusive, Global Telephony
Convergence of voice and data, the need to lower operating costs and the proliferation of emerging Internet protocol (IP)-based business applications...