Internet Draft Internet Draft W. Wimer Expires: December 31, 1999 FORE Systems, Inc. <draft-wimer-mpls-atm-rsvp-00.txt> June 1999 MPLS Using RSVP and ATM VC Switching Status of this Memo 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." 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 [MPLS-ARCH] 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. Additional ATM-specific routing and addressing is optional but not required. ATM switches used in this way are known as ATM-LSRs. This document extends and clarifies the relevant portions of [MPLS- ARCH] and [LSP-TUNNEL] by specifying in more detail the procedures to be used for distributing labels to or from ATM-LSRs, when those labels represent LSP tunnels setup via the RSVP protocol with MPLS extensions [LSP-TUNNEL]. 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 [MPLS-ENCAPS]. Wimer Expires December 31, 1999 [Page 1] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 Contents Acknowledgements ....................................... 2 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 Virtual Path .................... 7 7.3 Connections via an ATM SVC ............................. 8 8 Encapsulation .......................................... 12 9 RSVP Hop Count Object .................................. 14 10 TTL Manipulation ....................................... 16 11 Security Considerations ................................ 17 12 References ............................................. 17 13 Author's Address ....................................... 18 Acknowledgments Several portions of this document have been adapted from "MPLS using LDP and ATM VC Switching" <draft-ietf-mpls-atm-02.txt> by Bruce Davie, Jeremy Lawrence, Keith McCloghrie, Yakov Rekhter, Eric Rosen, George Swallow, and Paul Doolan. Other contributors to that document include Anthony Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan Littlewood, and Dan Tappan. These efforts are gratefully acknowledged. 1. Introduction The MPLS Architecture [MPLS-ARCH] 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. Additional ATM-specific routing and addressing is optional but not required. ATM switches used in this way are known as ATM-LSRs. This document extends and clarifies the relevant portions of [MPLS- ARCH] and [LSP-TUNNEL] by specifying in more detail the procedures to be used for distributing labels to or from ATM-LSRs, when those labels represent LSP tunnels setup via the RSVP protocol with MPLS extensions [LSP-TUNNEL]. The label distribution technique described here is referred to in [MPLS-ARCH] as "downstream-on-demand". Wimer Expires December 31, 1999 [Page 2] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 This document does NOT specify the label distribution techniques to be used in the following cases: - the routes are chosen on a hop-by-hop basis as label distribution proceeds, rather than being explicitly chosen before label distribution begins, - 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 [MPLS-ENCAPS]. The specified encapsulation is the same as that used for multicast or hop-by-hop routed labeled packets. [MPLS-LDP-ATM] This document uses terminology from [MPLS-ARCH]. 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 [REQUIRE]. 3. Definitions A Label Switching Router (LSR) is a device which implements the label switching control and forwarding components described in [MPLS-ARCH]. 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. Local configuration parameters control which particular discipline is used between a given pair of LSRs interconnected by LC-ATM interfaces. 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. Wimer Expires December 31, 1999 [Page 3] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 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. 4. Special Characteristics of ATM Switches While the MPLS architecture permits considerable flexibility in LSR implementation, an ATM-LSR is constrained by the capabilities of the (possibly pre-existing) hardware and the restrictions on such matters as cell format imposed by ATM standards. Because of these constraints, some special procedures are required for ATM-LSRs. Some of the key features of ATM switches that affect their behavior as LSRs are: - the label swapping function is performed on fields (the VCI and/or VPI) in the cell header; this dictates the size and placement of the label(s) in a packet. - multipoint-to-point and multipoint-to-multipoint VCs are generally not supported. This means that most switches cannot Wimer Expires December 31, 1999 [Page 4] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 support 'VC-merge' as defined above. - 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. 5. Label Switching Control Component for ATM To support label switching, an ATM switch MUST implement the control component of label switching. This consists primarily of label allocation, distribution, and maintenance procedures. Label binding information may be communicated by several mechanisms. This document is concerned with the application of the RSVP protocol (with LSP tunnel extensions) to ATM-LSRs. In some cases, LSRs make use of other protocols (e.g. LDP, 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. 6. Hybrid Switches (Ships in the Night) The existence of the label switching control component on an ATM switch does not preclude the ability to support the ATM control component defined by the ITU and ATM Forum on the same switch and the same interfaces. The two control components, label switching and the ITU/ATM Forum defined, would operate independently. Definition of how such a device operates is beyond the scope of this document. However, only a small amount of information needs to be 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 LSP tunnels, and using the label value to forward packets, including determining the value of any replacement label. See [MPLS-ARCH] and [LSP-TUNNEL] for further details. In an ATM-LSR, the label is Wimer Expires December 31, 1999 [Page 5] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 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 5.1 of RFC 1483 [RFC1483]. In addition, if two peer LSRs 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 RSVP 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 [RFC1483] 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 [RFC1483], or the LLC/SNAP encapsulation, as defined in Section 4.1 of RFC 1483 [RFC1483]. 7.1. Direct Connections We say that two LSRs are "directly connected" over an LC-ATM interface if all cells transmitted out that interface by one LSR will reach the other, and there are no ATM switches between the two LSRs. When two LSRs are directly connected via an LC-ATM interface, they jointly control the allocation of VPIs/VCIs on the interface connecting them. They may agree to use the VPI/VCI field to encode a single label. The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI 32. Other values can be configured, as long as both parties are aware of the configured value. A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label. With the exception of these reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces. The allowable range of VPI/VCIs is communicated through RSVP using the "Label Request with ATM Label Range" object. When signaling LSP setup between a pair of LSRs directly connected Wimer Expires December 31, 1999 [Page 6] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 via LC-ATM interfaces, the VPI and VCI values are encoded as the top label within the RSVP Label Object as shown below. (Note that [LSP- TUNNEL] encodes the label stack object such that the top label appears in the rightmost 4 octets of the label object.) The field marked "MBZ" is reserved for future use; it must be zero when transmitted and must be ignored upon receipt. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object contents: remainder of label stack) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ | VPI | VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 7.2. Connections via an ATM Virtual Path Sometimes it can 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 an ATM Virtual Path. In this case, the VPI field is not available to MPLS, and the label MUST be encoded entirely within the VCI field. In this case, the default VCI value of the non-MPLS connection between the LSRs is 32. The VPI is set to whatever is required to make use of the Virtual Path. A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST NOT be used as the encoding of a label. With the exception of these reserved values, the VPI/VCI values used in the two directions of the link MAY be treated as independent spaces. The allowable range of VPI/VCIs is communicated through RSVP. If more than one VPI is used for label switching, the allowable range of VCIs may be different for each VPI. For each independent RSVP session, a suitable range is communicated using the "Label Request with ATM Label Range" object. When signaling LSP setup between a pair of LSRs connected via an ATM Virtual Path, the VPI and VCI values are encoded as the top label within the RSVP Label Object as shown below. (Note that [LSP-TUNNEL] encodes the label stack object such that the top label appears in the rightmost 4 octets of the label object.) The field marked "MBZ" is Wimer Expires December 31, 1999 [Page 7] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 reserved for future use; it must be zero when transmitted and must be ignored upon receipt. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object contents: remainder of label stack) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ | VPI | VCI | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 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, there is no default VPI or VCI value for the non-MPLS connection. In general, an ATM SVC will not have the same VPI/VCI values at each of its endpoints. [VCID] discusses a procedure for exchanging an end-to-end identifier called a VCID. The VCID is communicated through RSVP as if it were the label value. [GIT] offers a mechanism for communicating the VCID within ATM signaling messages, thus providing a mapping between the VCID and the SVC being established. The top label of a received MPLS data packet is then inferred (via a one-to-one mapping) from the virtual circuit on which the packet arrived: SVC's Local VPI/VCI <---> VCID <---> NHLFE / RSVP state This document recommends a particular combination of the above techniques and details the interactions involved. [VCID] proposes a model in which an upstream LSR chooses a VCID value and then communicates that VCID value to the downstream LSR either during ATM SVC establishment or shortly thereafter. The downstream LSR must then return that particular VCID value in subsequent label mapping messages. Note that the downstream LSR thus has no choice in label assignment. In contrast, this document recommends a model more consistent with downstream label assignment. In particular, the downstream LSR chooses the VCID and passes it to the upstream LSR in RSVP Resv messages, before any ATM signaling is performed. When the Wimer Expires December 31, 1999 [Page 8] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 upstream LSR receives the Resv message, it then initiates an ATM Setup message toward the downstream LSR and includes the VCID within the Generic Identifier Information Element within the ATM Setup message. [GIT] suggests a number of techniques for carrying IP-related information within ATM signaling messages. Included is an approach for encapsulating RSVP messages entirely within ATM signaling messages using the User-to-User Signaling Information Element. However, this document recommends against the use of this particular approach for two reasons. First, complex RSVP messages may exceed the information element's 133-octet length restriction. Second, certain RSVP messages (state refreshes, errors, etc.) need to be sent at times other than initial connection-establishment time. Thus a separate non-ATM-signaling mechanism would be needed for these messages anyway. The use of a single transport mechanism (the non- MPLS connection) for all RSVP messages seems preferable to the use of two separate mechanisms. This document recommends sending RSVP messages over the normal unlabeled VC and recommends a downstream label-assignment discipline. The RSVP exchange proceeds as follows: |-----ATM SVC Cloud----| LSR u LSR d | | ...----Path--------->| | |--------Path--------->| | |--------Path----->... | | | |<---Resv w/label--... |<--Resv w/label=VCID--| | | |---ATM Setup w/VCID-->| | | |<-ATM Connect w/VCID--| ...<--Resv w/label---| | | | Wimer Expires December 31, 1999 [Page 9] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 The full procedure is: 1. In general, LSRs u and d receive and forward RSVP Path messages according to [LSP-TUNNEL]. When LSR u forwards a Path message to LSR d, LSR u uses its non-MPLS connection to LSR d. The "Label Request without Label Range" object (C_Type = 1) is used in the Path message (not the "Label Request with ATM Label Range" (C_Type = 2)). 2. Eventually, LSR d receives an RSVP Resv message from its downstream LSR (or LSR d is the end of the LSP tunnel). 3. LSR d allocates a label=VCID in the range 16 to 1048575 and records the label in the appropriate state block for this LSP tunnel. 4. Using its non-MPLS connection to LSR u, LSR d forwards the Resv message to LSR u containing the label=VCID in the Label Object. 5. LSR u receives the RSVP Resv message from LSR d and records it in its appropriate state block for this LSP tunnel. 6. LSR u initiates an ATM Setup message (with appropriate QoS parameters) toward LSR d. It includes the VCID value in the Setup message, encoded in the Generic Identifier Information Element [GIT]. The "standard/application" field is coded as 0x06 (MPLS) and the "identifier type" field is coded as 0x02 (Resource). Only the first such Generic Identifier is considered significant; additional MPLS+Resource entries MUST be ignored. See below and [GIT] for the format of the Generic Identifier information element. 7. LSR d receives the incoming ATM Setup message and uses the included VCID value to locate the corresponding state block. This allows LSR d to associate the VPI/VCI of the new incoming SVC with the appropriate state block and Next Hop Label Forwarding Entry (NHLFE). 8. LSR d responds with an ATM Connect message and "echos" back the Generic Identifier information element containing the received VCID value. This serves as a confirmation to LSR u that the VCID has been successfully received. Wimer Expires December 31, 1999 [Page 10] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 The encoding of the VCID within the Generic Identifier Information Element is: Bits 8 7 6 5 4 3 2 1 Octets +-----+-----+-----+-----+-----+-----+-----+-----+ | Information element identifier | | = Generic identifier transport IE (0x7F) | 1 +-----+-----+-----+-----+-----+-----+-----+-----+ | 1 | Coding | IE instruction field | | Ext | standard |Flag |Res. | IE action ind. | 2 +-----+-----+-----+-----+-----+-----+-----+-----+ | Length of contents of information element | 3-4 +-----+-----+-----+-----+-----+-----+-----+-----+ | Identifier related standard/application | | = MPLS (0x06) | 5 +-----+-----+-----+-----+-----+-----+-----+-----+ | Identifier type | | = Resource (0x02) | 6 +-----+-----+-----+-----+-----+-----+-----+-----+ | Identifier length | | = 4 octets (0x04) | 7 +-----+-----+-----+-----+-----+-----+-----+-----+ | | 8 | MPLS VCID (4 octets) | 9 | | 10 | | 11 +-----+-----+-----+-----+-----+-----+-----+-----+ The Identifier type field is Resource (0x02). The Identifier length is 4 octets. The MPLS VCID [12] is assigned to the Identifier value field. Wimer Expires December 31, 1999 [Page 11] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 When signaling LSP setup between a pair of LSRs connected via ATM SVCs, the VPI and VCI values are encoded as the top label within the RSVP Label Object as shown below. (Note that [LSP-TUNNEL] encodes the label stack object such that the top label appears in the rightmost 4 octets of the label object.) The field marked "MBZ" is reserved for future use; it must be zero when transmitted and must be ignored upon receipt. NOTE: This is the same as the normal label encoding in [LSP-TUNNEL]. 0 1 2 3 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | | // (Object contents: remainder of label stack) // | | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | MBZ | VCID | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 8. 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 [RFC1483]. 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" [MPLS-ENCAPS]. 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 Wimer Expires December 31, 1999 [Page 12] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 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 RSVP 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. Note that if the shim header is not present, the outgoing TTL is carried in the TTL field of the network layer header. Wimer Expires December 31, 1999 [Page 13] Internet Draft draft-wimer-mpls-atm-rsvp-00.txt June 1999 9. RSVP Hop Count Object The Resv message is augmented with aobject for use across ATM-LSR domains. The format of the Resv message is as follows: ::= [ ] [ ] [ ] [ ... ]