ARCHIVE | ID Number: EFRA-NA-DP-9904
| This research is provided for historical perspective; portions of this document may not reflect current conditions. |
MPLS: The Promise and the Problems
3 May 1999 John Coons Multi-Protocol Label Switching (MPLS) has emerged as a way for Internet service providers (ISPs) to improve network performance, reduce operating costs, integrate Layer 2 and Layer 3 infrastructures, and provide Internet Protocol (IP) quality of service (QoS). With the first MPLS specifications to be approved this month by the IETF, MPLS shows long-term promise as a way for ISPs to build more scalable, cost-effective networks. It also promises to provide the basis for a new class of VPN and other value-added services. However, in the short term, vendors' disagreements over signaling protocols will slow product development, interoperability testing, and actual implementation in ISPs' networks.
* | Recipients who do not own this document will receive a summary only.
| Browse Topics
| Advanced Search
| Ask an Analyst
| Rate This Document
| Downloads:
|  | 78139.pdf (32.7KB) |

# MPLS: The Promise and the Problems Multi-Protocol Label Switching (MPLS) has emerged as a way for Internet service providers (ISPs) to improve network performance, reduce operating costs, integrate Layer 2 and Layer 3 infrastructures, and provide Internet Protocol (IP) quality of service (QoS). With the first MPLS specifications to be approved this month by the IETF, MPLS shows long-term promise as a way for ISPs to build more scalable, cost-effective networks. It also promises to provide the basis for a new class of VPN and other value-added services. However, in the short term, vendors' disagreements over signaling protocols will slow product development, interoperability testing, and actual implementation in ISPs' networks.

Table of Contents
Technology Overview: Making Connections Technology Evolution: The Protocol Formerly Known as Tag Technology Comparison: Crossed Signals Dataquest Perspective

List of Figures
Figure 1: | Traffic Engineering Path versus IGP Shortest Path across a Service Provider's Network

Key Business Issue How will ATM, frame relay, and TCP/IP technologies be used to build multiservice networks? Strategic Business Assumption Production environments built from fully functional, interoperable MPLS devices remain at least two years away (0.8 probability). Technology Overview: Making Connections [return to Table of Contents] Ever-increasing traffic loads coupled with the need to improve the cost and performance of their backbone infrastructures have doubly challenged Internet service providers (ISPs). To optimize the performance of their Internet Protocol (IP) networks and lay the groundwork for new classes of service (CoSs) based on predictable network performance, ISPs are turning to Multi-Protocol Label Switching (MPLS), an emerging Internet Engineering Task Force (IETF) standard for building highly scalable, high-performance networks that cost-effectively carry packets across predetermined routes. In May, the IETF will likely approve the first wave of MPLS specifications that will allow vendors to build standards-based, interoperable MPLS equipment. The benefits of MPLS to ISPs include the following: Improved network performance and load balancing through traffic engineering that dynamically routes around network failures and congestion Reduced equipment and support costs by simplifying packet forwarding methods Better integration of Layer 2 and Layer 3 equipment, optimizing ISPs' investments in asynchronous transfer mode (ATM) switches, IP routers, and other internetworking equipment The ability to set up different classes of traffic that can serve as the basis for a variety of value-added services such as virtual private networks (VPNs) Interoperable, standards-based equipment that lets ISPs carry labeled packets across multivendor infrastructures Today, an IP packet's route across the Internet is determined dynamically by the ISP's Interior Gateway Protocol (IGP). This routing protocol, operating in every router, calculates the shortest route across the network based on lowest hop count. Each router along this route must examine every packet header and look up the full 32-bit IP address to determine where to send the packet next until it arrives at its ultimate destination. This process is expensive (because each router must maintain forwarding tables and process each packet that comes its way), unpredictable (because each router only chooses the shortest, not necessarily the fastest, route), and inflexible (because ISPs have no control over how packets traverse their networks). MPLS promises to change all of this by forwarding packets along explicitly mapped label switch paths (LSPs) in an ISP's network. When an IP packet hits a label switch router (LSR) on the edge of an MPLS domain, the packet is given a 32-bit header that includes a 20-bit label. (LSRs can be any Layer 2 or Layer 3 device—such as an ATM switch, an IP router, or a terabit core switch/router—that supports the MPLS label forwarding specification.) This label corresponds to an explicit LSP across the network. Every possible label can be stored in a simple table of a million entries, allowing fast direct lookups. Without labels, slower-hashing algorithms must be used to reduce address table size because there are more than 4 billion possible addresses for IP. Once the label has been attached, LSRs in the network core disregard the packet's network-layer header, simply using a "label swapping algorithm" to forward it along its LSP. Labels are assigned at Layer 3, and the traffic flow can be mapped to any Layer 2 connection, such as an ATM or frame relay virtual circuit, a SONET channel, or an optical wavelength. In this way, labels simplify the integration of cell switches and routers by providing a set of addressing, routing, and management procedures common to both Layer 2 and Layer 3 equipment. With a common routing system, Layer 2 switches can for the first time participate in hierarchical Layer 3 network architectures. Without a common routing domain, Layer 2 switches are seen only as simple point-to-point connections by the Layer 3 routers. This logically flattens the network topology and exacerbates a class of performance, leading to reliability problems caused by too many routers being logical peers to each other. Layer 3 LSPs can correspond to the shortest route across the network, but they can also correspond to a path that avoids a particularly congested segment or a set of switches that are down for maintenance, as shown in Figure 1. The LSP could also be mapped to a virtual circuit (VC) with particularly low latency, providing multiple classes of IP traffic across public network infrastructures. In short, LSPs introduce connectionlike behavior on connectionless IP networks, greatly reducing operating costs, automating traffic engineering, and providing IP networks quality of service (QoS) capabilities that have long eluded them.

