Last Modified: 2004-07-09
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
| 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 |
| 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) |
| 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) |
|
Multiprotocol Label Switching Minutes - IETF60
---------------------------------------------- WG status (Loa & George) Mail list - has been moved to the ietf server. We've also changed maillist administrators at this time. Thanks to Eric Rosen for serving us so well and so long. And thanks to Eric Gray for taking this on. Four new RFCs (all MIBs). RFCs 3811 - 3815. Various drafts on the RFC editor's queue. No real problem per se. Draft editors - please take care with refs to other docs (esp docs you don't control and normative refs). Some refs that were said to be normative weren't etc. Refs are most common reason for getting stuck in the Q. MTU signalling doc got stuck because of over-ambitious author (added RFC editor's note himself). Need to verify that we got the RFC editor's note correctly. Author, chairs, and ADs will be meeting to sort out comments on MPLS over GRE. A respin needed on LSP ping. Other documents including LSR self-test depend on this. ATM/FR LC MIB doc is in MIB-doctor review. Ina Minei has taken on the task of getting LDP to draft standard. MPLS OAM Framework draft-an-mpls-oam-frmwk-00.txt Tom Nadeau and Dave Allen An OAM framework was added to charter a few meetings back. Tom and Dave had been active in that area so were asked to have a go. This is initial output. The aim is to keep the scope down and describe circumstances where data plane tools would facilitate addressing FCAPS issues. Since the draft is a framework, it is intended to be technology agnostic. Specific tools are not discussed. Each of the topics in FCAPS will be addressed. The document currently covers the following. Fault Management - enumerates potential MPLS forwarding problems and explores where data plane tools can assist in detection and diagnostics. There is some discussion of availability criteria but this could use some fleshing out by providers. Config - using data plane tools to verify config. Admin in future. Perf - extracting counts etc. Security - can tools be abused? How to prevent this. Next steps are to adopt this as WG draft. The authors will continue to work on security and administative issues. George said it was inappropriate to poll the room for support to make this a WG document since the draft did not make the cut-off. So take to list after the meeting. P2MP requirements draft-ietf-mpls-p2mp-requirement-03.txt Seisho Yasukawa This draft has gone through an initial WG last call. This revision is intended to address those comments Further requirements issues were raised by the P2MP design team (see next draft below) that need to addressed in this draft, including: 1) are all leaves/branches subject to same LSP parameters? Esp important inter-domain. 2) How do we do re-merge and cross-over? Issues with duplication. 3) How does this scale. Is core of network so scaling different to pure IP multicast. Hopefully tree is more stable than in IP. 4) Partial tree reoptimisation is important - but can cause duplication. 5) What if path message gets fragmented downstream (as it grows as it goes)? Don't want to rely on IP fragmentation - so need to handle in control plane. 6) should we avoid replication on MPLS LAN interfaces? Next steps: Revision 4 - will add the new well understood requirements. Authors will ask list about those that are not well understood. Then hopefully will produce revision 5 as final rev. and put into WG last call. A lot of discussion ensued. For details see the detailed minutes sent to the list. George - Speaking as chair The draft needs to be revised to both clarify and narrow the scope to P2MP traffic engineering. The draft should only be about requirements, references to RSVP should be minimal if not completely expunged. Better coordination with multicast folks in general and MBONED in particular needs to happen. It was suggested by Dave Meyer that this be vetted in MBONED. P2MP merged solution document draft-raggarwa-mpls-rsvp-te-p2mp-00.txt Dimitri Papadimitriou, Rahul Aggarwal & Seisho Yasukawa In Korea there were two drafts that were far apart. Alex asked that there be one draft, merging the two and that a design team be formed. together. That happened slowly at first, but what happened once people started focussing on the problem were able to find the right solution. This draft represents both the consensus and captures the remining differences of the original two drafts. While it is far from converged much progress has been made. Open issues (partial list): 1) state management. Intent is to disambiguate message size. ID still needed for sub-tree reoptimisation. 2) re-optimisation. 3) re-merging. Would like to point out issues under discussion - data plane and control plane issues. Identified a case for this. 4) Recovery. Need to expand on GMPLS applicability. The authors will be requesting this be a WG document after this meeting. Source Routed MPLS LSP using Domain Wide Label draft-tian-mpls-lsp-source-route-01.txt Albert Tian This draft introduces global labels as a means of source routing or loose source routing a packet in an MPLS network. If each destination of interest (say all of the loopback addresses used as router-IDs) had a label which was both globally known and globally used by all routers, then one could source route a packet by stacking up labels for each of the routers in the source route. This technique could be applied to fast reroute. In the ensuing discussion it was pointed out that the idea of global labels had been discussed in the early days of MPLS. At that time it was decided that labels would only have local significance (within the forwarding plane). Many workgroup members expressed opposition to such a fundamental change to the MPLS architecture. Alex Zinin stated, "The workgroup is done with architecture. Unless it can be proved that architecture is not sufficient then this doesn't fit in charter." Loose Segment Optimization in Explicit Paths draft-tian-rsvp-loose-seg-opt-00.txt Albert Tian The issue addressed by this draft is FRR. The author has concerns about having large numbers of repair paths. If you use RSVP-TE could have a lot of state in the network. Can alleviate this by tunnelling the RSVP-TE path messages to reduce RSVP-TE state. Two applications are envisioned, Fast Reroute and P2MP. In the latter case this is applicable if shape is the only concern. The idea is to have RSVP state only at critical nodes and to use LDP as a form of fowarding adjacency between those nodes. Albert request that this become a WG document. Some discussion ensued with no clear direction. George asked that the discussion be continued on the list. FastReroute using Alternative Shortest Paths draft-tian-frr-alt-shortest-path-01.txt Albert Tian This draft proposes a new way to calculate repair paths which offers 100% repair coverage using explicit paths with loose segments. First issue is to determine the termination point. For link protection this is the next-hop; for node protection the next-next-hop. Repair path calculation is simple. Take out the link or node being protected and calculate a path. The repair can be made using any of: Source Routed MPLS LSP using Domain Wide Label RSVP-TE RSVP-TE with Loose Segment Optimization in Explicit Paths Draft gives algorithm to simplify the repair path. The key benefit benefits claimed are 100% coverage with reduced repair paths based on next-hop/next-next-hop termination, and shared protection for MPLS, IP unicast, and IP multicast. Albert asked that this become a WG document. George question which parts belonged here and pointed out that there was related work going on in the Routing Area WG. It would appear that the algorith part of the draft would belong there since it's applicable to IP as well as MPLS. Discussion will continue in that WG and on the list(s). Equal Cost Multipath Best Current Practices (ECMP BCP) draft-swallow-mpls-ecmp-bcp-00.txt George Swallow This draft is intended to give guidance to people building applications on MPLS. The issue first surfaced in PWE3. If all of the data for a psuedo-wire then steps need to be taken to avoid ECMP. There are several known reasons for wanting a single path. One is to reduce jitter and avoid out-of-order delivery (note that these can still occur in a reroute situation). Anther is to ensure that OAM flows follow the paths that they are trying to monitor. MPLS defines FECs. The primary FEC used in the core of the network is the IP prefix. MPLS has no payload identifier; it is inferred from the FEC. on this early on in MPLS. If you get label in middle of network for IP FEC and have no payload ID then many vendors assume is IP. But some vendors said "if look at first nibble and isn't 0x4 will assume it isn't IP. If it is IP we'll do our usual IP hash". All well and good as long as only carried IP or L3VPN. But get problems with PWE3 as have non-IP payload. If first nibble is 0x4 the core is likely to assume this is IP and we'll get mis-ordering. Ultimately best solution is to avoid 0x4 or 0x6 in first nibble. Problem is that IANA is working up from 4. Nobody knows the exact status of 0-3, but it is unlikely that they would be assign before 7-15, if at all. The recommendation in this draft is to use 0x0 and 0x1. George will be asking for WG status on the list. A poll of the room showed general support for this. |