2.5.8 Multiprotocol Label Switching (mpls)

NOTE: This charter is a snapshot of the 46th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 29-Sep-99


George Swallow <swallow@cisco.com>
Vijay Srinivasan <vijay@torrentnet.com>

Routing Area Director(s):

David Oran <oran@cisco.com>
Rob Coltun <rcoltun@siara.com>

Routing Area Advisor:

Rob Coltun <rcoltun@siara.com>

Mailing Lists:

General Discussion:mpls@uu.net
To Subscribe: mpls-request@uu.net
In Body: subscribe (unsubscribe)
Archive: ftp://ftpeng.cisco.com/mpls/mpls

Description of Working Group:

Problem Statement:

Recently the use of label-swapping based forwarding ("label switching") in conjunction with network layer routing has attracted much attention. Several vendors have proposed techniques based on this paradigm. Among the problems this paradigm is expected to address are the following:

1. Scalability of network layer routing

Using labels as a means to aggregate forwarding information, while working in the presence of routing hierarchies.

2. Greater flexibility in delivering routing services

Using labels to identify particular traffic which are to receive special services, e.g. QoS.

Using labels to provide forwarding along an explicit path different from the one constructed by destination-based forwarding.

3. Increased performance

Using the label-swapping paradigm to optimize network performance.

4. Simplify integration of routers with cell switching based technologies

a) making cell switches behave as peers to routers (thus reducing the number of routing peers that a router has to maintain),

b) by making information about physical topology available to Network Layer routing procedures, and

c) by employing common addressing, routing, and management procedures.

High Level Requirements

1. The solution should be general with respect to data link technologies. Specific optimizations for particular media will be considered.

2. The solution must be compatible with existing internetwork technologies and routing protocols.

3. The solution should be capable of operating independently of the underlying routing protocol. It has been observed that considerable optimizations can be achieved in some cases by small enhancements of existing protocols. Such enhancements will be considered in the case of IETF standard routing protocols, and if appropriate, coordinated with the relevant working group.

4. The solution should support a wide range of forwarding granularities associated with a given label, from a single application flow to a group of topologically related destinations.

5. The solution should support operations, administration, and maintenance facilities at least as extensive as those supported in IP networks.

6. Routing protocols that could be used in conjunction with MPLS could be based on distributed computation. As such, during routing transients these protocols may construct forwarding paths that contain loops. The protocols defined by MPLS must provide protocol mechanism(s) to either prevent the formation of loops and/or contain the amount of (networking) resources that could be consumed due to the presence of such loops.

7. The standard must clearly state how the protocol operates in a hierarchical network.

8. Scalability issues will be considered and analyzed. Very scalable solutions will be sought. For example, in the case of ATM technologies, the solution will attempt to conserve VC usage.

Charter Statement:

Currently, none of the solutions that that employ label-swapping based forwarding ("label switching") in conjunction with network layer routing are based on standard technology. In order to be able to achieve the benefits of this new technology, a standard solution is necessary.

The working group is responsible for standardizing a base technology for using label swapping forwarding paradigm (label switching) in conjunction with network layer routing and for the implementation of that technology over various link level technologies, which may include Packet-over-Sonet, Frame Relay, ATM, Ethernet (all forms, such as Gigabit Ethernet, etc.), Token Ring,...

This includes procedures and protocols for the distribution of labels between routers, encapsulations, multicast considerations, use of labels to support higher layer resource reservation and QoS mechanisms, and definition of host behaviors.


1. Specify standard protocol(s) for maintenance and distribution of label binding information to support unicast destination-based routing with forwarding based on label-swapping.

2. Specify standard protocol(s) for maintenance and distribution of label binding information to support multicast routing with forwarding based on label-swapping.

3. Specify standard protocol(s) for maintenance and distribution of label binding information to support hierarchy of routing knowledge (e.g., complete segregation of intra and inter-domain routing) with forwarding based on label-swapping.

