2.5.6 Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of the 58th IETF Meeting in Minneapolis, Minnesota USA. It may now be out-of-date.

Last Modified: 2003-10-22

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 document(s) specifying protocol extensions, enhancements and mechanisms for setup of P2MP TE LSPs
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 a document defining the scope, requirements, and issues to resolve for setup of P2MP TE LSPs (MPLS and GMPLS)
  • - draft-ietf-mpls-ldp-mib-13.txt
  • - draft-ietf-mpls-te-mib-13.txt
  • - draft-ietf-mpls-lsr-mib-13.txt
  • - draft-ietf-mpls-te-feed-06.txt
  • - draft-ietf-mpls-lsp-hierarchy-08.txt
  • - draft-ietf-mpls-ftn-mib-09.txt
  • - draft-ietf-mpls-lsp-query-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-02.txt
  • - draft-ietf-mpls-rsvp-lsp-fastreroute-03.txt
  • - draft-ietf-mpls-lsp-ping-04.txt
  • - draft-ietf-mpls-lc-if-mib-00.txt
  • - draft-ietf-mpls-ldp-mtu-extensions-02.txt
  • - draft-ietf-mpls-in-ip-or-gre-03.txt
  • - draft-ietf-mpls-nodeid-subobject-01.txt
  • - draft-ietf-mpls-oam-requirements-02.txt
  • - draft-ietf-mpls-soft-preemption-01.txt
  • - draft-ietf-mpls-telink-mib-04.txt
  • - draft-ietf-mpls-lsr-self-test-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)

    Current Meeting Report

    MPLS Working Group
     WG Chairs:  George Swallow <swallow@cisco.com>,    Loa Andersson 
     Tom Nadeau took the minutes - Thanks Tom!   NOTE: [NNG] means that the 
    speakers name was not given at the mike.
    1.  Agenda Bashing/Update      
       Loa  -- MPLS has been rechartered within routing area.  MIB 
    modules/management overview have been sent to the IESG.
    2.  Encoding of Attributes for LSP Establishment Using RSVP-TE        
    <draft-farrel-mpls-rsvpte-attributes-00.txt>       Adrian Farrel
       Adrian -- Asked to make this a WG document?   George -- Room 
    support? (no hands) non-support (no hands) Continue discussion on the 
    3.  RSVP Graceful Restart Extension        
          Reshad Rahman
       Adrian Farrel -- Should this be in CCAMP?
       George -- They didn't ask me, but I suggest it goes in CCAMP. The only 
    rationale for MPLS might be that there is slightly lower work load here.
       Rahul -- Why isn't it enough to just recover. Why do we need this?
       Reshad -- If a node preforms ERO expansion prior to the restart, it may 
    not have sufficient information to construct the some ERO expansion.
       After a bit of discussion and polling the room, it would appear that   
    there is a fair amount of interest and that the work belongs in   CCAMP.
    4.  TTL-Based Security Option for LDP Hello Message        
         Albert Tian
       Alex Zinin -- You cannot negotiate security messages with an 
    insecure mechanism. There are DOS attack potentials.
       Albert -- The multicast addresses are harder to spoof.
       Alex -- I understand how the TTL hack works. But the fact that you are 
    trying to negotiate the usage using insecure messages is the problem.
       Albert -- "secure" is relative here.
       Alex -- Take to list.
       George -- are there any SPs that feel there is a need for this? 
    5.  LDP signaled LSPs for external prefixes        
          Ina Minei
       Eric -- I see no advantage to do this. Dangerous to distribute 
    routing information w/ non-routing protocols.  
       Yakov -- We have seen this movie before. There are no issues with 
    overloading LDP.
       Luca -- You are adding more state to your core routers to support this. 
    Why not use iBGP to do this?
       George -- Asked a question about label withdraw times in the event of a 
    failue.  Won't that slow convergence?  
       Alex -- If you have more than one originator injecting more than one 
    FEC, how do you break the tie?  
       Ina  -- You consider this and do something smarter at the tail end.        
       Alex -- External prefixes are injected into LDP. Have you compared the 
    overhead of this versus that of using IGPs?  
       Ina  -- don't see why this is an issue.  
       Alex -- This assumes external prefixes are injected into an IGP.  How 
    much state will routers have to maintain versus in the normal ibgp case.  
       Ina  -- If you are trying to compare an IGP to an LDP solution.  
       Luca -- Clarification. In an IBGP you don't have to run this 
    anywhere but in the edge routers (BGP free core).  There is less state in 
    the core. Using your solution you add more state to the core.  
       Ina  -- but it has more danger of misconfiguring your 
       Vach -- Best for Luca to resubmit his BGP short-cuts draft which would 
    fix this problem.  If I wanted such a solution I would rather do this than 
    the current one.  
       George -- Continue this on the list.        
     6.  Requirements for Point to Multipoint extension to RSVP-TE        
          Seisho Yasukawa
       Loa  -- Comments?
       Yiqun Cai -- ID is taqlking about requirement of P2MP lsps (TE), but 
    also describes an extension to RSVP-TE. This seems that the WG has 
    already decided to extend RSVP_TE. The better way would be to split them, 
    and address both requirements separately. Second, this talks about mcast 
    deployment in a service provider environment. I think this needs to be 
    presented in the MWG and discussed.
       Dave Meyer -- I had discussed this with George, but ran out of agenda 
    time. This should be discussedin MWG.
       James Miles -- Dmitri's earlier point talked about whether this was a 
    requirements document? Are we going to extend this? What is the scope of the 
    document? Seems that the next step is that providers need to run RSVP-Te to 
    the edge.
       Loa  -- When we wrote this it was to describe how p2mp TE LSPs 
       Loa  -- Could I see the support in the room to make this a WG 
    document. A fiar number.  Oppositoion. A few.  Need to confirm on the list 
    that there is good support w/ a few opposing.  People that were opposed 
    should speak at the Mike.
       Toerless -- I don't understand how this framework is supposed to work.   
    The document seems to jump over one architectural element (p2mp).  
       Yiqun -- The document tries to address mcast vpn and other items. We 
    need to discuss whether or not this best solves this problem usiung p2mp 
    RSVP-TE LSPs or something else.
       George -- I would tend to agree with that last comment.
    7.  Extended RSVP-TE for Point-to-Multipoint LSP Tunnels        
         Seisho Yasukawa/Allan Killberg
       [Update on state of draft]
       George -- Can't do anything on this on the next draft until we get        
    the requirments accepted.
    8.  IP Multicast With PIM-SM Over a MPLS Traffic Engineered Core        
           Rahul Aggarawal
       George -- When the RPE gets an indication of the interface, how does  
    that count?
       Rahul -- The SPE sends a joint ack message.
       George -- what goes into it?
       Rahul -- it contains a set of messages including the PTMP ids.
       George --- you are keeping labels at the last hop to keep context?
       Rahul -- this is just the session object.
       George -- If you have more than one tunnel, you would have to turn PHP 
       [NNG] -- Are the labels interface or global space?
       Rahul -- doesn't matter. 
       [NNG]   -- The way you use labels to distinguish label states.  Does 
    this support PIMSM, but you did not describe how these are forwarded.
       Rahul -- Sure, I can add that.
       George -- Please show up at 1 to continue discussion (PIM?)
    9.  Requirements for multicast service using a group label over MPLS        
         Min Suk Sung
       George -- Discussion on the draft...       Andy Malis -- When we 
    sections 4.5, this is not a requirements draft; it contains protocol 
    specifications.  There are requirements in section 4.3, but these assume a 
    mechanism (group label) and just reverse engineer that.  Really doesn't 
    talk about requirements.  
       George -- Other point that Loa made is that originally when we 
    started MPLS, we made an architectural decision to not have globally 
    unique labels. We would need to change this to accomodate this draft.
       Min  -- We tried to consider where is the relevant location of the 
       George -- Continue on list.
    10. MPLS over Layer 2 Tunneling Protocol (Version 3)        
          Mark Townsley
       Yakov -- One significant subtle distinction between GRE and L2TP. 
    Neither IP or GRE require signaling, but L2TP requires signaling. Don't 
    combine into two documents.
       Loa  -- I rule that out betcause we have IP/GRE document in WG last 
       Yakov -- To have a multi-vendor interop implementation requires  
    specification of both signaling and protocol in standards track at same 
       Mark -- Both are specified in two documents in IDR.
       Yakov -- They are not WG documents. If you want to provide BGP as a 
    signaling mechanism for L2TPvp3.
       Mark -- There is a section on this. Please read the document.
       Yakov -- In this case, 2547 is just an example of p2mp signaling (so is 
    VPLS). When you do this, so should signaling be done in BGP?
       Mark -- Depends on what your VPLS network is using for signling. In 
    general when you want to reach a PE over IP and you say "this is the IP 
    addr of my PE" and you use BGP or wahthave you to signal this, even w/o 
    L2TPv3 encap, when you advertise this normally -- you imply use this PE IP 
    address w/ this protocol ID.  I am also saying to also use the cookie in 
    addition to these things.
       Yakov -- Need another document ot explain that BGP can be used for 
    signaling.  On your last point: talk about security that L2TP 
    provides.  Before this is a WG document, the security team should review 
    this to make sure that the statements are ok.
       Eric -- I would like a very small document that explained the encap. Put 
    cookie stuff into security considerations.  I disagree w/ Yakov's 
    statement. The cookie value is different depending on how it is 
    signaled. We don't want to start an L2TP signaling paradigm.
       Yakov -- this document doesn't have to contain signaling. doesn't make 
    sense to progress encap w/ signaling document.
       Eric -- Signaling is application dependent.
       George -- Get a sense of the room, not for this draft, but for 
    MPLS/L2TP as an encap type. How many think we need to do this.  We have 
    several opposed and several in favor. Continue on list.
    11. A Framework for MPLS Data Plane OAM
          Don Fedyk
      Eric Rosen -- This is taking MPLS and trying to make it ATM.  I 
    recommend starting over.
       Tom  -- I agree w/ Eric.   Lets start over.
       George -- I don't think that we need to throw away everything, but we 
    should be focusing on describing a framework within which we can define 
    tools that meet operational requirements.
       Loa  -- This is why I wanted Dave/Tom to do the edits.
       Jerry -- I think the document covers the entire solution space.
       Craig White -- I would like to underscore what the chairs just said. I am 
    not particularly interested in where the technology comes from, but more of 
    what does it do for me. I feel like we are going to end up with hacks to 
    address requirements, but lets document this somewhere.
       Loa will work to form a design team to create a combined draft   
    between this and the nadeau draft.
    12. Detecting MPLS Data Plane Failures        
          Kireeti Kompella / George Swallow
       Kireeti -- Reviewed latest changes.  Draft is nearly complete.  A new 
    version will be posted resolving the last few issues. Hope to go to last 
    call prior to Seoul
    13. LSR Self Test        
         George Swallow
       George -- The draft is mostly complete.  A few issues are hanging 
    contigent on the lsp ping draft.  More discussion on list.  
     14. BFD For MPLS LSPs        
         Rahul Aggarawal
       Rahul -- Since BFD is light weight, you can turn on 
    fault-detection on a larger number of LSPs.  Subsecond fault detection can be 
    possible (i.e.: bypass LSPs).
       Alex -- Did you think through the convergence issues w/ subsecond 
    detection and IGP level second-level detection? How are you going to react to 
    the failures found by BFD. 
      Rahul -- The answer is the same as with LSP ping.  The operator can take 
    the same action.
      Alex -- We need to think throught the case where IGPs are notified.
      Yakov -- One possible scenario. When bypass tunnels go away, you can use 
    the other one.
      [NNG] -- Since you are doing this over multiple hops. How do you handle 
    congestion in the network and variable delays?
      George -- BFD allows you to adjust your timers.  Lets continue on list.
    15. A Supplementary History Module for the MPLS LDP-MIB     
        Wai Sum Lai
      Tom  -- There have been scalability and other technical concerns raised on 
    the list. I suggest that we hear from other SPs.
      Waisum -- Can you give an example?
      Tom  -- PE with 800 directed LDP sessions. That seems to be a lot of 
    memory/processing to keep track of this, especially over a long period of 
      Waisum -- But we are only adding 5 counters.
      George -- Well, there is more to it than just 5 counters. You are 
    asking us to hold informations forever on expired sessions. The long term 
    implications for memory and CPU need to be considered.
      Craig White -- I would rather count packets/bytes than fwd packets. 
    However, I don't want to eat all of the memory to do this. I don't want to 
    have fewer VRFs on a PE to keep track of this stuff, for example.
      Bert -- If you want to look at the scalability of keeping the 
    information needs to be seriously examined.
      George -- The sense of the room is that something along these lines is 
    useful, but we need to refine the requirements on the list.
    16. Hybrid data forwarding for Economy Class Services in MPLS   
          Hyeon Park 
      George - We're out of time - discuss on the list.


    LDP signaled LSPs for external prefixes
    Encoding of Attributes for Multiprotocol Label
    LDP signaled LSPs for external prefixes