idnits 2.17.1 draft-ietf-mpls-atm-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-19) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** The abstract seems to contain references ([2], [3], [1]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: If an ATM-LSR receives a binding request containing a hop count that exceeds a configurable maximum, it MUST not establish a binding, and it MUST return an error to the requester. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 1998) is 9348 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) -- Possible downref: Non-RFC (?) normative reference: ref. '1' -- Possible downref: Non-RFC (?) normative reference: ref. '2' -- Possible downref: Non-RFC (?) normative reference: ref. '3' -- Possible downref: Non-RFC (?) normative reference: ref. '4' ** Obsolete normative reference: RFC 1483 (ref. '5') (Obsoleted by RFC 2684) Summary: 9 errors (**), 0 flaws (~~), 2 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Bruce Davie 3 Internet Draft Jeremy Lawrence 4 Expiration Date: March 1999 Keith McCloghrie 5 Yakov Rekhter 6 Eric Rosen 7 George Swallow 8 Cisco Systems, Inc. 10 Paul Doolan 11 Ennovate Networks, Inc. 13 September 1998 15 Use of Label Switching With ATM 17 draft-ietf-mpls-atm-00.txt 19 Status of this Memo 21 This document is an Internet-Draft. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 To view the entire list of current Internet-Drafts, please check the 32 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 33 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 34 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 35 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 37 Abstract 39 The MPLS Architecture [1] discusses a way in which ATM switches may 40 be used as Label Switching Routers. The ATM switches run network 41 layer routing algorithms (such as OSPF, IS-IS, etc.), and their data 42 forwarding is based on the results of these routing algorithms. No 43 ATM-specific routing or addressing is needed. ATM switches used in 44 this way are known as ATM-LSRs. 46 This document extends and clarifies the relevant portions of [1] and 47 [2] by specifying in more detail the procedures which to be used when 48 distributing labels to or from ATM-LSRs, when those labels represent 49 Forwarding Equivalence Classes (FECs, see [1]) for which the routes 50 are determined on a hop-by-hop basis by network layer routing 51 algorithms. 53 This document also specifies the MPLS encapsulation to be used when 54 sending labeled packets to or from ATM-LSRs, and in that respect is a 55 companion document to [3]. 57 Contents 59 1 Introduction ........................................... 3 60 2 Specification of Requirements .......................... 4 61 3 Definitions ............................................ 4 62 4 Special Characteristics of ATM Switches ................ 5 63 5 Label Switching Control Component for ATM .............. 5 64 6 Hybrid Switches (Ships in the Night) ................... 6 65 7 Use of VPI/VCIs ....................................... 6 66 7.1 Direct Connections ..................................... 6 67 7.2 Connections via an ATM VP .............................. 7 68 7.3 Connections via an ATM SVC ............................. 8 69 8 Label Distribution and Maintenance Procedures .......... 8 70 8.1 Edge LSR Behavior ...................................... 8 71 8.2 Conventional ATM Switches (non-VC-merge) ............... 9 72 8.3 VC-merge-capable ATM Switches .......................... 11 73 9 Encapsulation .......................................... 13 74 10 TTL Manipulation ....................................... 14 75 11 Security Considerations ................................ 15 76 12 Intellectual Property Considerations ................... 15 77 13 References ............................................. 15 78 14 Acknowledgments ........................................ 16 79 15 Authors' Addresses ..................................... 16 81 1. Introduction 83 The MPLS Architecture [1] discusses the way in which ATM switches may 84 be used as Label Switching Routers. The ATM switches run network 85 layer routing algorithms (such as OSPF, IS-IS, etc.), and their data 86 forwarding is based on the results of these routing algorithms. No 87 ATM-specific routing or addressing is needed. ATM switches used in 88 this way are known as ATM-LSRs. 90 This document extends and clarifies the relevant portions of [1] and 91 [2] by specifying in more detail the procedures which are to be used 92 for distributing labels to or from ATM-LSRs, when those labels 93 represent Forwarding Equivalence Classes (FECs, see [1]) for which 94 the routes are determined on a hop-by-hop basis by network layer 95 routing algorithms. The label distribution technique described here 96 is referred to in [1] as "downstream-on-demand". This label 97 distribution technique MUST be used by ATM-LSRs that are not capable 98 of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs 99 that are capable of VC merge. 101 This document does NOT specify the label distribution techniques to 102 be used in the following cases: 104 - the routes are explicitly chosen before label distribution 105 begins, instead of being chosen on a hop-by-hop basis as label 106 distribution proceeds, 108 - the labels represent FECs that consist of multicast packets, 110 - the LSRs use "VP merge". 112 Further statements made in this document about ATM-LSR label 113 distribution do not necessarily apply in these cases. 115 This document also specifies the MPLS encapsulation to be used when 116 sending labeled packets to or from ATM-LSRs, and in that respect is a 117 companion document to [3]. The specified encapsulation is to be used 118 for multicast or explicitly routed labeled packets as well. 120 This document uses terminology from [1]. 122 2. Specification of Requirements 124 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 125 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 126 document are to be interpreted as described in RFC 2119 [3]. 128 3. Definitions 130 A Label Switching Router (LSR) is a device which implements the label 131 switching control and forwarding components described in [1]. 133 A label switching controlled ATM (LC-ATM) interface is an ATM 134 interface controlled by the label switching control component. When a 135 packet traversing such an interface is received, it is treated as a 136 labeled packet. The packet's top label is inferred either from the 137 contents of the VCI field or the combined contents of the VPI and VCI 138 fields. Any two LDP peers which are connected via an LC-ATM 139 interface will use LDP negotiations to determine which of these cases 140 is applicable to that interface. 142 An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards 143 cells between these interfaces using labels carried in the VCI or 144 VPI/VCI field. 146 A frame-based LSR is a LSR which forwards complete frames between its 147 interfaces. Note that such a LSR may have zero, one or more LC-ATM 148 interfaces. 150 In general, an LC-ATM interface will be used either to connect two 151 ATM-LSRs, or to connect an ATM-LSR to a frame-based LSR. 153 An ATM-LSR domain is a set of ATM-LSRs which are mutually 154 interconnected by LC-ATM interfaces. 156 The Edge Set of an ATM-LSR domain is the set of frame-based LSRs 157 which are connected to members of the domain by LC-ATM interfaces. A 158 frame-based LSR which is a member of an Edge Set of an ATM-LSR domain 159 may be called an Edge LSR. 161 VC-merge is the process by which a switch receives cells on several 162 incoming VCIs and transmits them on a single outgoing VCI without 163 causing the cells of different AAL5 PDUs to become interleaved. 165 4. Special Characteristics of ATM Switches 167 While the MPLS architecture permits considerable flexibility in LSR 168 implementation, an ATM-LSR is constrained by the capabilities of the 169 (possibly pre-existing) hardware and the restrictions on such matters 170 as cell format imposed by ATM standards. Because of these 171 constraints, some special procedures are required for ATM-LSRs. 173 Some of the key features of ATM switches that affect their behavior 174 as LSRs are: 176 - the label swapping function is performed on fields (the VCI 177 and/or VPI) in the cell header; this dictates the size and 178 placement of the label(s) in a packet. 180 - multipoint-to-point and multipoint-to-multipoint VCs are 181 generally not supported. This means that most switches cannot 182 support `VC-merge' as defined above. 184 - there is generally no capability to perform a `TTL-decrement' 185 function as is performed on IP headers in routers. 187 This document describes ways of applying label switching to ATM 188 switches which work within these constraints. 190 5. Label Switching Control Component for ATM 192 To support label switching an ATM switch MUST implement the control 193 component of label switching. This consists primarily of label 194 allocation, distribution, and maintenance procedures. Label binding 195 information is communicated by several mechanisms, notably the Label 196 Distribution Protocol (LDP) [2]. This document imposes certain 197 requirements on the LDP. 199 This document considers only the case where the label switching 200 control component uses information learned directly from network 201 layer routing protocols. It is presupposed that the switch 202 participates as a peer in these protocols (e.g., OSPF, IS-IS). 204 In some cases, LSRs make use of other protocols (e.g. RSVP, PIM, BGP) 205 to distribute label bindings. In these cases, an ATM-LSR would need 206 to participate in these protocols. However, these are not explicitly 207 considered in this document. 209 Support of label switching on an ATM switch does NOT require the 210 switch to support the ATM control component defined by the ITU and 211 ATM Forum (e.g., UNI, PNNI). An ATM-LSR may OPTIONALLY respond to OAM 212 cells. 214 6. Hybrid Switches (Ships in the Night) 216 The existence of the label switching control component on an ATM 217 switch does not preclude the ability to support the ATM control 218 component defined by the ITU and ATM Forum on the same switch and the 219 same interfaces. The two control components, label switching and the 220 ITU/ATM Forum defined, would operate independently. 222 Definition of how such a device operates is beyond the scope of this 223 document. However, only a small amount of information needs to be 224 consistent between the two control components, such as the portions 225 of the VPI/VCI space which are available to each component. 227 7. Use of VPI/VCIs 229 Label switching is accomplished by associating labels with Forwarding 230 Equivalence Classes, and using the label value to forward packets, 231 including determining the value of any replacement label. See [1] 232 for further details. In an ATM-LSR, the label is carried in the 233 VPI/VCI field, or, when two ATM-LSRs are connected via an ATM 234 "Virtual Path", in the VCI field. In addition, if two LDP peers are 235 connected via an LC-ATM interface, a non-MPLS connection, capable of 236 carrying unlabelled IP packets, MUST be available. This non-MPLS 237 connection is used to carry LDP packets between the two peers, and 238 MAY also be used (but is not required to be used) for other unlabeled 239 packets (such as OSPF packets, etc.). The LLC/SNAP encapsulation of 240 RFC 1483 [5] MUST be used on the non-MPLS connection. 242 LDP MAY be used to advertise additional VPI/VCIs to carry control 243 information or non-labelled packets. These may use either the null 244 encapsulation, as defined in Section 5.1 of RFC 1483 [5], or the 245 LLC/SNAP encapsulation, as defined in Section 4.1 of RFC 1483 [5]. 247 7.1. Direct Connections 249 We say that two LSRs are "directly connected" over an LC-ATM 250 interface if all cells transmitted out that interface by one LSR will 251 reach the other, and there are no ATM switches between the two LSRs. 253 When two LSRs are directly connected via an LC-ATM interface, they 254 jointly control the allocation of VPIs/VCIs on the interface 255 connecting them. They may agree to use the VPI/VCI field to encode a 256 single label. 258 The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI 259 32. Other values can be configured, as long as both parties are 260 aware of the configured value. 262 A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST 263 NOT be used as the encoding of a label. 265 With the exception of these reserved values, the VPI/VCI values used 266 in the two directions of the link MAY be treated as independent 267 spaces. 269 The allowable ranges of VCIs are communicated through LDP. 271 7.2. Connections via an ATM VP 273 Sometimes it can be useful to treat two LSRs as adjacent (in some 274 LSP) across an LC-ATM interface, even though the connection between 275 them is made through an ATM "cloud" via an ATM Virtual Path. In this 276 case, the VPI field is not available to MPLS, and the label MUST be 277 encoded entirely within the VCI field. 279 In this case, the default VCI value of the non-MPLS connection 280 between the LSRs is 32. The VPI is set to whatever is required to 281 make use of the Virtual Path. 283 A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST 284 NOT be used as the encoding of a label. 286 With the exception of these reserved values, the VPI/VCI values used 287 in the two directions of the link MAY be treated as independent 288 spaces. 290 The allowable ranges of VPI/VCIs are communicated through LDP. If 291 more than one VPI is used for label switching, the allowable range of 292 VCIs may be different for each VPI, and each range is communicated 293 through LDP. 295 7.3. Connections via an ATM SVC 297 Sometimes it may be useful to treat two LSRs as adjacent (in some 298 LSP) across an LC-ATM interface, even though the connection between 299 them is made through an ATM "cloud" via a set of ATM Switched Virtual 300 Circuits. In this case, the procedures described in [4] MUST be used 301 to assign a VCID to each such VC, and LDP is used to bind a VCID to a 302 FEC. The top label of a received packet is then inferred (via a 303 one-to-one mapping) from the virtual circuit on which the packet 304 arrived. 306 In this case, there is no default VPI or VCI value for the non-MPLS 307 connection. 309 8. Label Distribution and Maintenance Procedures 311 This document discusses the use of "downstream-on-demand" label 312 distribution (see [1]) by ATM-LSRs. These label distribution 313 procedures MUST be used by ATM-LSRs that do not support VC-merge, and 314 MAY also be used by ATM-LSRs that do support VC-merge. The 315 procedures differ somewhat in the two cases, however. We therefore 316 describe the two scenarios in turn. We begin by describing the 317 behavior of members of the Edge Set of an ATM-LSR domain; these "Edge 318 LSRs" are not themselves ATM-LSRs, and their behavior is the same 319 whether the domain contains VC-merge capable LSRs or not. 321 8.1. Edge LSR Behavior 323 Consider a member of the Edge Set of an ATM-LSR domain. Assume that, 324 as a result of its routing calculations, it selects an ATM-LSR as the 325 next hop of a certain FEC, and that the next hop is reachable via a 326 LC-ATM interface. The Edge LSR uses LDP to request a label binding 327 for that FEC from the next hop. The hop count field in the request 328 is set to 1. Once the Edge LSR receives the label binding 329 information, it may use MPLS forwarding procedures to transmit 330 packets in the specified FEC, using the specified label as an 331 outgoing label. (Or using the VPI/VCI that corresponds to the 332 specified VCID as the outgoing label, if VCIDs are being used.) 334 The binding received by the edge LSR may contain a hop count, which 335 represents the number of hops a packet will take to cross the ATM-LSR 336 domain when using this label. If there is a hop count associated with 337 the binding, the ATM-LSR SHOULD adjust a data packet's TTL by this 338 amount before transmitting the packet. In any event, it MUST adjust 339 a data packet's TTL by at least one before transmitting it. The 340 procedures for doing so (in the case of IP packets) are specified in 341 section 10. The procedures for encapsulating the packets are 342 specified in section 9. 344 When a member of the Edge Set of the ATM-LSR domain receives a label 345 binding request from an ATM-LSR, it allocates a label, and returns 346 (via LDP) a binding containing the allocated label back to the peer 347 that originated the request. It sets the hop count in the binding to 348 1. 350 When a routing calculation causes an Edge LSR to change the next hop 351 for a particular FEC, and the former next hop was in the ATM-LSR 352 domain, the Edge LSR SHOULD notify the former next hop (via LDP) that 353 the label binding associated with the FEC is no longer needed. 355 8.2. Conventional ATM Switches (non-VC-merge) 357 When an ATM-LSR receives (via LDP) a label binding request for a 358 certain FEC from a peer connected to the ATM-LSR over a LC-ATM 359 interface, the ATM-LSR takes the following actions: 361 - it allocates a label, 363 - it requests (via LDP) a label binding from the next hop for that 364 FEC; 366 - it returns (via LDP) a binding containing the allocated incoming 367 label back to the peer that originated the request. 369 The hop count field in the request that the ATM-LSR sends (to the 370 next hop LSR) MUST be set to one more than the hop count field in the 371 request that it received from the upstream LSR. If the resulting hop 372 count exceeds a configured maximum value, the request MUST NOT be 373 sent to the next hop, and the ATM-LSR MUST notify the upstream 374 neighbor that its binding request cannot be satisfied. 376 Otherwise, once the ATM-LSR receives the binding from the next hop, 377 it begins using that label. 379 The ATM-LSR MAY choose to wait for the request to be satisfied from 380 downstream before returning the binding upstream. This is a form of 381 "ordered control" (as defined in [1] and [2]), in particular 382 "ingress-initiated ordered control". In this case, as long as the 383 ATM-LSR receives from downstream a hop count which is greater than 0 384 and less than a configured maximum value, it MUST increment the hop 385 count it receives from downstream and MUST include the result in the 386 binding it returns upstream. However, if the hop count exceeds a 387 configured maximum value, a label binding MUST NOT be passed 388 upstream. Rather, the upstream LDP peer MUST be informed that the 389 requested label binding cannot be satisfied. If the hop count 390 received from downstream is 0, the hop count passed upstream should 391 also be 0; this indicates that the actual hop count is unknown. 393 Alternatively, the ATM-LSR MAY return the binding upstream without 394 waiting for a binding from downstream ("independent" control, as 395 defined in [1] and [2]). In this case, it specifies a hop count of 0 396 in the binding, indicating that the true hop count is unknown. The 397 correct value for hop count will be returned later, as described 398 below. 400 Note that an ATM-LSR, or a member of the edge set of an ATM-LSR 401 domain, may receive multiple binding requests for the same FEC from 402 the same ATM-LSR. It MUST generate a new binding for each request 403 (assuming adequate resources to do so), and retain any existing 404 binding(s). For each request received, an ATM-LSR MUST also generate 405 a new binding request toward the next hop for the FEC. 407 When a routing calculation causes an ATM-LSR to change the next hop 408 for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that 409 the label binding associated with the FEC is no longer needed. 411 When a LSR receives a notification that a particular label binding is 412 no longer needed, the LSR MAY deallocate the label associated with 413 the binding, and destroy the binding. In the case where an ATM-LSR 414 receives such notification and destroys the binding, it MUST notify 415 the next hop for the FEC that the label binding is no longer needed. 416 If a LSR does not destroy the binding, it may re-use the binding only 417 if it receives a request for the same FEC with the same hop count as 418 the request that originally caused the binding to be created. 420 When a route changes, the label bindings are re-established from the 421 point where the route diverges from the previous route. LSRs 422 upstream of that point are (with one exception, noted below) 423 oblivious to the change. 425 Whenever a LSR changes its next hop for a particular FEC, if the new 426 next hop is reachable via an LC-ATM interface, then for each label 427 that it has bound to that FEC, and distributed upstream, it MUST 428 request a new label binding from the new next hop. 430 When an ATM-LSR receives a label binding for a particular FEC from a 431 downstream neighbor, it may already have provided a corresponding 432 label binding for this FEC to an upstream neighbor, either because it 433 is using independent control, or because the new binding from 434 downstream is the result of a routing change. In this case, unless 435 the hop count is 0, it MUST extract the hop count from the new 436 binding and increment it by one. If the new hop count is different 437 from that which was previously conveyed to the upstream neighbor 438 (including the case where the upstream neighbor was given the value 439 `unknown') the ATM-LSR MUST notify the upstream neighbor of the 440 change. Each ATM-LSR in turn MUST increment the hop count and pass it 441 upstream until it reaches the ingress Edge LSR. If at any point the 442 value of the hop count equals a configured maximum hop count value, 443 the ATM-LSR SHOULD withdraw the binding from the upstream neighbor. 444 A hop count of 0 MUST be passed upstream unchanged. 446 Whenever an ATM-LSR originates a label binding request to its next 447 hop LSR as a result of receiving a label binding request from another 448 (upstream) LSR, and the request to the next hop LSR is not satisfied, 449 the ATM-LSR SHOULD destroy the binding created in response to the 450 received request, and notify the requester (via LDP). 452 If an ATM-LSR receives a binding request containing a hop count that 453 exceeds a configurable maximum, it MUST not establish a binding, and 454 it MUST return an error to the requester. 456 When a LSR determines that it has lost its LDP session with another 457 LSR, the following actions are taken. Any binding information 458 learned via this connection MUST be discarded. For any label 459 bindings that were created as a result of receiving label binding 460 requests from the peer, the LSR MAY destroy these bindings (and 461 deallocate labels associated with these binding). 463 An ATM-LSR SHOULD use `split-horizon' when it satisfies binding 464 requests from its neighbors. That is, if it receives a request for a 465 binding to a particular FEC and the LSR making that request is, 466 according to this ATM-LSR, the next hop for that FEC, it should not 467 return a binding for that route. 469 Non-merging ATM-LSRs MUST use "conservative label retention mode" 470 [1]. 472 8.3. VC-merge-capable ATM Switches 474 Relatively minor changes are needed to accommodate ATM-LSRs which 475 support VC-merge. The primary difference is that a VC-merge-capable 476 ATM-LSR needs only one outgoing label per FEC, even if multiple 477 requests for label bindings to that FEC are received from upstream 478 neighbors. 480 When a VC-merge-capable ATM-LSR receives a binding request from an 481 upstream LSR for a certain FEC, and it does not already have an 482 outgoing label binding for that FEC (or an outstanding request for 483 such a label binding), it MUST issue a bind request to its next hop 484 just as it would do if it were not merge-capable. If, however, it 485 already has an outgoing label binding for that FEC, it does not need 486 to issue a downstream binding request. Instead, it may simply 487 allocate an incoming label, and return that label in a binding to the 488 upstream requester. When packets with that label as top label are 489 received from the requester, the top label value will be replaced 490 with the existing outgoing label value that corresponds to the same 491 FEC. 493 If the ATM-LSR does not have an outgoing label binding for the FEC, 494 but does have an outstanding request for one, it need not issue 495 another request. 497 When sending a label binding upstream, the hop count associated with 498 the corresponding binding from downstream MUST be incremented by 1, 499 and the result transmitted upstream as the hop count associated with 500 the new binding. However, there are two exceptions: a hop count of 0 501 MUST be passed upstream unchanged, and if the hop count is already at 502 the configured maximum value, the ATM-LSR MUST NOT pass a binding 503 upstream, but instead MUST send an error upstream. 505 Note that, just like conventional ATM-LSRs and members of the edge 506 set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a 507 new binding every time it receives a request from upstream, since 508 there may be switches upstream which do not support VC-merge. 509 However, it only needs to issue a corresponding binding request 510 downstream if it does not already have a label binding for the 511 appropriate route. 513 When a change in the routing table of a VC-merge-capable ATM-LSR 514 causes it to select a new next hop for one of its FECs, it MAY 515 optionally release the binding for that route from the former next 516 hop. If it doesn't already have a corresponding binding for the new 517 next hop, it must request one. (The choice between conservative and 518 liberal label retention mode [1] is an implementation option.) 520 If a new binding is obtained, which contains a hop count that differs 521 from that which was received in the old binding, then the ATM-LSR 522 must take the new hop count, increment it by one, and notify any 523 upstream neighbors who have label bindings for this FEC of the new 524 value. Just as with conventional ATM-LSRs, this enables the new hop 525 count to propagate back towards the ingress of the ATM-LSR domain. If 526 at any point the hop count exceeds the configurable maximum value, 527 then the label bindings for this route must be withdrawn from all 528 upstream neighbors to whom a binding was previously provided. This 529 ensures that any loops caused by routing transients will be detected 530 and broken. 532 9. Encapsulation 534 The procedures described in this section affect only the Edge LSRs of 535 the ATM-LSR domain. The ATM-LSRs themselves do not modify the 536 encapsulation in any way. 538 Except in certain circumstances specified below, when a labeled 539 packet is transmitted on an LC-ATM interface, where the VPI/VCI (or 540 VCID) is interpreted as the top label in the label stack, the packet 541 MUST also contain a "shim header" [3]. 543 If the packet has a label stack with n entries, it MUST carry a shim 544 with n entries. The actual value of the top label is encoded in the 545 VPI/VCI field. The label value of the top entry in the shim (which 546 is just a "placeholder" entry) MUST be set to 0 upon transmission, 547 and MUST be ignored upon reception. The packet's outgoing TTL, and 548 its CoS, are carried in the TTL and CoS fields respectively of the 549 top stack entry in the shim. 551 Note that if a packet has a label stack with only one entry, this 552 requires it to have a single-entry shim (4 bytes), even though the 553 actual label value is encoded into the VPI/VCI field. This is done 554 to ensure that the packet always has a shim. Otherwise, there would 555 be no way to determine whether it had one or not, i.e., no way to 556 determine whether there are additional label stack entries. 558 The only ways to eliminate this extra overhead are: 560 - through apriori knowledge that packets have only a single label 561 (e.g., perhaps the network only supports one level of label) 563 - by using two VCs per FEC, one for those packets which have only a 564 single label, and one for those packets which have more than one 565 label 567 While either of these techniques is permitted, it is doubtful that 568 they have any practical utility. Note that if the shim header is not 569 present, the outgoing TTL is carried in the TTL field of the network 570 layer header. 572 10. TTL Manipulation 574 The procedures described in this section affect only the Edge LSRs of 575 the ATM-LSR domain. The ATM-LSRs themselves do not modify the TTL in 576 any way. 578 The details of the TTL adjustment procedure are as follows. If a 579 packet was received by the Edge LSR as an unlabeled packet, the 580 "incoming TTL" comes from the IP header. (Procedures for other 581 network layer protocols are for further study.) If a packet was 582 received by the Edge LSR as a labeled packet, using the encapsulation 583 specified in [3], the "incoming TTL" comes from the entry at the top 584 of the label stack. 586 If a hop count has been associated with the label binding that is 587 used when the packet is forwarded, the "outgoing TTL" is set to the 588 larger of (a) 0 or (b) the difference between the incoming TTL and 589 the hop count. If a hop count has not been associated with the label 590 binding that is used when the packet is forwarded, the "outgoing TTL" 591 is set to the larger of (a) 0 or (b) one less than the incoming TTL. 593 If this causes the outgoing TTL to become zero, the packet MUST NOT 594 be transmitted as a labeled packet using the specified label. The 595 packet can be treated in one of two ways: 597 - it may be treated as having expired; this may cause an ICMP 598 message to be transmitted; 600 - the packet may be forwarded, as an unlabeled packet, with a TTL 601 that is 1 less than the incoming TTL; such forwarding would need 602 to be done over a non-MPLS connection. 604 Of course, if the incoming TTL is 1, only the first of these two 605 options is applicable. 607 If the packet is forwarded as a labeled packet, the outgoing TTL is 608 carried as specified in section 9. 610 When an Edge LSR receives a labeled packet over an LC-ATM interface, 611 it obtains the incoming TTL from the top label stack entry of the 612 generic encapsulation, or, if that encapsulation is not present, from 613 the IP header. 615 If the packet's next hop is an ATM-LSR, the outgoing TTL is formed 616 using the procedures described in this section. Otherwise the 617 outgoing TTL is formed using the procedures described in [3]. 619 The procedures in this section are intended to apply only to unicast 620 packets. 622 11. Security Considerations 624 The use of the procedures and encapsulations specified in this 625 document does not have any security impact other than that which may 626 generally be present in the use of any MPLS procedures or 627 encapsulations. 629 12. Intellectual Property Considerations 631 Cisco Systems may seek patent or other intellectual property 632 protection for some or all of the technologies disclosed in this 633 document. If any standards arising from this document are or become 634 protected by one or more patents assigned to Cisco Systems, Cisco 635 intends to disclose those patents and license them under openly 636 specified and non-discriminatory terms, for no fee. 638 13. References 640 [1] Rosen E., Viswanathan, A., Callon R., "Multi-Protocol Label 641 Switching Architecture", Work in Progress, July 1998 643 [2] Andersson L., Doolan P., Feldman N., Fredette A., Thomas R., 644 "Label Distribution Protocol", Work in Progress, August 1998. 646 [3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., 647 Li, T., Conta, A., "MPLS Label Stack Encoding", Work in Progress, 648 September 1998. 650 [4] Nagami, K., Demizu N., Esaki H., Doolan P., "VCID Notification 651 over ATM link", Work in Progress, August 1998. 653 [5] Heinanen, J., "Multiprotocol Encapsulation over ATM Adaptation 654 Layer 5", RFC 1483, July 1993 656 14. Acknowledgments 658 Significant contributions to this work have been made by Anthony 659 Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan 660 Littlewood and Dan Tappan. 662 15. Authors' Addresses 664 Bruce Davie 665 Cisco Systems, Inc. 666 250 Apollo Drive 667 Chelmsford, MA, 01824 669 E-mail: bsd@cisco.com 671 Paul Doolan 672 Ennovate Networks Inc. 673 330 Codman Hill Rd 674 Boxborough, MA 01719 676 E-mail: pdoolan@ennovatenetworks.com 678 Jeremy Lawrence 679 Cisco Systems, Inc. 680 1400 Parkmoor Ave. 681 San Jose, CA, 95126 683 E-mail: jlawrenc@cisco.com 685 Keith McCloghrie 686 Cisco Systems, Inc. 687 170 Tasman Drive 688 San Jose, CA, 95134 690 E-mail: kzm@cisco.com 692 Yakov Rekhter 693 Cisco Systems, Inc. 694 170 Tasman Drive 695 San Jose, CA, 95134 697 E-mail: yakov@cisco.com 698 Eric Rosen 699 Cisco Systems, Inc. 700 250 Apollo Drive 701 Chelmsford, MA, 01824 703 E-mail: erosen@cisco.com 705 George Swallow 706 Cisco Systems, Inc. 707 250 Apollo Drive 708 Chelmsford, MA, 01824 710 E-mail: swallow@cisco.com