Figure 1
Traffic Engineering Path versus IGP Shortest Path across a Service Provider's Network
[return to List of Figures]
Source: Juniper Networks

Technology Evolution: The Protocol Formerly Known as Tag [return to Table of Contents] MPLS was introduced to the IETF by Cisco in 1997. Originally based on Cisco's proprietary Tag Switching technology, MPLS has evolved into more than a dozen draft specifications being hashed out by more than a dozen vendors and ISPs. Vendors supporting MPLS standardization include Alcatel, Argon Networks, Avici Systems, Cisco, Ericsson, General DataComm (GDC), IBM, Juniper Networks, Lucent, Nexabit Networks, Nortel, and Pluris, among others. MPLS specifications that are expected to become proposed standards this month include the following: An architecture draft that provides the semantics for packet-forwarding equivalents Encapsulation drafts that specify how labels are carried via packet over SONET (PoS) channels, ATM VCs, and frame relay networks. These drafts specify how many bits identify the label, how many bits are used for CoS, and so forth. The Label Distribution Protocol (LDP), the packet-forwarding mechanism that grew from Cisco's proprietary Tag Distribution Protocol (TDP). LDP ties Layer 2 networks such as ATM with Layer 3 networks such as IP, letting them operate in the same routing domain. It provides the procedures and messages by which MPLS equipment exchange label/stream mapping information and set up paths through a network. This is done by mapping network-layer routing information to data-link-layer switched paths. Although the encapsulation specifications are expected to be approved as IETF draft standards this month, they have not changed significantly for more than a year, and vendors have already begun implementing MPLS encapsulation into their equipment. Similarly, LDP has been widely adopted in prestandard form, and vendors expect to begin testing standards-based interoperability this summer. Interestingly, Cisco has not yet adopted LDP, leaving its MPLS equipment based on proprietary TDP and potentially noninteroperable with standards-based LSRs. Equipment that already supports MPLS includes Juniper Networks' M40 core router, Nexabit Networks' NX64000 terabit router/frame relay switch, and Nortel's Passport, Versalar, and Backbone Node platforms. Cisco products that now support TDP and may support LDP later this year include the 7500-, 4700-, 4500-, 4200-, and 3600-series routers as well as the LightStream 1010, BPX 8650, and GSR 12000 switches. Cisco is also considering implementing MPLS in its digital subscriber line (xDSL) and cable modem platforms. Lucent plans to implement MPLS in the PacketStar IP switch later this year. Technology Comparison: Crossed Signals [return to Table of Contents] A major point of contention among vendors standardizing MPLS is how traffic engineering will be accomplished. Originally, the IETF intended LDP to include signaling capabilities for traffic engineering. But to put LDP on the fast track toward standardization, signaling was removed from the specification. Extensions to LDP were then proposed, leading to constraint-based routing LDP (CR-LDP). At about the same time, Cisco dusted off the nearly dormant Resource Reservation Protocol (RSVP), souped it up with a number of extensions, and proposed it as a signaling protocol by which traffic engineering could be accomplished. Both CR-LDP and RSVP have been submitted to the Internet Engineering Steering Group (IESG), and both are expected to become proposed IETF standards later this year. This has left vendors with two standards-based, although completely noninteroperable, methods of providing traffic engineering on MPLS networks. The difference between CR-LDP and RSVP is more of style than substance. Vendors that have invested resources in CR-LDP—namely Nortel, which edited the specification draft—note that CR-LDP was designed with traffic engineering specifically in mind. It is based on Transmission Control Protocol (TCP), a signaling protocol that, unlike RSVP, has proven its ability to scale. Moreover, using CR-LDP for traffic engineering and LDP for label assignment elegantly provides a single protocol for both functions. Advocates of RSVP-based signaling—namely Cisco, which edited the specification draft—contend that RSVP is no longer your father's Oldsmobile. The protocol, originally designed to request network bandwidth, has been significantly modified to establish explicitly routed LSPs across large MPLS networks. Using its control component, RSVP can trace a path across a network and send labeled packets down that path. Extensions to RSVP also allow it to dynamically resize LSPs as applications and traffic patterns require more or less bandwidth. In this role, RSVP should not have the scalability issues that previously plagued its acceptance when it was envisioned as the sole mechanism for both signaling and bandwidth allocation. By the end of the day, the two signaling protocols are functionally about equivalent and equally mature. Both allow MPLS equipment to perform traffic engineering and carry QoS across IP networks. Both map IP traffic to a physical infrastructure. Both are slated to become IETF specifications. Both are being integrated into equipment and have garnered interest from ISPs. Nortel, GDC, and Ericsson have already demonstrated interoperability among their respective prestandard CR-LDP implementations, and RSVP interoperability tests may take place as early as this summer. The existence of two signaling specifications promises to significantly complicate the implementation of MPLS. The problem is that the two signaling protocols do not interoperate: RSVP-based equipment will only interoperate with other RSVP-based equipment, and CR-LDP-based equipment will only interoperate with other CR-LDP-based equipment. Vendors have to choose to implement one, the other, or both in their equipment. Judging from the early implementation plans, ISPs will be challenged to keep track of which vendors support which protocol or protocols. For example, Nortel's Versalar routers will support both CR-LDP and RSVP, but Passport switches will only support CR-LDP initially. Pluris will initially implement CR-LDP, but by the time the company starts shipping products late this year, both signaling protocols are expected to be supported. Cisco plans to support only RSVP, while Torrent, Nexabit Networks, and Juniper Networks also plan to implement RSVP and will only implement CR-LDP if ISPs request them to do so. Later this year, Lucent plans to add support for both RSVP and CR-LDP in its PacketStar IP switch. To complicate things further, vendors have turned on their marketing machines to promote their preferred signaling protocol. In March, for example, Nortel opened its CR-LDP source code, making it available at no charge to other vendors interested in implementing it and furthering the CR-LDP cause. ISPs will be required to break the tie. If ISPs start supporting one standard over the other, vendors will quickly follow suit. However, it is too early for ISPs to cast their lots. Interoperable equipment is not yet ready to be tested, and it is as yet unclear if there are technical advantages of one protocol over the other. Meanwhile, AGIS, a longtime Nortel customer, is backing CR-LDP, while ISPs that have expressed interest in RSVP-based signaling include Verio and UUNET, the latter of which coedited the RSVP-based signaling specification. Signaling is not the only potential area of disconnect among vendors developing and implementing MPLS. Other potential glitches include the following: Proprietary equipment—Cisco, for all its work to standardize MPLS, has not yet implemented LDP in its products. Cisco still forwards packets based on TDP, which is not interoperable with the LDP specification. It is unclear whether Cisco plans to add LDP into its equipment or will test TDP-to-LDP mapping on a vendor-by-vendor basis as it has in the past. Number of service classes—It remains unclear how many service classes MPLS labels will map packets to. Some vendors (primarily Lucent and Argon) expect labels to correspond to thousands of different classes, while other vendors (primarily Cisco) may support less than five. How a switch supporting, for example, 64,000 classes will map packets to a switch only supporting three remains unclear. CoS precedence bits—The IETF's Differentiated Services (DiffServ) working group originally specified CoS as using three "precedence bits" in the IP header. The MPLS working group subsequently agreed to put three corresponding CoS bits in the MPLS header so that service class could easily be mapped from devices that support DiffServ to equipment based on MPLS. The DiffServ working group has since increased the number of precedence bits to six, leaving it unclear how IP CoS will be mapped across a network with six CoS DiffServ classes and three CoS MPLS classes. The current round of MPLS specifications defines architecture, encapsulation, and signaling, allowing vendors to build interoperable equipment that forwards labels and sets up LSPs from point to point across a network. A new round of specifications, expected to be approved late this year or in early 2000, define point-to-multipoint and multipoint-to-point capabilities as well. Several vendors have also submitted drafts intended to define VPN tunnels across MPLS-enabled networks, as labels provide a particularly elegant solution for isolating VPNs. However, it is not yet clear whether VPN capabilities have to be inherently defined in the MPLS protocol. Other MPLS specifications that are expected to be completed by the end of the year define how ATM virtual paths (VPs) can be set up and used for traffic management over MPLS-enabled networks. And in March, AT&T and Nortel presented a draft for enhancing CR-LDP with support for voice over IP (VoIP). The IETF is also considering starting a traffic engineering working group that will look at defining hierarchies in traffic-engineered networks. Dataquest Perspective [return to Table of Contents] The current round of MPLS specifications, likely to be approved by the IETF in May, goes a long way toward establishing standards-based, interoperable multilayer label switching equipment. The completion of these specifications promises to move the industry beyond the vendor-by-vendor MPLS interoperability tests that have taken place over the past 18 months. Dataquest expects standards-based MPLS equipment to be available for vendors to test by this summer. However, dual signaling protocols—CR-LDP and RSVP—promise to significantly complicate the development and deployment of interoperable MPLS equipment. Signaling is necessary to automate traffic engineering. Without it, carriers will be unable to derive the cost-reduction benefits promised by MPLS. But the approval of two competing signaling documents undermines the advantages of standardizing MPLS. Although some vendors will implement both signaling protocols in their equipment, others will not, leading to noninteroperable equipment despite its being based on MPLS specifications. The implementation of two signaling protocols also takes MPLS off the fast track. Developing, testing, and implementing software to support two protocols will take vendors more time and resources. And vendors adopting a wait-and-see attitude—not implementing one protocol or the other until ISPs have expressed interest in it—may further delay the development of standards-based, interoperable MPLS equipment. Dataquest believes the MPLS signaling wars will run their course by the end of the year, at which time ISPs will either remain split over signaling protocols, with different ISPs implementing different protocols, or the industry settling on one. Meanwhile, ISPs should remain apprised of their vendors' signaling plans and expect to test two separate rounds of MPLS equipment. Vendors, for their part, should either expect to support both protocols or anticipate giving their engineering staff bonuses after they have scrambled to implement the protocol that they previously thought would never get off the ground. Overall, MPLS still has a long road to walk. LDP interoperability tests may begin as soon as this summer, to be followed by signaling protocol interoperability tests. However, more advanced features, such as VPN tunnels across MPLS domains and mapping MPLS to DiffServ CoS, are at least a year away. Dataquest predicts that fully functional, interoperable MPLS devices deployed in production environments remain at least two years away.

| Browse Topics: Multiprotocol Label Switching Internet Service Providers IP Backbone Services Value Added IP Services Web Hosting and Co-Location Switching Signaling |
| This document is published in the following Dataquest Clusters: Public Network Infrastructure Worldwide Telecom Equipment Europe Telecom and Internet Markets Asia/Pacific Telecom Strategies and Directions Worldwide |
| © 2004 Gartner, Inc. and/or its Affiliates. All Rights Reserved. Reproduction of this publication in any form without prior written permission is forbidden. The information contained herein has been obtained from sources believed to be reliable. Gartner disclaims all warranties as to the accuracy, completeness or adequacy of such information. Gartner shall have no liability for errors, omissions or inadequacies in the information contained herein or for interpretations thereof. The opinions expressed herein are subject to change without notice. |

Resource Id: 304629