MPLS group should unite on routing approach

By Mary Petrosky
Network World, 04/05/99

When Cisco brought its Tag Switching proposal to the Internet Engineering Task Force (IETF) in late 1996, it set in motion the standardization of what has come to be called Multi-protocol Label Switching (MPLS). Now, after a number of key specifications have been finalized and implementations are ready to roll out in earnest, a split in the MPLS working group over a key standard could slow customer adoption of the technology.

MPLS is geared primarily toward service providers and carriers. However, it also has a number of features that will benefit enterprise customers, regardless of whether they're using public or private WAN services. For example, MPLS allows for traffic engineering, which should translate into improved throughput and fewer outages for customers.

As currently defined, MPLS is a shorthand method for IP routing based on labels. The labels can be used to represent hop-by-hop or explicit routes and to indicate quality-of-service (QoS), virtual private network and other types of information that affect how a given type of traffic (or a particular customer's traffic) is carried across a network.

MPLS can operate across various media, and the MPLS working group to date has standardized the labels to be used on frame relay, ATM and PPP links, as well as on IEEE 802.3 LANs. One of the benefits of MPLS operating over frame relay and ATM is that it brings the any-to-any connectivity of IP to these connection-oriented technologies. This capability is key to AT&T's recently announced IP-enabled frame relay. By adding MPLS software to its core ATM switches, AT&T will allow its frame-relay customers to interconnect multiple sites using a single circuit, rather than having to provision circuits on a one-for-one basis to each connected site.

A number of MPLS' most significant benefits, including traffic engineering and QoS support, hinge on its ability to support explicit routing. Today, routing protocols pick the shortest path between a given source and destination, regardless of whether that path is overloaded. With explicit routing, service providers can pick the path that specific traffic traverses, enabling video traffic to take a low-latency path.

Unfortunately, there are two explicit routing camps within the MPLS working group. One, led by Cisco, is promoting the use of a reworked version of the Resource Reservation Protocol (RSVP) to support explicit routing. The other, led by Nortel Networks, is backing the use of extensions to the Label Distribu-tion Protocol (LDP), which the MPLS working group has already approved for hop-by-hop routing.

Cisco already sells an implementation of explicit routing based on RSVP as part of its prestandard MPLS offering, which began shipping about a year ago under the Tag Switching banner. Likewise, Juniper Networks, another supporter of the RSVP approach, has been shipping a prestandard implementation of MPLS with RSVP support for some months. Cisco anticipates that vendors will begin interoperability testing of the RSVP approach in the coming months.

For its part, Nortel, with Ericsson and General DataComm, late last year completed interoperability testing of its approach, known as Constraint-Based Routing using LDP (CR-LDP). Nortel also recently announced it will provide other vendors with source code to a key part of its CR-LDP implementation for free. Nortel's move should speed vendor deployments of CR-LDP.

At this time, the MPLS working group is proceeding with both approaches. While choice is often a positive thing, there's questionable value in having two standards that address the same problem. Clearly there will be serious interoperability issues. Likewise, many vendors will find themselves burdened with implementing both sets of protocols.

Vendors expect the market to decide which approach will succeed. While that's a democratic attitude, past experience has shown that customers often postpone adopting new technologies in the face of uncertainty. Given MPLS' potential benefits, it would be a shame if its deployment were slowed for lack of agreement on a single explicit routing approach.