4. Specify standard protocol(s) for maintenance and distribution of label binding information to support explicit paths different from the one constructed by destination-based forwarding with forwarding based on label-swapping.

5. Specify standard procedures of carrying label information over various link level technologies.

6. Specify a standard way to use the ATM user plane

a) Allow operation/co-existence with standard (ATM Forum, ITU, etc.) ATM control plane and/or standard ATM hardware b) Specify a 'label swapping' control plane c) Take advantage of possible mods/improvements in ATM hardware, for example the ability to merge VCs

7. Discuss support for QOS (e.g. RSVP).

8. Define standard protocol(s) to allow direct host (e.g. server) participation.


The working group will coordinate its activities with other working groups as appropriate.

Goals and Milestones:

Mar 97


Produce Framework Document Internet-Draft to contain goals with detailed motivations and description of solution space, possible approaches

May 97


Submit Framework Document to IESG (Informational RFC)*

May 97


Freeze Internet Draft for carrying label information over serial lines (p2p links) and over LAN media (e.g., Ethernet, Token Ring, FDDI)

Jun 97


Submit Achitecture Document to IESG (Informational RFC)

Aug 97


Submit specifications for the protocol to distribute label binding information for unicast routes to IESG (Standards Track)

Oct 97


Submit specifications for handling label binding information (including distribution of this information) for multicast routes to IESG (Standards Track)

Dec 97


Submit specifications for Operation over ATM to IESG (Standards Track)

Dec 97


Submit specifications for carrying label information over serial lines (p2p links) and over LAN media (e.g., Ethernet, Token Ring, FDDI) to IESG (Standards Track)

Apr 98


Submit procedures for Host Behavior to IESG (Standards Track)

Apr 98


AD review status of WG efforts and determine whether to close down or not. If not, identify next set of milestones.


Request For Comments:







Requirements for Traffic Engineering Over MPLS

Current Meeting Report

Minutes, MPLS meeting, IETF-46, Washington DC
Wednesday and Thursday, November 10-11, 1999, 9:00 - 11:30

Chairs: Vijay Srinivasan, Ericsson, George Swallow, Cisco
Minutes taken by Andrew Malis, Lucent


First Session, Wednesday, November 10, 1999, 0900 - 1130

1. Agenda Bashing & WG Status
2. Le Faucheur, DiffServ over MPLS, draft-ietf-mpls-diff-ext-02.txt
3. Gibson, Management of QoS, draft-gibson-manage-mpls-qos-00.txt
4. Gray, LDP State, draft-ietf-mpls-ldp-state-02.txt
5. Jamoussi, CR-LDP update, draft-ietf-mpls-cr-ldp-03.txt
6. Aboul-Magd, Service Definition, draft-aboulmagd-srvc-def-crldp-00.txt
7. Ashwood-Smith, Improving Topology DB Accuracy, draft-ashw-mpls-te-feed-00.txt
8. Ash, Routing Guidelines for Efficient Routing Methods, draft-ash-itu-sg2-routing-guidelines-00.txt
9. Awduche, Multiprotocol Lambda Switching, draft-awduche-mpls-te-optical-00.txt
10. Basak, Multiprotocol Lambda Switching, draft-basak-mpls-oxc-issues-00.txt (not yet posted)

Second Session, Thursday, November 11, 1999, 1300 - 1500

1. Andersson, Reroute Framework, draft-andersson-reroute-frmwrk-00.txt
2. Owens, Protection/Restoration Requirements, (no draft)
3. Shew, Restoration, draft-shew-lsp-restoration-00.txt
4. Swallow, Bypass Labels, draft-swallow-rsvp-bypass-label-00.txt
5. Berger, RSVP refresh reduction, Update on what occurred in RSVP WG
6. Theimer, OAM Functionality, draft-theimer-mpls-oam-requ-00.txt
7. Andersson, Capabilities Set, draft-loa-mpls-cap-set-01.txt
8. Carson, NIST Implementation
9. Leu/Jensen, Interoperability Update
10. Charter Update

First session, Wednesday, 0900 - 1130

