2.4.7 Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00

Chair(s):

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

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@redback.com>

Routing Area Advisor:

Rob Coltun <rcoltun@redback.com>

Mailing Lists:

General Discussion:mpls@uu.net
To Subscribe: mpls-request@uu.net
In Body: subscribe (unsubscribe)
Archive: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html

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 Achitecture 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:

Request For Comments:

RFC

Status

Title

 

RFC2702

 

Requirements for Traffic Engineering Over MPLS

Current Meeting Report

None received.

Slides

MPLS/IP Header Compression + Over PPP
Signaling Requirements at the Optical UNI
Policy Framework QoS Information Model for MPLS