NOTE: This charter is a snapshot of that in effect at the time of the 38th IETF Meeting in Memphis, Tennessee. It may now be out-of-date.
Vijay Srinivasan <vijay@raleigh.ibm.com>
George Swallow <swallow@cisco.com>
Joel Halpern <jhalpern@newbridge.com>
Joel Halpern <jhalpern@newbridge.com>
General Discussion:mpls@external.cisco.com
To Subscribe: mpls-request@cisco.com
In Body: in body: subscribe
Archive: ftp://ftp.cisco.com/ftp/mpls
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.
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.
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:
Written Minutes Not Received (Provided Slides)
3. ARIS Support for LAN Media Switching