2.5.6 Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of the 59th IETF Meeting in Seoul, Korea. It may now be out-of-date.

Last Modified: 2004-02-02

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

The Working Group chairs tracking of the working group documents can be viewed at http://urax.utfors.net/~loa/MPLS_WG_Drafts.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
Oct 03  Advance the Label Distribution Protocol to Draft Standard
Oct 03  Submit the Traffic Engineering Link MIB to the IESG for as a Proposed Standard
Oct 03  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
Nov 03  Submit specification on LSP Ping to the IESG for publication as a Proposed Standard
Mar 04  Submit a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS)
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
Aug 04  Submit an OAM Framework Document to the IESG for publication as an Informational RFC
Oct 04  Advance
Nov 04  Submit document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs
  • - draft-ietf-mpls-ldp-mib-14.txt
  • - draft-ietf-mpls-te-mib-14.txt
  • - draft-ietf-mpls-lsr-mib-14.txt
  • - draft-ietf-mpls-lsp-hierarchy-08.txt
  • - draft-ietf-mpls-ftn-mib-09.txt
  • - draft-ietf-mpls-tc-mib-10.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-04.txt
  • - draft-ietf-mpls-lsp-ping-05.txt
  • - draft-ietf-mpls-lc-if-mib-01.txt
  • - draft-ietf-mpls-fastreroute-mib-02.txt
  • - draft-ietf-mpls-ldp-mtu-extensions-02.txt
  • - draft-ietf-mpls-in-ip-or-gre-05.txt
  • - draft-ietf-mpls-p2mp-requirement-01.txt
  • - draft-ietf-mpls-nodeid-subobject-02.txt
  • - draft-ietf-mpls-oam-requirements-02.txt
  • - draft-ietf-mpls-soft-preemption-01.txt
  • - draft-ietf-mpls-telink-mib-06.txt
  • - draft-ietf-mpls-lsr-self-test-02.txt
  • - draft-ietf-mpls-rsvpte-attributes-02.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)

    Current Meeting Report

    	PresentationMPLS Working Group Meeting in Seoul
    Monday, March 1 at 1300-1500
    Chair: Loa Andersson
    Note takers: Giles Heron and  Rahul Aggarawal. Thanks!
    1. Agenda bashing
    The agenda was accepted as published.
    Slides: mpls-agenda-seoul.htm
    2. Working group status - Loa Andersson
    bunch of docs on RFC editor queue.  In good shape.  Most docs waiting for 
    refs, but relatively few.  Waiting for IANA codepoints in some.  GMPLS 
    routing is holding some of this up.  It's depending on a whole bunch of 
    stuff.  The rest should be easy to get through.
    RFC Editor found that for FTN MIB two of the refs weren't 
    MTU draft and IP/GRE are with the IESG.  Problem with MTU is that there are 
    no known implementations - need implementations to go to standard track.  
    May be that we can do experimental first then move to standards.
    IESG has sent Fast Reroute and LDP PING back to WG for updates.  OAM 
    requirements author has asked for WG last call.  Loa waiting for OK from 
    authors to send various others drafts to IESG or WG last call.
    OAM framework - Tom Nadeau and Dave Allan editing it. Plan is to publish an 
    first version I-D soon.  The authors has agreed on an table of content and 
    started fill in text.
    Slides: wg-status-rfc-ed.ppt
    3. RSVP-TE attributes - Adrian Farrel
    The aim of this draft is to address shortage of bit-flags in session 
    attribute object. The attribute flags object has been variable lenght to 
    make it more extensible.
    RRO subobject allows each node to say whether it supports a bit and 
    whether it acts on it. An RSVP-TE attribute is an LSP attribute, not a 
    session attribute.
    This ID is stable and referenced by other drafts. There is a temporary 
    registry to track allocations until this goes to IANA.
    The attribute per-LSP os of value in Resv and might be used for P2MP. It is 
    easy to add and will be optional.
    The plan is for one more iteration of draft in March (with per-LSP Resv 
    added) and then document implementations, where are a couple started. 
    after that it will time for working group last call.
    Slides: LSP-Attributes.ppt
    4. LDP graceful restart for planned outages - Ina Minei
    The goal of this ID is to do graceful restarts, but only for planned 
    outages (e.g. s/w upgrades). It is not within the scope of this ID if 
    restart is ungraceful in other cases.
    Graceful Restart parameters are negotiated at session 
    establishment. So one will have to flap sessions to change them.
    The aim is to make it possible to run in a"no GR mode " by default. When a 
    planned restart takes place and the session is to be closed, one will be 
    able to configure that at the next restart this will be done in a 
    graceful manner. This will be backwards compatible with graceful restart 
    To make this work we need a new optional parm (GR data TLV) and to send 
    this with shutdown status code. The new TLV Carries reconnect time for when 
    it comes back up.
    A scenario is to tell neighbours that the LSR are going down, but tell them 
    to wait long enough to allow for the restarting LSR to come up 
    gracefully. Neighbours will then wait until the LSR has come back up.
    The restart box will be graceful for the planned outage, but 
    ungraceful after. This could be done without specific 
    The discussion focused on how useful this would be. A question was asked on 
    why it wouldn't be feasible to always do graceful restart. The authors said 
    this could be a way of introducing graceful restart in the network by 
    having it first be applied in a controlled environment, where the 
    operator is comfortable with it, before deploying it network wide.
    A question was asked whether there is a way to check if the neighbors 
    suport this behaviour. The authors said that the current draft does not 
    have provisions for it. The reason is because a planned restart is 
    initiated by  the operator, who can do all the necessary checks at that 
    time. The authors mentioned that the capability could be added.
    A comment was made that essentially this draft adds the planned restart 
    capabilities to RFC 3479 to RFC 3478.
    Discussion to be continued on the mailing list.
    Slides: ldp_gr_ietf_slides.pdf
    5. Requirements for Point to Multipoint extension to RSVP-TE - Seisho 
    The work orignated in an effort to put together requirements for TE MPLS 
    multicast. This will for a basis for evaluating solutions in this area. 
    Since last meeting input from service providers has been added to the 
    requirment specification.
    The ID is now very stable and the goal is now take the ID to working group 
    last call after some minor updates.
    Major changes since the previous version:
    1) Now a WG doc and added SP and CCAMP authors
    2) terminology
    3) scenarios
    4) make-before-break
    5) Added scalability and backwards compatibility.
    Remaining Issues:
    1) need some extra terminology
    2) do we address more sophisticated functions.  Authors would rather defer to 
    another doc.
    3) Intention is re-spin and then go to working group last call.
    Slides: p2mp_requirements_040302.ppt
    6. Extended RSVP-TE for Point-to-Multipoint LSP Tunnels - Alan Kulberg
    This draft is backwards compatibility with existing RSVP-TE LSPs, does 
    simultaneous prune and graft and allows for an implementation based on P2P 
    mechanisms and smoth migration because it doesn't need wholesale upgrade of 
    It will set up multiple P2P LSPs from sender to a single leaf, and then 
    from each branch node to a single leaf. The association object is used to 
    associate them together and form P2MP LSP.
    There have been some changes since the previous draft:
    Branches are encoded in secondary EROs (SEROs) up to the branching node, 
    after that encoded into ERO at the branching node. Only the brancing nodes 
    need to process the SERO.
    The association object allows parallel LSPs and does make before break on 
    P2MP LSP.
    The opinion of the authors is that  this draft satisfies the 
    There are two different solutions drafts for TE P2MP LSPs. The chairs and 
    the meeting strongly encourage the authors for both need to get 
    together and converge on a single soultion.
    Charter milestone is Nov 04 for WG document to be submitted.  Edits will be 
    done soon and submitted.  Welcome WG feedback on the email list.  Want 
    direction here as to how to get solutions merged together.
    Discussion were on capabilites of the solution. e.g. Fast Reroute in case of 
    node failure. Authors agreed that this should be added.
    The choice of RSVP-TE as protocol for TE P2MP MPLS were also 
    challenged, but this discussion was defered until after next 
    Slides: p2mp_solution_040301.ppt
    7. Establishing Point to Multipoint MPLS TE LSPs - Rahul Aggarwal
    This draft address the problem of introducing Traffic Engineered MPLS p2MP 
    LSPs into the data plane with minimal changes to current RSVP-TE. It is 
    optimized for a high volume of multicast. It uses P2P LSPS as building 
    It leveraging the existing Control Plane model, as RSVP-TE support 
    multiple LSPs per session. One design criteria has been simplicity of 
    protocol and implementation.
    MPLS multicast label mappings set up at the merge nodes. The Source PE 
    (SPE) initialises P2P LSPs to each Remote PE (RPE) for P2MP LSPs. common 
    session object but distinct sender templates and PATH messages (P2P TE ERO in 
    each PATH). Each RPE initates a Resv. 
    Upstream node does RSVP-TE SE style merge.
    SPE gets one Resv per RPE, but merge/branch nodes have set up the label 
    Makes it very easy to add new elements without impacting the existing tree 
    (could be significant churn with multicast).
    Enhancements since 00 draft:
    identifiers for constituents cleaned up
    supports secondary P2MP LSPs (as this is common for P2P)
    Non-adjacent signalling.
    Make before break.
    Fast Reroute.
    LSP hierarchy.
    Authors believe solution is on a par with P2P LSPs - and reuses their 
    machinery.  It lets you signal different attributes for each P2P LSP - so in 
    inter-domain case can give different behaviour for each exit point.  Aim is 
    to move to WG doc.
    Discussion were on the realtive merits of the two solutions 
    proposals. This discussion concluded in that issues with both 
    proposals should be sent to the list and the there seeems to be good 
    reason to continue investigating ways of merging the two proposals.
    It was also pointed out that there is work in other groups on 
    multicast, e.g. extending PIM. In response to that it was said that the 
    work specified in the two draft are for Traffic Engineered LSP only. 
    Nevertheless there is a need to coordinate this work with the 
    multicast working group(s), at least when it comes to non-TE.
    Slides: ietf-59-seoul-p2mp-te-prn.ppt
    8. Nexthop Fast ReRoute for IP and MPLS - Naiming Shen
    The goal for this draft is to solve the problem of Fast Rereoute for 
    traffic in general, not just TE LSPs. LSPs, regardless if they are LDP, TE, 
    IP or IP multicast is protected.
    There are several known approaches:
    1) IGP Fast Convergence - when a link or node failure is detected 
    flood/process this information faster than other IGP information.  This 
    enables the whole network to converge faster.
    2) MPLS-TE Fast Reroute
    3) Pre-Computed alternative next-hops.  Based on IP (typically IGP) 
    information.  Download alternative paths into forwarding plane and switch 
    onto that when there's a node/link failure.
    4) Next hop fast re-route.  Use MPLS LSP as an explicitly routed tunnel to 
    reroute general traffic in case of node failure.
    All four types of traffic have an IP next-hop.  An explicitly routed 
    tunnel is used to protect the next-hop.  Use this to route to next-hop node 
    or next-next-hop.  Protection LSP is unaffected by routing changes as is 
    explicitly routed.  Could equally do this with Frame Relay etc.  Reason for 
    doing it with MPLS  is because modern routers support MPLS LSPs.  Can 
    either use one tunnel to protect mix of traffic, or one tunnel per 
    traffic type, any approach is possible.  The uniform in itself is a 
    benefit. Don't need one mechanism for fast reroute for TE and another for 
    Tpo achieve this we need an new RSVP object - bypass next-hop.  It is used by 
    ingress node to inform egress of what you're trying to protect.  For link 
    protection is next-hop, for node protection is next-next-hop you've 
    learned through some other mechanism.  The major application is 
    multicast.  Need to modify the RPF check.
    We need to request a C-class number from IANA for bypass nexthop object. 
    There are also drafts on node-protection for LDP and for PIM.
    Too early to adopt this as a working group document, the discussion will be 
    continued on the mailing list.
    Slides: nexthop-frr-mpls.ppt
    9. Discovering LDP Next-Nexthop Labels - Enke Chen
    This is an LDP specific follow-up to the draft discussed previously.
    Normally LDP nodes only know bindings for adjacent peers.  To do node 
    protection next-nexthop labels are needed.
    The next hop label discovery is build on two capabilities.
    - the  ability of a node to signal its interest in getting the 
    next-nexthop label mapping info and the ability of the node that 
    receives this request to advertise the next-nexthop information
    - the use of the status TLV to carry info in notification message (saves 
    inventing a new TLV) and the use label TLV to carry next-nexthop info in 
    label mapping (consists of label/router-id pairs of next-nexthop nodes).
    Loa (chairman's hat off) - we do FRR.  Fine.  It is one of the key 
    element in TE.  Fine.  We have RSVP-TE as TE tool.  So why start doing TE 
    with LDP at this moment?  We closed CR-LDP about a year ago, and it is not 
    our intention to revive it.
    Authors responded that LDP is widely deployed today.  Fast reroute makes 
    sense in this kind of deployment.  RSVP-TE is already available sure.  If 
    you are using LDP for L3VPN then don't need to turn on RSVP-TE for Fast 
    reroute. BTW we are not trying to do TE for LDP.  Just trying to 
    protecting traffic.  
    Questions were asked if tLDP already gives give you what this draft tries to 
    accomplish. The discussion on first draft will contiune on the list, it 
    makes sense to include this second draft in that discussion, since they are 
    closely related.
    Slides: ldp-nnhop.ppt
    10 .Multiprotocol Label Switching Pre-emption - Adrian Farrel
    The issue were brought up in Minneapolis and it was agreed upon that there 
    are differnt interpreations on how to preeemption in different RFCs, as 
    well as various interpretations of what people *want* to achieve. In 
    preparing the draft the author have polled for requirements. The 
    discussion has been very limited on the list, and some off-line. 
    The requirements are 
    - that we have known and understood procedures for soft/hard 
    - that these procdures are backward compatible 
    - that it possible to tell what is soft vs. hard preemption.
    Author asked if there is an intrest to continue this work and several 
    people said that there is an contiuned interest.
    Need to clarify GMPLS - especially for soft preemption.
    Question as to whether existing soft preemption draft will now be 
    Not going to address rights and wrongs of implementations.
    Will clarify GMPLS in march.  Last call April.  Not a big deal - just an 
    error code.
    Adrian - Loa, would you like it to be a WG draft?
    Loa - asked you to do this because I care, so we need a working 
    solution with >1 implementation.  Not been asked if we should make this WG 
    doc.  Probably come back to it once you've done a re-spin.
    Dimitri - can we fix a timeline for this.  If we don't find a solution soon 
    will have workarounds that people find.  Would like it solved ASAP.  Do 
    re-spin soon and discuss on list.
    Loa - Adrian promised re-spin in March.  Take to list then and discuss if is 
    Slides: soft-preemption.ppt
    11. Meeting closed


    Encoding of Attributes for Multiprotocol Label Switching Label Switched Path Establishment Using RSVP-TE
    LDP Graceful Restart for Planned Outages
    Requirements for Point to Multipoint extension to RSVP-TE
    Extended RSVP-TE for Point-to-Multipoint LSP Tunnels
    Establishing P2MP MPLS TE LSPs
    Next-Hop Fast Re-Route
    LDP Next-Nexthop Labels
    Multiprotocol Label Switching Pre-emption