2.7.4 Multiprotocol Label Switching (mpls)

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

Last Modified: 2003-01-27

George Swallow <swallow@cisco.com>
Loa Andersson <loa.andersson@utfors.se>
Sub-IP Area Director(s):
Scott Bradner <sob@harvard.edu>
Bert Wijnen <bwijnen@lucent.com>
Sub-IP Area Advisor:
Scott Bradner <sob@harvard.edu>
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 has been responsible for standardizing a base technology for using label switching and for the implementation of label-switched paths over various 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, encapsulations and multicast considerations.

The initial goals of the working group have been largely completed. In particular, it has produced a number of RFCs (see list below) that define the base Label Distribution Protocol (LDP), the basic MPLS architecture and encapsulations, and definitions for how MPLS runs over ATM and Frame Relay links.

The Working Group chairs tracking of the working group documents can be viewed at http://urax.utfors.net/~loa/MPLS_WG_Drafts.htm

The current goals of the working group are:

1. Complete outstanding items from the original MPLS effort:


(6/12) Applicability Statement for Extensions to RSVP for LSP-Tunnels (8/08) Applicability Statement for CR-LDP (6/12) LDP State Machine


(10/19/99) MPLS Loop Prevention Mechanism

Standards Track:

(8/08) Constraint-Based LSP Setup using LDP (2/07) Carrying Label Information in BGP-4 (8/29) Extensions to RSVP for LSP Tunnels (8/29) MPLS Support of Differentiated Services (6/27) LSP Modification Using CR-LDP (9/01) Definitions of Managed Objects for LDP (8/29) MPLS Label Switch Router Management Information Base

2. Advance the Proposed Standards developed by the MPLS WG to Draft Standard. This includes the LDP, CR-LDP, and RSVP-TE signaling specifications as well as the encapsulations.

3. Specify appropriate extensions to LDP and RSVP for authentication of LSP originators.

4. Complete work on the MPLS-TE MIB.

5. Specify improved fault tolerance mechanisms for LDP

6. Specify MPLS-specific recovery mechanisms to allow one label-switched path to be used as backup for a set of other label-switched paths, including cases which permit local repair. What constitutes the necessary set of MPLS-specific recovery mechanism should be ascertained through cooperation with the CCAMP and TE working groups.

7. Document additional MPLS encapsulations to allow the operation of label-switched paths over additional lower-layer technologies, such as time-division (e.g. SONET ADMs), wavelength (optical lambdas) and spatial switching (e.g. incoming fiber to outgoing fiber).

8. Complete work in progress for specifying the framework for IP multicast over label switched paths.

