idnits 2.17.1 draft-davie-mpls-atm-01.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-26) 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: ---------------------------------------------------------------------------- -- 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 (July 1998) is 9417 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) == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-02 == Outdated reference: A later version (-11) exists of draft-ietf-mpls-ldp-00 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-02 == Outdated reference: A later version (-05) exists of draft-ietf-mpls-vcid-atm-00 == Outdated reference: A later version (-02) exists of draft-ohba-mpls-loop-prevention-01 -- Possible downref: Normative reference to a draft: ref. '5' Summary: 8 errors (**), 0 flaws (~~), 6 warnings (==), 3 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: January 1999 Keith McCloghrie 4 Yakov Rekhter 5 Eric Rosen 6 George Swallow 7 Cisco Systems, Inc. 9 Paul Doolan 10 Ennovate Networks, Inc. 12 July 1998 14 Use of Label Switching With ATM 16 draft-davie-mpls-atm-01.txt 18 Status of this Memo 20 This document is an Internet-Draft. Internet-Drafts are working 21 documents of the Internet Engineering Task Force (IETF), its areas, 22 and its working groups. Note that other groups may also distribute 23 working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 To view the entire list of current Internet-Drafts, please check the 31 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 32 Directories on ftp.is.co.za (Africa), ftp.nordu.net (Northern 33 Europe), ftp.nis.garr.it (Southern Europe), munnari.oz.au (Pacific 34 Rim), ftp.ietf.org (US East Coast), or ftp.isi.edu (US West Coast). 36 Abstract 38 The MPLS Architecture [1] discusses a way in which ATM switches may 39 be used as Label Switching Routers. The ATM switches run network 40 layer routing algorithms (such as OSPF, IS-IS, etc.), and their data 41 forwarding is based on the results of these routing algorithms. No 42 ATM-specific routing or addressing is needed. ATM switches used in 43 this way are known as ATM-LSRs. 45 This document extends and clarifies the relevant portions of [1] and 46 [2] by specifying in more detail the procedures which to be used when 47 distributing labels to or from ATM-LSRs, when those labels represent 48 Forwarding Equivalence Classes (FECs, see [1]) for which the routes 49 are determined on a hop-by-hop basis by network layer routing 50 algorithms. 52 This document also specifies the MPLS encapsulation to be used when 53 sending labeled packets to or from ATM-LSRs, and in that respect is a 54 companion document to [3]. 56 Contents 58 1 Introduction ........................................... 2 59 2 Definitions ............................................ 3 60 3 Special Characteristics of ATM Switches ................ 4 61 4 Label Switching Control Component for ATM .............. 5 62 5 Hybrid Switches (Ships in the Night) ................... 5 63 6 Use of VPI/VCIs ....................................... 6 64 6.1 Direct Connections ..................................... 6 65 6.2 Connections via an ATM VP .............................. 7 66 6.3 Connections via an ATM SVC ............................. 7 67 7 Label Distribution and Maintenance Procedures .......... 8 68 7.1 Edge LSR Behavior ...................................... 8 69 7.2 Conventional ATM Switches (non-VC-merge) ............... 9 70 7.3 VC-merge-capable ATM Switches .......................... 11 71 8 Encapsulation .......................................... 12 72 9 TTL Manipulation ....................................... 14 73 10 Security Considerations ................................ 15 74 11 Intellectual Property Considerations ................... 15 75 12 References ............................................. 15 76 13 Acknowledgments ........................................ 15 77 14 Authors' Addresses ..................................... 16 79 1. Introduction 81 The MPLS Architecture [1] discusses the way in which ATM switches may 82 be used as Label Switching Routers. The ATM switches run network 83 layer routing algorithms (such as OSPF, IS-IS, etc.), and their data 84 forwarding is based on the results of these routing algorithms. No 85 ATM-specific routing or addressing is needed. ATM switches used in 86 this way are known as ATM-LSRs. 88 This document extends and clarifies the relevant portions of [1] and 89 [2] by specifying in more detail the procedures which are to be used 90 for distributing labels to or from ATM-LSRs, when those labels 91 represent Forwarding Equivalence Classes (FECs, see [1]) for which 92 the routes are determined on a hop-by-hop basis by network layer 93 routing algorithms. The label distribution technique described here 94 is referred to in [1] as "downstream-on-demand". This label 95 distribution technique is mandatory for ATM-LSRs that are not capable 96 of "VC merge" (defined in section 2), and is optional for ATM-LSRs 97 that are capable of VC merge. 99 Label distribution techniques used when the routes are explicitly 100 chosen, or when the FECs consist of multicast packets, are not 101 considered in this document, and further statements made in this 102 document about ATM-LSR label distribution do not necessarily apply in 103 those cases. 105 The label distribution procedures specified herein are required for 106 use when the ATM-LSRs are not capable of "VC merge", and may also be 107 used if the ATM-LSRs are capable of VC merge. Label distribution 108 procedures for the case of "VP merge" are not considered in this 109 document. 111 This document also specifies the MPLS encapsulation to be used when 112 sending labeled packets to or from ATM-LSRs, and in that respect is a 113 companion document to [3]. The specified encapsulation is to be used 114 for multicast or explicitly routed labeled packets as well. 116 This document uses terminology from [1]. 118 2. Definitions 120 A Label Switching Router (LSR) is a device which implements the label 121 switching control and forwarding components described in [1]. 123 A label switching controlled ATM (LC-ATM) interface is an ATM 124 interface controlled by the label switching control component. When a 125 packet traversing such an interface is received, it is treated as a 126 labeled packet. The packet's top label is inferred either from the 127 contents of the VPI field, the contents of the VCI field, or the 128 combined contents of the VPI and VCI fields. Any two LDP peers which 129 are connected via an LC-ATM interface will use LDP negotiations to 130 determine which of these three cases is applicable to that interface. 132 An ATM-LSR is a LSR with a number of LC-ATM interfaces which forwards 133 cells between these interfaces using labels carried in the VCI and/or 134 VPI field. 136 A frame-based LSR is a LSR which forwards complete frames between its 137 interfaces. Note that such a LSR may have zero, one or more LC-ATM 138 interfaces. 140 In general, an LC-ATM interface will be used either to connect two 141 ATM-LSRs, or to connect an ATM-LSR to a frame-based LSR. 143 An ATM-LSR domain is a set of ATM-LSRs which are mutually 144 interconnected by LC-ATM interfaces. 146 The Edge Set of an ATM-LSR domain is the set of frame-based LSRs 147 which are connected to members of the domain by LC-ATM interfaces. A 148 frame-based LSR which is a member of an Edge Set of an ATM-LSR domain 149 may be called an Edge LSR. 151 VC-merge is the process by which a switch receives cells on several 152 incoming VCIs and transmits them on a single outgoing VCI without 153 causing the cells of different AAL5 PDUs to become interleaved. 155 3. Special Characteristics of ATM Switches 157 While the MPLS architecture permits considerable flexibility in LSR 158 implementation, an ATM-LSR is constrained by the capabilities of the 159 (possibly pre-existing) hardware and the restrictions on such matters 160 as cell format imposed by ATM standards. Because of these 161 constraints, some special procedures are required for ATM-LSRs. 163 Some of the key features of ATM switches that affect their behavior 164 as LSRs are: 166 - the label swapping function is performed on fields (the VCI 167 and/or VPI) in the cell header; this dictates the size and 168 placement of the label(s) in a packet. 170 - multipoint-to-point and multipoint-to-multipoint VCs are 171 generally not supported. This means that most switches cannot 172 support `VC-merge' as defined above. 174 - there is generally no capability to perform a `TTL-decrement' 175 function as is performed on IP headers in routers. 177 This document describes ways of applying label switching to ATM 178 switches which work within these constraints. 180 4. Label Switching Control Component for ATM 182 To support label switching an ATM switch must implement the control 183 component of label switching. This consists primarily of label 184 allocation, distribution, and maintenance procedures. Label binding 185 information is communicated by several mechanisms, notably the Label 186 Distribution Protocol (LDP) [2]. This document imposes certain 187 requirements on the LDP. 189 This document considers only the case where the label switching 190 control component uses information learned directly from network 191 layer routing protocols. It is presupposed that the switch 192 participates as a peer in these protocols (e.g., OSPF, IS-IS). 194 In some cases, LSRs make use of other protocols (e.g. RSVP, PIM, BGP) 195 to distribute label bindings. In these cases, an ATM-LSR would need 196 to participate in these protocols. However, these are not explicitly 197 considered in this document. 199 Support of label switching on an ATM switch does not require the 200 switch to support the ATM control component defined by the ITU and 201 ATM Forum (e.g., UNI, PNNI). An ATM-LSR may optionally respond to OAM 202 cells. 204 5. Hybrid Switches (Ships in the Night) 206 The existence of the label switching control component on an ATM 207 switch does not preclude the ability to support the ATM control 208 component defined by the ITU and ATM Forum on the same switch and the 209 same interfaces. The two control components, label switching and the 210 ITU/ATM Forum defined, would operate independently. 212 Definition of how such a device operates is beyond the scope of this 213 document. However, only a small amount of information needs to be 214 consistent between the two control components, such as the portions 215 of the VPI/VCI space which are available to each component. 217 6. Use of VPI/VCIs 219 Label switching is accomplished by associating labels with Forwarding 220 Equivalence Classes, and using the label value to forward packets, 221 including determining the value of any replacement label. See [1] 222 for further details. In an ATM-LSR, the label is carried in the VPI 223 and/or VCI field. Just as in conventional ATM, for a cell arriving at 224 an interface, the VPI/VCI is looked up, replaced, and the cell is 225 switched. 227 In addition, if two LDP peers are connected via an LC-ATM interface, 228 a non-MPLS connection, capable of carrying unlabelled IP packets, 229 must always be available. This non-MPLS connection is used to carry 230 LDP packets between the two peers, and may also be used (but is not 231 required to be used) for any other unlabeled packets (such as OSPF 232 packets, etc.). The LLC/SNAP encapsulation of RFC 1483 is always 233 used on the non-MPLS connection. 235 LDP may be used to advertise additional VPI/VCIs to carry control 236 information or non-labelled packets. These may use either the null 237 encapsulation, as defined in Section 5.1 of RFC1483, or the LLC/SNAP 238 encapsulation, as defined in Section 4.1 of RFC1483. 240 6.1. Direct Connections 242 We say that two LSRs are "directly connected" over an LC-ATM 243 interface if all cells transmitted out that interface by one LSR will 244 reach the other, and there are no ATM switches between the two LSRs. 246 When two LSRs are directly connected via an LC-ATM interface, they 247 jointly control the allocation of VPIs/VCIs on the interface 248 connecting them. They may agree to use the entire VPI/VCI field to 249 encode a single label. Alternatively, they may agree to use the VPI 250 field to encode the top label in the stack, and the VCI field to 251 encode the second label in the stack. However, the latter 252 alternative is only allowed when the top label represents a FEC for 253 which the Label Switched Path (LSP, see [1]) consists entirely of 254 LSRs, directly connected via LC-ATM interfaces, which have agreed to 255 encode the top label in the VPI field and the second label in the VCI 256 field. 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 It is prohibited to encode any label as a VPI/VCI value whose VCI 263 part is in the range 0-32 inclusive. 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 6.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 It is prohibited to encode any label as a VPI/VCI value whose VCI 284 part is in the range 0-32 inclusive. 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 6.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 7. 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 are mandatory for ATM-LSRs that do not support VC-merge, 314 and 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 7.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 the packet's TTL by this 338 amount before transmitting the packet. The procedures for doing so 339 are specified in section 9. The procedures for encapsulating the 340 packets, are specified in section 8. 342 When a member of the Edge Set of the ATM-LSR domain receives a label 343 binding request from an ATM-LSR, it allocates a label, and returns 344 (via LDP) a binding containing the allocated label back to the peer 345 that originated the request. It sets the hop count in the binding to 346 1. 348 When a routing calculation causes an Edge LSR to change the next hop 349 for a particular FEC, and the former next hop was in the ATM-LSR 350 domain, the Edge LSR should notify the former next hop (via LDP) that 351 the label binding associated with the FEC is no longer needed. 353 7.2. Conventional ATM Switches (non-VC-merge) 355 When an ATM-LSR receives (via LDP) a label binding request for a 356 certain FEC from a peer connected to the ATM-LSR over a LC-ATM 357 interface, the ATM-LSR takes the following actions: 359 - it allocates a label, 361 - it requests (via LDP) a label binding from the next hop for that 362 FEC; 364 - it returns (via LDP) a binding containing the allocated incoming 365 label back to the peer that originated the request. 367 The hop count field in the request that the ATM-LSR sends (to the 368 next hop LSR) is set to the hop count field in the request that it 369 received from the upstream LSR plus one. If the resulting hop count 370 exceeds a configured maximum value, the request is not sent to the 371 next hop, and the ATM-LSR notifies the upstream neighbor that its 372 binding request cannot be satisfied. 374 Otherwise, once the ATM-LSR receives the binding from the next hop, 375 it places the label from the binding into the outgoing label 376 component of the LIB entry. 378 The ATM-LSR may choose to wait for the request to be satisfied from 379 downstream before returning the binding upstream. This is a form of 380 "ordered control" (as defined in [1] and [2]), in particular 381 "ingress-initiated ordered control". In this case, the ATM-LSR 382 increments the hop count it received from downstream and uses this 383 value in the binding it returns upstream. However, if the hop count 384 exceeds a configured maximum value, a label binding is not passed 385 upstream. Rather, the upstream LDP peer is informed that the 386 requested label binding cannot be satisfied. 388 Alternatively, the ATM-LSR may return the binding upstream without 389 waiting for a binding from downstream ("independent" control, as 390 defined in [1] and [2]). In this case, it uses a reserved value for 391 hop count in the binding, indicating that the true hop count is 392 unknown. The correct value for hop count will be returned later, as 393 described below. 395 Note that an ATM-LSR, or a member of the edge set of an ATM-LSR 396 domain, may receive multiple binding requests for the same FEC from 397 the same ATM-LSR. It must generate a new binding for each request 398 (assuming adequate resources to do so), and retain any existing 399 binding(s). For each request received, an ATM-LSR should also 400 generate a new binding request toward the next hop for the FEC. 402 When a routing calculation causes an ATM-LSR to change the next hop 403 for a FEC, the ATM-LSR should notify the former next hop (via LDP) 404 that the label binding associated with the FEC is no longer needed. 406 When a LSR receives a notification that a particular label binding is 407 no longer needed, the LSR may deallocate the label associated with 408 the binding, and destroy the binding. In the case where an ATM-LSR 409 receives such notification and destroys the binding, it should notify 410 the next hop for the FEC that the label binding is no longer needed. 411 If a LSR does not destroy the binding, it may re-use the binding only 412 if it receives a request for the same FEC with the same hop count as 413 the request that originally caused the binding to be created. 415 When a route changes, the label bindings are re-established from the 416 point where the route diverges from the previous route. LSRs 417 upstream of that point are (with one exception, noted below) 418 oblivious to the change. 420 Whenever a LSR changes its next hop for a particular FEC, if the new 421 next hop is reachable via an LC-ATM interface, then for each label 422 that it has bound to that FEC, and distributed upstream, it must 423 request a new label binding from the new next hop. 425 When an ATM-LSR receives a label binding for a particular FEC from a 426 downstream neighbor, it may already have provided a corresponding 427 label binding for this FEC to an upstream neighbor, either because it 428 is using independent control, or because the new binding from 429 downstream is the result of a routing change. In this case, it should 430 extract the hop count from the new binding and increment it by one. 431 If the new hop count is different from that which was previously 432 conveyed to the upstream neighbor (including the case where the 433 upstream neighbor was given the value `unknown') the ATM-LSR must 434 notify the upstream neighbor of the change. Each ATM-LSR in turn 435 increments the hop count and passes it upstream until it reaches the 436 ingress Edge LSR. If at any point the value of the hop count equals a 437 configured maximum hop count value, the ATM-LSR should withdraw the 438 binding from the upstream neighbor. 440 Whenever an ATM-LSR originates a label binding request to its next 441 hop LSR as a result of receiving a label binding request from another 442 (upstream) LSR, and the request to the next hop LSR is not satisfied, 443 the ATM-LSR should destroy the binding created in response to the 444 received request, and notify the requester (via LDP). 446 If an ATM-LSR receives a binding request containing a hop count that 447 exceeds a configurable maximum, no binding should be established and 448 an error message should be returned to the requester. 450 When a LSR determines that it has lost its LDP session with another 451 LSR, the following actions are taken. Any binding information 452 learned via this connection must be discarded. For any label 453 bindings that were created as a result of receiving label binding 454 requests from the peer, the LSR may destroy these bindings (and 455 deallocate labels associated with these binding). 457 An ATM-LSR should use `split-horizon' when it satisfies binding 458 requests from its neighbors. That is, if it receives a request for a 459 binding to a particular FEC and the LSR making that request is, 460 according to this ATM-LSR, the next hop for that FEC, it should not 461 return a binding for that route. 463 Note that if ordered control is used, it is not possible to create 464 looping paths consisting entirely of non-VC-merging ATM-LSRs. LDP 465 messages might be sent in a loop until the hop count reaches the 466 configured maximum, but data would not loop. 468 Note that non-merging ATM-LSRs must use "conservative label retention 469 mode" [1]. 471 7.3. VC-merge-capable ATM Switches 473 Relatively minor changes are needed to accommodate ATM-LSRs which 474 support VC-merge. The primary difference is that a VC-merge-capable 475 ATM-LSR needs only one outgoing label per FEC, even if multiple 476 requests for label bindings to that FEC are received from upstream 477 neighbors. 479 When a VC-merge-capable ATM-LSR receives a binding request from an 480 upstream LSR for a certain FEC, and it does not already have an 481 outgoing label binding for that FEC (or an outstanding request for 482 such a label binding), it issues a bind request to its next hop just 483 as it would do if it were not merge-capable. If, however, it already 484 has an outgoing label binding for that FEC, it does not need to issue 485 a downstream binding request. Instead, it allocates an incoming 486 label, and returns that label in a binding to the upstream requester. 487 When packets with that label as top label are received from the 488 requester, the top label value will be replaced with the existing 489 outgoing label value that corresponds to the same FEC. 491 If the ATM-LSR does not have an outgoing label binding for the FEC, 492 but does have an outstanding request for one, it does not issue 493 another request. 495 When sending a label binding upstream, the hop count associated with 496 the corresponding binding from downstream is incremented by 1, and 497 the result transmitted upstream as the hop count associated with the 498 new binding. 500 Note that, just like conventional ATM-LSRs and members of the edge 501 set of the ATM-LSR domain, a VC-merge-capable ATM-LSR must issue a 502 new binding every time it receives a request from upstream, since 503 there may be switches upstream which do not support VC-merge. 504 However, it only needs to issue a corresponding binding request 505 downstream if it does not already have a label binding for the 506 appropriate route. 508 When a change in the routing table of a VC-merge-capable ATM-LSR 509 causes it to select a new next hop for one of its FECs, it may 510 optionally release the binding for that route from the former next 511 hop. If it doesn't already have a corresponding binding for the new 512 next hop, it must request one. (The choice between conservative and 513 liberal label retention mode is an implementation option.) 515 If a new binding is obtained, which contains a hop count that differs 516 from that which was received in the old binding, then the ATM-LSR 517 must take the new hop count, increment it by one, and notify any 518 upstream neighbors who have label bindings for this FEC of the new 519 value. Just as with conventional ATM-LSRs, this enables the new hop 520 count to propagate back towards the ingress of the ATM-LSR domain. If 521 at any point the hop count exceeds the configurable maximum value, 522 then the label bindings for this route must be withdrawn from all 523 upstream neighbors to whom a binding was previously provided. This 524 ensures that any loops caused by routing transients will be detected 525 and broken. 527 Complete prevention of transient looping paths can be achieved by 528 means of the techniques described in [5], which work with any mix of 529 merging and non-merging ATM-LSRs. Note that the loop prevention 530 technique described in [1] and [2] cannot be used along with 531 downstream-on-demand label distribution. 533 8. Encapsulation 535 The procedures described in this section affect only the Edge LSRs of 536 the ATM-LSR domain. The ATM-LSRs themselves do not modify the 537 encapsulation in any way. 539 In general, when a labeled packet is transmitted on an LC-ATM 540 interface, where the VPI/VCI (or VCID) is interpreted as the top one 541 or two labels in the label stack, it is also necessary for the packet 542 to be encapsulated as specified in [3], and for the resulting packet 543 to be placed directly into the AAL5 frame. 545 Let n be the depth of a packet's label stack, and let c be the number 546 of labels (1 or 2) which are represented by the VPI/VCI or VCID. 548 If n == c, the packet should be encapsulated as specified in [3], 549 with at least one, but no more than n, label stack entries. The 550 label value of the bottom label stack entry should be set to the 551 distinguished "Explicit NULL" value for the network layer protocol of 552 the packet. The label value of any other label in the stack should 553 be set to the "IPv4 Explicit NULL" value as defined in [3]. 555 Essentially, this creates at least four bytes of overhead whose 556 meaning is "n == c". The only ways to eliminate this overhead are: 558 - through apriori knowledge that n == c; 560 - by using two VCs per FEC, one for those packets where n == c, and 561 one for those packets where n > c. 563 While either of these techniques is permitted, it is doubtful that 564 they have any practical utility. 566 If n > c, the packet should be encapsulated as specified in [3]. The 567 number of label stack entries contained in that encapsulation, e, 568 must be between n and n - c inclusive. If more than n - c label 569 stack entries are encoded, the top e - n labels must have their label 570 values set to the distinguished value "IPv4 Explicit NULL", as 571 defined in [3]. 573 Note that if n > c for some packet, it is an implementation choice as 574 to whether the generic encapsulation should contains n or n - c 575 entries. Using the smaller number of entries in the encapsulation 576 saves communications bandwidth, but may complicate the logic of the 577 transmit and/or received forwarding paths of the Edge LSRs. 579 In any case, the packet's outgoing TTL, and its CoS, are carried in 580 the TTL and CoS fields respectively of the top stack entry in the 581 generic encapsulation. If the generic encapsulation is not present, 582 the outgoing TTL is carried in the TTL field of the network layer 583 header. 585 9. TTL Manipulation 587 The procedures described in this section affect only the Edge LSRs of 588 the ATM-LSR domain. The ATM-LSRs themselves do not modify the TTL in 589 any way. 591 The details of the TTL adjustment procedure are as follows. If a 592 packet was received by the Edge LSR as an unlabeled packet, the 593 "incoming TTL" comes from the IP header. (Procedures for other 594 network layer protocols are for further study.) If a packet was 595 received by the Edge LSR as a labeled packet, using the encapsulation 596 specified in [3], the "incoming TTL" comes from the entry at the top 597 of the label stack. 599 If a hop count has been associated with the label binding that is 600 used when the packet is forwarded, the "outgoing TTL" is set to the 601 larger of (a) 0 or (b) the difference between the incoming TTL and 602 the hop count. If a hop count has not been associated with the label 603 binding that is used when the packet is forwarded, the "outgoing TTL" 604 is set to the larger of (a) 0 or (b) one less than the incoming TTL. 606 If this causes the outgoing TTL to become zero, the packet must not 607 be transmitted as a labeled packet using the specified label. The 608 packet can be treated in one of two ways: 610 - it may be treated as having expired; this may cause an ICMP 611 message to be transmitted; 613 - the packet may be forwarded, as an unlabeled packet, with a TTL 614 that is 1 less than the incoming TTL; such forwarding would need 615 to be done over a non-MPLS connection. 617 Of course, if the incoming TTL is 1, only the first of these two 618 options is applicable. 620 If the packet is forwarded as a labeled packet, the outgoing TTL is 621 carried as specified in section 8. 623 When an Edge LSR receives a labeled packet over an LC-ATM interface, 624 it obtains the incoming TTL from the top label stack entry of the 625 generic encapsulation, or, if that encapsulation is not present, from 626 the IP header. 628 If the packet's next hop is an ATM-LSR, the outgoing TTL is formed 629 using the procedures described in this section. Otherwise the 630 outgoing TTL is formed using the procedures described in [3]. 632 The procedures in this section are intended to apply only to unicast 633 packets. 635 10. Security Considerations 637 Security considerations are not addressed in this document. 639 11. Intellectual Property Considerations 641 Cisco Systems may seek patent or other intellectual property 642 protection for some or all of the technologies disclosed in this 643 document. If any standards arising from this document are or become 644 protected by one or more patents assigned to Cisco Systems, Cisco 645 intends to disclose those patents and license them under openly 646 specified and non-discriminatory terms, for no fee. 648 12. References 650 [1] Rosen, Viswanathan, Callon, "Multi-Protocol Label Switching 651 Architecture", Internet Draft, draft-ietf-mpls-arch-02.txt, July, 652 1998 654 [2] Andersson, Doolan, Feldman, Fredette, Thomas, "Label Distribution 655 Protocol", Internet Draft, draft-ietf-mpls-ldp-00.txt, March, 1998. 657 [3] Rosen, et al. "Label Switching: Label Stack Encodings", Internet 658 Draft, draft-ietf-mpls-label-encaps-02.txt, July, 1998. 660 [4] Nagami, Demizu, Esaki, Doolan, "VCID Notification over ATM link", 661 Internet Draft, draft-ietf-mpls-vcid-atm-00.txt. 663 [5] Ohba, Katsube, Rosen, Doolan, "MPLS Loop Prevention Technique 664 Using LSP-id and Hop Count", Internet Draft, draft-ohba-mpls-loop- 665 prevention-01.txt. 667 13. Acknowledgments 669 Significant contributions to this work have been made by Anthony 670 Alles, Fred Baker, Dino Farinacci, Guy Fedorkow, Arthur Lin, Morgan 671 Littlewood and Dan Tappan. 673 14. Authors' Addresses 675 Bruce Davie 676 Cisco Systems, Inc. 677 250 Apollo Drive 678 Chelmsford, MA, 01824 680 E-mail: bsd@cisco.com 682 Paul Doolan 683 Ennovate Networks Inc. 684 330 Codman Hill Rd 685 Boxborough, MA 01719 687 E-mail: pdoolan@ennovatenetworks.com 689 Jeremy Lawrence 690 Cisco Systems, Inc. 691 1400 Parkmoor Ave. 692 San Jose, CA, 95126 694 E-mail: jlawrenc@cisco.com 696 Keith McCloghrie 697 Cisco Systems, Inc. 698 170 Tasman Drive 699 San Jose, CA, 95134 701 E-mail: kzm@cisco.com 703 Yakov Rekhter 704 Cisco Systems, Inc. 705 170 Tasman Drive 706 San Jose, CA, 95134 708 E-mail: yakov@cisco.com 709 Eric Rosen 710 Cisco Systems, Inc. 711 250 Apollo Drive 712 Chelmsford, MA, 01824 714 E-mail: erosen@cisco.com 716 George Swallow 717 Cisco Systems, Inc. 718 250 Apollo Drive 719 Chelmsford, MA, 01824 721 E-mail: swallow@cisco.com