idnits 2.17.1 draft-ietf-mpls-atm-03.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Looks like you're using RFC 2026 boilerplate. This must be updated to follow RFC 3978/3979, as updated by RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 618 has weird spacing: '...he shim is...' == Line 758 has weird spacing: '...ge from its n...' == 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 MAXHOP, 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 (May 2000) is 8744 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' Summary: 4 errors (**), 0 flaws (~~), 5 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Bruce Davie 2 Internet Draft Jeremy Lawrence 3 Expiration Date: November 2000 Keith McCloghrie 4 Yakov Rekhter 5 Eric Rosen 6 George Swallow 7 Cisco Systems, Inc. 9 Paul Doolan 10 Ennovate Networks, Inc. 12 May 2000 14 MPLS using LDP and ATM VC Switching 16 draft-ietf-mpls-atm-03.txt 18 Status of this Memo 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 Copyright Notice 41 Copyright (C) The Internet Society (2000). All Rights Reserved. 43 Abstract 45 The MPLS Architecture [1] discusses a way in which ATM switches may 46 be used as Label Switching Routers. The ATM switches run network 47 layer routing algorithms (such as OSPF, IS-IS, etc.), and their data 48 forwarding is based on the results of these routing algorithms. No 49 ATM-specific routing or addressing is needed. ATM switches used in 50 this way are known as ATM-LSRs. 52 This document extends and clarifies the relevant portions of [1] and 53 [2] by specifying in more detail the procedures which to be used when 54 distributing labels to or from ATM-LSRs, when those labels represent 55 Forwarding Equivalence Classes (FECs, see [1]) for which the routes 56 are determined on a hop-by-hop basis by network layer routing 57 algorithms. 59 This document also specifies the MPLS encapsulation to be used when 60 sending labeled packets to or from ATM-LSRs, and in that respect is a 61 companion document to [3]. 63 Contents 65 1 Introduction ........................................... 3 66 2 Specification of Requirements .......................... 4 67 3 Definitions ............................................ 4 68 4 Special Characteristics of ATM Switches ................ 5 69 5 Label Switching Control Component for ATM .............. 6 70 6 Hybrid Switches (Ships in the Night) ................... 7 71 7 Use of VPI/VCIs ....................................... 7 72 7.1 Direct Connections ..................................... 8 73 7.2 Connections via an ATM VP .............................. 8 74 7.3 Connections via an ATM SVC ............................. 9 75 8 Label Distribution and Maintenance Procedures .......... 9 76 8.1 Edge LSR Behavior ...................................... 9 77 8.2 Conventional ATM Switches (non-VC-merge) ............... 10 78 8.3 VC-merge-capable ATM Switches .......................... 13 79 9 Encapsulation .......................................... 14 80 10 TTL Manipulation ....................................... 15 81 11 Optional Loop Detection: Distributing Path Vectors ..... 16 82 11.1 When to Send Path Vectors Downstream ................... 16 83 11.2 When to Send Path Vectors Upstream ..................... 17 84 12 Security Considerations ................................ 18 85 13 Intellectual Property Considerations ................... 18 86 14 References ............................................. 19 87 15 Acknowledgments ........................................ 19 88 16 Authors' Addresses ..................................... 20 89 17 Full Copyright Statement ............................... 21 91 1. Introduction 93 The MPLS Architecture [1] discusses the way in which ATM switches may 94 be used as Label Switching Routers. The ATM switches run network 95 layer routing algorithms (such as OSPF, IS-IS, etc.), and their data 96 forwarding is based on the results of these routing algorithms. No 97 ATM-specific routing or addressing is needed. ATM switches used in 98 this way are known as ATM-LSRs. 100 This document extends and clarifies the relevant portions of [1] and 101 [2] by specifying in more detail the procedures which are to be used 102 for distributing labels to or from ATM-LSRs, when those labels 103 represent Forwarding Equivalence Classes (FECs, see [1]) for which 104 the routes are determined on a hop-by-hop basis by network layer 105 routing algorithms. The label distribution technique described here 106 is referred to in [1] as "downstream-on-demand". This label 107 distribution technique MUST be used by ATM-LSRs that are not capable 108 of "VC merge" (defined in section 3), and is OPTIONAL for ATM-LSRs 109 that are capable of VC merge. 111 This document does NOT specify the label distribution techniques to 112 be used in the following cases: 114 - the routes are explicitly chosen before label distribution 115 begins, instead of being chosen on a hop-by-hop basis as label 116 distribution proceeds, 118 - the routes are intended to diverge in any way from the routes 119 chosen by the conventional hop-by-hop routing at any time, 121 - the labels represent FECs that consist of multicast packets, 123 - the LSRs use "VP merge". 125 Further statements made in this document about ATM-LSR label 126 distribution do not necessarily apply in these cases. 128 This document also specifies the MPLS encapsulation to be used when 129 sending labeled packets to or from ATM-LSRs, and in that respect is a 130 companion document to [3]. The specified encapsulation is to be used 131 for multicast or explicitly routed labeled packets as well. 133 This document uses terminology from [1]. 135 2. Specification of Requirements 137 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 138 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 139 document are to be interpreted as described in RFC 2119. 141 3. Definitions 143 A Label Switching Router (LSR) is a device which implements the label 144 switching control and forwarding components described in [1]. 146 A label switching controlled ATM (LC-ATM) interface is an ATM 147 interface controlled by the label switching control component. When a 148 packet traversing such an interface is received, it is treated as a 149 labeled packet. The packet's top label is inferred either from the 150 contents of the VCI field or the combined contents of the VPI and VCI 151 fields. Any two LDP peers which are connected via an LC-ATM 152 interface will use LDP negotiations to determine which of these cases 153 is applicable to that interface. 155 An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards 156 cells between these interfaces, using labels carried in the VCI or 157 VPI/VCI field, without reassembling the cells into frames before 158 forwarding. 160 A frame-based LSR is a LSR which forwards complete frames between its 161 interfaces. Note that such a LSR may have zero, one or more LC-ATM 162 interfaces. 164 Sometimes a single box may behave as an ATM-LSR with respect to 165 certain pairs of interfaces, but may behave as a frame-based LSR with 166 respect to other pairs. For example, an ATM switch with an ethernet 167 interface may function as an ATM-LSR when forwarding cells between 168 its LC-ATM interfaces, but may function as a frame-based LSR when 169 forwarding frames from its ethernet to one of its LC-ATM interfaces. 170 In such cases, one can consider the two functions (ATM-LSR and 171 frame-based LSR) as being coresident in a single box. 173 It is intended that an LC-ATM interface be used to connect two ATM- 174 LSRs, or to connect an ATM-LSR to a frame-based LSR. The use of an 175 LC-ATM interface to connect two frame-based LSRs is not considered in 176 this document. 178 An ATM-LSR domain is a set of ATM-LSRs which are mutually 179 interconnected by LC-ATM interfaces. 181 The Edge Set of an ATM-LSR domain is the set of frame-based LSRs 182 which are connected to members of the domain by LC-ATM interfaces. A 183 frame-based LSR which is a member of an Edge Set of an ATM-LSR domain 184 may be called an Edge LSR. 186 VC-merge is the process by which a switch receives cells on several 187 incoming VCIs and transmits them on a single outgoing VCI without 188 causing the cells of different AAL5 PDUs to become interleaved. 190 4. Special Characteristics of ATM Switches 192 While the MPLS architecture permits considerable flexibility in LSR 193 implementation, an ATM-LSR is constrained by the capabilities of the 194 (possibly pre-existing) hardware and the restrictions on such matters 195 as cell format imposed by ATM standards. Because of these 196 constraints, some special procedures are required for ATM-LSRs. 198 Some of the key features of ATM switches that affect their behavior 199 as LSRs are: 201 - the label swapping function is performed on fields (the VCI 202 and/or VPI) in the cell header; this dictates the size and 203 placement of the label(s) in a packet. 205 - multipoint-to-point and multipoint-to-multipoint VCs are 206 generally not supported. This means that most switches cannot 207 support 'VC-merge' as defined above. 209 - there is generally no capability to perform a 'TTL-decrement' 210 function as is performed on IP headers in routers. 212 This document describes ways of applying label switching to ATM 213 switches which work within these constraints. 215 5. Label Switching Control Component for ATM 217 To support label switching an ATM switch MUST implement the control 218 component of label switching. This consists primarily of label 219 allocation, distribution, and maintenance procedures. Label binding 220 information is communicated by several mechanisms, notably the Label 221 Distribution Protocol (LDP) [2]. This document imposes certain 222 requirements on the LDP. 224 This document considers only the case where the label switching 225 control component uses information learned directly from network 226 layer routing protocols. It is presupposed that the switch 227 participates as a peer in these protocols (e.g., OSPF, IS-IS). 229 In some cases, LSRs make use of other protocols (e.g. RSVP, PIM, BGP) 230 to distribute label bindings. In these cases, an ATM-LSR would need 231 to participate in these protocols. However, these are not explicitly 232 considered in this document. 234 Support of label switching on an ATM switch does NOT require the 235 switch to support the ATM control component defined by the ITU and 236 ATM Forum (e.g., UNI, PNNI). An ATM-LSR may OPTIONALLY respond to OAM 237 cells. 239 6. Hybrid Switches (Ships in the Night) 241 The existence of the label switching control component on an ATM 242 switch does not preclude the ability to support the ATM control 243 component defined by the ITU and ATM Forum on the same switch and the 244 same interfaces. The two control components, label switching and the 245 ITU/ATM Forum defined, would operate independently. 247 Definition of how such a device operates is beyond the scope of this 248 document. However, only a small amount of information needs to be 249 consistent between the two control components, such as the portions 250 of the VPI/VCI space which are available to each component. 252 7. Use of VPI/VCIs 254 Label switching is accomplished by associating labels with Forwarding 255 Equivalence Classes, and using the label value to forward packets, 256 including determining the value of any replacement label. See [1] 257 for further details. In an ATM-LSR, the label is carried in the 258 VPI/VCI field, or, when two ATM-LSRs are connected via an ATM 259 "Virtual Path", in the VCI field. 261 Labeled packets MUST be transmitted using the null encapsulation, as 262 defined in Section 6.1 of RFC 2684 [5]. 264 In addition, if two LDP peers are connected via an LC-ATM interface, 265 a non-MPLS connection, capable of carrying unlabelled IP packets, 266 MUST be available. This non-MPLS connection is used to carry LDP 267 packets between the two peers, and MAY also be used (but is not 268 required to be used) for other unlabeled packets (such as OSPF 269 packets, etc.). The LLC/SNAP encapsulation of RFC 2684 [5] MUST be 270 used on the non-MPLS connection. 272 It SHOULD be possible to configure an LC-ATM interface with 273 additional VPI/VCIs that are used to carry control information or 274 non-labelled packets. In that case, the VCI values MUST NOT be in 275 the 0-32 range. These may use either the null encapsulation, as 276 defined in Section 6.1 of RFC 2684 [5], or the LLC/SNAP 277 encapsulation, as defined in Section 5.1 of RFC 2684 [5]. 279 7.1. Direct Connections 281 We say that two LSRs are "directly connected" over an LC-ATM 282 interface if all cells transmitted out that interface by one LSR will 283 reach the other, and there are no ATM switches between the two LSRs. 285 When two LSRs are directly connected via an LC-ATM interface, they 286 jointly control the allocation of VPIs/VCIs on the interface 287 connecting them. They may agree to use the VPI/VCI field to encode a 288 single label. 290 The default VPI/VCI value for the non-MPLS connection is VPI 0, VCI 291 32. Other values can be configured, as long as both parties are 292 aware of the configured value. 294 A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST 295 NOT be used as the encoding of a label. 297 With the exception of these reserved values, the VPI/VCI values used 298 in the two directions of the link MAY be treated as independent 299 spaces. 301 The allowable ranges of VCIs are communicated through LDP. 303 7.2. Connections via an ATM VP 305 Sometimes it can be useful to treat two LSRs as adjacent (in some 306 LSP) across an LC-ATM interface, even though the connection between 307 them is made through an ATM "cloud" via an ATM Virtual Path. In this 308 case, the VPI field is not available to MPLS, and the label MUST be 309 encoded entirely within the VCI field. 311 In this case, the default VCI value of the non-MPLS connection 312 between the LSRs is 32. Other values can be configured, as long as 313 both parties are aware of the configured value. The VPI is set to 314 whatever is required to make use of the Virtual Path. 316 A VPI/VCI value whose VCI part is in the range 0-32 inclusive MUST 317 NOT be used as the encoding of a label. 319 With the exception of these reserved values, the VPI/VCI values used 320 in the two directions of the link MAY be treated as independent 321 spaces. 323 The allowable ranges of VPI/VCIs are communicated through LDP. If 324 more than one VPI is used for label switching, the allowable range of 325 VCIs may be different for each VPI, and each range is communicated 326 through LDP. 328 7.3. Connections via an ATM SVC 330 Sometimes it may be useful to treat two LSRs as adjacent (in some 331 LSP) across an LC-ATM interface, even though the connection between 332 them is made through an ATM "cloud" via a set of ATM Switched Virtual 333 Circuits. 335 The current document does not specify the procedure for handling this 336 case. Such procedures can be found in [4]. The procedures described 337 in [4] allow a VCID to be assigned to each such VC, and specify how 338 LDP can be used used to bind a VCID to a FEC. The top label of a 339 received packet would then be inferred (via a one-to-one mapping) 340 from the virtual circuit on which the packet arrived. There would 341 not be a default VPI or VCI value for the non-MPLS connection. 343 8. Label Distribution and Maintenance Procedures 345 This document discusses the use of "downstream-on-demand" label 346 distribution (see [1]) by ATM-LSRs. These label distribution 347 procedures MUST be used by ATM-LSRs that do not support VC-merge, and 348 MAY also be used by ATM-LSRs that do support VC-merge. The 349 procedures differ somewhat in the two cases, however. We therefore 350 describe the two scenarios in turn. We begin by describing the 351 behavior of members of the Edge Set of an ATM-LSR domain; these "Edge 352 LSRs" are not themselves ATM-LSRs, and their behavior is the same 353 whether the domain contains VC-merge capable LSRs or not. 355 8.1. Edge LSR Behavior 357 Consider a member of the Edge Set of an ATM-LSR domain. Assume that, 358 as a result of its routing calculations, it selects an ATM-LSR as the 359 next hop of a certain FEC, and that the next hop is reachable via a 360 LC-ATM interface. The Edge LSR uses LDP to request a label binding 361 for that FEC from the next hop. The hop count field in the request 362 is set to 1 (but see the next paragraph). Once the Edge LSR receives 363 the label binding information, it may use MPLS forwarding procedures 364 to transmit packets in the specified FEC, using the specified label 365 as an outgoing label. (Or using the VPI/VCI that corresponds to the 366 specified VCID as the outgoing label, if the VCID technique of [4] is 367 being used.) 369 Note: if the Edge LSR's previous hop is using downstream-on-demand 370 label distribution to request a label from the Edge LSR for a 371 particular FEC, and if the Edge LSR is not merging the LSP from that 372 previous hop with any other LSP, and if the request from the previous 373 hop has a hop count of h, then the hop count in the request issued by 374 the Edge LSR should not be set to 1, but rather to h+1. 376 The binding received by the edge LSR may contain a hop count, which 377 represents the number of hops a packet will take to cross the ATM-LSR 378 domain when using this label. If there is a hop count associated with 379 the binding, the ATM-LSR SHOULD adjust a data packet's TTL by this 380 amount before transmitting the packet. In any event, it MUST adjust 381 a data packet's TTL by at least one before transmitting it. The 382 procedures for doing so (in the case of IP packets) are specified in 383 section 10. The procedures for encapsulating the packets are 384 specified in section 9. 386 When a member of the Edge Set of the ATM-LSR domain receives a label 387 binding request from an ATM-LSR, it allocates a label, and returns 388 (via LDP) a binding containing the allocated label back to the peer 389 that originated the request. It sets the hop count in the binding to 390 1. 392 When a routing calculation causes an Edge LSR to change the next hop 393 for a particular FEC, and the former next hop was in the ATM-LSR 394 domain, the Edge LSR SHOULD notify the former next hop (via LDP) that 395 the label binding associated with the FEC is no longer needed. 397 8.2. Conventional ATM Switches (non-VC-merge) 399 When an ATM-LSR receives (via LDP) a label binding request for a 400 certain FEC from a peer connected to the ATM-LSR over a LC-ATM 401 interface, the ATM-LSR takes the following actions: 403 - it allocates a label, 405 - it requests (via LDP) a label binding from the next hop for that 406 FEC; 408 - it returns (via LDP) a binding containing the allocated incoming 409 label back to the peer that originated the request. 411 For purposes of this procedure, we define a maximum hop count value 412 MAXHOP. MAXHOP has a default value of 255, but may be configured to 413 a different value. 415 The hop count field in the request that the ATM-LSR sends (to the 416 next hop LSR) MUST be set to one more than the hop count field in the 417 request that it received from the upstream LSR. If the resulting hop 418 count exceeds MAXHOP, the request MUST NOT be sent to the next hop, 419 and the ATM-LSR MUST notify the upstream neighbor that its binding 420 request cannot be satisfied. 422 Otherwise, once the ATM-LSR receives the binding from the next hop, 423 it begins using that label. 425 The ATM-LSR MAY choose to wait for the request to be satisfied from 426 downstream before returning the binding upstream. This is a form of 427 "ordered control" (as defined in [1] and [2]), in particular 428 "ingress-initiated ordered control". In this case, as long as the 429 ATM-LSR receives from downstream a hop count which is greater than 0 430 and less than MAXHOP, it MUST increment the hop count it receives 431 from downstream and MUST include the result in the binding it returns 432 upstream. However, if the hop count exceeds MAXHOP, a label binding 433 MUST NOT be passed upstream. Rather, the upstream LDP peer MUST be 434 informed that the requested label binding cannot be satisfied. If 435 the hop count received from downstream is 0, the hop count passed 436 upstream should also be 0; this indicates that the actual hop count 437 is unknown. 439 Alternatively, the ATM-LSR MAY return the binding upstream without 440 waiting for a binding from downstream ("independent" control, as 441 defined in [1] and [2]). In this case, it specifies a hop count of 0 442 in the binding, indicating that the true hop count is unknown. The 443 correct value for hop count will be returned later, as described 444 below. 446 Note that an ATM-LSR, or a member of the edge set of an ATM-LSR 447 domain, may receive multiple binding requests for the same FEC from 448 the same ATM-LSR. It MUST generate a new binding for each request 449 (assuming adequate resources to do so), and retain any existing 450 binding(s). For each request received, an ATM-LSR MUST also generate 451 a new binding request toward the next hop for the FEC. 453 When a routing calculation causes an ATM-LSR to change the next hop 454 for a FEC, the ATM-LSR MUST notify the former next hop (via LDP) that 455 the label binding associated with the FEC is no longer needed. 457 When a LSR receives a notification that a particular label binding is 458 no longer needed, the LSR MAY deallocate the label associated with 459 the binding, and destroy the binding. In the case where an ATM-LSR 460 receives such notification and destroys the binding, it MUST notify 461 the next hop for the FEC that the label binding is no longer needed. 462 If a LSR does not destroy the binding, it may re-use the binding only 463 if it receives a request for the same FEC with the same hop count as 464 the request that originally caused the binding to be created. 466 When a route changes, the label bindings are re-established from the 467 point where the route diverges from the previous route. LSRs 468 upstream of that point are (with one exception, noted below) 469 oblivious to the change. 471 Whenever a LSR changes its next hop for a particular FEC, if the new 472 next hop is reachable via an LC-ATM interface, then for each label 473 that it has bound to that FEC, and distributed upstream, it MUST 474 request a new label binding from the new next hop. 476 When an ATM-LSR receives a label binding for a particular FEC from a 477 downstream neighbor, it may already have provided a corresponding 478 label binding for this FEC to an upstream neighbor, either because it 479 is using independent control, or because the new binding from 480 downstream is the result of a routing change. In this case, unless 481 the hop count is 0, it MUST extract the hop count from the new 482 binding and increment it by one. If the new hop count is different 483 from that which was previously conveyed to the upstream neighbor 484 (including the case where the upstream neighbor was given the value 485 'unknown') the ATM-LSR MUST notify the upstream neighbor of the 486 change. Each ATM-LSR in turn MUST increment the hop count and pass it 487 upstream until it reaches the ingress Edge LSR. If at any point the 488 value of the hop count equals MAXHOP, the ATM-LSR SHOULD withdraw the 489 binding from the upstream neighbor. A hop count of 0 MUST be passed 490 upstream unchanged. 492 Whenever an ATM-LSR originates a label binding request to its next 493 hop LSR as a result of receiving a label binding request from another 494 (upstream) LSR, and the request to the next hop LSR is not satisfied, 495 the ATM-LSR SHOULD destroy the binding created in response to the 496 received request, and notify the requester (via LDP). 498 If an ATM-LSR receives a binding request containing a hop count that 499 exceeds MAXHOP, it MUST not establish a binding, and it MUST return 500 an error to the requester. 502 When a LSR determines that it has lost its LDP session with another 503 LSR, the following actions are taken. Any binding information 504 learned via this connection MUST be discarded. For any label 505 bindings that were created as a result of receiving label binding 506 requests from the peer, the LSR MAY destroy these bindings (and 507 deallocate labels associated with these binding). 509 An ATM-LSR SHOULD use 'split-horizon' when it satisfies binding 510 requests from its neighbors. That is, if it receives a request for a 511 binding to a particular FEC and the LSR making that request is, 512 according to this ATM-LSR, the next hop for that FEC, it should not 513 return a binding for that route. 515 It is expected that non-merging ATM-LSRs would generally use 516 "conservative label retention mode" [1]. 518 8.3. VC-merge-capable ATM Switches 520 Relatively minor changes are needed to accommodate ATM-LSRs which 521 support VC-merge. The primary difference is that a VC-merge-capable 522 ATM-LSR needs only one outgoing label per FEC, even if multiple 523 requests for label bindings to that FEC are received from upstream 524 neighbors. 526 When a VC-merge-capable ATM-LSR receives a binding request from an 527 upstream LSR for a certain FEC, and it does not already have an 528 outgoing label binding for that FEC (or an outstanding request for 529 such a label binding), it MUST issue a bind request to its next hop 530 just as it would do if it were not merge-capable. If, however, it 531 already has an outgoing label binding for that FEC, it does not need 532 to issue a downstream binding request. Instead, it may simply 533 allocate an incoming label, and return that label in a binding to the 534 upstream requester. When packets with that label as top label are 535 received from the requester, the top label value will be replaced 536 with the existing outgoing label value that corresponds to the same 537 FEC. 539 If the ATM-LSR does not have an outgoing label binding for the FEC, 540 but does have an outstanding request for one, it need not issue 541 another request. 543 When sending a label binding upstream, the hop count associated with 544 the corresponding binding from downstream MUST be incremented by 1, 545 and the result transmitted upstream as the hop count associated with 546 the new binding. However, there are two exceptions: a hop count of 0 547 MUST be passed upstream unchanged, and if the hop count is already at 548 MAXHOP, the ATM-LSR MUST NOT pass a binding upstream, but instead 549 MUST send an error upstream. 551 Note that, just like conventional ATM-LSRs and members of the edge 552 set of the ATM-LSR domain, a VC-merge-capable ATM-LSR MUST issue a 553 new binding every time it receives a request from upstream, since 554 there may be switches upstream which do not support VC-merge. 555 However, it only needs to issue a corresponding binding request 556 downstream if it does not already have a label binding for the 557 appropriate route. 559 When a change in the routing table of a VC-merge-capable ATM-LSR 560 causes it to select a new next hop for one of its FECs, it MAY 561 optionally release the binding for that route from the former next 562 hop. If it doesn't already have a corresponding binding for the new 563 next hop, it must request one. (The choice between conservative and 564 liberal label retention mode [1] is an implementation option.) 566 If a new binding is obtained, which contains a hop count that differs 567 from that which was received in the old binding, then the ATM-LSR 568 must take the new hop count, increment it by one, and notify any 569 upstream neighbors who have label bindings for this FEC of the new 570 value. Just as with conventional ATM-LSRs, this enables the new hop 571 count to propagate back towards the ingress of the ATM-LSR domain. If 572 at any point the hop count exceeds MAXHOP, then the label bindings 573 for this route must be withdrawn from all upstream neighbors to whom 574 a binding was previously provided. This ensures that any loops caused 575 by routing transients will be detected and broken. 577 9. Encapsulation 579 The procedures described in this section affect only the Edge LSRs of 580 the ATM-LSR domain. The ATM-LSRs themselves do not modify the 581 encapsulation in any way. 583 Labeled packets MUST be transmitted using the null encapsulation of 584 Section 6.1 of RFC 2684 [5]. 586 Except in certain circumstances specified below, when a labeled 587 packet is transmitted on an LC-ATM interface, where the VPI/VCI (or 588 VCID) is interpreted as the top label in the label stack, the packet 589 MUST also contain a "shim header" [3]. 591 If the packet has a label stack with n entries, it MUST carry a shim 592 with n entries. The actual value of the top label is encoded in the 593 VPI/VCI field. The label value of the top entry in the shim (which 594 is just a "placeholder" entry) MUST be set to 0 upon transmission, 595 and MUST be ignored upon reception. The packet's outgoing TTL, and 596 its CoS, are carried in the TTL and CoS fields respectively of the 597 top stack entry in the shim. 599 Note that if a packet has a label stack with only one entry, this 600 requires it to have a single-entry shim (4 bytes), even though the 601 actual label value is encoded into the VPI/VCI field. This is done 602 to ensure that the packet always has a shim. Otherwise, there would 603 be no way to determine whether it had one or not, i.e., no way to 604 determine whether there are additional label stack entries. 606 The only ways to eliminate this extra overhead are: 608 - through apriori knowledge that packets have only a single label 609 (e.g., perhaps the network only supports one level of label) 611 - by using two VCs per FEC, one for those packets which have only a 612 single label, and one for those packets which have more than one 613 label 615 The second technique would require that there be some way of 616 signalling via LDP that the VC is carrying only packets with a single 617 label, and is not carrying a shim. When supporting VC merge, one 618 would also have to take care not to merge a VC on which the shim is 619 not used into a VC on which it is used, or vice versa. 621 While either of these techniques is permitted, it is doubtful that 622 they have any practical utility. Note that if the shim header is not 623 present, the outgoing TTL is carried in the TTL field of the network 624 layer header. 626 10. TTL Manipulation 628 The procedures described in this section affect only the Edge LSRs of 629 the ATM-LSR domain. The ATM-LSRs themselves do not modify the TTL in 630 any way. 632 The details of the TTL adjustment procedure are as follows. If a 633 packet was received by the Edge LSR as an unlabeled packet, the 634 "incoming TTL" comes from the IP header. (Procedures for other 635 network layer protocols are for further study.) If a packet was 636 received by the Edge LSR as a labeled packet, using the encapsulation 637 specified in [3], the "incoming TTL" comes from the entry at the top 638 of the label stack. 640 If a hop count has been associated with the label binding that is 641 used when the packet is forwarded, the "outgoing TTL" is set to the 642 larger of (a) 0 or (b) the difference between the incoming TTL and 643 the hop count. If a hop count has not been associated with the label 644 binding that is used when the packet is forwarded, the "outgoing TTL" 645 is set to the larger of (a) 0 or (b) one less than the incoming TTL. 647 If this causes the outgoing TTL to become zero, the packet MUST NOT 648 be transmitted as a labeled packet using the specified label. The 649 packet can be treated in one of two ways: 651 - it may be treated as having expired; this may cause an ICMP 652 message to be transmitted; 654 - the packet may be forwarded, as an unlabeled packet, with a TTL 655 that is 1 less than the incoming TTL; such forwarding would need 656 to be done over a non-MPLS connection. 658 Of course, if the incoming TTL is 1, only the first of these two 659 options is applicable. 661 If the packet is forwarded as a labeled packet, the outgoing TTL is 662 carried as specified in section 9. 664 When an Edge LSR receives a labeled packet over an LC-ATM interface, 665 it obtains the incoming TTL from the top label stack entry of the 666 generic encapsulation, or, if that encapsulation is not present, from 667 the IP header. 669 If the packet's next hop is an ATM-LSR, the outgoing TTL is formed 670 using the procedures described in this section. Otherwise the 671 outgoing TTL is formed using the procedures described in [3]. 673 The procedures in this section are intended to apply only to unicast 674 packets. 676 11. Optional Loop Detection: Distributing Path Vectors 678 Every ATM-LSR MUST implement, as a configurable option, the following 679 procedure for detecting forwarding loops. We refer to this as the 680 LDPV (Loop Detection via Path Vectors) procedure. This procedure 681 does not prevent the formation of forwarding loops, but does ensure 682 that any such loops are detected. If this option is not enabled, 683 loops are detected by the hop count mechanism previously described. 684 If this option is enabled, loops will be detected more quickly, but 685 at a higher cost in overhead. 687 11.1. When to Send Path Vectors Downstream 689 Suppose an LSR R sends a request for a label binding, for a 690 particular LSP, to its next hop. Then if R does not support VC- 691 merging, and R is configured to use the LDPV procedure: 693 - If R is sending the request because it is an ingress node for 694 that LSP, or because it has acquired a new next hop, then R MUST 695 include a path vector object with the request, and the path 696 vector object MUST contain only R's own address. 698 - If R is sending the request as a result of having received a 699 request from an upstream LSR, then: 701 * if the received request has a path vector object, R MUST add 702 its own address to the received path vector object, and MUST 703 pass the resulting path vector object to its next hop along 704 with the label binding request; 706 * if the received request does not have a path vector object, R 707 MUST include a path vector object with the request it sends, 708 and the path vector object MUST contain only R's own address. 710 An LSR which supports VC-merge SHOULD NOT include a path vector 711 object in the requests that it sends to its next hop. 713 If an LSR receives a label binding request whose path vector object 714 contains the address of the node itself, the LSR concludes that the 715 label binding requests have traveled in a loop. The LSR MUST act as 716 it would in the case where the hop count exceeds MAXHOP (see section 717 8.2). 719 This procedure detects the case where the request messages loop 720 though a sequence of non-merging ATM-LSRs. 722 11.2. When to Send Path Vectors Upstream 724 As specified in section 8, there are circumstances in which an LSR R 725 must inform its upstream neighbors, via a label binding response 726 message, of a change in hop count for a particular LSP. If the 727 following conditions all hold: 729 - R is configured for the LDPV procedure, 731 - R supports VC-merge, 733 - R is not the egress for that LSP, and 735 - R is not informing its neighbors of a decrease in the hop count, 737 then R MUST include a path vector object in the response message. 739 If the change in hop count is a result of R's having been informed by 740 its next hop, S, of a change in hop count, and the message from S to 741 R included a path vector object, then if the above conditions hold, R 742 MUST add itself to this object and pass the result upstream. 743 Otherwise, if the above conditions hold, R MUST create a new object 744 with only its own address. 746 If R is configured for the LDPV procedure, and R supports VC merge, 747 then it MAY include a path vector object in any label binding 748 response message that it sends upstream. In particular, at any time 749 that R receives a label binding response from its next hop, if that 750 response contains a path vector, R MAY (if configured for the LDPV 751 procedure) send a response to its upstream neighbors, containing the 752 path vector object formed by adding its own address to the received 753 path vector. 755 If R does not support VC merge, it SHOULD NOT send a path vector 756 object upstream. 758 If an LSR receives a message from its next hop, with a path vector 759 object containing its own address, then LSR MUST act as it would if 760 it received a message with a hop count equal to MAXHOP. 762 LSRs which are configured for the LDPV procedure SHOULD NOT store a 763 path vector once the corresponding path vector object has been 764 transmitted. 766 Note that if the ATM-LSR domain consists entirely of non-merging 767 ATM-LSRs, path vectors need not ever be sent upstream, since any 768 loops will be detected by means of the path vectors traveling 769 downstream. 771 By not sending path vectors unless the hop count increases, one 772 avoids sending them in many situations when there is no loop. The 773 cost is that in some situations in which there is a loop, the time to 774 detect the loop may be lengthened. 776 12. Security Considerations 778 The use of the procedures and encapsulations specified in this 779 document does not have any security impact other than that which may 780 generally be present in the use of any MPLS procedures or 781 encapsulations. 783 13. Intellectual Property Considerations 785 The IETF has been notified of intellectual property rights claimed in 786 regard to some or all of the specification contained in this 787 document. For more information consult the online list of claimed 788 rights. 790 The IETF takes no position regarding the validity or scope of any 791 intellectual property or other rights that might be claimed to 792 pertain to the implementation or use of the technology described in 793 this document or the extent to which any license under such rights 794 might or might not be available; neither does it represent that it 795 has made any effort to identify any such rights. Information on the 796 IETF's procedures with respect to rights in standards-track and 797 standards-related documentation can be found in BCP-11. Copies of 798 claims of rights made available for publication and any assurances of 799 licenses to be made available, or the result of an attempt made to 800 obtain a general license or permission for the use of such 801 proprietary rights by implementors or users of this specification can 802 be obtained from the IETF Secretariat. 804 The IETF invites any interested party to bring to its attention any 805 copyrights, patents or patent applications, or other proprietary 806 rights which may cover technology that may be required to practice 807 this standard. Please address the information to the IETF Executive 808 Director. 810 14. References 812 [1] Rosen E., Viswanathan, A., Callon R., "Multi-Protocol Label 813 Switching Architecture", Work in Progress, August 1999. 815 [2] Andersson L., Doolan P., Feldman N., Fredette A., Thomas R., "LDP 816 Specification", Work in Progress, October 1999. 818 [3] Rosen, E., Rekhter, Y., Tappan, D., Farinacci, D., Fedorkow, G., 819 Li, T., Conta, A., "MPLS Label Stack Encoding", Work in Progress, 820 September 1999. 822 [4] Nagami, K., Demizu N., Esaki H., Doolan P., "VCID Notification 823 over ATM link", Work in Progress, July 1999. 825 [5] Grossman, D., Heinanen, J., "Multiprotocol Encapsulation over ATM 826 Adaptation Layer 5", RFC 2684, September 1999 828 15. Acknowledgments 830 Significant contributions to this work have been made by Anthony 831 Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan 832 Littlewood and Dan Tappan. We thank Alex Conta for his comments. 834 16. Authors' Addresses 836 Bruce Davie 837 Cisco Systems, Inc. 838 250 Apollo Drive 839 Chelmsford, MA, 01824 841 E-mail: bsd@cisco.com 843 Paul Doolan 844 Ennovate Networks Inc. 845 330 Codman Hill Rd 846 Boxborough, MA 01719 848 E-mail: pdoolan@ennovatenetworks.com 850 Jeremy Lawrence 851 Cisco Systems, Inc. 852 99 Walker St. 853 North Sydney, NSW, Australia 855 E-mail: jlawrenc@cisco.com 857 Keith McCloghrie 858 Cisco Systems, Inc. 859 170 Tasman Drive 860 San Jose, CA, 95134 862 E-mail: kzm@cisco.com 864 Yakov Rekhter 865 Cisco Systems, Inc. 866 170 Tasman Drive 867 San Jose, CA, 95134 869 E-mail: yakov@cisco.com 870 Eric Rosen 871 Cisco Systems, Inc. 872 250 Apollo Drive 873 Chelmsford, MA, 01824 875 E-mail: erosen@cisco.com 877 George Swallow 878 Cisco Systems, Inc. 879 250 Apollo Drive 880 Chelmsford, MA, 01824 882 E-mail: swallow@cisco.com 884 17. Full Copyright Statement 886 Copyright (C) The Internet Society (2000). All Rights Reserved. 888 This document and translations of it may be copied and furnished to 889 others, and derivative works that comment on or otherwise explain it 890 or assist in its implmentation may be prepared, copied, published and 891 distributed, in whole or in part, without restriction of any kind, 892 provided that the above copyright notice and this paragraph are 893 included on all such copies and derivative works. However, this 894 document itself may not be modified in any way, such as by removing 895 the copyright notice or references to the Internet Society or other 896 Internet organizations, except as needed for the purpose of 897 developing Internet standards in which case the procedures for 898 copyrights defined in the Internet Standards process must be 899 followed, or as required to translate it into languages other than 900 English. 902 The limited permissions granted above are perpetual and will not be 903 revoked by the Internet Society or its successors or assigns.