2.5.8 Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of the 39th IETF Meeting in Munich, Bavaria, Germany. It may now be out-of-date.

Chair(s):

George Swallow <swallow@cisco.com>
Vijay Srinivasan <vijay_srinivasan@vnet.ibm.com>

Routing Area Director(s):

Joel Halpern <jhalpern@newbridge.com>

Routing Area Advisor:

Joel Halpern <jhalpern@newbridge.com>

Mailing Lists:

General Discussion: mpls@external.cisco.com
To Subscribe: mpls-request@cisco.com
In Body: in body: subscribe (unsubscribe)
Archive: ftp://ftpeng.cisco.com/mpls/mpls

Description of Working Group:

Problem Statement:

Recently the use of label-swapping based forwarding ("label switching") in conjunction with network layer routing has attracted much attention. Several vendors have proposed techniques based on this paradigm. Among the problems this paradigm is expected to address are the following:

1. Scalability of network layer routing

Using labels as a means to aggregate forwarding information, while working in the presence of routing hierarchies.

2. Greater flexibility in delivering routing services

Using labels to identify particular traffic which are to receive special services, e.g. QoS.

Using labels to provide forwarding along an explicit path different from the one constructed by destination-based forwarding.

3. Increased performance

Using the label-swapping paradigm to optimize network performance.

4. Simplify integration of routers with cell switching based technologies

a) making cell switches behave as peers to routers (thus reducing the number of routing peers that a router has to maintain),

b) by making information about physical topology available to Network Layer routing procedures, and

c) by employing common addressing, routing, and management procedures.

High Level Requirements

1. The solution should be general with respect to data link technologies. Specific optimizations for particular media will be considered.

2. The solution must be compatible with existing internetwork technologies and routing protocols.

3. The solution should be capable of operating independently of the underlying routing protocol. It has been observed that considerable optimizations can be achieved in some cases by small enhancements of existing protocols. Such enhancements will be considered in the case of IETF standard routing protocols, and if appropriate, coordinated with the relevant working group.

4. The solution should support a wide range of forwarding granularities associated with a given label, from a single application flow to a group of topologically related destinations.

5. The solution should support operations, administration, and maintenance facilities at least as extensive as those supported in IP networks.

6. Routing protocols that could be used in conjunction with MPLS could be based on distributed computation. As such, during routing transients these protocols may construct forwarding paths that contain loops. The protocols defined by MPLS must provide protocol mechanism(s) to either prevent the formation of loops and/or contain the amount of (networking) resources that could be consumed due to the presence of such loops.

7. The standard must clearly state how the protocol operates in a hierarchical network.

8. Scalability issues will be considered and analyzed. Very scalable solutions will be sought. For example, in the case of ATM technologies, the solution will attempt to conserve VC usage.

Charter Statement:

Currently, none of the solutions that that employ label-swapping based forwarding ("label switching") in conjunction with network layer routing are based on standard technology. In order to be able to achieve the benefits of this new technology, a standard solution is necessary.

The working group is responsible for standardizing a base technology for using label swapping forwarding paradigm (label switching) in conjunction with network layer routing and for the implementation of that technology over various link level technologies, which may include Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,...

This includes procedures and protocols for the distribution of labels between routers, encapsulations, multicast considerations, use of labels to support higher layer resource reservation and QoS mechanisms, and definition of host behaviors.

Objectives:

1. Specify standard protocol(s) for maintenance and distribution of label binding information to support unicast destination-based routing with forwarding based on label-swapping.

2. Specify standard protocol(s) for maintenance and distribution of label binding information to support multicast routing with forwarding based on label-swapping.

3. Specify standard protocol(s) for maintenance and distribution of label binding information to support hierarchy of routing knowledge (e.g., complete segregation of intra and inter-domain routing) with forwarding based on label-swapping.

4. Specify standard protocol(s) for maintenance and distribution of label binding information to support explicit paths different from the one constructed by destination-based forwarding with forwarding based on label-swapping.

5. Specify standard procedures of carrying label information over various link level technologies.

6. Specify a standard way to use the ATM user plane

a) Allow operation/co-existence with standard (ATM Forum, ITU, etc.) ATM control plane and/or standard ATM hardware b) Specify a 'label swapping' control plane c) Take advantage of possible mods/improvements in ATM hardware, for example the ability to merge VCs

7. Discuss support for QOS (e.g. RSVP).

8. Define standard protocol(s) to allow direct host (e.g. server) participation.

Coordination:

The working group will coordinate its activities with other working groups as appropriate.

