NOTE: This charter is a snapshot of the 41st IETF Meeting in Los Angeles, California. It may now be out-of-date. Last Modified: 12-Feb-98
Chair(s):
George Swallow <swallow@cisco.com>
Vijay Srinivasan <vijay@raleigh.ibm.com>
Routing Area Director(s):
Joel Halpern <jhalpern@newbridge.com>
Routing Area Advisor:
Joel Halpern <jhalpern@newbridge.com>
Mailing Lists:
General Discussion:mpls@external.cisco.com
To Subscribe: mpls-request@cisco.com
In Body: 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.
Objectives:
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.
Coordination:
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 Architecture 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. |
Internet-Drafts:
· A Framework for Multiprotocol Label Switching
· Use of Label Switching With RSVP
· A Proposed Architecture for MPLS
· MPLS Label Stack Encoding
· Use of Label Switching on Frame Relay Networks Specification
· VCID Notification over ATM link
No Request For Comments
Minutes of the Multiprotocol Label Switching (mpls) Working Group
FIRST SESSION 9:00-11:30
1.1. Introduction and Administrativia
George Swallow and Vijay Srinivasan chaired the meeting. Karen O'Donoghue took notes. The ritual agenda bashing resulted in no changes to the agenda.
1.2. Label Distribution Protocol (LDP)
<draft-ietf-mpls-ldp-00.txt>
(Note the draft was posted to the list as draft-mpls-ldp-00.txt, and as of this writing has still not appeared on the servers.)
Paul Doolan presented the latest version of the LDP document providing a brief overview and discussion on items changed since the last meeting. Paul described the three classes of messages; discovery, adjacency, and advertisement. He described in some detail the changes made to the document and remaining open issues. The loop detection and prevention aspects of the draft are still under discussion. Detection is a configurable option. Detection uses path vector, and prevention uses diffusing computation. Explicit routing has been added since the last meeting, but this is just a strawman. The procedure sets up tunnels from the destination to the source. Many folks prefer this to be done source to destination. Either way Paul pointed out that the explicit routing material needs additional work.
Also included in this draft was an object to carry reservation information. There was some debate about whether there had actually been a mandate to add this or not. Vijay recalled from the minutes that there was consensus to add 'simple qos' capabilities, but there was no mention of making reservations.
George raised a number of issues as chair. He stated that label distribution is pretty far along. However, the explicit routing part is just emerging. This material needs to be thought out more thoroughly. It is desirable to get the basic LDP document out in a finite amount of time. If the explicit routing aspects slow the document down maybe they should be spun off to a different document. This also applies to the issue of providing some notion of class of service (possibly more like diffserv than intserv). A possible option is to issue the existing material as an Informational RFC while we continue efforts. (Note - since the meeting I've heard that such an RFC should properly be Experimental.)
Two significant issues need resolution:
1) Will LDP do bandwidth reservation?
2) Should explicit routing be in a separate document?
George moved the discussion to the mailing list.
1.3. Carrying Label Information in BGP-4
<draft-rekhter-bgp4-mpls-00.txt>
Yakov Rekhter presented a mechanism to exchange label binding information among BGP peers by adding (piggybacking) the label mapping information on the BGP route update. The proposal provides an encoding and rules for handling the label mapping information. Yakov indicated that the encoding was extremely straightforward. He asked what the group thought should be done with the proposal. A question was raised regarding why we would want this in addition to LDP. Yakov pointed out that the MPLS architecture document discusses two mechanisms for exchanging label information, piggybacking and a separate label distribution protocol. This documents one of those mechanisms. Rob Coltun brought up a point about globally unique AFIs. Ross Callon indicated that he thought the proposal was a sensible thing that should be worked including number assignment by IANA. George will follow up on the number assignment.
The consensus of the WG was to accept the proposal as a working group draft.
1.4. VPN Mpt to Mpt Tunnel Protocol
<draft-pegrum-vmmt-00.txt>
Scott Pegrum presented his draft on a multipoint to multipoint tunnel protocol. The proposal is for the distribution of VPN information within a single service provider's network. Its goal is to decouple the private network topology from the service provider's topology. The proposal is based on ICMP router discovery. Issues identified include VPN setup across untrusted networks, controlled access from dialups, necessary authentication additions to the protocol, and scalability in light of non-multicast environments. Yakov Rekhter pointed out that there are multiple ways of accomplishing this. George Swallow asked Scott what action he wanted for this document. Scott indicated that this was originally intended for the VPN working group. There is a plan to have a second VPN BOF at the August IETF. This material was determined to be for further study possibly in conjunction with future VPN efforts.
1.5. VPN Support with MPLS
<draft-heinanen-mpls-vpn-01.txt>
Juha Heinanen addressed his draft providing a high level perspective on how MPLS can support VPNs. VPNs give the illusion of a private line network where only member sites see each other. There are a number of choices for implementing a VPN including traditional layer 2 techniques, layer 3 techniques based on IP tunnels, and layer 3 technique using MPLS. MPLS based VPNs combine the best features of Layer 2 and IP tunnels. This technique automatically provides a full mesh of connectivity between the member sites with native support for IP multicasting. Tony Li asked about a slightly simplified version using BGP. Yakov Rekhter noted that the simplification had been considered. Another question was raised on denial of service security considerations. It was felt that the subject needed to be addressed in the document. A concern was raised that LDP is being extended to being a routing protocol because of the impression that LDP is being used to distribute route information. This draft is also for further study in conjunction with future VPN efforts.
1.6. MPLS Routing Dynamics
<draft-ayandeh-mpls-dynamics-00.txt>
Siamack Ayandeh presented some analysis on the impacts of transients in protocols like MPLS. It was concluded that such transients could result in loops and other undesirable routing phenomena. These phenomena need to be identified and considered during the development of MPLS. George Swallow indicated that the analysis was both informative and useful.
1.7. Loop Prevention
<draft-ohba-mpls-loop-prevention-00.txt>
Eric Rosen presented a draft on a new loop prevention proposal based primarily on work of Ohba and Katsube at Toshiba. The goal is to replace the diffusion/path vector schemes as the MPLS standard optional loop prevention scheme. The main features of this proposal include:
1) support for merging and/or non- merging ATM LSRs separately and in combination; and
2) support for egress and local (down-stream-on-demand) control equally well. There are a number of weaknesses of the current schemes including an unbounded amount of information, complexity, and non-robustness. This approach is to replace the variable length path vector with a fixed length quantity. On a routing change, the distributed computation involves only nodes downstream of the change.
Eric concluded by recommending that this become a replacement for the path vector diffusion with this loop prevention mechanism. He also noted that there are items in this proposal that need further work (e.g., retry timer). He asked that the group review the proposal in detail, and barring technical flaws that it be adopted.
George indicated that email discussion is appropriate. However, we do need to bring this to closure in a month or so.
1.8. TF-TEN Tag Switching Experience
Jean-Marc Uze discussed the tag switching experiment conducted on JAMES (an ATM test-bed connecting six European countries) in the Trans-European Network. The experiment was performed in January. Each country has one tag (ATM) switch and one tag router. The switches were Cisco LS1010's and the routers were 7500s and 7200s. Overall tag switching worked well.
A number of performance tests were conducted involving single and multiple TCP or UDP connections both with and without tag switching. The tests were run between 3 different hosts using netperf 2.1 and mgen 3.2. The parameters monitored included round trip time, route recovery time, throughput of TCP connections, packet loss for UDP streams, and average CPU utilization of route. The results showed some improvement in throughput with tag switching. Jean-Marc speculated that this may be mostly attributable to encapsulation.
Jean-Marc also commented that the Traffic Engineering feature worked well and was simple to configure. Traffic Engineering uses RSVP to establish explicit tag switched paths through the network.
SECOND SESSION
2.1 Traffic Engineering
<draft-li-paste-00.txt>
Tony Li presented his draft on a provider architecture for differentiated services and traffic engineering (paste). This architecture provides for differentiated services and traffic engineering using MPLS and RSVP. Tony discussed why traffic engineering is beneficial including the more cost-effective utilization of network resources. Traffic is partitioned into trunks that can be aggregated by merging and bundling. RSVP is used for the establishment and maintenance of these trunks. The current status of this proposal is that it has been implemented by at least Juniper and Cisco with interoperability testing planned in the near future. Additional vendors are welcome (contact either Tony Li or Yakov Rekhter).
Some concern was expressed about the possible impact of the differential service work producing more levels of service than the tos bits allow. Tony indicated there were other bits that could be used as well. It was also pointed out that one doesn't need a full-blown implementation of RSVP. It is necessary to refresh reservations, but the queue management components are not necessary. There was some concern about the need to refresh because this is believed to be one of the problems with RSVP today. Tony indicated that this was not an issue since the number of traffic engineered paths is much smaller than the potential level of host to host reservations which was the basis of that concern. Ross Callon voiced a concern about soft state nature of RSVP and explicit routing. He thought that there may be a potential for loops. Tony disagreed. Ross said the issue needs to be addressed in the document. Tony agreed that it should be addressed more fully.
No disposition of the document was made; the authors will likely publish it as an Informational RFC.
2.2 Architecture Issues
<draft-gray-mpls-arch-issues-00.txt>
Eric Gray documented some issues identified in the current architecture document. His primary complaints about the architecture document were that it was too complicated and it was incomplete in several key areas including flexibility. He felt that it should allow building in phases and propose a roadmap for doing so. He also deemed some of the definitions to be vague. Eric's draft makes several suggestions for improving the current architecture document. Ross Callon indicated that the architecture document did need some work. Some of Eric's suggestions have already been addressed. The balance will be handled by the authors of the architecture document offline.
2.3 Traffic Management
<draft-vaananen-mpls-tm-framework-00.txt>
Pasi Vaananen presented his draft on a framework for traffic management. The motivation of this draft is to address the 2nd problem statement from the charter. Pasi feels pure destination based forwarding support in MPLS is not enough to support special service (e.g. QoS). Pasi feels that what is required is not well addressed in the current documents. He examined the service categories and discussed traffic management requirements. A basic question he posed is "Should LDP be extended to provide basic functionality for TM purposes, or should we rely on 'incorrect use' of RSVP?" Differentiated services, especially those requiring many bits, are not good friends to labeled paths. Pasi concluded that the use of LSPs allows network operators better control over their network resources than pure best effort packet forwarding. The use of LSPs reduces the processing requirements to perform forwarding and scheduling decisions for services with explicit guarantees (including management of best effort paths). Finally, the use of LSPs, together with aggregation and merging, reduces the amount of connection state that needs to be retained in core network.
George Swallow opened the floor for discussion reminding the group of the earlier discussion on explicit routing. There are currently two proposals - using RSVP or LDP with a large overlap infunctionality. Ross Callon claimed that RSVP was not designed to do explicit routing because it has a soft state model. He is skeptical that the group can come to a consensus on one versus the other. Greg Minshall said that RSVP's soft state model is not sufficient to reject it here. Andy Malis indicated that it is much too premature to come to any sort of conclusion at this time. Ross Callon stated that when the IETF has tried to choose between two competing protocols we fail, but the two competing protocols do tend to get fleshed out more thoroughly during the decision process.
George Swallow stated that adding explicit routes will slow down LDP somewhat. Adding reservations will slow it down even further. There is a strong desire to get the basic specification out soon. Additional functionality can be developed later. Joel feels that the group is overstating the complexity of both sides. George asked that discussion continue on the mail list.
2.4 VCID
<draft-ietf-mpls-vcid-atm-00.txt>
Hiroshi Esaki presented the VCID notification over ATM link draft. This draft details how the UUS (see next item) can be used to carry the VCID. The WG accepted the inclusion of this approach.
There are two possibilities for progress:
1) add VCID mechanism to existing LDP spec; or
2) complete the VCID mechanism as a separate document and then moving it into the LDP spec or referring to it in the LDP specification. George Swallow indicated that development can proceed as a separate document. The decision about incorporation can take place as the WG gets closer to forwarding the LDP specification to the IESG.
2.5 Q.2957 UU Signaling support for MPLS
<draft-suzuki-git-uus-assignment-02.txt>
Mr. Suzuki reported on the current status of the ITU-T SG11 liaison with IETF. At the last IETF ION WG, draft-suzuki git-uus-assignment-00.txt was discussed. At the SG11 WP1 January meeting, WP1 decided to discuss B-ISDN signaling support for the Internet protocol based on this draft. UUS enables transfer of information between end-to-end users in an ATM network. All of the B-ISDN signaling messages transferred between end-to-end users in an ATM network may contain one UUS information element. The ATM network transfers UUS elements transparently. Additional information is available: (http://www.nal.ecl.net/SG11WP1; www.nal.ecl.net/~suzuki/ietf40-ion-prezen.ps; and www.nal.ecl.net/~suzuki/ietf41-ion-prezen.ps).
This proposal currently has only one information element, and it is proposed for use by the MPLS VCID. The question was raised as to whether any thought had been given to providing for multiple sub-elements, which would allow for additional applications. Mr. Suzuki agreed to consider that modification.
2.6 TDP Implementation Experience
Bob Thomas presented some of the experience gained during the implementation of Cisco's tag switching. This particular implementation has been in field trials at some customer sites since last summer. Bob said one important lesson from the implementation experience had already been discussed earlier during the LDP presentation. That being the neighbor discovery mechanisms which have now been added to the LDP draft.
Bob provided an overview of some of their implementation decisions including using a tag switch controller to support tag distribution for an otherwise pure ATM switch, using an enhanced RSVP for setup of paths for TE, and using TDP to support dynamic tag switching. Bob also provided some basic performance information based on their implementation. Tag forwarding was 10% faster than IP forwarding. Tag imposition was slightly slower than IP forwarding. Tag removal was slower than tag forwarding but faster than IP forwarding.
VPN Multipoint to Multipoint Tunnel Protocol