Last Modified: 2004-02-02
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
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 |
RFC | Status | Title |
---|---|---|
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) |
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 referenced. 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 ------------------------------------- <draft-ietf-mpls-rsvpte-attributes-02.txt> 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 ------------------------------------------------------- <draft-minei-mpls-ldp-planned-restart-00.txt> 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 RFC. 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 configuration. 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 Yasukawa ---------------------------------------- -------------------------------------- <draft-ietf-mpls-p2mp-requirement-01.txt> 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 ---------------------------------------- --------------------------- <draft-yasukawa-mpls-rsvp-p2mp-04.txt> 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 network. 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 requirements. Issues: 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 preentation. Slides: p2mp_solution_040301.ppt 7. Establishing Point to Multipoint MPLS TE LSPs - Rahul Aggarwal ---------------------------------------- ------------------------- <draft-raggarwa-mpls-p2mp-te-02.txt> 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 blocks. 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 binding. 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 ------------------------------------------------------ <draft-shen-nhop-fastreroute-00.txt> 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 IP. 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 -------------------------------------------------- <draft-shen-mpls-ldp-nnhop-label-00.txt> 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 ---------------------------------------- --------------------- <draft-farrel-mpls-preemption-00.txt> 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 pre-emption, - 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. Issues: Need to clarify GMPLS - especially for soft preemption. Question as to whether existing soft preemption draft will now be redundant. Not going to address rights and wrongs of implementations. Plan: 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 WG. Slides: soft-preemption.ppt 11. Meeting closed |