Goals and Milestones:

Mar 97

  

Produce Framework Document Internet-Draft to contain goals with detailed motivations and description of solution space, possible approaches

May 97

  

Submit Framework Document to IESG (Informational RFC)*

May 97

  

Freeze Internet Draft for carrying label information over serial lines (p2p links) and over LAN media (e.g., Ethernet, Token Ring, FDDI)

Jun 97

  

Submit Architecture Document to IESG (Informational RFC)

Aug 97

  

Submit specifications for the protocol to distribute label binding information for unicast routes to IESG (Standards Track)

Oct 97

  

Submit specifications for handling label binding information (including distribution of this information) for multicast routes to IESG (Standards Track)

Dec 97

  

Submit specifications for Operation over ATM to IESG (Standards Track)

Dec 97

  

Submit specifications for carrying label information over serial lines (p2p links) and over LAN media (e.g., Ethernet, Token Ring, FDDI) to IESG (Standards Track)

Apr 98

  

Submit procedures for Host Behavior to IESG (Standards Track)

Apr 98

  

AD review status of WG efforts and determine whether to close down or not. If not, identify next set of milestones.

Internet-Drafts:

No Request For Comments

Current Meeting Report

Minutes of the MPLS WG Meeting

I. Framework Document - Ross Callon

<draft-ietf-mpls-framework-01.txt>

Ross made a brief presentation on the framework document. Another draft was submitted. In it, several sections of the former draft were fleshed out. The framework document is also being used to capture architecture discussions that have lead to particular decisions in the architecture document. The hierarchy and multicast sections were pointed out as in need of further work.

II. MPLS Architecture - Callon, Rosen, Viswanathan

<draft-rosen-mpls-arch-00.txt>

Eric Rosen presented the draft. An extensive number of architectural issues have been agreed and settled. These include the semantics of labels, the concept of equivalence classes, the need for hierarchy and thus the label stack, the need for explicit routes, a preference for topology based (actually control) label distribution vs. traffic (data) based setup.

Several important issues remain to be resolved. These were discussed extensively during the meeting, but with no resolution. The discussion did have the effect of getting a large number of people informed on the issues. The most prominent issues are:

A. Distributed vs. Egress control

The debate here is one of both versus egress only. The observation was made that the two modes can interoperate in a natural way. Arun on the other hand argues that egress control offers all the capabilities of distributed control and more, so why have two. In particular, egress control allows the level of aggregation to be consistent across the network. Eric Rosen pointed out that this only holds when you want to explicitly configure granularities other than coarse or fine. Those in favor of the distributed method point to the issues of scalability and convergence time as weaknesses of egress control.

B. Loop Prevention

Rick Bovie presented the loop prevention scheme that is in the current architecture draft. The scheme is based on the diffusion algorithm. It pins down routes until it can verify that a change will not result in a loop. The effects of this are that for traffic moving from a good path to a better path will continue to use the good path. Traffic, which is being black-holed, may be black-holed longer.

The architecture team believes that this is a workable approach with acceptable trade-offs. The point of contention is whether the algorithm is mandatory or optional. It was pointed out that in all cases except ATM with VC merge, there are other mechanisms to deal with looping packets. Also, Jeremy Lawrence made a presentation showing that some classes of ATM switches have the capability of using fair queuing or fair buffering schemes to contain the effects of loops in the VC merge case.

C. LDP Transport

It is agreed that LDP transactions need to be reliable, but there is no agreement on how that reliability should be achieved.

The architecture draft was accepted as the baseline text for the working group.

III. LAN Encapsulation (Ghanwani)

<draft-srinivasan-mpls-lans-label-00.txt>

IBM presented an update of the LAN proposal to carry labels in the destination MAC address field. The most significant changes are:

a) switches are now required to swap labels
b) labels are placed in the source address of label update messages to allow bridges to learn them

The authors will continue to refine their draft.

IV. MPLS Encapsulation Format (Rosen)

<draft-rosen-tag-stack-02.txt>

Eric presented the changes to his encaps draft, namely that the label is now 20 bits, the tos 3 bits and the TTL 8 bits.

It was proposed that the document be accepted as baseline text. Vijay objected to the presence of a LAN encapsulation in that document given that the above LAN encaps has also been proposed. Rosen agreed to drop the LAN section from his document (for now). It was then agreed that rough consensus existed to promote the draft to a working group document.

V. Soft State Switching (Blake)

<draft-viswanathan-mpls-rsvp-00.txt>

