2.5.7 Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of the 60th IETF Meeting in San Diego, CA USA. It may now be out-of-date.

Last Modified: 2004-07-09

George Swallow <swallow@cisco.com>
Loa Andersson <loa@pi.se>
Routing Area Director(s):
Bill Fenner <fenner@research.att.com>
Alex Zinin <zinin@psg.com>
Routing Area Advisor:
Alex Zinin <zinin@psg.com>
Mailing Lists:
General Discussion: mpls@lists.ietf.org
To Subscribe: https://www1.ietf.org/mailman/listinfo/mpls
Archive: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html
Description of Working Group:
The MPLS working group is responsible for standardizing a base technology for using label switching and for the implementation of label-switched paths over various packet based link-level technologies, such as Packet-over-Sonet, Frame Relay, ATM, and LAN technologies (e.g. all forms of Ethernet, Token Ring, etc.). This includes procedures and protocols for the distribution of labels between routers and encapsulation.

The working group is also responsible for specifying the necessary MIBs for the functionality specified in the base MPLS technology.

The first generation of the MPLS standards are largely complete, and the current WG work items are:

- procedures and protocols for multicast protocol extensions for point-to-multipoint TE, including soft-preemption

- Define requirements and mechanisms for MPLS OAM

- Define an overall OAM framework for MPLS applications

- MPLS-specific aspects of traffic engineering for multi-areas/multi-AS in cooperation with the CCAMP WG

- Determine (with CCAMP) what procedures are appropriate for evaluating proposals to extend the MPLS and GMPLS protocols, and document these

- Document current implementation practices for MPLS load sharing

The Working Group chairs tracking of the working group documents can be viewed at http://www.tla-group.com/~mpls/mpls-wg-docs.htm

