NOTE: This charter is a snapshot of the 48th IETF Meeting in Pittsburgh, Pennsylvania. It may now be out-of-date. Last Modified: 17-Jul-00
Chair(s):
George Swallow <swallow@cisco.com>
Vijay Srinivasan <vijay@torrentnet.com>
Routing Area Director(s):
David Oran <oran@cisco.com>
Rob Coltun <rcoltun@redback.com>
Routing Area Advisor:
Rob Coltun <rcoltun@redback.com>
Mailing Lists:
General Discussion:mpls@uu.net
To Subscribe: mpls-request@uu.net
In Body: subscribe (unsubscribe)
Archive: http://cell.onecall.net/cell-relay/archives/mpls/mpls.index.html
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 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. |
Internet-Drafts:
· Multiprotocol Label Switching Architecture
· Use of Label Switching on Frame Relay Networks Specification
· VCID Notification over ATM link for LDP
· Carrying Label Information in BGP-4
· MPLS using LDP and ATM VC Switching
· Extensions to RSVP for LSP Tunnels
· Constraint-Based LSP Setup using LDP
· MPLS Traffic Engineering Management Information Base Using SMIv2
· MPLS Support of Differentiated Services
· MPLS Loop Prevention Mechanism
· Framework for IP Multicast in MPLS
· MPLS Label Switch Router Management Information Base Using SMIv2
· Applicability Statement for CR-LDP
· Applicability Statement for Extensions to RSVP for LSP-Tunnels
· LSP Modification Using CR-LDP
Request For Comments:
RFC |
Status |
Title |
RFC2702 |
Requirements for Traffic Engineering Over MPLS |
None received.
MPLS/IP Header Compression + Over PPP
Signaling Requirements at the Optical UNI
Policy Framework QoS Information Model for MPLS