IBM presented an update of their draft and then moved that it be accepted as baseline text. This was objected to on the grounds that a) there was already another existing draft on the subject, and b) their draft was a late submission. After some discussion it was agreed that the authors of the two drafts would work together to create a combined document. The two drafts appear to be quite reconcilable.

VI. MPLS in VC environments (Doolan/Esaki/Demizu)

The soon-to-be-published draft addresses problems related running MPLS in ATM networks where the LSR's are not directly connected. In this situation, the label (VPI/VCI) will not be preserved between the logically adjacent LSR's.

The document points out that there are two functions of a label. These are:

a) To provide the value upon which something is switched. and
b) To provide the binding between the switching operation and the associated equivalence class.

When LSRs are directly connected the same value is easily used for both functions. But when ATM switches are not directly connected, the VPI/VCI cannot be used as a binding as the intermediate switch may not preserve the VPI/VCI from the incoming to the outgoing link.

The authors plan to continue developing their draft.

VII. VC pool (Noritoshi)

<draft-demizu-vcpool-00.txt>

Setting up ATM SVCs requires signaling and this will introduce delay in setting up LSPs. The proposal is to pre-create a pool of VCs. When a tag is allocated, the VC is then picked in the LDP BIND procedure.

VIII. Two Modes of Explicit Label Distribution Protocol (Katsube)

<draft-katsube-mpls-two-ldp-00.txt>

There are two modes of assigning labels, edge initiated and distributed. The TDP specification could be classed in both categories where the conservative mode over ATM represents an edge-initiated approach and the liberal mode the distributed. The distribute approach are more light-weight as it only is link by link, while the edge initiated approach implies end to end signaling. Edge initiated is desirable for controlling LSPs with arbitrary granularity, while distributed is adequate for multicast, RSVP driven or unicast with limited granularity.

IX. Double Identification Label Switching - DILS (Droz)

<draft-droz-dils-arch-00.txt>

The goal of this draft is to have a scalable solution for n endpoints, avoid the n**2 cross connect problem, preserve ATM traffic characteristics, and not require hardware changes. The DILS concept involves the use of flow merging and connection setup as proposed by ARIS and the use of VP merging.

Two cases are supported a symmetric and an asymmetric. The proposal is considered complementary to ARIS, it is possible to extend with QoS support. It was claimed that this could be achieved with no ATM hardware changes.

The presentation generated quite a bit of discussion. It was pointed out that most ATM hardware does not allow the VCI replacement function to be independent of the VPI replacement, since these operations are coupled in normal ATM. This means that in a worst case, the number of cross connects required is still n**2.

X. Performance Issues in VC merge MPLS Switches (Widjaja)

<draft-widjaja-mpls-vc-merge-00.txt>

VC merging requires that all the cells of a packet be buffered before the first cell can be transmitted. This changes the queuing behavior of ATM systems. To investigate the effects of VC merge, a series of comparative simulations was run across various utilizations and traffic models. The simulations showed that within normal operational limits that the additional buffering for VC merging is minimal and that best effort traffic would benefit from VC merging. As utilization increases, the additional drops due to VC merge decreases.

XI. Multi-Protocol Labels Switching: Performance and QoS Issues (Crosby)

The requirements on improved forwarding performance has to be better defined. What is the metrics? The intention is to explicitly describe the performance requirements and include them in the Framework document.

XII. CSR Experimental Operation (Esaki)

The WIDE project is an experimental network in Japan using legacy routers and CSRs all based on ATM. Hiroshi gave an update of their progress, pointing out the various service offerings and pointing out that the project incorporates hardware and software from different vendors.

XIII. Scalability Issues in MPLS over ATM (Wang)

<draft-wang-mpls-scaling-atm-00.txt>

Scalability is a major concern for MPLS over ATM. While VC merging address this issue, it may not be available on all platforms. This ID analyzes the scalability of MPLS without VC merge in terms of the size of the VPI/VCI space. If all 28 bits in the VPI/VCI field are available for label switching, then the number of end to end LSPs that can be supported is equivalent to 32k endpoints. Given that LSPs will end on routers rather than hosts, this is quite sufficient to support most real networks. Support of different services between the same end points will consume additional VPI/VCI space. However, the conclusion is that the combined VPI/VCI space in ATM should still be able to support networks of sufficient size.

In the ensuing discussion, it was pointed out that in most cases the size of the cross connect tables of the ATM switch would be the limiting factor.

Slides

None Received

Attendees List

go to list

Previous PageNext Page