George began the meeting by announcing that we had to change the order of the agenda because the video projector was not yet working.

1. Mark Gibson, Nortel, Management of QoS, draft-gibson-manage-mpls-qos-00.txt

Mark discussed managing MPLS using SIP. The operation of MPLS is left unchanged, but SIP is used to determine the path based on QoS metrics. SIP also performs the reservation.

The reference architecture is a session control layer using ISUP, a core management layer, using SIP, and a core transport layer, using MPLS. MEGACO is the interface between the session control layer and the core transport layer, while COPS is the interface between the core management layer and the core transport layer.

The MPLS configuration is a network of known-size ER-LSP paths, which act like trunks. The trunks are advertised using the SIP REGISTER method. SIP then sets up sessions within the trunks.

The key features are dynamic route selection, provides a mechanism for guaranteed QoS, enables traffic engineering, scalable, small level of session state, and MPLS operation is unaltered.

This draft was presented for information only at this point.

George Swallow asked a couple of questions:

Q: Does this require carrying labels in SIP?
A: No

Q: How is the binding done?
A: There is syncing up between the endpoints, and then a CR-LDP or RSVP session setup occurs.

2. Peter Ashwood-Smith, Nortel, Improving Topology DB Accuracy, draft-ashw-mpls-te-feed-00.txt

Peter spoke on improved topology database accuracy with LSP feedback via CR-LDP.

The problem being solved is that the distribution of link resource information via OSPF or ISIS is not timely enough when many LSPs must be set up or reprovisioned as a result of changes in the network. The result is a step function where LSPs establish in bursts with minimum flood interval-sized pauses. Reducing the flood intervals does not help - it just makes the step-size smaller.

Another alternative is to make the route computation non-deterministic (guess), but this results in non-lowest cost routes in the best case, or excessive fruitless hunting in the worst case.

The proposed solution is to overwrite the topology database with information learned during connection setup attempts, so that the topology database is updated to reflect the proper residual bandwidth following either an unsuccessful or successful connection setup.

They found in simulations that without the feedback, the link state database always showed more bandwidth available than in the real network until the next update flood arrived. The feedback more tightly bounds the available bandwidth in the database to more closely match the real network.

He proposed an optional TLV to the CR-LDP notification, mapping ,and withdraw messages to carry the bandwidth for each link on the path.

Q (Vijay Srinivasan): How stable would this be in a real network with many endpoints running this? Did you simulate this with more than just one endpoint creating LSPs?
A: The simulations did have multiple endpoints requesting LSPs. If you only had one endpoint, then you wouldn't need these mechanisms.

Q: Have you considered using piggybacked feedback during failures?
A: Yes, this is in the withdraw messages as well.

Q (Joel Halpern): You need to emphasize in the document that if you get feedback, and then a flood comes in, the information from flooding must override the feedback. Also, the feedback on failure is much more valuable than the feedback on success, since the feedback on success removes available bandwidth from the topology database.
A: That's exactly what you want to happen, so you don't try to open LSPs over paths that aren't going to be able to satisfy the request.

Q (Tony Li): How do you deal with race conditions when you have bandwidth info arriving from different sources in non-deterministic order?
A: I don't care about it, because I'm interested in time scales of seconds, not milliseconds.

At this point, the video projector was working and we resumed the normal agenda order. George announced that he would go over the working group status update at the end of the second session.

3. Francois Le Faucheur, Diff Serv over MPLS, draft-ietf-mpls-diff-ext-02.txt

