NOTE: This charter is a snapshot of the 40th IETF Meeting in Washington, DC. It may now be out-of-date. Last Modified: 24-Oct-97
George Swallow <email@example.com>
Vijay Srinivasan <firstname.lastname@example.org>
Routing Area Director(s):
Joel Halpern <email@example.com>
Routing Area Advisor:
Joel Halpern <firstname.lastname@example.org>
To Subscribe: email@example.com
In Body: in body: subscribe (unsubscribe)
Description of Working Group:
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.
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:
Produce Framework Document Internet-Draft to contain goals with detailed motivations and description of solution space, possible approaches
Submit Framework Document to IESG (Informational RFC)*
Freeze Internet Draft for carrying label information over serial lines (p2p links) and over LAN media (e.g., Ethernet, Token Ring, FDDI)
Submit Architecture Document to IESG (Informational RFC)
Submit specifications for the protocol to distribute label binding information for unicast routes to IESG (Standards Track)
Submit specifications for handling label binding information (including distribution of this information) for multicast routes to IESG (Standards Track)
Submit specifications for Operation over ATM to IESG (Standards Track)
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)
Submit procedures for Host Behavior to IESG (Standards Track)
AD review status of WG efforts and determine whether to close down or not. If not, identify next set of milestones.
· A Framework for Multiprotocol Label Switching
· A Proposed Architecture for MPLS
· MPLS Label Stack Encoding
No Request For Comments
Minutes of the Multprotocol Label Switching (MPLS) Working Group
I. Introduction and Administrative
The meeting was chaired by George Swallow and Vijay Srinivasan. Notes taken by Loa Andersson. The meeting was called to order at 3.30 PM Monday 8th of December.
II. Label Distribution Protocol
Before the document was presented, Paul Doolan briefly discussed how the work on the document had been organized, what is included and excluded from the document, what work items remain and what contentious issues are still open.
The document was presented by Nancy Feldman. LDP messages classes and messages were reviewed, and the function of each message and the objects in the messages were discussed. The approach taken by the LDP design team towards egress vs. local control and loop detection and loop prevention were presented.
Juha Heinanen raised the question of support for CUG (Closed User Group). Nancy said that this was a topic that had not been addressed, and was something that could be added to the future items list.
A question was raised from the floor on the configuration for egress vs. local control and it was explained that egress and local control work perfectly together and that the configuration only was intended for boxes that could do both.
III. Generic Label Distribution
The document was presented by Eric Gray. Eric explained the motives behind starting this work. One point of mismatch between the LDP design team's spec and the Gray et al draft is that the latter includes support for upstream allocation (this is because of the fact that multicast has been included in the Gray et al draft).
Eric maintained that the difference between local and egress control is an artificial distinction. Apart from this and the fact in the Gray et al draft there is only one message for detection and initialization, there is a great amount of agreement between the two drafts
IV. Ingress Control with Simple Loop Prevention Mechanism
The draft was presented by Katsube-san. The draft discusses the differences between Local Control, Egress Control and the proposed Ingress Control. The ingress control was proposed by Bruce Davie et al for ATM, but here a mechanism for loop prevention has been added. The mechanism can be extended to both unicast and multicast cases.
V. Discussion on LDP
Bruce Davie proposed that we take some the complexity out of the Design Team specification and once this is done look at the Lucent specification and see if there is something in that still needs to included in order to come up with a united proposal.
Ross Callon argued that we do not want to make e.g. RSVP a requirement to be able to implement MPLS.
Grenville Armitage argued that we should try to merge the two documents. It was suggested that the principal authors of both drafts should meet to discuss existing differences in the drafts, and decide on how to move forward.
VI. Label Switching for RSVP Flows
The document was presented by Bruce Davie. This document proposes methods for hosts and routers that support both label switching and RSVP to associate labels with RSVP flows. The proposals from IBM and Cisco authors (presented at previous meetings) have been merged in this respect. There are still some open issues, e.g. non-reserving nodes on shared media and opportunities for better aggregation of flows to reduce label usage. The presenter also clarified, in response to a question from the floor, that it was not the intent of this draft to preclude support for CoS/QoS in LDP.
The draft was moved forward as a working group document.
Wednesday, December 10 at 1530-1730
I. MPLS Explicit Routes
The draft was presented by Bruce Davie. Bruce started to speak of some loose ends from his presentation on Monday, as the use QoS mechanisms in MPLS and referred back to an older draft: draft-lin-tags-cos-00.txt.
Bruce addressed the question of why should we use RSVP for explicit routing in MPLS. It takes little additional mechanism over what RSVP already provides and also enables resource reservation along an explicitly routed part. As RSVP already maintains state along the path end to end, it is not necessary to introduce the same mechanism into. It also avoids over-complicating LDP.
With RSVP, we can establish explicitly routed paths for both best effort and aggregated flows. Objections were raised from the floor over the idea of using RSVP to set up best effort ER LSPs. Concerns were voiced over needing to deploy RSVP in order to do explicit routing in a MPLS environment; i.e., mandating the need to implement RSVP. Further questions were raised over whether this meant that explicit routing is not required in LDP. (Bruce clarified that he was not proposing that we prohibit LDP from supporting explicit routing.) If we wed MPLS and RSVP closely and give the change control over to another working group, and RSVP is a quite new protocol and will be subject to change over the coming months.
There appeared to be general agreement that there is a need to include the explicit routing into the LDP together with some notion of CoS/QoS, perhaps only bandwidth. If you want to do a more complex QoS, you have to use another protocol.
II. VCID: Virtual Connection Identifier
Hiroshi Esaki presented this draft. The VCID is used as a mapping between the FEC and the VPI/VCI. Both out-band and in-band notification. With multicast Upstream allocation is necessary, in all other case both downstream and upstream is possible. The proposal is that that the procedure proposed in the draft shall be included in the Architecture document. Ross Callon, as one of the author of the architecture document accepted this, but pointed out that other documents also might be affected and that we of line should work this through.
III. Stream Merge for IP Over ATM
Andre Fredette presented the draft. The basic problem addressed is how a downstream node can know if it is possible to allocate the same label to different incoming flows. There are several possibilities to combine aggregation and merging to reduce the number of labels used. The draft gives a mechanism for maximizing aggregation, by the use of a Merge ID (MID) in the LDP Request message. The mechanism guarantee that a request that reaches an egress and has the same MID has taken the same routed path through the network and can safely be aggregated on the same label.
The proposal is that the information in draft is submitted to the group working with the Framework document (architecture?).
IV. LAN Label Stack Encoding
Eric Rosen presented the draft. There are two proposal, shim and mac, that differs on the encoding of the top stack entry. The draft compares the working of these proposals on ethernet. The mac proposal frames are smaller than the shim proposal. The mac-proposal make it necessary for routers to run in promiscuous mode to receive frames, while the shim proposal has the DA available. There are a number of issues with the mac proposal, e.g., SA spoofing and uniqueness that is not a problem with the shim proposal.
V. Use of Label Switching With Frame Relay
Alex Conta presented the draft. The draft discusses the characteristics of FR switches i.e. Frame format, no TTL available and mp-to-p not always supported. The TTL processing is done at the boundary of the FR network, there the TTL is decremented by the number of hops through the network.
The proposal is that the draft is forwarded as a working group document, there were consensus on this.
VI. CSR Testing Experience
Michael Smirnov presented the experience from the testing of the CSR. The tests have been done in Germany by GMD Fokus in co-operation with Toshiba.
The LDP spec was moved forward as a working group document, with the explicit understanding that the work presented in the Lucent variant of the spec. will be considered for incorporating new ideas.
Label stack encoding draft from Rosen et al was also moved forward as a working group document.
go to list