Network Working Group B. Davie Request for Comments: 3035 J. Lawrence Category: Standards Track K. McCloghrie E. Rosen G. Swallow Cisco Systems, Inc. Y. Rekhter Juniper Networks P. Doolan Ennovate Networks, Inc. January 2001 MPLS using LDP and ATM VC Switching Status of this Memo This document specifies an Internet standards track protocol for the Internet community, and requests discussion and suggestions for improvements. Please refer to the current edition of the "Internet Official Protocol Standards" (STD 1) for the standardization state and status of this protocol. Distribution of this memo is unlimited. Copyright Notice Copyright (C) The Internet Society (2001). All Rights Reserved.
AbstractThe Multiprotocol Label Switching (MPLS) Architecture  discusses a way in which Asynchronous Transfer Mode (ATM) switches may be used as Label Switching Routers. The ATM switches run network layer routing algorithms (such as Open Shortest Path First (OSPF), Intermediate System to Intermediate System (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 (Label Switching Routers). This document extends and clarifies the relevant portions of  and  by specifying in more detail the procedures which to be used when distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see ) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to .
1 Introduction ........................................... 2 2 Specification of Requirements .......................... 3 3 Definitions ............................................ 3 4 Special Characteristics of ATM Switches ................ 4 5 Label Switching Control Component for ATM .............. 5 6 Hybrid Switches (Ships in the Night) ................... 5 7 Use of VPI/VCIs ....................................... 5 7.1 Direct Connections ..................................... 6 7.2 Connections via an ATM VP .............................. 7 7.3 Connections via an ATM SVC ............................. 7 8 Label Distribution and Maintenance Procedures .......... 7 8.1 Edge LSR Behavior ...................................... 8 8.2 Conventional ATM Switches (non-VC-merge) ............... 9 8.3 VC-merge-capable ATM Switches .......................... 11 9 Encapsulation .......................................... 12 10 TTL Manipulation ....................................... 13 11 Optional Loop Detection: Distributing Path Vectors ..... 15 11.1 When to Send Path Vectors Downstream ................... 15 11.2 When to Send Path Vectors Upstream ..................... 16 12 Security Considerations ................................ 17 13 Intellectual Property Considerations ................... 17 14 References ............................................. 18 15 Acknowledgments ........................................ 18 16 Authors' Addresses ..................................... 18 17 Full Copyright Statement ............................... 20 1] discusses the 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. This document extends and clarifies the relevant portions of  and  by specifying in more detail the procedures which are to be used for distributing labels to or from ATM-LSRs, when those labels represent Forwarding Equivalence Classes (FECs, see ) for which the routes are determined on a hop-by-hop basis by network layer routing algorithms. The label distribution technique described here is referred to in  as "downstream-on-demand". This label distribution technique MUST be used by ATM-LSRs that are not capable of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs that are capable of VC merge.
This document does NOT specify the label distribution techniques to be used in the following cases: - the routes are explicitly chosen before label distribution begins, instead of being chosen on a hop-by-hop basis as label distribution proceeds, - the routes are intended to diverge in any way from the routes chosen by the conventional hop-by-hop routing at any time, - the labels represent FECs that consist of multicast packets, - the LSRs use "VP merge". Further statements made in this document about ATM-LSR label distribution do not necessarily apply in these cases. This document also specifies the MPLS encapsulation to be used when sending labeled packets to or from ATM-LSRs, and in that respect is a companion document to . The specified encapsulation is to be used for multicast or explicitly routed labeled packets as well. This document uses terminology from . RFC 2119. 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 contents of the VCI field or the combined contents of the VPI and VCI fields. Any two LDP peers which are connected via an LC-ATM interface will use LDP negotiations to determine which of these cases is applicable to that interface. An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards cells between these interfaces, using labels carried in the VCI or VPI/VCI field, without reassembling the cells into frames before forwarding.
A frame-based LSR is a LSR which forwards complete frames between its interfaces. Note that such a LSR may have zero, one or more LC-ATM interfaces. Sometimes a single box may behave as an ATM-LSR with respect to certain pairs of interfaces, but may behave as a frame-based LSR with respect to other pairs. For example, an ATM switch with an ethernet interface may function as an ATM-LSR when forwarding cells between its LC-ATM interfaces, but may function as a frame-based LSR when forwarding frames from its ethernet to one of its LC-ATM interfaces. In such cases, one can consider the two functions (ATM-LSR and frame-based LSR) as being coresident in a single box. It is intended that an LC-ATM interface be used to connect two ATM- LSRs, or to connect an ATM-LSR to a frame-based LSR. The use of an LC-ATM interface to connect two frame-based LSRs is not considered in this document. An ATM-LSR domain is a set of ATM-LSRs which are mutually interconnected by LC-ATM interfaces. The Edge Set of an ATM-LSR domain is the set of frame-based LSRs which are connected to members of the domain by LC-ATM interfaces. A frame-based LSR which is a member of an Edge Set of an ATM-LSR domain may be called an Edge LSR. VC-merge is the process by which a switch receives cells on several incoming VCIs and transmits them on a single outgoing VCI without causing the cells of different AAL5 PDUs to become interleaved.
- there is generally no capability to perform a 'TTL-decrement' function as is performed on IP headers in routers. This document describes ways of applying label switching to ATM switches which work within these constraints. 2]. This document imposes certain requirements on the LDP. This document considers only the case where the label switching control component uses information learned directly from network layer routing protocols. It is presupposed that the switch participates as a peer in these protocols (e.g., OSPF, IS-IS). In some cases, LSRs make use of other protocols (e.g., RSVP, PIM, BGP) to distribute label bindings. In these cases, an ATM-LSR would need to participate in these protocols. However, these are not explicitly considered in this document. Support of label switching on an ATM switch does NOT require the switch to support the ATM control component defined by the ITU and ATM Forum (e.g., UNI, PNNI). An ATM-LSR may OPTIONALLY respond to OAM cells. 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. Labeled packets MUST be transmitted using the null encapsulation, as defined in Section 6.1 of RFC 2684 . 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 2684  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 NOT be in the 0-32 range. These may use either the null encapsulation, as defined in Section 6.1 of RFC 2684 , or the LLC/SNAP encapsulation, as defined in Section 5.1 of RFC 2684 .
4]. The procedures described in  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. 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. 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. When a member of the Edge Set of the ATM-LSR domain receives a label binding request from an ATM-LSR, it allocates a label, and returns (via LDP) a binding containing the allocated label back to the peer that originated the request. It sets the hop count in the binding to 1. When a routing calculation causes an Edge LSR to change the next hop for a particular FEC, and the former next hop was in the ATM-LSR domain, the Edge LSR SHOULD notify the former next hop (via LDP) that the label binding associated with the FEC is no longer needed.
1] and ), in particular "ingress-initiated ordered control". In this case, as long as the ATM-LSR receives from downstream a hop count which is greater than 0 and less than MAXHOP, it MUST increment the hop count it receives from downstream and MUST include the result in the binding it returns upstream. However, if the hop count exceeds MAXHOP, a label binding MUST NOT be passed upstream. Rather, the upstream LDP peer MUST be informed that the requested label binding cannot be satisfied. If the hop count received from downstream is 0, the hop count passed upstream should also be 0; this indicates that the actual hop count is unknown. Alternatively, the ATM-LSR MAY return the binding upstream without waiting for a binding from downstream ("independent" control, as defined in  and ). In this case, it specifies a hop count of 0 in the binding, indicating that the true hop count is unknown. The correct value for hop count will be returned later, as described below.
Note that an ATM-LSR, or a member of the edge set of an ATM-LSR domain, may receive multiple binding requests for the same FEC from the same ATM-LSR. It MUST generate a new binding for each request (assuming adequate resources to do so), and retain any existing binding(s). For each request received, an ATM-LSR MUST also generate a new binding request toward the next hop for the FEC. When a routing calculation causes an ATM-LSR to change the next hop for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that the label binding associated with the FEC is no longer needed. When a LSR receives a notification that a particular label binding is no longer needed, the LSR MAY deallocate the label associated with the binding, and destroy the binding. In the case where an ATM-LSR receives such notification and destroys the binding, it MUST notify the next hop for the FEC that the label binding is no longer needed. If a LSR does not destroy the binding, it may re-use the binding only if it receives a request for the same FEC with the same hop count as the request that originally caused the binding to be created. When a route changes, the label bindings are re-established from the point where the route diverges from the previous route. LSRs upstream of that point are (with one exception, noted below) oblivious to the change. Whenever a LSR changes its next hop for a particular FEC, if the new next hop is reachable via an LC-ATM interface, then for each label that it has bound to that FEC, and distributed upstream, it MUST request a new label binding from the new next hop. When an ATM-LSR receives a label binding for a particular FEC from a downstream neighbor, it may already have provided a corresponding label binding for this FEC to an upstream neighbor, either because it is using independent control, or because the new binding from downstream is the result of a routing change. In this case, unless the hop count is 0, it MUST extract the hop count from the new binding and increment it by one. If the new hop count is different from that which was previously conveyed to the upstream neighbor (including the case where the upstream neighbor was given the value 'unknown') the ATM-LSR MUST notify the upstream neighbor of the change. Each ATM-LSR in turn MUST increment the hop count and pass it upstream until it reaches the ingress Edge LSR. If at any point the value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw the binding from the upstream neighbor. A hop count of 0 MUST be passed upstream unchanged.
Whenever an ATM-LSR originates a label binding request to its next hop LSR as a result of receiving a label binding request from another (upstream) LSR, and the request to the next hop LSR is not satisfied, the ATM-LSR SHOULD destroy the binding created in response to the received request, and notify the requester (via LDP). If an ATM-LSR receives a binding request containing a hop count that exceeds MAXHOP, it MUST not establish a binding, and it MUST return an error to the requester. When a LSR determines that it has lost its LDP session with another LSR, the following actions are taken. Any binding information learned via this connection MUST be discarded. For any label bindings that were created as a result of receiving label binding requests from the peer, the LSR MAY destroy these bindings (and deallocate labels associated with these binding). An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding requests from its neighbors. That is, if it receives a request for a binding to a particular FEC and the LSR making that request is, according to this ATM-LSR, the next hop for that FEC, it should not return a binding for that route. It is expected that non-merging ATM-LSRs would generally use "conservative label retention mode" .
If the ATM-LSR does not have an outgoing label binding for the FEC, but does have an outstanding request for one, it need not issue another request. When sending a label binding upstream, the hop count associated with the corresponding binding from downstream MUST be incremented by 1, and the result transmitted upstream as the hop count associated with the new binding. However, there are two exceptions: a hop count of 0 MUST be passed upstream unchanged, and if the hop count is already at MAXHOP, the ATM-LSR MUST NOT pass a binding upstream, but instead MUST send an error upstream. Note that, just like conventional ATM-LSRs and members of the edge set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a new binding every time it receives a request from upstream, since there may be switches upstream which do not support VC-merge. However, it only needs to issue a corresponding binding request downstream if it does not already have a label binding for the appropriate route. When a change in the routing table of a VC-merge-capable ATM-LSR causes it to select a new next hop for one of its FECs, it MAY optionally release the binding for that route from the former next hop. If it doesn't already have a corresponding binding for the new next hop, it must request one. (The choice between conservative and liberal label retention mode  is an implementation option.) If a new binding is obtained, which contains a hop count that differs from that which was received in the old binding, then the ATM-LSR must take the new hop count, increment it by one, and notify any upstream neighbors who have label bindings for this FEC of the new value. Just as with conventional ATM-LSRs, this enables the new hop count to propagate back towards the ingress of the ATM-LSR domain. If at any point the hop count exceeds MAXHOP, then the label bindings 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. Section 6.1 of RFC 2684 .
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" . 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 its CoS, are carried in the TTL and CoS fields respectively of the top stack entry in the shim. Note that if a packet has a label stack with only one entry, this requires it to have a single-entry shim (4 bytes), even though the actual label value is encoded into the VPI/VCI field. This is done to ensure that the packet always has a shim. Otherwise, there would be no way to determine whether it had one or not, i.e., no way to determine whether there are additional label stack entries. The only ways to eliminate this extra overhead are: - through apriori knowledge that packets have only a single label (e.g., perhaps the network only supports one level of label) - by using two VCs per FEC, one for those packets which have only a single label, and one for those packets which have more than one label The second technique would require that there be some way of signalling via LDP that the VC is carrying only packets with a single label, and is not carrying a shim. When supporting VC merge, one would also have to take care not to merge a VC on which the shim is not used into a VC on which it is used, or vice versa. While either of these techniques is permitted, it is doubtful that they have any practical utility. Note that if the shim header is not present, the outgoing TTL is carried in the TTL field of the network layer header.
The details of the TTL adjustment procedure are as follows. If a packet was received by the Edge LSR as an unlabeled packet, the "incoming TTL" comes from the IP header. (Procedures for other network layer protocols are for further study.) If a packet was received by the Edge LSR as a labeled packet, using the encapsulation specified in , the "incoming TTL" comes from the entry at the top of the label stack. If a hop count has been associated with the label binding that is used when the packet is forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) the difference between the incoming TTL and the hop count. If a hop count has not been associated with the label binding that is used when the packet is forwarded, the "outgoing TTL" is set to the larger of (a) 0 or (b) one less than the incoming TTL. If this causes the outgoing TTL to become zero, the packet MUST NOT be transmitted as a labeled packet using the specified label. The packet can be treated in one of two ways: - it may be treated as having expired; this may cause an ICMP message to be transmitted; - the packet may be forwarded, as an unlabeled packet, with a TTL that is 1 less than the incoming TTL; such forwarding would need to be done over a non-MPLS connection. Of course, if the incoming TTL is 1, only the first of these two options is applicable. If the packet is forwarded as a labeled packet, the outgoing TTL is carried as specified in section 9. When an Edge LSR receives a labeled packet over an LC-ATM interface, it obtains the incoming TTL from the top label stack entry of the generic encapsulation, or, if that encapsulation is not present, from the IP header. If the packet's next hop is an ATM-LSR, the outgoing TTL is formed using the procedures described in this section. Otherwise the outgoing TTL is formed using the procedures described in . The procedures in this section are intended to apply only to unicast packets.
section 8.2). This procedure detects the case where the request messages loop though a sequence of non-merging ATM-LSRs.
section 8, there are circumstances in which an LSR R must inform its upstream neighbors, via a label binding response message, of a change in hop count for a particular LSP. If the following conditions all hold: - R is configured for the LDPV procedure, - R supports VC-merge, - R is not the egress for that LSP, and - R is not informing its neighbors of a decrease in the hop count, then R MUST include a path vector object in the response message. If the change in hop count is a result of R's having been informed by its next hop, S, of a change in hop count, and the message from S to R included a path vector object, then if the above conditions hold, R MUST add itself to this object and pass the result upstream. Otherwise, if the above conditions hold, R MUST create a new object with only its own address. If R is configured for the LDPV procedure, and R supports VC merge, then it MAY include a path vector object in any label binding response message that it sends upstream. In particular, at any time that R receives a label binding response from its next hop, if that response contains a path vector, R MAY (if configured for the LDPV procedure) send a response to its upstream neighbors, containing the path vector object formed by adding its own address to the received path vector. If R does not support VC merge, it SHOULD NOT send a path vector object upstream. If an LSR receives a message from its next hop, with a path vector object containing its own address, then LSR MUST act as it would if it received a message with a hop count equal to MAXHOP. LSRs which are configured for the LDPV procedure SHOULD NOT store a path vector once the corresponding path vector object has been transmitted.
Note that if the ATM-LSR domain consists entirely of non-merging ATM-LSRs, path vectors need not ever be sent upstream, since any loops will be detected by means of the path vectors traveling downstream. By not sending path vectors unless the hop count increases, one avoids sending them in many situations when there is no loop. The cost is that in some situations in which there is a loop, the time to detect the loop may be lengthened. 2].
The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights which may cover technology that may be required to practice this standard. Please address the information to the IETF Executive Director.  Rosen, E., Viswanathan, A. and R. Callon "Multi-Protocol Label Switching Architecture", RFC 3031, January 2001.  Andersson L., Doolan P., Feldman N., Fredette A. and R. Thomas, "LDP Specification", RFC 3036, January 2001.  Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., Li, T. and A. Conta, "MPLS Label Stack Encoding", RFC 3032, January 2001.  Nagami, K., Demizu N., Esaki H. and P. Doolan, "VCID Notification over ATM Link for LDP", RFC 3038, January 2001.  Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation Layer 5", RFC 2684, September 1999.
Jeremy Lawrence Cisco Systems, Inc. 99 Walker St. North Sydney, NSW, Australia EMail: firstname.lastname@example.org Keith McCloghrie Cisco Systems, Inc. 170 Tasman Drive San Jose, CA, 95134 EMail: email@example.com Yakov Rekhter Juniper Networks 1194 N. Mathilda Avenue Sunnyvale, CA 94089 EMail: firstname.lastname@example.org Eric Rosen Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 EMail: email@example.com George Swallow Cisco Systems, Inc. 250 Apollo Drive Chelmsford, MA, 01824 EMail: firstname.lastname@example.org
Acknowledgement Funding for the RFC Editor function is currently provided by the Internet Society.