Goals and Milestones:
Done  Submit documents from original MPLS effort to IESG
Done  Framework for IP multicast over label-switched paths ready for advancement.
Done  LDP fault tolerance specification ready for advancement to Proposed Standard.
Done  Submit Definitions of Managed Objects for MultoiProtocol Label Switching, Label Distribution Protocol (LDP) to the IESG for publication as Proposed Standards
Done  Specification for MPLS-specific recovery ready for advancement.
Done  Submit Multiprotocol Label Switching (MPLS) Forward Equivalency Class-To-Next Hop Label Forwarding Entry Management Information Base to the IESG for publication as Proposed Standards
Done  Submit Multiprotocol Label Switching (MPLS) Label Switching Router (LSR), Management Information Base to the IESG for publication as Proposed Standards
Done  Submit Multiprotocol Label Switching (MPLS) Management Overview to the IESG for publication as Proposed Standards
Done  Submit Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management to the IESG for publication as Proposed Standards
Done  Submit Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base to the IESG for publication as Proposed Standards
Done  Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard
Done  Submit a specification on Encapsulations to carry MPLS over IP and GRE to the IESG for as a Proposed Standard
Nov 03  Together with CCAMP complete and establish the (G)MPLS change process
Apr 04  Advance MPLS Architecture and MPLS encapsulation to Draft Standard
Apr 04  Submit a specification on Soft Pre-emption of LSP Tunnels to the IESG for publication as a Proposed Standard
Apr 04  Submit specification on LSR Self Test to the IESG for publication as a Proposed Standard
Jul 04  Submit specification on LSP Ping to the IESG for publication as a Proposed Standard
Jul 04  Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS)
Aug 04  Submit an OAM Framework Document to the IESG for publication as an Informational RFC
Oct 04  Advance 'Extension to RSVP for LSP Tunnels' to Draft Standard
Nov 04  Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs
Nov 04  Submit a BCP on MPLS load sharing to the IESG
  • - draft-ietf-mpls-lsp-hierarchy-08.txt
  • - draft-ietf-mpls-bundle-04.txt
  • - draft-ietf-mpls-mgmt-overview-09.txt
  • - draft-ietf-mpls-bgp-mpls-restart-03.txt
  • - draft-ietf-mpls-rsvp-lsp-fastreroute-06.txt
  • - draft-ietf-mpls-lsp-ping-06.txt
  • - draft-ietf-mpls-lc-if-mib-02.txt
  • - draft-ietf-mpls-fastreroute-mib-02.txt
  • - draft-ietf-mpls-ldp-mtu-extensions-03.txt
  • - draft-ietf-mpls-in-ip-or-gre-08.txt
  • - draft-ietf-mpls-p2mp-requirement-03.txt
  • - draft-ietf-mpls-nodeid-subobject-02.txt
  • - draft-ietf-mpls-soft-preemption-02.txt
  • - draft-ietf-mpls-telink-mib-07.txt
  • - draft-ietf-mpls-lsr-self-test-02.txt
  • - draft-ietf-mpls-rsvpte-attributes-04.txt
  • - draft-ietf-mpls-explicit-null-01.txt
  • Request For Comments:
    RFC2702 I Requirements for Traffic Engineering Over MPLS
    RFC3031 PS Multiprotocol Label Switching Architecture
    RFC3032 PS MPLS Label Stack Encoding
    RFC3034 PS Use of Label Switching on Frame Relay Networks Specification
    RFC3035 PS MPLS using LDP and ATM VC Switching
    RFC3036 PS LDP Specification
    RFC3037 PS LDP Applicability
    RFC3038 PS VCID Notification over ATM link for LDP
    RFC3033 PS The Assignment of the Information Field and Protocol Identifier in the Q.2941 Generic Identifier and Q.2957 User-to-user Signaling for the Internet Protocol
    RFC3063 E MPLS Loop Prevention Mechanism
    RFC3107 PS Carrying Label Information in BGP-4
    RFC3209 PS RSVP-TE: Extensions to RSVP for LSP Tunnels
    RFC3210 I Applicability Statement for Extensions to RSVP for LSP-Tunnels
    RFC3212 PS Constraint-Based LSP Setup using LDP
    RFC3213 I Applicability Statement for CR-LDP
    RFC3214 PS LSP Modification Using CR-LDP
    RFC3215 I LDP State Machine
    RFC3270 PS MPLS Support of Differentiated Services
    RFC3353 I Framework for IP Multicast in MPLS
    RFC3443 PS Time to Live (TTL) Processing in MPLS Networks (Updates RFC 3032)
    RFC3477 PS Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)
    RFC3469 I Framework for MPLS-based Recovery
    RFC3478 PS Graceful Restart Mechanism for Label Distribution Protocol
    RFC3479 PS Fault Tolerance for the Label Distribution Protocol (LDP)
    RFC3480 PS Signalling Unnumbered Links in CR-LDP (Constraint-Routing Label Distribution Protocol)
    RFC3612 I Applicability Statement for Restart Mechanisms for the Label Distribution Protocol (LDP)
    RFC3811StandardDefinitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management
    RFC3812StandardMultiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base
    RFC3813StandardMultiprotocol Label Switching (MPLS) Label Switching Router (LSR)Management Information Base
    RFC3814StandardMultiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)Management Information Base
    RFC3815StandardDefinitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)

    Current Meeting Report

    Multiprotocol Label Switching Minutes - IETF60

    WG status (Loa & George)

    Mail list - has been moved to the ietf server. We've also changed maillist administrators at this time. Thanks to Eric Rosen for serving us so well and so long. And thanks to Eric Gray for taking this on.

    Four new RFCs (all MIBs). RFCs 3811 - 3815.

    Various drafts on the RFC editor's queue. No real problem per se. Draft editors - please take care with refs to other docs (esp docs you don't control and normative refs). Some refs that were said to be normative weren't etc. Refs are most common reason for getting stuck in the Q.

    MTU signalling doc got stuck because of over-ambitious author (added RFC editor's note himself). Need to verify that we got the RFC editor's note correctly.

    Author, chairs, and ADs will be meeting to sort out comments on MPLS over GRE.

    A respin needed on LSP ping. Other documents including LSR self-test depend on this.

    ATM/FR LC MIB doc is in MIB-doctor review.

    Ina Minei has taken on the task of getting LDP to draft standard.

    MPLS OAM Framework

    Tom Nadeau and Dave Allen

    An OAM framework was added to charter a few meetings back. Tom and Dave had been active in that area so were asked to have a go. This is initial output.

    The aim is to keep the scope down and describe circumstances where data plane tools would facilitate addressing FCAPS issues. Since the draft is a framework, it is intended to be technology agnostic. Specific tools are not discussed. Each of the topics in FCAPS will be addressed. The document currently covers the following.

    Fault Management - enumerates potential MPLS forwarding problems and explores where data plane tools can assist in detection and diagnostics. There is some discussion of availability criteria but this could use some fleshing out by providers.

    Config - using data plane tools to verify config.

    Admin in future.

    Perf - extracting counts etc.

    Security - can tools be abused? How to prevent this.

    Next steps are to adopt this as WG draft. The authors will continue to work on security and administative issues. George said it was inappropriate to poll the room for support to make this a WG document since the draft did not make the cut-off. So take to list after the meeting.

    P2MP requirements

    Seisho Yasukawa

    This draft has gone through an initial WG last call. This revision is intended to address those comments

    Further requirements issues were raised by the P2MP design team (see next draft below) that need to addressed in this draft, including:

    1) are all leaves/branches subject to same LSP parameters? Esp important inter-domain.

    2) How do we do re-merge and cross-over? Issues with duplication.

    3) How does this scale. Is core of network so scaling different to pure IP multicast. Hopefully tree is more stable than in IP.

    4) Partial tree reoptimisation is important - but can cause duplication.

    5) What if path message gets fragmented downstream (as it grows as it goes)? Don't want to rely on IP fragmentation - so need to handle in control plane.

    6) should we avoid replication on MPLS LAN interfaces?

    Next steps:

    Revision 4 - will add the new well understood requirements.

    Authors will ask list about those that are not well understood.

    Then hopefully will produce revision 5 as final rev. and put into WG last call.

    A lot of discussion ensued. For details see the detailed minutes sent to the list.

    George - Speaking as chair

    The draft needs to be revised to both clarify and narrow the scope to P2MP traffic engineering. The draft should only be about requirements, references to RSVP should be minimal if not completely expunged.

    Better coordination with multicast folks in general and MBONED in particular needs to happen. It was suggested by Dave Meyer that this be vetted in MBONED.

    P2MP merged solution document

    Dimitri Papadimitriou, Rahul Aggarwal & Seisho Yasukawa

    In Korea there were two drafts that were far apart. Alex asked that there be one draft, merging the two and that a design team be formed. together. That happened slowly at first, but what happened once people started focussing on the problem were able to find the right solution. This draft represents both the consensus and captures the remining differences of the original two drafts. While it is far from converged much progress has been made.

    Open issues (partial list):

    1) state management. Intent is to disambiguate message size. ID still needed for sub-tree reoptimisation.

    2) re-optimisation.

    3) re-merging. Would like to point out issues under discussion - data plane and control plane issues. Identified a case for this.

    4) Recovery. Need to expand on GMPLS applicability.

    The authors will be requesting this be a WG document after this meeting.

    Source Routed MPLS LSP using Domain Wide Label

    Albert Tian

    This draft introduces global labels as a means of source routing or loose source routing a packet in an MPLS network. If each destination of interest (say all of the loopback addresses used as router-IDs) had a label which was both globally known and globally used by all routers, then one could source route a packet by stacking up labels for each of the routers in the source route. This technique could be applied to fast reroute.

    In the ensuing discussion it was pointed out that the idea of global labels had been discussed in the early days of MPLS. At that time it was decided that labels would only have local significance (within the forwarding plane). Many workgroup members expressed opposition to such a fundamental change to the MPLS architecture. Alex Zinin stated, "The workgroup is done with architecture. Unless it can be proved that architecture is not sufficient then this doesn't fit in charter."

    Loose Segment Optimization in Explicit Paths

    Albert Tian

    The issue addressed by this draft is FRR. The author has concerns about having large numbers of repair paths. If you use RSVP-TE could have a lot of state in the network. Can alleviate this by tunnelling the RSVP-TE path messages to reduce RSVP-TE state. Two applications are envisioned, Fast Reroute and P2MP. In the latter case this is applicable if shape is the only concern.

    The idea is to have RSVP state only at critical nodes and to use LDP as a form of fowarding adjacency between those nodes.

    Albert request that this become a WG document. Some discussion ensued with no clear direction. George asked that the discussion be continued on the list.

    FastReroute using Alternative Shortest Paths

    Albert Tian

    This draft proposes a new way to calculate repair paths which offers 100% repair coverage using explicit paths with loose segments.

    First issue is to determine the termination point. For link protection this is the next-hop; for node protection the next-next-hop. Repair path calculation is simple. Take out the link or node being protected and calculate a path.

    The repair can be made using any of:

    Source Routed MPLS LSP using Domain Wide Label
    RSVP-TE with Loose Segment Optimization in Explicit Paths

    Draft gives algorithm to simplify the repair path.

    The key benefit benefits claimed are 100% coverage with reduced repair paths based on next-hop/next-next-hop termination, and shared protection for MPLS, IP unicast, and IP multicast.

    Albert asked that this become a WG document. George question which parts belonged here and pointed out that there was related work going on in the Routing Area WG. It would appear that the algorith part of the draft would belong there since it's applicable to IP as well as MPLS. Discussion will continue in that WG and on the list(s).

    Equal Cost Multipath Best Current Practices (ECMP BCP)

    George Swallow

    This draft is intended to give guidance to people building applications on MPLS. The issue first surfaced in PWE3. If all of the data for a psuedo-wire then steps need to be taken to avoid ECMP. There are several known reasons for wanting a single path. One is to reduce jitter and avoid out-of-order delivery (note that these can still occur in a reroute situation). Anther is to ensure that OAM flows follow the paths that they are trying to monitor.

    MPLS defines FECs. The primary FEC used in the core of the network is the IP prefix. MPLS has no payload identifier; it is inferred from the FEC. on this early on in MPLS. If you get label in middle of network for IP FEC and have no payload ID then many vendors assume is IP. But some vendors said "if look at first nibble and isn't 0x4 will assume it isn't IP. If it is IP we'll do our usual IP hash". All well and good as long as only carried IP or L3VPN. But get problems with PWE3 as have non-IP payload. If first nibble is 0x4 the core is likely to assume this is IP and we'll get mis-ordering.

    Ultimately best solution is to avoid 0x4 or 0x6 in first nibble. Problem is that IANA is working up from 4. Nobody knows the exact status of 0-3, but it is unlikely that they would be assign before 7-15, if at all. The recommendation in this draft is to use 0x0 and 0x1.

    George will be asking for WG status on the list. A poll of the room showed general support for this.


    None received.