Francois spoke on MPLS support of DiffServ. He began by presenting the complicated history of DiffServ over MPLS proposals, and how the -01 version of this draft was merged with a number of other existing drafts. As a result, the document was completely restructured to specify media-independent operations (E-LSPs, L-LSPs, forwarding, RSVP, LDP, etc. There are also media-specific sections for PPP, ATM, FR, and LANs. The deployment scenarios were moved to an appendix. They added the concepts of an "ordering constraint" among sets of Per- Hop Behaviors and sets of Behavior Aggregates.

The draft also now discusses the relationship between labels and Forwarding Equivalence Classes. The label represents the combination of a FEC and a precedence or class of service.

On the email list, several possible approaches for E-L-LSPs, "L-LSPs supporting multiple PSCs" were proposed. The approach adopted was that E-L-LSPs are not included in the draft for now, but the draft was structured to facilitate their future addition if that becomes desirable.

They modified the text to reflect that E-LSPs can actually be used to perform traffic engineering and fast reroute separately for each ordering aggregate.

They added error handling, and specified that whenever there is a doubt about whether the LSP can meet the required DiffServ requirements, the LSP is not established.

They proposed some RSVP and CR-LSP signaling extensions to improve DiffServ support.

They added text to clarify the relationship between MPLS and Explicit Congestion Notification. Non-ECN-capable LSPs do not need to set any EXP bits aside for ECN. For ECN-capable LSPs, one EXP bit is used for DCN.

Open issues:

What next:

Q (Juha Heinanen): I don't like the necessity for manual configuration in the routers to determine the mapping of the EXP bits.
A: This has already been discussed at length. We had the requirement to not redefine DiffServ, and we're only trying to set up LSPs to support that. He's not comfortable with saying that DiffServ requires too much configuration so it should be fixed in LSP signaling.

George agreed that trying to wrap this up by Adelaide is a very good goal.

4. Eric Gray, Lucent, LDP State, draft-ietf-mpls-ldp-state-02.txt

Eric wasn't able to present his overheads due to problems with his laptop, but he will put them up on a public web site. He said that this draft has been around with very few comments. They would like to go to last call if possible. It's intended to be an information draft of the LDP state machine that can be used for code development or testing. There were several issues that were closed. The authors had a discussion with Fred Baker regarding the open security issues, especially when the state machine receives spurious events in the form of LDP messages, and the current security section arose from that discussion. Other received comments were also addressed.

Eric subsequently sent email to the list announcing that his overheads can be found at: http://www.mindspring.com/~ewgray/ldpstate

George said that last call will be issued on the list as soon as Eric's presentation is publicly available.

5. Bilel Jamoussi, Nortel, CR-LDP update, draft-ietf-mpls-cr-ldp-03.txt

CR-LDP is now in version 3. Its purpose is to address the requirements in RFC 2702. Bilel gave a very quick overview of the protocol and its history. The primary recent updates were to align with recent changes in the LDP specification. It is now in IESG last call for Proposed Standard. There is free PDU processing code on the Nortel web site, and a Linux implementation is available from the University of Wisconsin, there was an Interopnet Labs multivendor interoperability demo, and the ITU has determined CR-LDP as the signaling protocol for MPLS operation over public ATM data networks. Determination is a fairly mature status within the ITU. The final vote on this is expected at the next ITU SG13 meeting.

6. Osama Aboul-Magd, Nortel, Service Definition, draft-aboulmagd-srvc-def-crldp-00.txt

Osama spoke on a framework for service definition and interworking using CR-LDP. He discussed CR-LDP's QoS capabilities, such as the signaling of traffic parameters, indicating the required service frequency, and the assignment of different priorities to different LSPs. However, it doesn't explicitly define services. Rather, it defines building blocks from which services can be defined. In this case, a service is defined as a combination of the rules enforced at the edge and he packet treatment received at the nodes. The service definition methodology is specifying the policing rules at the edge and the packet treatment rules though the network. He presented a service model for interworking with other domains, such as non-MPLS domains or MPLS domains using RSVP signaling.

Q: Are you trying to define services?
A: No, I'm just defining the building blocks.

Q (Tom Worster): Tom suggested some additions to the draft to include using policy systems to set the edge behaviors. He will work offline with Osama on this.

7. Gerald Ash, AT&T, Routing Guidelines for Efficient Routing Methods, draft-ash-itu-sg2-routing-guidelines-00.txt

His draft proposes mechanisms to improve the efficiency and stability of network routing for MPLS, especially during periods of congestion. Under congestion, networks can exhibit instability with drastic loss of network throughput. State-dependent routing (SDR) path selection with LSA flooding can lead to large processing overhead and smaller AS size.

Event-dependent routing (EDR) path selection can improve routing performance, especially during congestion. He proposed using EDR to address these instabilities and inefficiencies.

He also advocated the use of dynamic bandwidth reservation when setting up LSPs to protect preferred traffic against loss. He discussed various dynamic bandwidth reservation methods.

His proposed next steps are to include these guidelines in the traffic engineering framework draft coming out of the new Traffic Engineering working group and write a comprehensive informational draft on TE and QoS methods for multiservice networks.

8. Daniel Awduche, UUNET, Multiprotocol Lambda Switching, draft-awduche-mpls-te-optical-00.txt

Daniel proposed the use of MPLS for controlling optical cross-connect control planes in order to reuse work done for MPLS in the layer 2 control plane. He discussed the evolving requirements in the Internet for high performance, survivable, and scalable core networks.

He presented an introduction to optical cross-connects (OXCs). The premise of the draft is to adopt MPLS traffic engineering control plane constructs to OXCs. He compared several possible control-plane paradigms, including PNNI, MPLS IP LSR, and proprietary. He proposed a new paradigm using MPLS IP LSRs for all OXC control uses. The advantage is that the work on MPLS traffic engineering can be reused in the optical context.

He reviewed the ITU-T G.872 Optical Transport Network architecture. He discussed the requirements for the control plane operation. He discussed the commonalties between OXCs and LSRs. The basic approach is to adopt IGP extensions for MPLS traffic engineering and MPLS signaling at the optical layer.

The next steps are to develop domain specific adaptation functions, articulate end-to-end architectural implications, develop interoperable extensions to RSVP, CR-LDP, and IGPs, and determine the role of the IETF in this work.

Q: In the document, you excluded the possibility for in-band signaling between OXCs. These should be included.
A: Agreed.

Q (Eric Gray): The level at which OXCs work make it hard to use "ships in the night" operation with other control models. It's going to need an interworking model that is going to involve other groups' work as well.
A: Agreed.

Q (Antonio Rodriguez-Moral): The draft needs to include the layer model in addition to the peer model for OXC control. Also, addressing and signaling interworking need to be addressed.
A: Agreed on the first comment. On the second comment, there are two problems. One is doing this for an IP-centric network, and the second problem is how to control OXCs for more generic use.

Q (Liam Casey): Liam was wondering why the draft stopped at optical switches. This really can apply to any circuit-switch connection. He was wondering if the scope of MPLS is for IP-centric networks, or for MPLS for all possible uses.
A: The scope should be for IP-related uses, at least for now.

Q: There are advantages to multiple control planes.
A: There are two basic issues - building a network and building a control plane. There are cases when an architectural separation makes sense, but other cases when one control plane is correct.

9. Debashis Basak, Fore/Marconi, Multiprotocol Lambda Switching, draft-basak-mpls-oxc-issues-00.txt (not yet posted)

Debashis spoke on issues in combining MPLS traffic engineering control with OXCs. This is an extension to Daniel's draft. He presented an example of LSP setup between OXCs, the issues of conservative wavelength allocation, the impact on link state routing, and the impact on MPLS signaling.

He noted that OXCs cannot perform label push and pop operations, so that start and end of tunnel LSPs have to be on an LSR. There are new link attributes that will be useful, such as if a link is adjacent to an OXC or the number of unused wavelengths on a link. When doing MPLS signaling, the label being signaled have to represent a wavelength, and it needs to be able to specify if an LSP is "multiplexable" or not.

Some additional issues are that today's routers and switches work with SONET interfaces. A signaling message may need to distinguish the channel to use. There is concern for legacy optical equipment that would not include MPLS functionality. That would be modeled as an optical cloud. Wavelength paths may need to use greater bandwidth than they require, due to the fixed nature of lambda bandwidths.

Q (Eric Gray): Eric pointed out a problem in some of the switching examples in the overheads.
A: This will be corrected in the draft.

George pointed out that the disposition of these drafts will be discussed during the charter discussion at the end of the next session.

Second Session, Thursday, 1300 - 1500

1. Loa Andersson, Nortel, Reroute Framework, draft-andersson-reroute-frmwrk-00.txt

This was the second time Loa presented this draft - he had already presented it earlier on the same day in the Traffic Engineering working group. This is a proposed framework document for the various MPLS backup restoration proposals. It discusses the commonalties between all of the various proposals and discusses requirements for this type of work. It doesn't propose a specific reroute scheme but can be used as a framework for evaluation. Requirements could include restoration time, loss bounds, backup capacity, state overhead, and packet reordering. Loa asked for input from service providers, and suggested that this draft perhaps be combined with the other related drafts being discussed at the meeting. The WG also needs to decide if this work belongs here or in the TE WG.

George Swallow announced that he, Ed Kern (one of the TE WG chairs) and Brad Cain (one of the co-authors of this draft) discussed this issue after the draft was presented in the TE-WG. They agreed that anything MPLS-specific belongs in MPLS, while the more general requirements for rerouting could be incorporated in the TE-WG requirements draft.

2. Vas Makam, Tellabs, Protection/Restoration Requirements, draft-makam-mpls-protection-00.txt (not yet posted)

This was also presented at the TE WG in the morning. Vas discussed protection and restoration of traffic engineered IP networks. Their motivation is that layer 3 or IP routing may be too slow for a core network that much support high reliability or availability. However, Layer 0 (optical) or Layer 1 (SONET) may be limited to ring topologies and may not include mesh protection or visibility into higher layer protocols.

They want to facilitate fast recovery of the working traffic while avoiding layering violations by defining an interworking function between the layers. They presented a set of restoration requirements, such as providing mechanisms for doing path or segment restoration, configuring the protection path, enabling restoration of the original path, detecting impairments, and notification. They proposed that the WG produce RSVP and LDP/CR-LDP extensions needed for protection and a WG draft on protection requirements.

3. Stephen Shew, Nortel, Fast MPLS LSP Restoration, draft-shew-lsp-restoration-00.txt

Stephen noted that it is often difficult to accurately determine when an LSP fails, or it may take a long time to determine that there was a failure, and that there is a scaling issue with layer 2 link failures, since a single link failure could affect thousands of LSPs using that link. He described a mechanism for fast detection of MPLS LSP failure when a link fails and scales to all LSPs affected by the failure. This fast detection enables affected LSPs to be quickly recovered onto backup LSPs. The mechanism relies on a node and network architecture that integrates layers 1, 2, and 3 topologies and technology. He defines layer 1 "cut-through" forwarding for layer 3 service. When a physical link that is carrying multiple L1 cut-through paths fails, each endpoint of all the paths knows about the failure through usual physical detection methods. That information is fed up to the MPLS layer, which moves the traffic onto backups LSPs that use a different set of L1 cut-throughs. He said the architecture is similar to draft-awduche-mpls-te-optical-00.txt.

4. George Swallow, Cisco, Bypass Labels, draft-swallow-rsvp-bypass-label-00.txt

George also gave this talk in the TE WG. George presented proposed extensions to RSVP to support traffic engineering restoration (fast reroute). The goal is to reroute around failed nodes and to be able to quickly switch LSPs to predefined backup tunnels, by using the label stack. The backup tunnel does "local repair" around the failure by appearing as a single hop to the original LSP. To effect the repair of the backed up LSPs, packets belonging to those LSPs are redirected onto the bypass tunnel. An additional label representing the bypass tunnel is stacked onto the redirected packets. At the penultimate hop of the bypass tunnel, the label for the bypass tunnel is popped off the stack, revealing the labels which represent the LSPs being backed up. He presented an optimization when a global label space is used instead of local labels on each interface which adds a new label sub- object to the route record object.

George said that it "pretty much works", but he is certainly open to suggestions for improvements. His objective is 50 ms for restoration. He said they can do 12 ms.

Q: (Ram Krishnan): How many tunnels did you test with when you achieved 12 ms restoration?
A: This was tested with about 100 tunnels.

Q (Peter Ashwood-Smith): Do we lose the use of the mergability bit when this is used, since the draft reuses this bit? Should the draft use a different bit instead?
A: George would like some guidance on how the bit is currently being used, and would appreciate suggestions.

Q (Peter A-S): Do the refreshes go over the bypass, or does it not matter?
A: If you're doing the refresh reduction, then there aren't any refreshes to worry about.

George would like this to be a WG draft. He's happy to make the determination on the list once people have had a chance to read the draft.

5. Lou Berger, LabN Consulting, RSVP refresh reduction, update on what occurred in RSVP WG

Lou presented an update on what happened in the RSVP Working Group regarding the refresh reductions. draft-ietf-rsvp-refresh-reduct- 01.txt addresses RVSP scaling issues in the wide area. The RSVP WG met on Tuesday and hotly discussed some of the technical details. The consensus is that some specific changes will be made, there will be an RSVP WG last call after the update, and the draft will be submitted to be a Proposed Standard. There specific changes are:

Other planned changes:

Lou expects to have the draft out in several weeks.

6. Thomas Theimer, Siemens, OAM Functionality, draft-theimer-mpls-oam-requ-00.txt

Thomas presented his draft on proposed OAM functionality for MPLS. He defining OAM (Operation, Administration, and Maintenance), discussed his motivation for MPLS OAM functionality, and presented possible requirements for OAM in MPLS networks. He discussed example of OAM functions, including fault management, continuity checks, loopbacks, performance monitoring, and protection switching. Such capabilities may be useful in many applications of MPLS networks, but a detailed set of requirements is currently not available. He solicited further discussion and input, in particular from network operators and service providers.

He concluded by asking: Do we agree that the MPLS OAM issues should be discussed in this WG? Should we adopt OAM issues as a work item in this WG? Please send comments and input to the list.

7. Loa Andersson, MPLS Capabilities Set, draft-loa-mpls-cap-set-01.txt

Loa presented his revised capability set draft. The purpose is to describe what MPLS is capable of, and what is required for particular applications, so that people will know what is interoperable without having to implement everything. The goal was to describe a limited number of "valid" capability sets. The current draft defines 10 capability sets, including "implement everything". The methodology was to identify a number of MPLS "components", such as basic LDP, RSVP- TE, etc., and show the valid combinations of these components. A new revision of this draft is planned for the next meeting. This is aimed at being an informational RFC.

8. Mark Carson, NIST, NIST's MPLS Implementation

Mark presented his group's MPLS implementation. He started by stating why MPLS is interesting from a research standpoint and why they felt they needed an experimental platform. The implemented it on the "NIST Switch" platform, which are rack-mounted PCs running freeBSD that they use for networking experiments. Their current release uses RSVP for signaling, and they will be incorporating CR-LDP as well. Version 0.1 came out for the Oslo IETF, and they are currently testing version 0.2. They are planning 0.3 for the next IETF meeting. 0.2 has ATM support and also supports -04 of the RSVP tunnel draft. Version 0.3 will support CR-LDP. The code can be found at: http://www.antd.nist.gov/itg/nistswitch

There is a discussion list at: nistswitch-request@antd.nist.gov

The code is in the public domain, and contributions to the code are encouraged.

9. Bill Jensen, University of Wisconsin and Jim Leu, Ericsson, Interoperability Update

Bill and Jim discussed the InteropNet Labs MPLS interoperability demonstration at the Atlanta Networld+Interop trade show. In Atlanta, the InteropNet demonstrated VPNs, VoIP/QoS, High Bandwidth IP, and MPLS.

They demonstrated interoperability for LDP, CR-LDP, and RSVP. They had seven vendors and eleven platforms. For LDP, Cisco, Nortel, Ericsson, Ficon, and Harris and Jeffries participated. For CR-LDP, they had Nortel, Ericsson, and Ficon. For RSVP, they had Cisco, Ericsson, FORE, and Juniper.

They accommodated as many transports as possible: Ethernet, ATM, POS.

They ran LDP and CR-LDP together, and RSVP off on its own island. They tested implementations for conformance to changes in the specifications. The LDP testing was very successful. CR-LDP didn't complete all of the tests possible due to lack of time and resources, but those tests that they did do worked well. Some LDP/CR-LDP "encounters" included RFC 1700 address family misinterpretation, obsolescence of TLV x0601 (dropped in draft -04), handling of unknown TLVs and messages, and inconsistent interpretation of when to use the Message ID TLV in the Label Mapping Message.

For RSVP, they tested sending Path Messages and reception of RESV message with TE TLVs (very successful) manually configured explicit paths (somewhat less successful).

They unintentionally ended up doing some testing of the traffic engineering enhancements to IS-IS, but they didn't get it to work completely.

RVSP "encounters": Outside requirements to trigger origination of LSPs varied between vendors, they found differences in the address used in explicit path messages, path reservation style support varied between implementations, and use of PHP on non-PHP capable transports was a problem (e.g., ATM and lambdas).

They found that MPLS is moving rapidly and they're looking forward to doing this again at the May Interop.

Their talk can be found at: http://www.mpls.interop.net/confstuff/ietf46/interoperabilityupdate/index.htm

10. Charter Update

George discussed the current status of the WG. Much of the charter is either done or largely complete.

To date, there is one RFC: RFC 2702, Requirements for Traffic Engineering Over MPLS.

The state of the other working group documents are:

On RFC Editor's queue:

In the hands of the IESG:

In IESG last call:

WG last call (To, In, Through):

Active drafts:


George presented a score card based on the current charter's work items. The items without a * are complete or mostly so; the two items with a * were not done.

1. Support unicast destination-based routing
2. Support multicast routing *
3. Support hierarchy of routing knowledge
4. Support explicit paths
5. Operate over various link level technologies
6. Specify a standard way to use the ATM user plane: allow operation/co-existence with standard ATM, specify a 'label swapping' control plane, take advantage of possible mods to ATM (e.g. VC merge)
7. Discuss support for QoS (e.g. RSVP)
8. Allow direct host (e.g. server) participation *

A summary of the recent ongoing work is:

Active drafts:

Less active work:

Inactive work:

Recent topics of interest:

After presenting the above, George then opened the microphone for discussion.

Comment: Multicasting hasn't been discussed for a while. If active work doesn't continue, it should be removed from the charter.

Vijay said that both of the existing drafts were from vendors. He would like to see input from service providers on multicast as well. George said that there are a number of issues that need to be resolved in this area, especially for traffic engineering, and volunteers are needed to do this work.

There was support for adding LSP recovery, optical cross-connects, and OAM to the charter. Bilel Jamoussi proposed that signaling improvements for traffic engineering belong in this WG, but routing improvements should be done in the routing WGs.

Rob Coltun (Routing Area Director) made the point that the optical cross-connect work needs to cooperate with the proper other bodies in this area, such as OIF, ITU-T, ANSI, etc. George noted that the best way to liaison to other groups is by having people from those groups participate in this work, and vice-versa.

Vijay asked if people are comfortable that the only QoS being discussed here is the DiffServ model. This question served to generate quite a bit of discussion. Bruce Davie said that he would like to see IntServ semantics included, as well as the explicit congestion notification work. Joel Halpern said that there are several issues that have gotten confused. He pointed out that all of the proposals we have looked at with interest aggregate QoS for scaling purposes. For the purposes of the charter, this could be listed as "based on aggregated QoS", which is more general than just DiffServ. Vijay withdrew his question.

George and Vijay will draft a new charter based on the discussion and put it out on the list for comments.


Protection/Restoration of MPLS Networks draft-makam-mpls-protection-01.txt