--- 1/draft-ietf-mpls-atm-01.txt 2006-02-05 00:37:14.000000000 +0100 +++ 2/draft-ietf-mpls-atm-02.txt 2006-02-05 00:37:14.000000000 +0100 @@ -1,45 +1,47 @@ - Network Working Group Bruce Davie Internet Draft Jeremy Lawrence -Expiration Date: May 1999 Keith McCloghrie +Expiration Date: October 1999 Keith McCloghrie Yakov Rekhter Eric Rosen George Swallow Cisco Systems, Inc. Paul Doolan Ennovate Networks, Inc. - November 1998 + April 1999 - MPLS using ATM VC Switching + MPLS using LDP and ATM VC Switching - draft-ietf-mpls-atm-01.txt + draft-ietf-mpls-atm-02.txt Status of this Memo - This document is an Internet-Draft. Internet-Drafts are working - documents of the Internet Engineering Task Force (IETF), its areas, - and its working groups. Note that other groups may also distribute - working documents as Internet-Drafts. + This document is an Internet-Draft and is in full conformance with + all provisions of Section 10 of RFC2026. + + Internet-Drafts are working documents of the Internet Engineering + Task Force (IETF), its areas, and its working groups. Note that + other groups may also distribute working documents as Internet- + Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." - To view the entire list of current Internet-Drafts, please check the - "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow - Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern - Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific - Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). + The list of current Internet-Drafts can be accessed at + http://www.ietf.org/ietf/1id-abstracts.txt. + + The list of Internet-Draft Shadow Directories can be accessed at + http://www.ietf.org/shadow.html. Abstract The MPLS Architecture [1] discusses a way in which ATM switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as OSPF, IS-IS, etc.), and their data forwarding is based on the results of these routing algorithms. No ATM-specific routing or addressing is needed. ATM switches used in this way are known as ATM-LSRs. @@ -122,21 +124,21 @@ sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to [3]. The specified encapsulation is to be used for multicast or explicitly routed labeled packets as well. This document uses terminology from [1]. 2. Specification of Requirements The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this - document are to be interpreted as described in RFC 2119 [3]. + document are to be interpreted as described in RFC 2119. 3. Definitions A Label Switching Router (LSR) is a device which implements the label switching control and forwarding components described in [1]. A label switching controlled ATM (LC-ATM) interface is an ATM interface controlled by the label switching control component. When a packet traversing such an interface is received, it is treated as a labeled packet. The packet's top label is inferred either from the @@ -241,27 +243,32 @@ consistent between the two control components, such as the portions of the VPI/VCI space which are available to each component. 7. Use of VPI/VCIs Label switching is accomplished by associating labels with Forwarding Equivalence Classes, and using the label value to forward packets, including determining the value of any replacement label. See [1] for further details. In an ATM-LSR, the label is carried in the VPI/VCI field, or, when two ATM-LSRs are connected via an ATM - "Virtual Path", in the VCI field. In addition, if two LDP peers are - connected via an LC-ATM interface, a non-MPLS connection, capable of - carrying unlabelled IP packets, MUST be available. This non-MPLS - connection is used to carry LDP packets between the two peers, and - MAY also be used (but is not required to be used) for other unlabeled - packets (such as OSPF packets, etc.). The LLC/SNAP encapsulation of - RFC 1483 [5] MUST be used on the non-MPLS connection. + "Virtual Path", in the VCI field. + + Labeled packets MUST be transmitted using the null encapsulation, as + defined in Section 5.1 of RFC 1483 [5]. + + In addition, if two LDP peers are connected via an LC-ATM interface, + a non-MPLS connection, capable of carrying unlabelled IP packets, + MUST be available. This non-MPLS connection is used to carry LDP + packets between the two peers, and MAY also be used (but is not + required to be used) for other unlabeled packets (such as OSPF + packets, etc.). The LLC/SNAP encapsulation of RFC 1483 [5] MUST be + used on the non-MPLS connection. It SHOULD be possible to configure an LC-ATM interface with additional VPI/VCIs that are used to carry control information or non-labelled packets. In that case, the VCI values MUST be in the 0-32 range. These may use either the null encapsulation, as defined in Section 5.1 of RFC 1483 [5], or the LLC/SNAP encapsulation, as defined in Section 4.1 of RFC 1483 [5]. 7.1. Direct Connections @@ -309,53 +316,61 @@ The allowable ranges of VPI/VCIs are communicated through LDP. If more than one VPI is used for label switching, the allowable range of VCIs may be different for each VPI, and each range is communicated through LDP. 7.3. Connections via an ATM SVC Sometimes it may be useful to treat two LSRs as adjacent (in some LSP) across an LC-ATM interface, even though the connection between them is made through an ATM "cloud" via a set of ATM Switched Virtual - Circuits. In this case, the procedures described in [4] MUST be used - to assign a VCID to each such VC, and LDP is used to bind a VCID to a - FEC. The top label of a received packet is then inferred (via a - one-to-one mapping) from the virtual circuit on which the packet - arrived. + Circuits. - In this case, there is no default VPI or VCI value for the non-MPLS - connection. + The current document does not specify the procedure for handling this + case. Such procedures can be found in [4]. The procedures described + in [4] allow a VCID to be assigned to each such VC, and specify how + LDP can be used used to bind a VCID to a FEC. The top label of a + received packet would then be inferred (via a one-to-one mapping) + from the virtual circuit on which the packet arrived. There would + not be a default VPI or VCI value for the non-MPLS connection. 8. Label Distribution and Maintenance Procedures This document discusses the use of "downstream-on-demand" label distribution (see [1]) by ATM-LSRs. These label distribution procedures MUST be used by ATM-LSRs that do not support VC-merge, and MAY also be used by ATM-LSRs that do support VC-merge. The procedures differ somewhat in the two cases, however. We therefore describe the two scenarios in turn. We begin by describing the behavior of members of the Edge Set of an ATM-LSR domain; these "Edge LSRs" are not themselves ATM-LSRs, and their behavior is the same whether the domain contains VC-merge capable LSRs or not. 8.1. Edge LSR Behavior Consider a member of the Edge Set of an ATM-LSR domain. Assume that, as a result of its routing calculations, it selects an ATM-LSR as the next hop of a certain FEC, and that the next hop is reachable via a LC-ATM interface. The Edge LSR uses LDP to request a label binding for that FEC from the next hop. The hop count field in the request - is set to 1. Once the Edge LSR receives the label binding - information, it may use MPLS forwarding procedures to transmit - packets in the specified FEC, using the specified label as an - outgoing label. (Or using the VPI/VCI that corresponds to the - specified VCID as the outgoing label, if VCIDs are being used.) + is set to 1 (but see the next paragraph). Once the Edge LSR receives + the label binding information, it may use MPLS forwarding procedures + to transmit packets in the specified FEC, using the specified label + as an outgoing label. (Or using the VPI/VCI that corresponds to the + specified VCID as the outgoing label, if the VCID technique of [4] is + being used.) + Note: if the Edge LSR's previous hop is using downstream-on-demand + label distribution to request a label from the Edge LSR for a + particular FEC, and if the Edge LSR is not merging the LSP from that + previous hop with any other LSP, and if the request from the previous + hop has a hop count of h, then the hop count in the request issued by + the Edge LSR should not be set to 1, but rather to h+1. The binding received by the edge LSR may contain a hop count, which represents the number of hops a packet will take to cross the ATM-LSR domain when using this label. If there is a hop count associated with the binding, the ATM-LSR SHOULD adjust a data packet's TTL by this amount before transmitting the packet. In any event, it MUST adjust a data packet's TTL by at least one before transmitting it. The procedures for doing so (in the case of IP packets) are specified in section 10. The procedures for encapsulating the packets are specified in section 9. @@ -549,20 +565,23 @@ for this route must be withdrawn from all upstream neighbors to whom a binding was previously provided. This ensures that any loops caused by routing transients will be detected and broken. 9. Encapsulation The procedures described in this section affect only the Edge LSRs of the ATM-LSR domain. The ATM-LSRs themselves do not modify the encapsulation in any way. + Labeled packets MUST be transmitted using the null encapsulation of + Section 5.1 of RFC 1483 [5]. + Except in certain circumstances specified below, when a labeled packet is transmitted on an LC-ATM interface, where the VPI/VCI (or VCID) is interpreted as the top label in the label stack, the packet MUST also contain a "shim header" [3]. If the packet has a label stack with n entries, it MUST carry a shim with n entries. The actual value of the top label is encoded in the VPI/VCI field. The label value of the top entry in the shim (which is just a "placeholder" entry) MUST be set to 0 upon transmission, and MUST be ignored upon reception. The packet's outgoing TTL, and @@ -756,31 +777,31 @@ Cisco Systems may seek patent or other intellectual property protection for some or all of the technologies disclosed in this document. If any standards arising from this document are or become protected by one or more patents assigned to Cisco Systems, Cisco intends to disclose those patents and license them under openly specified and non-discriminatory terms, for no fee. 14. References [1] Rosen E., Viswanathan, A., Callon R., "Multi-Protocol Label - Switching Architecture", Work in Progress, July 1998 + Switching Architecture", Work in Progress, April 1999. [2] Andersson L., Doolan P., Feldman N., Fredette A., Thomas R., - "Label Distribution Protocol", Work in Progress, August 1998. + "Label Distribution Protocol", Work in Progress, April 1999. [3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T., Conta, A., "MPLS Label Stack Encoding", Work in Progress, - September 1998. + April 1999. [4] Nagami, K., Demizu N., Esaki H., Doolan P., "VCID Notification - over ATM link", Work in Progress, August 1998. + over ATM link", Work in Progress, April 1999. [5] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 1483, July 1993 15. Acknowledgments Significant contributions to this work have been made by Anthony Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan Littlewood and Dan Tappan. We thank Alex Conta for his comments. @@ -794,22 +815,22 @@ E-mail: bsd@cisco.com Paul Doolan Ennovate Networks Inc. 330 Codman Hill Rd Boxborough, MA 01719 E-mail: pdoolan@ennovatenetworks.com Jeremy Lawrence Cisco Systems, Inc. - 1400 Parkmoor Ave. - San Jose, CA, 95126 + 99 Walker St. + North Sydney, NSW, Australia E-mail: jlawrenc@cisco.com Keith McCloghrie Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 E-mail: kzm@cisco.com