Goals and Milestones:
Done  Submit documents from original MPLS effort to IESG
JAN 01  Shepherd completed MPLS specifications through IESG review and RFC editor processing
FEB 01  MPLS-TE MIB ready for advancement to Proposed Standard
MAR 01  Framework for IP multicast over label-switched paths ready for advancement.
JUN 01  LDP fault tolerance specification ready for advancement to Proposed Standard.
AUG 01  Specification for MPLS-specific recovery ready for advancement.
NOV 01  Base MPLS Proposed Standard RFCs ready for advancement to Draft Standard.
DEC 01  LDP end-to-end LSP authentication ready for advancement to Proposed Standard.
  • - draft-ietf-mpls-ldp-mib-09.txt
  • - draft-ietf-mpls-te-mib-09.txt
  • - draft-ietf-mpls-lsr-mib-09.txt
  • - draft-ietf-mpls-te-feed-05.txt
  • - draft-ietf-mpls-lsp-hierarchy-08.txt
  • - draft-ietf-mpls-ftn-mib-05.txt
  • - draft-ietf-mpls-lsp-query-06.txt
  • - draft-ietf-mpls-crldp-unnum-10.txt
  • - draft-ietf-mpls-tc-mib-05.txt
  • - draft-ietf-mpls-bundle-04.txt
  • - draft-ietf-mpls-bundle-mib-04.txt
  • - draft-ietf-mpls-mgmt-overview-03.txt
  • - draft-ietf-mpls-bgp-mpls-restart-02.txt
  • - draft-ietf-mpls-rsvp-lsp-fastreroute-02.txt
  • - draft-ietf-mpls-lsp-ping-02.txt
  • - draft-ietf-mpls-fastreroute-mib-01.txt
  • - draft-ietf-mpls-ldp-mtu-extensions-00.txt
  • - draft-ietf-mpls-in-ip-or-gre-00.txt
  • - draft-ietf-mpls-ldp-restart-applic-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
    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)

    Current Meeting Report

    MPLS Working Group
    WG Chairs: George Swallow <swallow@cisco.com>, Loa Andersson 
    George chaired the meeting.  Andy Malis took the minutes.
    (Thanks Andy!)
    1.  Overview of ISOCORE Interoperability Tests
    Rajiv Papneja, rpapneja@isocore.com
    Rajiv presented the results of the March MPLS interoperability testing at 
    ISOCORE.  They tested RSVP-TE with FRR, MPLS LDP signaling, and MPLS as a 
    transport for L2 VPNs, specifically including VPLS.
    Their service provider sponsors provide the list of functionality to be 
    tested as input to the test plans.  They had ten vendors 
    participating in the testing, and they built a network with both core LSRs 
    and edge LERs.  They used ISIS-TE as the IGP for RSVP-TE.
    More than 30 interoperability issues were discovered in 7 days of 
    testing.  More than 15 fast reroute scenarios were tested, and they 
    achieved <40 ms switch-over in the scenarios.
    The found a number of issues in the testing.  Some of the highlights of 
    these issues were:
    * They found issues with reverse compatibility in FRR for the nodes that 
    don't support it.  There was an issue with ISIS-TE in that not all 
    vendors had implemented the latest drafts, so they recommend that all 
    vendors update their code.
    * They also suggest that all vendors support ERO in the RSVP-TE Path 
    message (they found that some did not).
    * In the LDP HELLO message, they found incompatible values in the 
    transport address TLV, and an ambiguity in the definition of the LDP TLV 
    length definition.  They recommended on how these problems need to be 
    corrected in RFC 3036.
    * There were also ambiguities in the value of the LSR-ID over targeted and 
    basic discovery.  This also needs to be fixed in RFC 3036.
    * Some vendors were advertising per-interface label space for targeted LDP 
    sessions when they should have been using per-platform labels due to an 
    ambiguity in the Martini signaling draft.
    * Backward compatibility issues between the different revisions of the VPLS 
    * An ambiguity in the Address List TLV in Address Withdraw messages.
    Their upcoming testing will be GMPLS interoperability in April, MPLS 
    Leading Edge testing in July and August, and the 4th MPLS 2003 Demo 
    following the MPLS 2003 conference.
    2.  TE-related drafts
    Reoptimization of explicit loosely routed MPLS TE paths
    Jean-Philippe Vasseur, jpv@cisco.com
    This draft proposes a mechanism for the reoptimization of loosely routed 
    explicit paths. A loosely routed explicit path is as a path specified as a 
    combination of strict and loose hop(s) that contains at least one loose hop 
    and zero or more strict hop(s). The path calculation (ERO expansion) to 
    reach a loose hop is made on the previous hop defined in the TE LSP path. 
    This draft proposes a mechanism that allows:
    - the TE LSP head-end LSR to trigger a reoptimization on every loose hops 
    along the path,
    - an LSR to signal to the TE LSP head-end that a better path exists to 
    reach a loose than the path in use. A better path is defined as a path with a 
    lower cost, where the cost is defined by the metric used to compute the 
    This primarily applies to inter-area TE LSPs and inter-AS TE LSPs when the 
    path is defined as a list of loose hops (generally the loose hops are the 
    area border routers) but the mechanism is also applicable to any loosely 
    routed explicit paths within a single routing domain.
    If and only if at least a better path exists in an area or AS, 
    reoptimization is triggered.
    The reoptimization can be event-driven or timer-driven, and triggered from 
    both the head-end and from a mid-point LSR.
    Comments have been received from service providers acknowledging their 
    interest in deploying this technology.
    Rahul Aggarwal suggested an improvement in one of the mechanisms in the 
    draft to simply the operation in some situations.  JP agreed with the 
    Philip Matthews asked a question about the use of PathErr 
    notification, since they can be lost in the network.  JP explained how the 
    draft can compensate for such losses.
    JP proposed that this become a working group draft. George said that the 
    IETF has to decide how it's going to treat the entire set of 
    inter-area and inter-AS TE drafts before this draft can be accepted.  This 
    topic is going to be discussed later in the week at the sub-IP 
    Directorate meeting.  Plus, decisions to accept drafts are always made on 
    the email list.  There may also be working group charter changes 
    required before taking this on.  A hum 'vote' showed some support for 
    making this a WG draft in the room.
    Definition of an RRO node-id subobject
    Jean-Philippe Vasseur, jpv@cisco.com
    In the context of MPLS TE fast reroute, the merge point (MP) address is 
    required at the point of local repair in order to select a backup tunnel 
    intersecting a protected TE LSP on a downstream LSR.  However, existing 
    protocol mechanisms are not sufficient to find the MP address in 
    multi-area or multi-domain routing networks. As a result, the current MPLS 
    Fast Reroute mechanism cannot be used to protect inter-area or inter-AS TE 
    LSPs from a failure of an area border router or Autonomous System border 
    router. This document specifies the use of existing RRO IPv4 and IPv6 
    subobjects (with a new flag defined) to define the node-id subobject in 
    order to resolve this issue.
    Use of MPLS TE FRR bypass has been identified as a key requirement by 
    service providers.  This draft proposes a simple flag definition to allow 
    backup tunnel selection of inter-area/inter-AS TE LSPs.
    Again, JP asked this draft be adopted as a WG draft.  George said that this 
    is a very simple point solution, and very straightforward, and he's in 
    favor of adopting it.  There was widespread support in the room.  This will 
    be ratified on the list.
    MPLS Traffic Engineering Fast reroute: bypass tunnel path 
    computation for bandwidth protection
    Jean-Louis Le Roux, 
    This draft proposes a model called the "Facility based computation model" 
    for computing bypass tunnels paths in the context of the MPLS TE fast 
    reroute, while allowing bandwidth sharing between bypass tunnels 
    protecting independent resources. Both a centralized and a 
    distributed path computation scenarios are covered. The required 
    signaling extensions are also discussed in the draft.
    Jean-Louis described how the model can efficiently perform the path 
    He showed how the draft fits into section 6 of the current MPLS WG 
    charter, and presented the history of the drafts that were combined in 
    order to produce this draft and the changes from -01 to -02.  The major 
    change was the introduction of the SDLG concept - Shared SRLG (shared risk 
    link group) Dependency Link Groups.
    Conclusion: FRR is now largely implemented and deployed.  BW 
    protection is a key requirement to protect sensitive traffic on 
    non-over-provisioned networks.  The facility-based computation model seems 
    the most efficient approach for bypass tunnel placement.
    Vishal Sharma said that he had suggested some improvements to the draft 
    that removes the need for protocol extensions.  Jean-Louis said that those 
    comments applied to version 1 of the draft, and not to version 2.
    Jean-Louis asked that this be made a WG draft.  Most of the room had not yet 
    read it, so George was hesitant to make a determination now.  He said it 
    should be discussed further on the list.
    MPLS Traffic Engineering Soft preemption
    Matthew Meyer, mrm@gblx.net
    This draft discusses MPLS TE soft preemption, a set of protocol 
    modifications extending the current concept of preemption with the goal of 
    reducing or eliminating traffic disruption of preempted TE LSPs.  Under 
    present RSVP-TE signaling methods, LSPs are immediately displaced upon 
    preemption.  The introduction of a new preemption pending flag helps to 
    more gracefully mitigate the re-route process of displaced LSPs.  For the 
    brief period soft preemption is activated, reservations (though not 
    necessarily traffic levels) are in effect overbooked until the LSP can be 
    The problem to be solved is that preemption can be unnecessarily 
    disruptive to the network, especially in conjunction with Diffserv, and 
    preemption may occur even when there is excess capacity in the network.  
    There is a concrete and operational issue that needs to be resolved.  This 
    draft proposes RSVP-TE mechanisms that can be used to treat the 
    lower-priority flows better.
    George, as one of the authors of RFC 3209, said that there is a hole in 
    that RFC and this RFC plugs it, and he supports this as a working group 
    Rahul said that he's also supportive of this, and he proposed an 
    improvement to the policing function. Matthew agreed.
    Kireeti Kompella said that we need to discuss RRO vs. PathErr on the list.  
    JP said that the first drat used PathErr, but it was changed to RRO in the 
    second draft based on implementation experience.
    Adrian Farrel asked that the authors not come up with protocol 
    solutions to respond to nonstandard deployed versions of the 
    specification.  Matthew and George both agreed.  The room agreed that this be 
    made a WG draft, and it will be ratified on the list.
    3.  Graceful Restart
    LDP DoD Graceful Restart
    Bob Thomas, rhthomas@cisco.com
    LDP graceful restart is a mechanism that helps reduce the negative 
    effects on MPLS traffic caused by the restart of an LSR's control plane, 
    specifically by the restart of its LDP component on LSRs that are 
    capable of preserving MPLS forwarding state across the restart. RFC 3478 
    defines procedures for LDP graceful restart for downstream 
    unsolicited label distribution but leaves procedures for downstream on 
    demand label distribution a subject for future study.  This document 
    defines graceful restart procedures for downstream on demand label 
    Bob gave an overview of how his draft builds upon the mechanisms already in 
    RFC 3478, and specifies changes to the Label Request and Label Abort 
    messages.  It also makes changes to the behavior of a neighbor router 
    immediately following an LDP outage.
    Bob asked that the WG accept the completion of LDP restart as a work item, 
    and this draft as the way to address the issue.
    Rahul said that he was one of the authors on RFC 3478, and at the time that 
    document was done, there was no requirement for DoD.  He asked what the 
    requirement is for this draft.  Bob said that the motivation is MPLS over 
    ATM, which uses DoD.  There are MPLS over ATM deployments that could take 
    advantage of this.  Rahul also had some technical suggestions that he will 
    take offline with Bob.
    There was widespread support for making this a WG document.  It will be 
    ratified on the list.
    4.  OAM
    OAM Requirements for MPLS Networks
    Tom Nadeau, tnadeau@cisco.com
    As transport of diverse traffic types such as voice, frame relay, and ATM 
    over MPLS become more common, the ability to detect, handle and 
    diagnose control and data plane defects becomes critical. Detection and 
    specification of how to handle the defects is important, because such 
    defects may not only affect the fundamental operation of an MPLS 
    network, but also because they may impact SLA commitments for end 
    customers of that network.
    This draft describes requirements for user and data plane MPLS 
    operations and management. These requirements have been gathered from 
    network operators who have extensive experience deploying MPLS 
    networks, and some of these requirements have appeared in other 
    documents, including Y.1710.  This draft specifies OAM requirements for 
    MPLS, as well as for applications of MPLS such as pseudowire voice and VPN 
    At the last meeting, the authors were directed to combine their 
    separate drafts into a single OAM requirements draft.  This draft is the 
    result of that process.  Tom would like to see it accepted as a WG 
    Dave Allan, the co-author, said that other Standards Develop 
    Organizations would find this document useful as a stake in the ground for 
    IETF MPLS OAM requirements.  The group showed support.
    Y.1711 and LSP-PING
    Dave Allan, dallan@nortelnetworks.com
    Y.1711 and LSP-PING are products of ITU-T SG13/Q3 and the IETF MPLS WG 
    respectively. Each is reflective of the design philosophies of the 
    communities of their origin.
    The purpose of this draft is to compare and contrast design elements of the 
    two approaches. The conclusion drawn is that the approaches are 
    complementary and comprehensive instrumentation of MPLS is ultimately 
    possible using both.
    Dave gave an overview of Y.1711.  In Nov. 2002 it was recommended for 
    publication.  It focuses on point-to-point LSPs, without penultimate hop pop 
    There has been ongoing new work in order to support 
    multipoint-to-point LDP networks using PHP.  It uses a "bloom filter" to 
    encode the FEC information as a 128-bit string.  The initial focus is 
    mis-branching detection, and current proposals relate to LDP 
    He compared Y.1711 to LSP-PING, which is based on the 
    ping/traceroute paradigm.  It has good diagnostic capabilities, but is 
    difficult to scale for proactive detection.
    Dave's conclusion is that the two protocols are complementary in 
    philosophy and design.  Y.1711 has utility as a detection tool, and then you 
    use LSP-PING and traceroute from a CLI to find out what's going wrong.
    Dave concluded his talk by inviting people to read his Y.1711 FEC-CV 
    tutorial, available at
    Kireeti said that this is a good comparison of the two approaches, and the 
    fact they are not competing, but are complementary.  He would like to help 
    with some of the wording for the LSP-PING part.  He also had some 
    comments on the definition of "transaction" in the draft - he would like to 
    see that improved.  He also pointed out that LSP-PING can be run 
    periodically to use it as a detection mechanism.  The CLI part is mostly for 
    traceroute, rather than ping.  He compared LSP-PING to the Frame Relay 
    local management interface, which polls for status every 10 seconds.  The 
    difference between Y.1711 and running LSP-PING periodically is that you are 
    notified of outages in seconds rather than milliseconds, but you are still 
    Tom Nadeau said that he things the scalability concerns with LSP-PING are 
    unnecessarily harsh in the document, and that the document is tilted more 
    towards Y.1711 than it should be.
    Shahram Davari said LSP-PING has become more complicated as the work on it 
    has progressed, and that it now neither simple nor efficient. This fact has 
    been recognized by the authors, and in fact an earlier text that 
    suggested LSP-PING is a simple and efficient protocol has been taken out of 
    the draft.
    Detecting MPLS Data Plane Liveness
    Kireeti Kompella, kireeti@juniper.net
    This document describes LSP-PING, which can be used to detect data plane 
    failures in MPLS Label Switched Paths.  There are two parts to the draft: 
    information carried in an MPLS "echo request" and "echo reply" for the 
    purposes of fault detection and isolation; and mechanisms for reliably 
    sending the echo reply.
    Kireeti discussed the recent changes in the draft.  Many 
    clarifications were added, ECMP support was added, and the router alert 
    option is a MUST in echo requests.
    There are still issues to be fixed, so there will be at least one more 
    revision.  The current text on the MPLS TTL is broken, and it will be 
    fixed.  Sections 5 and 11 will be removed.  The label stack in 
    downstream mapping with clarified.  Downstream mappings still need 
    clarification.  ECMP address selection needs to be expanded upon.  The 
    timestamp will be changed to NTP format.
    Next steps: New revision in the next couple of weeks, and reissue the WG 
    last call.
    Rahul said that there is a lot of value in LSP-PING in L3 VPNs.  Kireeti 
    said that just IP ping works fine for this application.  Rahul talked 
    about why LSP-PING is valuable in this situation.  George said that a good 
    place to discuss this issue is in the framework document (which doesn't 
    exist) or in the requirements document.  George is going to propose in the 
    sub-IP meeting that such a document be developed in this WG.
    Marco Carugi proposed that existing technologies should be examined to see 
    how it can be used in PPVPN troubleshooting.  George agreed.  Kireeti said 
    that Tom Nadeau is working on how to use LSP-PING primitives with other 
    protocols than MPLS, such as L2TPv3.  There was general agreement that we 
    need a document that discusses the total set of tools that can be used in 
    this context.
    5.  MIBs
    Multiprotocol Label Switching (MPLS) Traffic Engineering Management 
    Information Base for Fast Reroute
    Tom Nadeau
    This draft defines a MIB module with managed objects for MPLS fast 
    Tom reported that the current status is that we've gained a lot of 
    experience and the MIB has been updated based on that, and is almost ready 
    for working group last call.  The major changes were adding full support for 
    both Facility and One-to-One backup.  The conformance statement was 
    updated to require either, but there is a common section that is 
    mandatory.  There are two implementations, and a third one is on the way.  
    Tom is pretty confident that the MIB works and after the next revision will 
    be ready for working group last call.  Please send comments to the 
    mailing list.
    Multiprotocol Label Switching (MPLS) Label-Controlled ATM and 
    Frame-Relay Management Interface Definition
    Tom Nadeau
    This MIB module completes the picture for the base MPLS MIBs by 
    managing label-controlled Frame Relay and ATM MPLS interfaces (this 
    function was left out of the base MIBs).
    It's been updated based upon MIB review and comments on the list.  
    Implementations have started, and feedback is coming in on that as well.  He 
    said that this should be progressed as a separate document from the base 
    MIBs, and be accepted as a WG document.
    Very few people in the room have read the draft.  George asked for more 
    people to read it and comment.
    Multiprotocol Label Switching (MPLS) Management Overview
    Tom also gave an update on the Management Overview document.  The 
    authors agree that the document is ready to progress because it 
    reflects all pending updates to the MPLS MIBs, including the TE MIB.  
    There will be a quick re-spin and Tom would like it go to last call at that 
    George said that a last call will be issued shortly after the meeting.
    6.  Explicitly routed Multicast
    Requirements for Point-to-Multipoint capability extension
    Seisho Yasukawa, yasukawa.seisho@lab.ntt.co.jp
    This document presents a set of requirements for adding 
    Point-to-Multipoint (P2MP) traffic engineering to MPLS. It identifies the 
    functional and performance extensions required to realize MPLS-based 
    Content Distribution Networks. It also identifies functional 
    extensions required to implement CDN/VoIP/VPN service convergence 
    networks. These extensions can be used to provide high performance and 
    scalable broadband service network with MPLS.
    Yasukawa-san discussed the requirements in terms of market trends in the 
    explosive growth of broadband subscribers, especially in Japan.  Service 
    providers much create a new broadband service infrastructure to meet this 
    demand.  It must accommodate not only IP, but current voice traffic as 
    well.  Among applications for these services include VoIP, VPNs, and 
    content distribution, including IPTV, live istribution, video 
    conferencing, and VPN multicast.
    There are a number of technical challenges to this sort of a service 
    network.  A primary challenge is that current MPLS mechanisms are not 
    optimized for multipoint distribution due to its point-to-point nature.
    The requirements in the draft include the coexistence of P2P and P2MP LSP 
    tunnels, P2MP path computation in the IGPs, P2MP LSP management based on 
    tree-based RRO, QoS control mechanism (SE/FF) for P2MP LSPs, IPv4 and IPv6 
    support, interworking with IP multicast, and VPN multicast support.
    A number of possible broadband applications for this technology are 
    discussed in the draft.
    Conclusion: P2MP MPLS is attractive technology for next generation 
    broadband IP service convergence network.  He proposed defining a P2MP MPLS 
    signaling protocol extension based on conventional RSVP-TE.
    George said that this general topic is in the WG's overall charter, but 
    there needs to be a revision to the charter before this can become a 
    working group draft since there's no specific work task for this at this 
    Philip Matthew remarked that there should be cross-pollination with the 
    MBONE-TE folks, since that is where many of these requirements are being 
    Extended RSVP-TE for Point-to-Multipoint LSP Tunnels
    Alan Kullberg, akullber@netplane.com
    Point-to-multipoint technology will become increasingly important with the 
    dissemination of new, real-time applications, such as content delivery 
    services and video conferences, which require P2MP real-time 
    transmission capability with much more bandwidth and stricter QoS than 
    non-real-time applications.
    This draft defines protocol extensions to RSVP-TE in order to 
    establish, maintain, and teardown a P2MP LSP. These extensions allow 
    service providers to offer services that utilize P2P and P2MP LSPs in the 
    same service network.
    Alan talked about the changes in the draft from the first revision.  The 
    point is to extend RFCs 2205, which supports multicast but not TE, and 
    3209, which supports TE but not multicast, to support both multicast and TE.
    Alan asked for more feedback on the WG list, and he would like to make it a 
    WG draft.  Scott Bradner (SubIP Area Director) said that the IESG needs to 
    approve a charter change in order to add this as a new work item for the WG.  
    It's premature to ask the WG to make this a WG draft.
    7.  Header Compression
    George said by way of introduction that this set of drafts cannot be 
    accepted as MPLS working group items yet until after the Sub-IP 
    Directorate meeting later in the week, because these don't very clearly sit 
    in any particular working group or area at this time.  This work was first 
    presented in the Adelaide meeting three years ago, and its status has been 
    very much unclear since then.
    Requirements for End-to-End VoIP Header Compression
    Jerry Ash, gash@att.com
    VoIP typically uses the encapsulation voice/RTP/UDP/IP.  When MPLS labels 
    are added, this becomes voice/RTP/UDP/IP/MPLS.  For an MPLS VPN, the 
    packet header is at least 48 bytes, while the voice payload is 
    typically no more than 30 bytes. VoIP header compression can 
    significantly reduce the VoIP overhead through various compression 
    mechanisms.  This is important on access links where bandwidth is 
    scarce, and can be important on backbone facilities, especially where 
    costs are high (e.g., some global cross-sections).  This draft gives a 
    problem statement and requirements for end-to-end VoIP header 
    compression, possibly over MPLS.
    Jerry gave an overview of the list of requirements from the draft, from 
    providing efficient voice transport to robustness to packet loss and delay 
    minimization.  He discussed the background of the work over the last three 
    years, and then described the two proposed solution drafts, using cRTP (RFC 
    2508) and end-to-end header compression.
    End-to-End VoIP Header Compression Using cRTP
    This draft proposes to re-use the methods in cRTP to determine the header 
    compression context and to use the cRTP session context ID to route a 
    compressed packet between the ingress and egress routers.
    End-to-End VoIP over MPLS Header Compression
    This draft proposes to use RSVP extensions to signal the header 
    compression context and other control messages between the ingress and 
    egress LSR.  It provides two approaches to determining the header 
    compression context: a) re-use the methods in cRTP to determine the 
    context, and b) re-use the methods in George Swallow's and Lou Berger's 
    "simple" approach to determine the context.
    Scott is nervous about application-dependent solutions, and wanted 
    clarification on what "end-to-end" meant.  This means from voice gateway to 
    voice gateway, rather than true end station to end station.
    The main issue is finding the right home for this work - some people 
    believe that the MPLS WG is the right place, and the authors would like to 
    propose that this is the right place.
    Scott wanted to make sure that the authors were aware of the robust 
    header compression work ongoing in the transport area.  The answer is yes.  
    In fact, the primary author of that work (Steve Casner) also thinks this 
    work belongs in the MPLS WG.
    George and Scott agreed that this will be brought up in the Sub-IP 
    Directorate meeting.
    8.  Draft Status Update
    George Swallow
    New RFCs
    RFC 3443, TTL Processing in MPLS Networks (PS)
    RFC 3469, Framework for MPLS-based Recovery (INF)
    RFC 3477, Signaling Unnumbered Links in RSVP-TE (PS)
    RFC 3478, Graceful Restart Mechanism for LDP (PS)
    RFC 3479, Fault Tolerance for LDP and CR-LDP (PS)
    RFC 3480, Signaling Unnumbered Links in CR-LDP (PS)
    RFCs (On RFC Editor's Queue)
    LSP Hierarchy with Generalized MPLS TE (PS)
    George said this has been on the editor's queue for a long time.
    Scott said that it's waiting for normative references.
    Link Bundling in MPLS Traffic Engineering
    Including these two, there are now a total of 27 MPLS RFCs, so the WG has 
    been prolific.
    IESG Last Call
    MPLS LDP Query Message Description
    Fast Reroute Extensions to RSVP-TE for LSP Tunnels
    IESG Evaluation
    Improving Topology Data Base Accuracy with LSP Feedback
    This is on the IESG agenda for the next teleconference, in two weeks.
    Awaiting action on BGP Restart
    Graceful Restart Mechanism for BGP with MPLS
    Note: Last call in IDR working group - ends 11/29
    Yakov Rekhter said that this is implemented by several vendors and 
    interoperable.  It is on hold in IDR until BGP is published.
    Awaiting updates from Authors
    MTU Signaling Extensions for LDP
    George asked Kireeti for the status.  Kireeti said that further 
    clarifications are needed, but he's been unable to contact his 
    coauthor.  He promised an update in the next month.  The last call will 
    need to be redone.
    Multiprotocol Label Switching (MPLS) Traffic Engineering Management 
    Information Base
    Multiprotocol Label Switching (MPLS) FEC-To-NHLFE (FTN) Management 
    Information Base
    Bert Wijnen said that if we don't have the final versions of these 
    documents by the next IETF, they will all be put in the waste bin.  Tom is 
    planning to send updated revisions soon.
    Nearing completion
    Detecting Data Plane Liveliness in MPLS
    Other Drafts
    Encapsulating MPLS in IP or GRE
    This is ready for working group last call.  A last call will be issued 
    after the meeting.
    Applicability Statement for Restart Mechanisms for LDP
    Adrian said that he's waiting on what happens with the DoD restart 
    document, because it should be included in this document.  George might 
    rather get this out there first, since it will be an informational RFC. 
    There will be a WG last call after the meeting.
    9. Charter Discussion
    There will be a spin on the WG charter between now and the next 
    meeting.  If there are additions that people would like to be added to the 
    work plan, please put them on the list.
    George is currently leaning towards adding an OAM framework document, 
    multi-area/multi-AS TE, soft preemption, and the 
    point-to-multipoint TE 


    Misc. End-to-End Header Compression