Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.

Chair(s): 

Vijay Srinivasan <vijay@raleigh.ibm.com>
George Swallow <swallow@cisco.com>

Routing Area Director(s): 

Joel Halpern <jhalpern@newbridge.com>

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
Archive: ftp://ftp.cisco.com/ftp/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.

No Current Internet-Drafts

No Request For Comments 

Current Meeting Report

Written Minutes Not Received (Provided Slides) 

Slides

1. Route Loops in MPLS 

2. Merging RSVP Flows 

3. ARIS Support for LAN Media Switching 

4. ARIS Features 

Attendees List

TOC