2.5.5 Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of the 61st IETF Meeting in Washington, DC USA. It may now be out-of-date.

Last Modified: 2004-09-20


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-07.txt
  • draft-ietf-mpls-lsp-ping-07.txt
  • draft-ietf-mpls-lc-if-mib-04.txt
  • draft-ietf-mpls-ldp-mtu-extensions-03.txt
  • draft-ietf-mpls-in-ip-or-gre-08.txt
  • draft-ietf-mpls-p2mp-requirement-04.txt
  • draft-ietf-mpls-nodeid-subobject-02.txt
  • draft-ietf-mpls-oam-requirements-04.txt
  • draft-ietf-mpls-soft-preemption-03.txt
  • draft-ietf-mpls-telink-mib-07.txt
  • draft-ietf-mpls-lsr-self-test-03.txt
  • draft-ietf-mpls-rsvpte-attributes-04.txt
  • draft-ietf-mpls-explicit-null-01.txt
  • draft-ietf-mpls-rfc3036bis-00.txt
  • draft-ietf-mpls-ecmp-bcp-00.txt

    Request For Comments:

    RFC2702 I Requirements for Traffic Engineering Over MPLS
    RFC3031 PS Multiprotocol Label Switching Architecture
    RFC3032 PS MPLS Label Stack Encoding
    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
    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
    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)
    RFC3469 I Framework for MPLS-based Recovery
    RFC3477 PS Signalling Unnumbered Links in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)
    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)
    RFC3811 Standard Definitions of Textual Conventions for Multiprotocol Label Switching (MPLS) Management
    RFC3812 Standard Multiprotocol Label Switching (MPLS) Traffic Engineering Management Information Base
    RFC3813 Standard Multiprotocol Label Switching (MPLS) Label Switching Router (LSR)Management Information Base
    RFC3814 Standard Multiprotocol Label Switching (MPLS) Forwarding Equivalence Class To Next Hop Label Forwarding Entry (FEC-To-NHLFE)Management Information Base
    RFC3815 Standard Definitions of Managed Objects for the Multiprotocol Label Switching, Label Distribution Protocol (LDP)

    Current Meeting Report

    MPLS WG Agenda for the Washington Meeting

    November 2004, 9.00 - 11.30

    1. Agenda bashing
    Agenda accepted as proposed.
    Scribes: Markus and Dimitri

    2. Working group status (20 min)
    - liaison from MPLS & Frame Relay Alliance on RFC 3036
    The MPLS working group has recieved a comunication from the MPLS & Frame Relay Alliance (MFA) on RFC 3036 as it is being progressed to draft standard.
    It was pointed out that IETF and/or its working groups do not enter liaision relationships with any other orgtanizations than Standards Development organizations. However, this will not stop us from having an open and trustful communication with indurial forums like MFA. The technical issue brought up in the communication will be discussed in this meeting, and based on that discussion a response to MFA will be sent.
    Note: This response were sent November 11 and will be found at http://www.cell-relay.com/mhonarc/mpls/current/msg00028.html

    - new RFCs / IESG reviews
    two drafts "draft-ietf-mpls-explicit-null-01.txt" and draft-ietf-mpls-rsvpte-attributes-04.txt have been in AD evaluation a long time, don't know why?
    Alex: they will be IETF last called pretty soon

    A number of docs has been moved to rfc ed queue: congrats to authors/editors. Since the dependencies on other documents are not that heavy they will go out as RFC soon

    The mpls bundle draft (draft-ietf-mpls-bundle-04) has been pulled from rfc queue, and taken back to wg for a (hopefully) quick respin, the reasons for this were discussed by Zafar at this meeting. A problem here is that several other documents depends on the bundle draft.

    - wg drafts
    This draft is stuck waiting for the lsp-ping draft to progress

    These two draft did miss the the cut-off date to be published as working group documents, the working groups chairs have sent a mail to the mailing list saying that for "all practical purposes the two draft should be treated as working group documents.

    "Graceful Restart Mechanism for BGP with MPLS" needs re-spin

    RRO Node-ID subobject: Jean-Philippe told that an update has been submitted

    Zafar Ali: Issues with link bundling draft
    After discussion among draft contributors, wg co-chairs and ADs it was decided decided that some issues with draft needed to be fixed. To tht end the draft was pulled from rfc queue.
    The scope of this presentation is to outline the issues, focusing on required functionality
    1. scoping of component link id: node vs. bundled te link scope
    2. equivalents of type 4/5 tlvs for ipv4 and ipv6 if_id_rsvp_hop and if_id error_spec objects
    3. recording (and explicit controol) of component interface id
    Zafar described all three issues in more detail.
    Next step: would like wg to close on issues, then discuss solution space
    Adrian ("ccamp co-chair hat on"): Good to do this work in mpls, but it's blocking huge number of ccamp drafts in the rfc queue
    Loa: Just pulled the draft yesterday, don't know yet how long it will take to fix it
    Lou: Will submit update on draft as soon as drafts are accepted again
    George: authors should just circulate updated draft and solicit input
    Kireeti: No rewriting planned, only address specific issues and not open up the whole thing
    Yakov: Focus only on changes, not rest of document, wg chairs should structure discussion appropriately
    Lou: Don't add new things, don't reopen old issues, new functionality needs new draft
    Loa: The issues will be dealt with as wg last-call, limited to the issues outlined in Zafars slides
    slides: www.tla-group.com/~mpls/bundling.ppt

    3. LDP to Draft Standards

    Ina Minei

    Ina: Since the last IETF work has been done into two areas

    1. produced first draft of the revised specification
    - editorial
    - areas not covered in the document: securing hellos, LDP MTU signaling
    - shutting down adjacencies
    - clarifications: corner cases not spelled out correctly in the original spec
    - errors/clarifications/changes in the pseudo-code (split horizon when doing
    ordered label control)

    2. started the operator survey
    - deadline for reply after the ietf

    Next steps
    - feedback from the changes made in the document
    - re-submit a version

    Kireeti Kompella: We need to update the IANA section, will propose text to Ina to go into this part of the document.
    Slides: www.tla-group.com/~mpls/3036bis.ppt

    Liaison from MPLS & Frame Relay Alliance on RFC 3036
    Andy Malis
    Andy presented a liaison from MPLS & Frame Relay Alliance regarding the LDP Host Address FEC. He described what the HA FEC is in comparison to the Address Prefix FEC.
    Ina's original email proposed to remove host addr fec due to non-use, changes to the Address Prefix FEC with a /32 prefix were alos proposed Andy summarized the liaison and stated that while the MFA could use the Address Prefix FEC with a /32 prefix, the MFA prefer to keep HA FEC as is due to implementation plans.
    Slides: www.tla-group.com/~mpls/mfa-communication.ppt

    Discussion on Host Address FEC
    Eric Rosen

    RFC3036 defines FEC element types used to bind labels to address prefixes in routing table the RFC define two FECs (Address Prefix (AP) and Host Address (HA)), other FEC element types will be defined by other protocols in early versiions of the LDP specification only AP FEC existed, the HA FEC were included because it was assumed that an LSR must be able to distinguish between locally delivered vs. forwarded packets (constraints of particular ATM based implementation).
    The HA FEC has not been used so far, the LDP specification is written so it is easy to remove it when we progress to Draft Standard.
    The MFA laim they use the HA FEC in their specification, a closer reading of the documents show that they are not using the FEC axactly as specified in RFC3036, in particular it violates section in the LDP specification. The conclusion is that a new FEC has been specified and a new FEC type is needed.
    Slides: www.tla-group.com/~mpls/rosen-fec.ppt

    George: Does anybody object to keep the same number for new FEC?
    Andy: Keeping the same FEC type value is fine. But given it's all there in the doc, why take it out?
    Kireeti: A Draft Standard means that an implementation has existed for some time. New fec does not belong in ds std.
    George: Reusing the FEC type value implies that we first remove it from the LDP specification.
    Alex: Based on the discussion here, moving it to separate document is best idea
    Loa: As we don't have an implementation of the HA FEC, we can't move the LDP specification to Draft Standard. Move the new FEC into new doc and we will "reassign" same number.
    Andy: To reassign number requires wg draft accordig to iana allocation process (ietf consensus).
    Alex: Doesn't think proposed standard is required, but will need to check this.

    4. P2MP TE (25 min)

    Requirements for Point to Multipoint Traffic Engineered MPLS LSPs
    Sheisho Yasukawa

    Sheisho stressed that the scope of the requirement specification is p2mp traffic enginered LSPs only, how the p2mp tree is co,puted is outside the scope of the requirment specification. Earlier revision -02 were working group last called, and revision -03 included updates accoring the last call comments. Revision -04 introduced new text to include requirements and clarification originating from the for all solution team issues.
    Thre are till some open issues:
    - variation of lsp parameters on different lsp branches?
    - can a transit (probably branch) re-optimize a sub-tree?
    - what should be the behavior if the tree "re-merges"?
    - can short-term data duplication be tolerated?
    - limits and design targets
    A new version is planned shortly and should be sent to working group last call.
    Slides: www.tla-group.com/~mpls/p2mp-reqs.ppt

    Eric: Because of the way some of the requirements and the motivation for the requirements are stated the requirement document becomes more controversial than the solution document. It could be discussed if we need this requirment document at all.
    Igor: Do we need to includ a requirmentfor leaf-initiated add/drop
    George: I'm opposed to it. Complete solution needs more work elsewhere. If such requirements exists, they need to be captured somewhere else.
    Rahul: The solution assumes that all leaves are known. Application use will be defined elsewhere.
    Yakov: The requirement document should state that some issues are outside the scope of the requirment document upfront. This needs to made very clear.
    Seisho: Will update the document according to the discussion of the scope of the document.

    Extensions to RSVP-TE for Point to Multipoint TE LSPs
    Dimtri, Rahul, Seisho

    The extensions to RSVP-TE for traffic engineered p2mp LSPs has progressed since the meeting in San Diego and a merged solutions document has been created. This document will be published as a working groupd ID after this meeting.
    The state management issue has been solved by means of <sub-group orig ID, sub-group ID>.
    Outstanding issues are:
    a) style usage
    b) p2mp sender_template obj and filter_spec obj encoding specifics
    c) review re-merge/cross-over conditions
    d) re-optimization
    e) sub-ero compression re-organisation
    f) stitching mechanism detail
    Next steps: revision -01 will be submitted after meeting as wg i-d; for revision -02 the organization of the document will be reviewed and a terminology section included.
    Slides: www.tla-group.com/~mpls/p2mp-solution.ppt

    5. MPLS OAM (20)
    Tom Nadeau and Dave Allan

    Tom: The first version of the document wer publsihed for the San Diego meeting and accepted as a working droup document. Will be published after this meeting.
    The document provides an overview of the FCAPS functionality and the required data plane tools.
    Authors asks for working group input.
    Slides: www.tla-group.com/~mpls/oam-frmwrk.ppt

    6. P2MP LSP Ping (10 min)
    Detecting Data Plane Failures in Point-to-Multipoint
    MPLS TrafficEngineering - Extensions to LSP Ping
    Adrian Farrel

    This document extends the techniques described in [LSP-PING] in order that they may be applied to P2MP MPLS TE LSPs. This document stresses the reuse of existing LSP Ping mechanisms as such reuse simplifies operations of the network.
    Since Traffic Engineered P2MP LSPs are at least as vulnerable to data plane failures a mechanism to verufy livesness of the data plane is needed. The P2MP tree brings new requirements for verifying data plane liveness. An obvious candidate to be used to create a tool for this is "LSP ping". The draft does not change the LSP ping as it exist, but describes extension to the LSP ping techniques so that they may be applied to P2MP MPLS TE LSPs
    Several issues needs to be discussed and questions need to be answered, e.g.:
    - is this the right approach, what are alternatives?
    - how to handle scaling
    - additional requirements?
    - what should happen to this draft?
    There is no consensus yet on this approach, we'll discuss on the mailing list until next meeting to see if we can make it a working group document.
    Slides: http://www.tla-group.com/~mpls/p2mp-lsp-ping.ppt

    7. LDP/IGP Synchronization (10 min)
    Markus Jork
    In networks depending on edge-to-edge establishment of MPLS forwarding paths via LDP, blackholing of traffic can occur in situations where the IGP is operational on a link and thus the link is used for IP forwarding but LDP is not operational on that link for whatever reason. This document describes a mechanism to avoid traffic loss due to this condition without introducing any protocol changes. This means that along the IP shortest path from one PE router to the other, all the links need to have operational LDP sessions and the necessary label binding must have been exchanged over those sessions.
    Reasons for the a missing LDP session could e.g. be a configuration error.
    The draft need to cover interaction with TE tunnels better and it need clarify that it is applicable to targeted LDP. The discussions focused on sorting out the concepts and the scope of the docuemnt. The differences between IGP and LDP convergence were discussed.
    It was concluded that we need to discuss both content and the purpose of this document if we are to accept it as a working group document.
    Slides: www.tla-group.com/~mpls/ldp-igp-sync.ppt

    8. Encapsulation of MPLS over (10 min)
    Layer 2 Tunneling Protocol Version 3
    Mark Townsley
    The Layer 2 Tunneling Protocol, Version 3, (L2TPv3) defines a protocol for tunneling a variety of payload types over IP networks.
    This document defines how to carry an MPLS label or label stack and its payload over L2TPv3.

    Yakov Rekhter: there is no reason to accept this as a WG document,
    - because we have enogh methods to transport MPLS over an IP core
    Eric Rosen: This is really a no brainer - there is nothing specific here to do this and if this is just to make people being interested in the topic I don't see the reason to prefer one method or the other.
    Peter Lothberg: Speaking for isp using l2tp. Useful to add mpls into it as its just another l2.
    Jeff Young: Support in making this a standard of this to interoperate.
    Loa: Rename the draft-townsley-mpls-l2tpv3 to indicate it is intended to be mpls work item, take the discussion on the mailing list and come back with a resolution for the next meeting.
    Slides: www.tla-group.com/~mpls/mpls-over-l2tpv3.ppt

    9. Meeting closes


    Issues with Link Bundling Draft
    Liaison from MPLS & FR Alliance regarding LDP Host Address FEC
    RFC 3036 FECs
    Requirements for Point to Multipoint Traffic Engineered MPLS LSPs
    Extensions to G/RSVP-TE for Point to Multipoint TE LSPs
    A Framework for MPLS Operations and Management (OAM)
    Detecting P2MP Data Plane Failures
    LDP IGP Synchronization
    MPLS over L2TPv3 Encapsulation
    Progressing LDP to draft-standard status