idnits 2.17.1 draft-ietf-mpls-arch-05.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: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 62 pages 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. == There are 1 instance of lines with private range IPv4 addresses in the document. If these are generic example addresses, they should be changed to use any of the ranges defined in RFC 6890 (or successor): 192.0.2.x, 198.51.100.x or 203.0.113.x. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 455: '...ne. That is, Rd MUST NOT agree with R...' RFC 2119 keyword, line 643: '... operation MUST be to "pop the stack...' RFC 2119 keyword, line 694: '...M THE NHLFE; THIS MAY IN SOME CASES BE...' RFC 2119 keyword, line 736: '... cases, Rd MUST NOT distribute to Ru...' RFC 2119 keyword, line 888: '...popping the label stack at all MUST do...' (9 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 258 has weird spacing: '...e class a gr...' == Line 296 has weird spacing: '... router an ...' == Line 355 has weird spacing: '...itching an IE...' == Line 2381 has weird spacing: '...4.2, we will ...' == Line 2477 has weird spacing: '...d later becom...' -- 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 (April 1999) is 9137 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. 'MPLS-ATM' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-BGP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-CR-LDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-FRMWRK' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-FRMRLY' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-LDP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-RSVP' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-RSVP-TUNNELS' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-SHIM' -- Possible downref: Non-RFC (?) normative reference: ref. 'MPLS-TRFENG' Summary: 5 errors (**), 0 flaws (~~), 8 warnings (==), 12 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Eric C. Rosen 2 Internet Draft Cisco Systems, Inc. 3 Expiration Date: October 1999 4 Arun Viswanathan 5 Lucent Technologies 7 Ross Callon 8 IronBridge Networks, Inc. 10 April 1999 12 Multiprotocol Label Switching Architecture 14 draft-ietf-mpls-arch-05.txt 16 Status of this Memo 18 This document is an Internet-Draft and is in full conformance with 19 all provisions of Section 10 of RFC2026. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 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 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This internet draft specifies the architecture for Multiprotocol 40 Label Switching (MPLS). 42 Table of Contents 44 1 Introduction to MPLS ............................... 4 45 1.1 Overview ........................................... 4 46 1.2 Terminology ........................................ 6 47 1.3 Acronyms and Abbreviations ......................... 9 48 1.4 Acknowledgments .................................... 10 49 2 MPLS Basics ........................................ 10 50 2.1 Labels ............................................. 10 51 2.2 Upstream and Downstream LSRs ....................... 11 52 2.3 Labeled Packet ..................................... 11 53 2.4 Label Assignment and Distribution .................. 11 54 2.5 Attributes of a Label Binding ...................... 12 55 2.6 Label Distribution Protocols ....................... 12 56 2.7 Unsolicited Downstream vs. Downstream-on-Demand .... 12 57 2.8 Label Retention Mode ............................... 13 58 2.9 The Label Stack .................................... 13 59 2.10 The Next Hop Label Forwarding Entry (NHLFE) ........ 14 60 2.11 Incoming Label Map (ILM) ........................... 15 61 2.12 FEC-to-NHLFE Map (FTN) ............................. 15 62 2.13 Label Swapping ..................................... 15 63 2.14 Scope and Uniqueness of Labels ..................... 16 64 2.15 Label Switched Path (LSP), LSP Ingress, LSP Egress . 17 65 2.16 Penultimate Hop Popping ............................ 19 66 2.17 LSP Next Hop ....................................... 20 67 2.18 Invalid Incoming Labels ............................ 21 68 2.19 LSP Control: Ordered versus Independent ............ 21 69 2.20 Aggregation ........................................ 22 70 2.21 Route Selection .................................... 24 71 2.22 Lack of Outgoing Label ............................. 24 72 2.23 Time-to-Live (TTL) ................................. 25 73 2.24 Loop Control ....................................... 26 74 2.25 Label Encodings .................................... 27 75 2.25.1 MPLS-specific Hardware and/or Software ............. 27 76 2.25.2 ATM Switches as LSRs ............................... 27 77 2.25.3 Interoperability among Encoding Techniques ......... 29 78 2.26 Label Merging ...................................... 29 79 2.26.1 Non-merging LSRs ................................... 30 80 2.26.2 Labels for Merging and Non-Merging LSRs ............ 31 81 2.26.3 Merge over ATM ..................................... 32 82 2.26.3.1 Methods of Eliminating Cell Interleave ............. 32 83 2.26.3.2 Interoperation: VC Merge, VP Merge, and Non-Merge .. 32 84 2.27 Tunnels and Hierarchy .............................. 33 85 2.27.1 Hop-by-Hop Routed Tunnel ........................... 34 86 2.27.2 Explicitly Routed Tunnel ........................... 34 87 2.27.3 LSP Tunnels ........................................ 34 88 2.27.4 Hierarchy: LSP Tunnels within LSPs ................. 35 89 2.27.5 Label Distribution Peering and Hierarchy ........... 35 90 2.28 Label Distribution Protocol Transport .............. 37 91 2.29 Why More than one Label Distribution Protocol? ..... 37 92 2.29.1 BGP and LDP ........................................ 37 93 2.29.2 Labels for RSVP Flowspecs .......................... 37 94 2.29.3 Labels for Explicitly Routed LSPs .................. 38 95 2.30 Multicast .......................................... 38 96 3 Some Applications of MPLS .......................... 38 97 3.1 MPLS and Hop by Hop Routed Traffic ................. 38 98 3.1.1 Labels for Address Prefixes ........................ 38 99 3.1.2 Distributing Labels for Address Prefixes ........... 39 100 3.1.2.1 Label Distribution Peers for an Address Prefix ..... 39 101 3.1.2.2 Distributing Labels ................................ 39 102 3.1.3 Using the Hop by Hop path as the LSP ............... 40 103 3.1.4 LSP Egress and LSP Proxy Egress .................... 41 104 3.1.5 The Implicit NULL Label ............................ 41 105 3.1.6 Option: Egress-Targeted Label Assignment ........... 42 106 3.2 MPLS and Explicitly Routed LSPs .................... 44 107 3.2.1 Explicitly Routed LSP Tunnels ...................... 44 108 3.3 Label Stacks and Implicit Peering .................. 45 109 3.4 MPLS and Multi-Path Routing ........................ 46 110 3.5 LSP Trees as Multipoint-to-Point Entities .......... 46 111 3.6 LSP Tunneling between BGP Border Routers ........... 47 112 3.7 Other Uses of Hop-by-Hop Routed LSP Tunnels ........ 49 113 3.8 MPLS and Multicast ................................. 49 114 4 Label Distribution Procedures (Hop-by-Hop) ......... 50 115 4.1 The Procedures for Advertising and Using labels .... 50 116 4.1.1 Downstream LSR: Distribution Procedure ............. 50 117 4.1.1.1 PushUnconditional .................................. 51 118 4.1.1.2 PushConditional .................................... 51 119 4.1.1.3 PulledUnconditional ................................ 52 120 4.1.1.4 PulledConditional .................................. 52 121 4.1.2 Upstream LSR: Request Procedure .................... 53 122 4.1.2.1 RequestNever ....................................... 53 123 4.1.2.2 RequestWhenNeeded .................................. 53 124 4.1.2.3 RequestOnRequest ................................... 54 125 4.1.3 Upstream LSR: NotAvailable Procedure ............... 54 126 4.1.3.1 RequestRetry ....................................... 54 127 4.1.3.2 RequestNoRetry ..................................... 54 128 4.1.4 Upstream LSR: Release Procedure .................... 55 129 4.1.4.1 ReleaseOnChange .................................... 55 130 4.1.4.2 NoReleaseOnChange .................................. 55 131 4.1.5 Upstream LSR: labelUse Procedure ................... 55 132 4.1.5.1 UseImmediate ....................................... 56 133 4.1.5.2 UseIfLoopNotDetected ............................... 56 134 4.1.6 Downstream LSR: Withdraw Procedure ................. 56 135 4.2 MPLS Schemes: Supported Combinations of Procedures . 57 136 4.2.1 Schemes for LSRs that Support Label Merging ........ 57 137 4.2.2 Schemes for LSRs that do not Support Label Merging . 58 138 4.2.3 Interoperability Considerations .................... 59 139 5 Security Considerations ............................ 61 140 6 Intellectual Property .............................. 61 141 7 Authors' Addresses ................................. 61 142 8 References ......................................... 62 144 1. Introduction to MPLS 146 1.1. Overview 148 As a packet of a connectionless network layer protocol travels from 149 one router to the next, each router makes an independent forwarding 150 decision for that packet. That is, each router analyzes the packet's 151 header, and each router runs a network layer routing algorithm. Each 152 router independently chooses a next hop for the packet, based on its 153 analysis of the packet's header and the results of running the 154 routing algorithm. 156 Packet headers contain considerably more information than is needed 157 simply to choose the next hop. Choosing the next hop can therefore be 158 thought of as the composition of two functions. The first function 159 partitions the entire set of possible packets into a set of 160 "Forwarding Equivalence Classes (FECs)". The second maps each FEC to 161 a next hop. Insofar as the forwarding decision is concerned, 162 different packets which get mapped into the same FEC are 163 indistinguishable. All packets which belong to a particular FEC and 164 which travel from a particular node will follow the same path (or if 165 certain kinds of multi-path routing are in use, they will all follow 166 one of a set of paths associated with the FEC). 168 In conventional IP forwarding, a particular router will typically 169 consider two packets to be in the same FEC if there is some address 170 prefix X in that router's routing tables such that X is the "longest 171 match" for each packet's destination address. As the packet traverses 172 the network, each hop in turn reexamines the packet and assigns it to 173 a FEC. 175 In MPLS, the assignment of a particular packet to a particular FEC is 176 done just once, as the packet enters the network. The FEC to which 177 the packet is assigned is encoded as a short fixed length value known 178 as a "label". When a packet is forwarded to its next hop, the label 179 is sent along with it; that is, the packets are "labeled" before they 180 are forwarded. 182 At subsequent hops, there is no further analysis of the packet's 183 network layer header. Rather, the label is used as an index into a 184 table which specifies the next hop, and a new label. The old label 185 is replaced with the new label, and the packet is forwarded to its 186 next hop. 188 In the MPLS forwarding paradigm, once a packet is assigned to a FEC, 189 no further header analysis is done by subsequent routers; all 190 forwarding is driven by the labels. This has a number of advantages 191 over conventional network layer forwarding. 193 - MPLS forwarding can be done by switches which are capable of 194 doing label lookup and replacement, but are either not capable of 195 analyzing the network layer headers, or are not capable of 196 analyzing the network layer headers at adequate speed. 198 - Since a packet is assigned to a FEC when it enters the network, 199 the ingress router may use, in determining the assignment, any 200 information it has about the packet, even if that information 201 cannot be gleaned from the network layer header. For example, 202 packets arriving on different ports may be assigned to different 203 FECs. Conventional forwarding, on the other hand, can only 204 consider information which travels with the packet in the packet 205 header. 207 - A packet that enters the network at a particular router can be 208 labeled differently than the same packet entering the network at 209 a different router, and as a result forwarding decisions that 210 depend on the ingress router can be easily made. This cannot be 211 done with conventional forwarding, since the identity of a 212 packet's ingress router does not travel with the packet. 214 - The considerations that determine how a packet is assigned to a 215 FEC can become ever more and more complicated, without any impact 216 at all on the routers that merely forward labeled packets. 218 - Sometimes it is desirable to force a packet to follow a 219 particular route which is explicitly chosen at or before the time 220 the packet enters the network, rather than being chosen by the 221 normal dynamic routing algorithm as the packet travels through 222 the network. This may be done as a matter of policy, or to 223 support traffic engineering. In conventional forwarding, this 224 requires the packet to carry an encoding of its route along with 225 it ("source routing"). In MPLS, a label can be used to represent 226 the route, so that the identity of the explicit route need not be 227 carried with the packet. 229 Some routers analyze a packet's network layer header not merely to 230 choose the packet's next hop, but also to determine a packet's 231 "precedence" or "class of service". They may then apply different 232 discard thresholds or scheduling disciplines to different packets. 233 MPLS allows (but does not require) the precedence or class of service 234 to be fully or partially inferred from the label. In this case, one 235 may say that the label represents the combination of a FEC and a 236 precedence or class of service. 238 MPLS stands for "Multiprotocol" Label Switching, multiprotocol 239 because its techniques are applicable to ANY network layer protocol. 240 In this document, however, we focus on the use of IP as the network 241 layer protocol. 243 A router which supports MPLS is known as a "Label Switching Router", 244 or LSR. 246 A general discussion of issues related to MPLS is presented in "A 247 Framework for Multiprotocol Label Switching" [MPLS-FRMWRK]. 249 1.2. Terminology 251 This section gives a general conceptual overview of the terms used in 252 this document. Some of these terms are more precisely defined in 253 later sections of the document. 255 DLCI a label used in Frame Relay networks to 256 identify frame relay circuits 258 forwarding equivalence class a group of IP packets which are 259 forwarded in the same manner (e.g., 260 over the same path, with the same 261 forwarding treatment) 263 frame merge label merging, when it is applied to 264 operation over frame based media, so that 265 the potential problem of cell interleave 266 is not an issue. 268 label a short fixed length physically 269 contiguous identifier which is used to 270 identify a FEC, usually of local 271 significance. 273 label merging the replacement of multiple incoming 274 labels for a particular FEC with a single 275 outgoing label 277 label swap the basic forwarding operation consisting 278 of looking up an incoming label to 279 determine the outgoing label, 280 encapsulation, port, and other data 281 handling information. 283 label swapping a forwarding paradigm allowing 284 streamlined forwarding of data by using 285 labels to identify classes of data 286 packets which are treated 287 indistinguishably when forwarding. 289 label switched hop the hop between two MPLS nodes, on which 290 forwarding is done using labels. 292 label switched path The path through one or more LSRs at one 293 level of the hierarchy followed by a 294 packets in a particular FEC. 296 label switching router an MPLS node which is capable of 297 forwarding native L3 packets 299 layer 2 the protocol layer under layer 3 (which 300 therefore offers the services used by 301 layer 3). Forwarding, when done by the 302 swapping of short fixed length labels, 303 occurs at layer 2 regardless of whether 304 the label being examined is an ATM 305 VPI/VCI, a frame relay DLCI, or an MPLS 306 label. 308 layer 3 the protocol layer at which IP and its 309 associated routing protocols operate link 310 layer synonymous with layer 2 312 loop detection a method of dealing with loops in which 313 loops are allowed to be set up, and data 314 may be transmitted over the loop, but the 315 loop is later detected 317 loop prevention a method of dealing with loops in which 318 data is never transmitted over a loop 320 label stack an ordered set of labels 322 merge point a node at which label merging is done 324 MPLS domain a contiguous set of nodes which operate 325 MPLS routing and forwarding and which are 326 also in one Routing or Administrative 327 Domain 329 MPLS edge node an MPLS node that connects an MPLS domain 330 with a node which is outside of the 331 domain, either because it does not run 332 MPLS, and/or because it is in a different 333 domain. Note that if an LSR has a 334 neighboring host which is not running 335 MPLS, that that LSR is an MPLS edge node. 337 MPLS egress node an MPLS edge node in its role in handling 338 traffic as it leaves an MPLS domain 340 MPLS ingress node an MPLS edge node in its role in handling 341 traffic as it enters an MPLS domain 343 MPLS label a label which is carried in a packet 344 header, and which represents the packet's 345 FEC 347 MPLS node a node which is running MPLS. An MPLS 348 node will be aware of MPLS control 349 protocols, will operate one or more L3 350 routing protocols, and will be capable of 351 forwarding packets based on labels. An 352 MPLS node may optionally be also capable 353 of forwarding native L3 packets. 355 MultiProtocol Label Switching an IETF working group and the effort 356 associated with the working group 358 network layer synonymous with layer 3 360 stack synonymous with label stack 362 switched path synonymous with label switched path 364 virtual circuit a circuit used by a connection-oriented 365 layer 2 technology such as ATM or Frame 366 Relay, requiring the maintenance of state 367 information in layer 2 switches. 369 VC merge label merging where the MPLS label is 370 carried in the ATM VCI field (or combined 371 VPI/VCI field), so as to allow multiple 372 VCs to merge into one single VC 374 VP merge label merging where the MPLS label is 375 carried din the ATM VPI field, so as to 376 allow multiple VPs to be merged into one 377 single VP. In this case two cells would 378 have the same VCI value only if they 379 originated from the same node. This 380 allows cells from different sources to be 381 distinguished via the VCI. 383 VPI/VCI a label used in ATM networks to identify 384 circuits 386 1.3. Acronyms and Abbreviations 388 ATM Asynchronous Transfer Mode 389 BGP Border Gateway Protocol 390 DLCI Data Link Circuit Identifier 391 FEC Forwarding Equivalence Class 392 FTN FEC to NHLFE Map 393 IGP Interior Gateway Protocol 394 ILM Incoming Label Map 395 IP Internet Protocol 396 LDP Label Distribution Protocol 397 L2 Layer 2 L3 Layer 3 398 LSP Label Switched Path 399 LSR Label Switching Router 400 MPLS MultiProtocol Label Switching 401 NHLFE Next Hop Label Forwarding Entry 402 SVC Switched Virtual Circuit 403 SVP Switched Virtual Path 404 TTL Time-To-Live 405 VC Virtual Circuit 406 VCI Virtual Circuit Identifier 407 VP Virtual Path 408 VPI Virtual Path Identifier 410 1.4. Acknowledgments 412 The ideas and text in this document have been collected from a number 413 of sources and comments received. We would like to thank Rick Boivie, 414 Paul Doolan, Nancy Feldman, Yakov Rekhter, Vijay Srinivasan, and 415 George Swallow for their inputs and ideas. 417 2. MPLS Basics 419 In this section, we introduce some of the basic concepts of MPLS and 420 describe the general approach to be used. 422 2.1. Labels 424 A label is a short, fixed length, locally significant identifier 425 which is used to identify a FEC. The label which is put on a 426 particular packet represents the Forwarding Equivalence Class to 427 which that packet is assigned. 429 Most commonly, a packet is assigned to a FEC based (completely or 430 partially) on its network layer destination address. However, the 431 label is never an encoding of that address. 433 If Ru and Rd are LSRs, they may agree that when Ru transmits a packet 434 to Rd, Ru will label with packet with label value L if and only if 435 the packet is a member of a particular FEC F. That is, they can 436 agree to a "binding" between label L and FEC F for packets moving 437 from Ru to Rd. As a result of such an agreement, L becomes Ru's 438 "outgoing label" representing FEC F, and L becomes Rd's "incoming 439 label" representing FEC F. 441 Note that L does not necessarily represent FEC F for any packets 442 other than those which are being sent from Ru to Rd. L is an 443 arbitrary value whose binding to F is local to Ru and Rd. 445 When we speak above of packets "being sent" from Ru to Rd, we do not 446 imply either that the packet originated at Ru or that its destination 447 is Rd. Rather, we mean to include packets which are "transit 448 packets" at one or both of the LSRs. 450 Sometimes it may be difficult or even impossible for Rd to tell, of 451 an arriving packet carrying label L, that the label L was placed in 452 the packet by Ru, rather than by some other LSR. (This will 453 typically be the case when Ru and Rd are not direct neighbors.) In 454 such cases, Rd must make sure that the binding from label to FEC is 455 one-to-one. That is, Rd MUST NOT agree with Ru1 to bind L to FEC F1, 456 while also agreeing with some other LSR Ru2 to bind L to a different 457 FEC F2, UNLESS Rd can always tell, when it receives a packet with 458 incoming label L, whether the label was put on the packet by Ru1 or 459 whether it was put on by Ru2. 461 It is the responsibility of each LSR to ensure that it can uniquely 462 interpret its incoming labels. 464 2.2. Upstream and Downstream LSRs 466 Suppose Ru and Rd have agreed to bind label L to FEC F, for packets 467 sent from Ru to Rd. Then with respect to this binding, Ru is the 468 "upstream LSR", and Rd is the "downstream LSR". 470 To say that one node is upstream and one is downstream with respect 471 to a given binding means only that a particular label represents a 472 particular FEC in packets travelling from the upstream node to the 473 downstream node. This is NOT meant to imply that packets in that FEC 474 would actually be routed from the upstream node to the downstream 475 node. 477 2.3. Labeled Packet 479 A "labeled packet" is a packet into which a label has been encoded. 480 In some cases, the label resides in an encapsulation header which 481 exists specifically for this purpose. In other cases, the label may 482 reside in an existing data link or network layer header, as long as 483 there is a field which is available for that purpose. The particular 484 encoding technique to be used must be agreed to by both the entity 485 which encodes the label and the entity which decodes the label. 487 2.4. Label Assignment and Distribution 489 In the MPLS architecture, the decision to bind a particular label L 490 to a particular FEC F is made by the LSR which is DOWNSTREAM with 491 respect to that binding. The downstream LSR then informs the 492 upstream LSR of the binding. Thus labels are "downstream-assigned", 493 and label bindings are distributed in the "downstream to upstream" 494 direction. 496 If an LSR has been designed so that it can only look up labels that 497 fall into a certain numeric range, then it merely needs to ensure 498 that it only binds labels that are in that range. 500 2.5. Attributes of a Label Binding 502 A particular binding of label L to FEC F, distributed by Rd to Ru, 503 may have associated "attributes". If Ru, acting as a downstream LSR, 504 also distributes a binding of a label to FEC F, then under certain 505 conditions, it may be required to also distribute the corresponding 506 attribute that it received from Rd. 508 2.6. Label Distribution Protocols 510 A label distribution protocol is a set of procedures by which one LSR 511 informs another of the label/FEC bindings it has made. Two LSRs 512 which use a label distribution protocol to exchange label/FEC binding 513 information are known as "label distribution peers" with respect to 514 the binding information they exchange. If two LSRs are label 515 distribution peers, we will speak of there being a "label 516 distribution adjacency" between them. 518 (N.B.: two LSRs may be label distribution peers with respect to some 519 set of bindings, but not with respect to some other set of bindings.) 521 The label distribution protocol also encompasses any negotiations in 522 which two label distribution peers need to engage in order to learn 523 of each other's MPLS capabilities. 525 THE ARCHITECTURE DOES NOT ASSUME THAT THERE IS ONLY A SINGLE LABEL 526 DISTRIBUTION PROTOCOL. In fact, a number of different label 527 distribution protocols are being standardized. Existing protocols 528 have been extended so that label distribution can be piggybacked on 529 them (see, e.g., [MPLS-BGP], [MPLS-RSVP], [MPLS-RSVP-TUNNELS]). New 530 protocols have also been defined for the explicit purpose of 531 distributing labels (see, e.g., [MPLS-LDP], [MPLS-CR-LDP]. 533 In this document, we try to use the acronym "LDP" to refer 534 specifically to the protocol defined in [MPLS-LDP]; when speaking of 535 label distribution protocols in general, we try to avoid the acronym. 537 2.7. Unsolicited Downstream vs. Downstream-on-Demand 539 The MPLS architecture allows an LSR to explicitly request, from its 540 next hop for a particular FEC, a label binding for that FEC. This is 541 known as "downstream-on-demand" label distribution. 543 The MPLS architecture also allows an LSR to distribute bindings to 544 LSRs that have not explicitly requested them. This is known as 545 "unsolicited downstream" label distribution. 547 It is expected that some MPLS implementations will provide only 548 downstream-on-demand label distribution, and some will provide only 549 unsolicited downstream label distribution, and some will provide 550 both. Which is provided may depend on the characteristics of the 551 interfaces which are supported by a particular implementation. 552 However, both of these label distribution techniques may be used in 553 the same network at the same time. On any given label distribution 554 adjacency, the upstream LSR and the downstream LSR must agree on 555 which technique is to be used. 557 2.8. Label Retention Mode 559 An LSR Ru may receive (or have received) a label binding for a 560 particular FEC from an LSR Rd, even though Rd is not Ru's next hop 561 (or is no longer Ru's next hop) for that FEC. 563 Ru then has the choice of whether to keep track of such bindings, or 564 whether to discard such bindings. If Ru keeps track of such 565 bindings, then it may immediately begin using the binding again if Rd 566 eventually becomes its next hop for the FEC in question. If Ru 567 discards such bindings, then if Rd later becomes the next hop, the 568 binding will have to be reacquired. 570 If an LSR supports "Liberal Label Retention Mode", it maintains the 571 bindings between a label and a FEC which are received from LSRs which 572 are not its next hop for that FEC. If an LSR supports "Conservative 573 Label Retention Mode", it discards such bindings. 575 Liberal label retention mode allows for quicker adaptation to routing 576 changes, but conservative label retention mode though requires an LSR 577 to maintain many fewer labels. 579 2.9. The Label Stack 581 So far, we have spoken as if a labeled packet carries only a single 582 label. As we shall see, it is useful to have a more general model in 583 which a labeled packet carries a number of labels, organized as a 584 last-in, first-out stack. We refer to this as a "label stack". 586 Although, as we shall see, MPLS supports a hierarchy, the processing 587 of a labeled packet is completely independent of the level of 588 hierarchy. The processing is always based on the top label, without 589 regard for the possibility that some number of other labels may have 590 been "above it" in the past, or that some number of other labels may 591 be below it at present. 593 An unlabeled packet can be thought of as a packet whose label stack 594 is empty (i.e., whose label stack has depth 0). 596 If a packet's label stack is of depth m, we refer to the label at the 597 bottom of the stack as the level 1 label, to the label above it (if 598 such exists) as the level 2 label, and to the label at the top of the 599 stack as the level m label. 601 The utility of the label stack will become clear when we introduce 602 the notion of LSP Tunnel and the MPLS Hierarchy (section 2.27). 604 2.10. The Next Hop Label Forwarding Entry (NHLFE) 606 The "Next Hop Label Forwarding Entry" (NHLFE) is used when forwarding 607 a labeled packet. It contains the following information: 609 1. the packet's next hop 611 2. the operation to perform on the packet's label stack; this is 612 one of the following operations: 614 a) replace the label at the top of the label stack with a 615 specified new label 617 b) pop the label stack 619 c) replace the label at the top of the label stack with a 620 specified new label, and then push one or more specified 621 new labels onto the label stack. 623 It may also contain: 625 d) the data link encapsulation to use when transmitting the packet 627 e) the way to encode the label stack when transmitting the packet 629 f) any other information needed in order to properly dispose of 630 the packet. 632 Note that at a given LSR, the packet's "next hop" might be that LSR 633 itself. In this case, the LSR would need to pop the top level label, 634 and then "forward" the resulting packet to itself. It would then 635 make another forwarding decision, based on what remains after the 636 label stacked is popped. This may still be a labeled packet, or it 637 may be the native IP packet. 639 This implies that in some cases the LSR may need to operate on the IP 640 header in order to forward the packet. 642 If the packet's "next hop" is the current LSR, then the label stack 643 operation MUST be to "pop the stack". 645 2.11. Incoming Label Map (ILM) 647 The "Incoming Label Map" (ILM) maps each incoming label to a set of 648 NHLFEs. It is used when forwarding packets that arrive as labeled 649 packets. 651 If the ILM maps a particular label to a set of NHLFEs that contains 652 more than one element, exactly one element of the set must be chosen 653 before the packet is forwarded. The procedures for choosing an 654 element from the set are beyond the scope of this document. Having 655 the ILM map a label to a set containing more than one NHLFE may be 656 useful if, e.g., it is desired to do load balancing over multiple 657 equal-cost paths. 659 2.12. FEC-to-NHLFE Map (FTN) 661 The "FEC-to-NHLFE" (FTN) maps each FEC to a set of NHLFEs. It is used 662 when forwarding packets that arrive unlabeled, but which are to be 663 labeled before being forwarded. 665 If the FTN maps a particular label to a set of NHLFEs that contains 666 more than one element, exactly one element of the set must be chosen 667 before the packet is forwarded. The procedures for choosing an 668 element from the set are beyond the scope of this document. Having 669 the FTN map a label to a set containing more than one NHLFE may be 670 useful if, e.g., it is desired to do load balancing over multiple 671 equal-cost paths. 673 2.13. Label Swapping 675 Label swapping is the use of the following procedures to forward a 676 packet. 678 In order to forward a labeled packet, a LSR examines the label at the 679 top of the label stack. It uses the ILM to map this label to an 680 NHLFE. Using the information in the NHLFE, it determines where to 681 forward the packet, and performs an operation on the packet's label 682 stack. It then encodes the new label stack into the packet, and 683 forwards the result. 685 In order to forward an unlabeled packet, a LSR analyzes the network 686 layer header, to determine the packet's FEC. It then uses the FTN to 687 map this to an NHLFE. Using the information in the NHLFE, it 688 determines where to forward the packet, and performs an operation on 689 the packet's label stack. (Popping the label stack would, of course, 690 be illegal in this case.) It then encodes the new label stack into 691 the packet, and forwards the result. 693 IT IS IMPORTANT TO NOTE THAT WHEN LABEL SWAPPING IS IN USE, THE NEXT 694 HOP IS ALWAYS TAKEN FROM THE NHLFE; THIS MAY IN SOME CASES BE 695 DIFFERENT FROM WHAT THE NEXT HOP WOULD BE IF MPLS WERE NOT IN USE. 697 2.14. Scope and Uniqueness of Labels 699 A given LSR Rd may bind label L1 to FEC F, and distribute that 700 binding to label distribution peer Ru1. Rd may also bind label L2 to 701 FEC F, and distribute that binding to label distribution peer Ru2. 702 Whether or not L1 == L2 is not determined by the architecture; this 703 is a local matter. 705 A given LSR Rd may bind label L to FEC F1, and distribute that 706 binding to label distribution peer Ru1. Rd may also bind label L to 707 FEC F2, and distribute that binding to label distribution peer Ru2. 708 IF (AND ONLY IF) RD CAN TELL, WHEN IT RECEIVES A PACKET WHOSE TOP 709 LABEL IS L, WHETHER THE LABEL WAS PUT THERE BY RU1 OR BY RU2, THEN 710 THE ARCHITECTURE DOES NOT REQUIRE THAT F1 == F2. In such cases, we 711 may say that Rd is using a different "label space" for the labels it 712 distributes to Ru1 than for the labels it distributes to Ru2. 714 In general, Rd can only tell whether it was Ru1 or Ru2 that put the 715 particular label value L at the top of the label stack if the 716 following conditions hold: 718 - Ru1 and Ru2 are the only label distribution peers to which Rd 719 distributed a binding of label value L, and 721 - Ru1 and Ru2 are each directly connected to Rd via a point-to- 722 point interface. 724 When these conditions hold, an LSR may use labels that have "per 725 interface" scope, i.e., which are only unique per interface. We may 726 say that the LSR is using a "per-interface label space". When these 727 conditions do not hold, the labels must be unique over the LSR which 728 has assigned them, and we may say that the LSR is using a "per- 729 platform label space." 731 If a particular LSR Rd is attached to a particular LSR Ru over two 732 point-to-point interfaces, then Rd may distribute to Ru a binding of 733 label L to FEC F1, as well as a binding of label L to FEC F2, F1 != 734 F2, if and only if each binding is valid only for packets which Ru 735 sends to Rd over a particular one of the interfaces. In all other 736 cases, Rd MUST NOT distribute to Ru bindings of the same label value 737 to two different FECs. 739 This prohibition holds even if the bindings are regarded as being at 740 different "levels of hierarchy". In MPLS, there is no notion of 741 having a different label space for different levels of the hierarchy; 742 when interpreting a label, the level of the label is irrelevant. 744 The question arises as to whether it is possible for an LSR to use 745 multiple per-platform label spaces, or to use multiple per-interface 746 label spaces for the same interface. This is not prohibited by the 747 architecture. However, in such cases the LSR must have some means, 748 not specified by the architecture, of determining, for a particular 749 incoming label, which label space that label belongs to. For 750 example, [MPLS-SHIM] specifies that a different label space is used 751 for unicast packets than for multicast packets, and uses a data link 752 layer codepoint to distinguish the two label spaces. 754 2.15. Label Switched Path (LSP), LSP Ingress, LSP Egress 756 A "Label Switched Path (LSP) of level m" for a particular packet P is 757 a sequence of routers, 759 761 with the following properties: 763 1. R1, the "LSP Ingress", is an LSR which pushes a label onto P's 764 label stack, resulting in a label stack of depth m; 766 2. For all i, 10). 790 In other words, we can speak of the level m LSP for Packet P as the 791 sequence of routers: 793 1. which begins with an LSR (an "LSP Ingress") that pushes on a 794 level m label, 796 2. all of whose intermediate LSRs make their forwarding decision 797 by label Switching on a level m label, 799 3. which ends (at an "LSP Egress") when a forwarding decision is 800 made by label Switching on a level m-k label, where k>0, or 801 when a forwarding decision is made by "ordinary", non-MPLS 802 forwarding procedures. 804 A consequence (or perhaps a presupposition) of this is that whenever 805 an LSR pushes a label onto an already labeled packet, it needs to 806 make sure that the new label corresponds to a FEC whose LSP Egress is 807 the LSR that assigned the label which is now second in the stack. 809 We will call a sequence of LSRs the "LSP for a particular FEC F" if 810 it is an LSP of level m for a particular packet P when P's level m 811 label is a label corresponding to FEC F. 813 Consider the set of nodes which may be LSP ingress nodes for FEC F. 814 Then there is an LSP for FEC F which begins with each of those nodes. 815 If a number of those LSPs have the same LSP egress, then one can 816 consider the set of such LSPs to be a tree, whose root is the LSP 817 egress. (Since data travels along this tree towards the root, this 818 may be called a multipoint-to-point tree.) We can thus speak of the 819 "LSP tree" for a particular FEC F. 821 2.16. Penultimate Hop Popping 823 Note that according to the definitions of section 2.15, if is a level m LSP for packet P, P may be transmitted from R[n-1] 825 to Rn with a label stack of depth m-1. That is, the label stack may 826 be popped at the penultimate LSR of the LSP, rather than at the LSP 827 Egress. 829 From an architectural perspective, this is perfectly appropriate. 830 The purpose of the level m label is to get the packet to Rn. Once 831 R[n-1] has decided to send the packet to Rn, the label no longer has 832 any function, and need no longer be carried. 834 There is also a practical advantage to doing penultimate hop popping. 835 If one does not do this, then when the LSP egress receives a packet, 836 it first looks up the top label, and determines as a result of that 837 lookup that it is indeed the LSP egress. Then it must pop the stack, 838 and examine what remains of the packet. If there is another label on 839 the stack, the egress will look this up and forward the packet based 840 on this lookup. (In this case, the egress for the packet's level m 841 LSP is also an intermediate node for its level m-1 LSP.) If there is 842 no other label on the stack, then the packet is forwarded according 843 to its network layer destination address. Note that this would 844 require the egress to do TWO lookups, either two label lookups or a 845 label lookup followed by an address lookup. 847 If, on the other hand, penultimate hop popping is used, then when the 848 penultimate hop looks up the label, it determines: 850 - that it is the penultimate hop, and 852 - who the next hop is. 854 The penultimate node then pops the stack, and forwards the packet 855 based on the information gained by looking up the label that was 856 previously at the top of the stack. When the LSP egress receives the 857 packet, the label which is now at the top of the stack will be the 858 label which it needs to look up in order to make its own forwarding 859 decision. Or, if the packet was only carrying a single label, the 860 LSP egress will simply see the network layer packet, which is just 861 what it needs to see in order to make its forwarding decision. 863 This technique allows the egress to do a single lookup, and also 864 requires only a single lookup by the penultimate node. 866 The creation of the forwarding "fastpath" in a label switching 867 product may be greatly aided if it is known that only a single lookup 868 is ever required: 870 - the code may be simplified if it can assume that only a single 871 lookup is ever needed 873 - the code can be based on a "time budget" that assumes that only a 874 single lookup is ever needed. 876 In fact, when penultimate hop popping is done, the LSP Egress need 877 not even be an LSR. 879 However, some hardware switching engines may not be able to pop the 880 label stack, so this cannot be universally required. There may also 881 be some situations in which penultimate hop popping is not desirable. 882 Therefore the penultimate node pops the label stack only if this is 883 specifically requested by the egress node, OR if the next node in the 884 LSP does not support MPLS. (If the next node in the LSP does support 885 MPLS, but does not make such a request, the penultimate node has no 886 way of knowing that it in fact is the penultimate node.) 888 An LSR which is capable of popping the label stack at all MUST do 889 penultimate hop popping when so requested by its downstream label 890 distribution peer. 892 Initial label distribution protocol negotiations MUST allow each LSR 893 to determine whether its neighboring LSRS are capable of popping the 894 label stack. A LSR MUST NOT request a label distribution peer to pop 895 the label stack unless it is capable of doing so. 897 It may be asked whether the egress node can always interpret the top 898 label of a received packet properly if penultimate hop popping is 899 used. As long as the uniqueness and scoping rules of section 2.14 900 are obeyed, it is always possible to interpret the top label of a 901 received packet unambiguously. 903 2.17. LSP Next Hop 905 The LSP Next Hop for a particular labeled packet in a particular LSR 906 is the LSR which is the next hop, as selected by the NHLFE entry used 907 for forwarding that packet. 909 The LSP Next Hop for a particular FEC is the next hop as selected by 910 the NHLFE entry indexed by a label which corresponds to that FEC. 912 Note that the LSP Next Hop may differ from the next hop which would 913 be chosen by the network layer routing algorithm. We will use the 914 term "L3 next hop" when we refer to the latter. 916 2.18. Invalid Incoming Labels 918 What should an LSR do if it receives a labeled packet with a 919 particular incoming label, but has no binding for that label? It is 920 tempting to think that the labels can just be removed, and the packet 921 forwarded as an unlabeled IP packet. However, in some cases, doing 922 so could cause a loop. If the upstream LSR thinks the label is bound 923 to an explicit route, and the downstream LSR doesn't think the label 924 is bound to anything, and if the hop by hop routing of the unlabeled 925 IP packet brings the packet back to the upstream LSR, then a loop is 926 formed. 928 It is also possible that the label was intended to represent a route 929 which cannot be inferred from the IP header. 931 Therefore, when a labeled packet is received with an invalid incoming 932 label, it MUST be discarded, UNLESS it is determined by some means 933 (not within the scope of the current document) that forwarding it 934 unlabeled cannot cause any harm. 936 2.19. LSP Control: Ordered versus Independent 938 Some FECs correspond to address prefixes which are distributed via a 939 dynamic routing algorithm. The setup of the LSPs for these FECs can 940 be done in one of two ways: Independent LSP Control or Ordered LSP 941 Control. 943 In Independent LSP Control, each LSR, upon noting that it recognizes 944 a particular FEC, makes an independent decision to bind a label to 945 that FEC and to distribute that binding to its label distribution 946 peers. This corresponds to the way that conventional IP datagram 947 routing works; each node makes an independent decision as to how to 948 treat each packet, and relies on the routing algorithm to converge 949 rapidly so as to ensure that each datagram is correctly delivered. 951 In Ordered LSP Control, an LSR only binds a label to a particular FEC 952 if it is the egress LSR for that FEC, or if it has already received a 953 label binding for that FEC from its next hop for that FEC. 955 If one wants to ensure that traffic in a particular FEC follows a 956 path with some specified set of properties (e.g., that the traffic 957 does not traverse any node twice, that a specified amount of 958 resources are available to the traffic, that the traffic follows an 959 explicitly specified path, etc.) ordered control must be used. With 960 independent control, some LSRs may begin label switching a traffic in 961 the FEC before the LSP is completely set up, and thus some traffic in 962 the FEC may follow a path which does not have the specified set of 963 properties. Ordered control also needs to be used if the recognition 964 of the FEC is a consequence of the setting up of the corresponding 965 LSP. 967 Ordered LSP setup may be initiated either by the ingress or the 968 egress. 970 Ordered control and independent control are fully interoperable. 971 However, unless all LSRs in an LSP are using ordered control, the 972 overall effect on network behavior is largely that of independent 973 control, since one cannot be sure that an LSP is not used until it is 974 fully set up. 976 This architecture allows the choice between independent control and 977 ordered control to be a local matter. Since the two methods 978 interwork, a given LSR need support only one or the other. Generally 979 speaking, the choice of independent versus ordered control does not 980 appear to have any effect on the label distribution mechanisms which 981 need to be defined. 983 2.20. Aggregation 985 One way of partitioning traffic into FECs is to create a separate FEC 986 for each address prefix which appears in the routing table. However, 987 within a particular MPLS domain, this may result in a set of FECs 988 such that all traffic in all those FECs follows the same route. For 989 example, a set of distinct address prefixes might all have the same 990 egress node, and label swapping might be used only to get the the 991 traffic to the egress node. In this case, within the MPLS domain, 992 the union of those FECs is itself a FEC. This creates a choice: 993 should a distinct label be bound to each component FEC, or should a 994 single label be bound to the union, and that label applied to all 995 traffic in the union? 997 The procedure of binding a single label to a union of FECs which is 998 itself a FEC (within some domain), and of applying that label to all 999 traffic in the union, is known as "aggregation". The MPLS 1000 architecture allows aggregation. Aggregation may reduce the number 1001 of labels which are needed to handle a particular set of packets, and 1002 may also reduce the amount of label distribution control traffic 1003 needed. 1005 Given a set of FECs which are "aggregatable" into a single FEC, it is 1006 possible to (a) aggregate them into a single FEC, (b) aggregate them 1007 into a set of FECs, or (c) not aggregate them at all. Thus we can 1008 speak of the "granularity" of aggregation, with (a) being the 1009 "coarsest granularity", and (c) being the "finest granularity". 1011 When order control is used, each LSR should adopt, for a given set of 1012 FECs, the granularity used by its next hop for those FECs. 1014 When independent control is used, it is possible that there will be 1015 two adjacent LSRs, Ru and Rd, which aggregate some set of FECs 1016 differently. 1018 If Ru has finer granularity than Rd, this does not cause a problem. 1019 Ru distributes more labels for that set of FECs than Rd does. This 1020 means that when Ru needs to forward labeled packets in those FECs to 1021 Rd, it may need to map n labels into m labels, where n > m. As an 1022 option, Ru may withdraw the set of n labels that it has distributed, 1023 and then distribute a set of m labels, corresponding to Rd's level of 1024 granularity. This is not necessary to ensure correct operation, but 1025 it does result in a reduction of the number of labels distributed by 1026 Ru, and Ru is not gaining any particular advantage by distributing 1027 the larger number of labels. The decision whether to do this or not 1028 is a local matter. 1030 If Ru has coarser granularity than Rd (i.e., Rd has distributed n 1031 labels for the set of FECs, while Ru has distributed m, where n > m), 1032 it has two choices: 1034 - It may adopt Rd's finer level of granularity. This would require 1035 it to withdraw the m labels it has distributed, and distribute n 1036 labels. This is the preferred option. 1038 - It may simply map its m labels into a subset of Rd's n labels, if 1039 it can determine that this will produce the same routing. For 1040 example, suppose that Ru applies a single label to all traffic 1041 that needs to pass through a certain egress LSR, whereas Rd binds 1042 a number of different labels to such traffic, depending on the 1043 individual destination addresses of the packets. If Ru knows the 1044 address of the egress router, and if Rd has bound a label to the 1045 FEC which is identified by that address, then Ru can simply apply 1046 that label. 1048 In any event, every LSR needs to know (by configuration) what 1049 granularity to use for labels that it assigns. Where ordered control 1050 is used, this requires each node to know the granularity only for 1051 FECs which leave the MPLS network at that node. For independent 1052 control, best results may be obtained by ensuring that all LSRs are 1053 consistently configured to know the granularity for each FEC. 1054 However, in many cases this may be done by using a single level of 1055 granularity which applies to all FECs (such as "one label per IP 1056 prefix in the forwarding table", or "one label per egress node"). 1058 2.21. Route Selection 1060 Route selection refers to the method used for selecting the LSP for a 1061 particular FEC. The proposed MPLS protocol architecture supports two 1062 options for Route Selection: (1) hop by hop routing, and (2) explicit 1063 routing. 1065 Hop by hop routing allows each node to independently choose the next 1066 hop for each FEC. This is the usual mode today in existing IP 1067 networks. A "hop by hop routed LSP" is an LSP whose route is selected 1068 using hop by hop routing. 1070 In an explicitly routed LSP, each LSR does not independently choose 1071 the next hop; rather, a single LSR, generally the LSP ingress or the 1072 LSP egress, specifies several (or all) of the LSRs in the LSP. If a 1073 single LSR specifies the entire LSP, the LSP is "strictly" explicitly 1074 routed. If a single LSR specifies only some of the LSP, the LSP is 1075 "loosely" explicitly routed. 1077 The sequence of LSRs followed by an explicitly routed LSP may be 1078 chosen by configuration, or may be selected dynamically by a single 1079 node (for example, the egress node may make use of the topological 1080 information learned from a link state database in order to compute 1081 the entire path for the tree ending at that egress node). 1083 Explicit routing may be useful for a number of purposes, such as 1084 policy routing or traffic engineering. In MPLS, the explicit route 1085 needs to be specified at the time that labels are assigned, but the 1086 explicit route does not have to be specified with each IP packet. 1087 This makes MPLS explicit routing much more efficient than the 1088 alternative of IP source routing. 1090 The procedures for making use of explicit routes, either strict or 1091 loose, are beyond the scope of this document. 1093 2.22. Lack of Outgoing Label 1095 When a labeled packet is traveling along an LSP, it may occasionally 1096 happen that it reaches an LSR at which the ILM does not map the 1097 packet's incoming label into an NHLFE, even though the incoming label 1098 is itself valid. This can happen due to transient conditions, or due 1099 to an error at the LSR which should be the packet's next hop. 1101 It is tempting in such cases to strip off the label stack and attempt 1102 to forward the packet further via conventional forwarding, based on 1103 its network layer header. However, in general this is not a safe 1104 procedure: 1106 - If the packet has been following an explicitly routed LSP, this 1107 could result in a loop. 1109 - The packet's network header may not contain enough information to 1110 enable this particular LSR to forward it correctly. 1112 Unless it can be determined (through some means outside the scope of 1113 this document) that neither of these situations obtains, the only 1114 safe procedure is to discard the packet. 1116 2.23. Time-to-Live (TTL) 1118 In conventional IP forwarding, each packet carries a "Time To Live" 1119 (TTL) value in its header. Whenever a packet passes through a 1120 router, its TTL gets decremented by 1; if the TTL reaches 0 before 1121 the packet has reached its destination, the packet gets discarded. 1123 This provides some level of protection against forwarding loops that 1124 may exist due to misconfigurations, or due to failure or slow 1125 convergence of the routing algorithm. TTL is sometimes used for other 1126 functions as well, such as multicast scoping, and supporting the 1127 "traceroute" command. This implies that there are two TTL-related 1128 issues that MPLS needs to deal with: (i) TTL as a way to suppress 1129 loops; (ii) TTL as a way to accomplish other functions, such as 1130 limiting the scope of a packet. 1132 When a packet travels along an LSP, it SHOULD emerge with the same 1133 TTL value that it would have had if it had traversed the same 1134 sequence of routers without having been label switched. If the 1135 packet travels along a hierarchy of LSPs, the total number of LSR- 1136 hops traversed SHOULD be reflected in its TTL value when it emerges 1137 from the hierarchy of LSPs. 1139 The way that TTL is handled may vary depending upon whether the MPLS 1140 label values are carried in an MPLS-specific "shim" header [MPLS- 1141 SHIM], or if the MPLS labels are carried in an L2 header, such as an 1142 ATM header [MPLS-ATM] or a frame relay header [MPLS-FRMRLY]. 1144 If the label values are encoded in a "shim" that sits between the 1145 data link and network layer headers, then this shim MUST have a TTL 1146 field that SHOULD be initially loaded from the network layer header 1147 TTL field, SHOULD be decremented at each LSR-hop, and SHOULD be 1148 copied into the network layer header TTL field when the packet 1149 emerges from its LSP. 1151 If the label values are encoded in a data link layer header (e.g., 1152 the VPI/VCI field in ATM's AAL5 header), and the labeled packets are 1153 forwarded by an L2 switch (e.g., an ATM switch), and the data link 1154 layer (like ATM) does not itself have a TTL field, then it will not 1155 be possible to decrement a packet's TTL at each LSR-hop. An LSP 1156 segment which consists of a sequence of LSRs that cannot decrement a 1157 packet's TTL will be called a "non-TTL LSP segment". 1159 When a packet emerges from a non-TTL LSP segment, it SHOULD however 1160 be given a TTL that reflects the number of LSR-hops it traversed. In 1161 the unicast case, this can be achieved by propagating a meaningful 1162 LSP length to ingress nodes, enabling the ingress to decrement the 1163 TTL value before forwarding packets into a non-TTL LSP segment. 1165 Sometimes it can be determined, upon ingress to a non-TTL LSP 1166 segment, that a particular packet's TTL will expire before the packet 1167 reaches the egress of that non-TTL LSP segment. In this case, the LSR 1168 at the ingress to the non-TTL LSP segment must not label switch the 1169 packet. This means that special procedures must be developed to 1170 support traceroute functionality, for example, traceroute packets may 1171 be forwarded using conventional hop by hop forwarding. 1173 2.24. Loop Control 1175 On a non-TTL LSP segment, by definition, TTL cannot be used to 1176 protect against forwarding loops. The importance of loop control may 1177 depend on the particular hardware being used to provide the LSR 1178 functions along the non-TTL LSP segment. 1180 Suppose, for instance, that ATM switching hardware is being used to 1181 provide MPLS switching functions, with the label being carried in the 1182 VPI/VCI field. Since ATM switching hardware cannot decrement TTL, 1183 there is no protection against loops. If the ATM hardware is capable 1184 of providing fair access to the buffer pool for incoming cells 1185 carrying different VPI/VCI values, this looping may not have any 1186 deleterious effect on other traffic. If the ATM hardware cannot 1187 provide fair buffer access of this sort, however, then even transient 1188 loops may cause severe degradation of the LSR's total performance. 1190 Even if fair buffer access can be provided, it is still worthwhile to 1191 have some means of detecting loops that last "longer than possible". 1192 In addition, even where TTL and/or per-VC fair queuing provides a 1193 means for surviving loops, it still may be desirable where practical 1194 to avoid setting up LSPs which loop. All LSRs that may attach to 1195 non-TTL LSP segments will therefore be required to support a common 1196 technique for loop detection; however, use of the loop detection 1197 technique is optional. The loop detection technique is specified in 1198 [MPLS-ATM] and [MPLS-LDP]. 1200 2.25. Label Encodings 1202 In order to transmit a label stack along with the packet whose label 1203 stack it is, it is necessary to define a concrete encoding of the 1204 label stack. The architecture supports several different encoding 1205 techniques; the choice of encoding technique depends on the 1206 particular kind of device being used to forward labeled packets. 1208 2.25.1. MPLS-specific Hardware and/or Software 1210 If one is using MPLS-specific hardware and/or software to forward 1211 labeled packets, the most obvious way to encode the label stack is to 1212 define a new protocol to be used as a "shim" between the data link 1213 layer and network layer headers. This shim would really be just an 1214 encapsulation of the network layer packet; it would be "protocol- 1215 independent" such that it could be used to encapsulate any network 1216 layer. Hence we will refer to it as the "generic MPLS 1217 encapsulation". 1219 The generic MPLS encapsulation would in turn be encapsulated in a 1220 data link layer protocol. 1222 The MPLS generic encapsulation is specified in [MPLS-SHIM]. 1224 2.25.2. ATM Switches as LSRs 1226 It will be noted that MPLS forwarding procedures are similar to those 1227 of legacy "label swapping" switches such as ATM switches. ATM 1228 switches use the input port and the incoming VPI/VCI value as the 1229 index into a "cross-connect" table, from which they obtain an output 1230 port and an outgoing VPI/VCI value. Therefore if one or more labels 1231 can be encoded directly into the fields which are accessed by these 1232 legacy switches, then the legacy switches can, with suitable software 1233 upgrades, be used as LSRs. We will refer to such devices as "ATM- 1234 LSRs". 1236 There are three obvious ways to encode labels in the ATM cell header 1237 (presuming the use of AAL5): 1239 1. SVC Encoding 1241 Use the VPI/VCI field to encode the label which is at the top 1242 of the label stack. This technique can be used in any network. 1243 With this encoding technique, each LSP is realized as an ATM 1244 SVC, and the label distribution protocol becomes the ATM 1245 "signaling" protocol. With this encoding technique, the ATM- 1246 LSRs cannot perform "push" or "pop" operations on the label 1247 stack. 1249 2. SVP Encoding 1251 Use the VPI field to encode the label which is at the top of 1252 the label stack, and the VCI field to encode the second label 1253 on the stack, if one is present. This technique some advantages 1254 over the previous one, in that it permits the use of ATM "VP- 1255 switching". That is, the LSPs are realized as ATM SVPs, with 1256 the label distribution protocol serving as the ATM signaling 1257 protocol. 1259 However, this technique cannot always be used. If the network 1260 includes an ATM Virtual Path through a non-MPLS ATM network, 1261 then the VPI field is not necessarily available for use by 1262 MPLS. 1264 When this encoding technique is used, the ATM-LSR at the egress 1265 of the VP effectively does a "pop" operation. 1267 3. SVP Multipoint Encoding 1269 Use the VPI field to encode the label which is at the top of 1270 the label stack, use part of the VCI field to encode the second 1271 label on the stack, if one is present, and use the remainder of 1272 the VCI field to identify the LSP ingress. If this technique 1273 is used, conventional ATM VP-switching capabilities can be used 1274 to provide multipoint-to-point VPs. Cells from different 1275 packets will then carry different VCI values. As we shall see 1276 in section 2.26, this enables us to do label merging, without 1277 running into any cell interleaving problems, on ATM switches 1278 which can provide multipoint-to-point VPs, but which do not 1279 have the VC merge capability. 1281 This technique depends on the existence of a capability for 1282 assigning 16-bit VCI values to each ATM switch such that no 1283 single VCI value is assigned to two different switches. (If an 1284 adequate number of such values could be assigned to each 1285 switch, it would be possible to also treat the VCI value as the 1286 second label in the stack.) 1288 If there are more labels on the stack than can be encoded in the ATM 1289 header, the ATM encodings must be combined with the generic 1290 encapsulation. 1292 2.25.3. Interoperability among Encoding Techniques 1294 If is a segment of a LSP, it is possible that R1 will 1295 use one encoding of the label stack when transmitting packet P to R2, 1296 but R2 will use a different encoding when transmitting a packet P to 1297 R3. In general, the MPLS architecture supports LSPs with different 1298 label stack encodings used on different hops. Therefore, when we 1299 discuss the procedures for processing a labeled packet, we speak in 1300 abstract terms of operating on the packet's label stack. When a 1301 labeled packet is received, the LSR must decode it to determine the 1302 current value of the label stack, then must operate on the label 1303 stack to determine the new value of the stack, and then encode the 1304 new value appropriately before transmitting the labeled packet to its 1305 next hop. 1307 Unfortunately, ATM switches have no capability for translating from 1308 one encoding technique to another. The MPLS architecture therefore 1309 requires that whenever it is possible for two ATM switches to be 1310 successive LSRs along a level m LSP for some packet, that those two 1311 ATM switches use the same encoding technique. 1313 Naturally there will be MPLS networks which contain a combination of 1314 ATM switches operating as LSRs, and other LSRs which operate using an 1315 MPLS shim header. In such networks there may be some LSRs which have 1316 ATM interfaces as well as "MPLS Shim" interfaces. This is one example 1317 of an LSR with different label stack encodings on different hops. 1318 Such an LSR may swap off an ATM encoded label stack on an incoming 1319 interface and replace it with an MPLS shim header encoded label stack 1320 on the outgoing interface. 1322 2.26. Label Merging 1324 Suppose that an LSR has bound multiple incoming labels to a 1325 particular FEC. When forwarding packets in that FEC, one would like 1326 to have a single outgoing label which is applied to all such packets. 1327 The fact that two different packets in the FEC arrived with different 1328 incoming labels is irrelevant; one would like to forward them with 1329 the same outgoing label. The capability to do so is known as "label 1330 merging". 1332 Let us say that an LSR is capable of label merging if it can receive 1333 two packets from different incoming interfaces, and/or with different 1334 labels, and send both packets out the same outgoing interface with 1335 the same label. Once the packets are transmitted, the information 1336 that they arrived from different interfaces and/or with different 1337 incoming labels is lost. 1339 Let us say that an LSR is not capable of label merging if, for any 1340 two packets which arrive from different interfaces, or with different 1341 labels, the packets must either be transmitted out different 1342 interfaces, or must have different labels. ATM-LSRs using the SVC or 1343 SVP Encodings cannot perform label merging. This is discussed in 1344 more detail in the next section. 1346 If a particular LSR cannot perform label merging, then if two packets 1347 in the same FEC arrive with different incoming labels, they must be 1348 forwarded with different outgoing labels. With label merging, the 1349 number of outgoing labels per FEC need only be 1; without label 1350 merging, the number of outgoing labels per FEC could be as large as 1351 the number of nodes in the network. 1353 With label merging, the number of incoming labels per FEC that a 1354 particular LSR needs is never be larger than the number of label 1355 distribution adjacencies. Without label merging, the number of 1356 incoming labels per FEC that a particular LSR needs is as large as 1357 the number of upstream nodes which forward traffic in the FEC to the 1358 LSR in question. In fact, it is difficult for an LSR to even 1359 determine how many such incoming labels it must support for a 1360 particular FEC. 1362 The MPLS architecture accommodates both merging and non-merging LSRs, 1363 but allows for the fact that there may be LSRs which do not support 1364 label merging. This leads to the issue of ensuring correct 1365 interoperation between merging LSRs and non-merging LSRs. The issue 1366 is somewhat different in the case of datagram media versus the case 1367 of ATM. The different media types will therefore be discussed 1368 separately. 1370 2.26.1. Non-merging LSRs 1372 The MPLS forwarding procedures is very similar to the forwarding 1373 procedures used by such technologies as ATM and Frame Relay. That is, 1374 a unit of data arrives, a label (VPI/VCI or DLCI) is looked up in a 1375 "cross-connect table", on the basis of that lookup an output port is 1376 chosen, and the label value is rewritten. In fact, it is possible to 1377 use such technologies for MPLS forwarding; a label distribution 1378 protocol can be used as the "signalling protocol" for setting up the 1379 cross-connect tables. 1381 Unfortunately, these technologies do not necessarily support the 1382 label merging capability. In ATM, if one attempts to perform label 1383 merging, the result may be the interleaving of cells from various 1384 packets. If cells from different packets get interleaved, it is 1385 impossible to reassemble the packets. Some Frame Relay switches use 1386 cell switching on their backplanes. These switches may also be 1387 incapable of supporting label merging, for the same reason -- cells 1388 of different packets may get interleaved, and there is then no way to 1389 reassemble the packets. 1391 We propose to support two solutions to this problem. First, MPLS will 1392 contain procedures which allow the use of non-merging LSRs. Second, 1393 MPLS will support procedures which allow certain ATM switches to 1394 function as merging LSRs. 1396 Since MPLS supports both merging and non-merging LSRs, MPLS also 1397 contains procedures to ensure correct interoperation between them. 1399 2.26.2. Labels for Merging and Non-Merging LSRs 1401 An upstream LSR which supports label merging needs to be sent only 1402 one label per FEC. An upstream neighbor which does not support label 1403 merging needs to be sent multiple labels per FEC. However, there is 1404 no way of knowing a priori how many labels it needs. This will depend 1405 on how many LSRs are upstream of it with respect to the FEC in 1406 question. 1408 In the MPLS architecture, if a particular upstream neighbor does not 1409 support label merging, it is not sent any labels for a particular FEC 1410 unless it explicitly asks for a label for that FEC. The upstream 1411 neighbor may make multiple such requests, and is given a new label 1412 each time. When a downstream neighbor receives such a request from 1413 upstream, and the downstream neighbor does not itself support label 1414 merging, then it must in turn ask its downstream neighbor for another 1415 label for the FEC in question. 1417 It is possible that there may be some nodes which support label 1418 merging, but can only merge a limited number of incoming labels into 1419 a single outgoing label. Suppose for example that due to some 1420 hardware limitation a node is capable of merging four incoming labels 1421 into a single outgoing label. Suppose however, that this particular 1422 node has six incoming labels arriving at it for a particular FEC. In 1423 this case, this node may merge these into two outgoing labels. 1425 Whether label merging is applicable to explicitly routed LSPs is for 1426 further study. 1428 2.26.3. Merge over ATM 1430 2.26.3.1. Methods of Eliminating Cell Interleave 1432 There are several methods that can be used to eliminate the cell 1433 interleaving problem in ATM, thereby allowing ATM switches to support 1434 stream merge: 1436 1. VP merge, using the SVP Multipoint Encoding 1438 When VP merge is used, multiple virtual paths are merged into a 1439 virtual path, but packets from different sources are 1440 distinguished by using different VCIs within the VP. 1442 2. VC merge 1444 When VC merge is used, switches are required to buffer cells 1445 from one packet until the entire packet is received (this may 1446 be determined by looking for the AAL5 end of frame indicator). 1448 VP merge has the advantage that it is compatible with a higher 1449 percentage of existing ATM switch implementations. This makes it more 1450 likely that VP merge can be used in existing networks. Unlike VC 1451 merge, VP merge does not incur any delays at the merge points and 1452 also does not impose any buffer requirements. However, it has the 1453 disadvantage that it requires coordination of the VCI space within 1454 each VP. There are a number of ways that this can be accomplished. 1455 Selection of one or more methods is for further study. 1457 This tradeoff between compatibility with existing equipment versus 1458 protocol complexity and scalability implies that it is desirable for 1459 the MPLS protocol to support both VP merge and VC merge. In order to 1460 do so each ATM switch participating in MPLS needs to know whether its 1461 immediate ATM neighbors perform VP merge, VC merge, or no merge. 1463 2.26.3.2. Interoperation: VC Merge, VP Merge, and Non-Merge 1465 The interoperation of the various forms of merging over ATM is most 1466 easily described by first describing the interoperation of VC merge 1467 with non-merge. 1469 In the case where VC merge and non-merge nodes are interconnected the 1470 forwarding of cells is based in all cases on a VC (i.e., the 1471 concatenation of the VPI and VCI). For each node, if an upstream 1472 neighbor is doing VC merge then that upstream neighbor requires only 1473 a single VPI/VCI for a particular stream (this is analogous to the 1474 requirement for a single label in the case of operation over frame 1475 media). If the upstream neighbor is not doing merge, then the 1476 neighbor will require a single VPI/VCI per stream for itself, plus 1477 enough VPI/VCIs to pass to its upstream neighbors. The number 1478 required will be determined by allowing the upstream nodes to request 1479 additional VPI/VCIs from their downstream neighbors (this is again 1480 analogous to the method used with frame merge). 1482 A similar method is possible to support nodes which perform VP merge. 1483 In this case the VP merge node, rather than requesting a single 1484 VPI/VCI or a number of VPI/VCIs from its downstream neighbor, instead 1485 may request a single VP (identified by a VPI) but several VCIs within 1486 the VP. Furthermore, suppose that a non-merge node is downstream 1487 from two different VP merge nodes. This node may need to request one 1488 VPI/VCI (for traffic originating from itself) plus two VPs (one for 1489 each upstream node), each associated with a specified set of VCIs (as 1490 requested from the upstream node). 1492 In order to support all of VP merge, VC merge, and non-merge, it is 1493 therefore necessary to allow upstream nodes to request a combination 1494 of zero or more VC identifiers (consisting of a VPI/VCI), plus zero 1495 or more VPs (identified by VPIs) each containing a specified number 1496 of VCs (identified by a set of VCIs which are significant within a 1497 VP). VP merge nodes would therefore request one VP, with a contained 1498 VCI for traffic that it originates (if appropriate) plus a VCI for 1499 each VC requested from above (regardless of whether or not the VC is 1500 part of a containing VP). VC merge node would request only a single 1501 VPI/VCI (since they can merge all upstream traffic into a single VC). 1502 Non-merge nodes would pass on any requests that they get from above, 1503 plus request a VPI/VCI for traffic that they originate (if 1504 appropriate). 1506 2.27. Tunnels and Hierarchy 1508 Sometimes a router Ru takes explicit action to cause a particular 1509 packet to be delivered to another router Rd, even though Ru and Rd 1510 are not consecutive routers on the Hop-by-hop path for that packet, 1511 and Rd is not the packet's ultimate destination. For example, this 1512 may be done by encapsulating the packet inside a network layer packet 1513 whose destination address is the address of Rd itself. This creates a 1514 "tunnel" from Ru to Rd. We refer to any packet so handled as a 1515 "Tunneled Packet". 1517 2.27.1. Hop-by-Hop Routed Tunnel 1519 If a Tunneled Packet follows the Hop-by-hop path from Ru to Rd, we 1520 say that it is in an "Hop-by-Hop Routed Tunnel" whose "transmit 1521 endpoint" is Ru and whose "receive endpoint" is Rd. 1523 2.27.2. Explicitly Routed Tunnel 1525 If a Tunneled Packet travels from Ru to Rd over a path other than the 1526 Hop-by-hop path, we say that it is in an "Explicitly Routed Tunnel" 1527 whose "transmit endpoint" is Ru and whose "receive endpoint" is Rd. 1528 For example, we might send a packet through an Explicitly Routed 1529 Tunnel by encapsulating it in a packet which is source routed. 1531 2.27.3. LSP Tunnels 1533 It is possible to implement a tunnel as a LSP, and use label 1534 switching rather than network layer encapsulation to cause the packet 1535 to travel through the tunnel. The tunnel would be a LSP , where R1 is the transmit endpoint of the tunnel, and Rn is the 1537 receive endpoint of the tunnel. This is called a "LSP Tunnel". 1539 The set of packets which are to be sent though the LSP tunnel 1540 constitutes a FEC, and each LSR in the tunnel must assign a label to 1541 that FEC (i.e., must assign a label to the tunnel). The criteria for 1542 assigning a particular packet to an LSP tunnel is a local matter at 1543 the tunnel's transmit endpoint. To put a packet into an LSP tunnel, 1544 the transmit endpoint pushes a label for the tunnel onto the label 1545 stack and sends the labeled packet to the next hop in the tunnel. 1547 If it is not necessary for the tunnel's receive endpoint to be able 1548 to determine which packets it receives through the tunnel, as 1549 discussed earlier, the label stack may be popped at the penultimate 1550 LSR in the tunnel. 1552 A "Hop-by-Hop Routed LSP Tunnel" is a Tunnel that is implemented as 1553 an hop-by-hop routed LSP between the transmit endpoint and the 1554 receive endpoint. 1556 An "Explicitly Routed LSP Tunnel" is a LSP Tunnel that is also an 1557 Explicitly Routed LSP. 1559 2.27.4. Hierarchy: LSP Tunnels within LSPs 1561 Consider a LSP . Let us suppose that R1 receives 1562 unlabeled packet P, and pushes on its label stack the label to cause 1563 it to follow this path, and that this is in fact the Hop-by-hop path. 1564 However, let us further suppose that R2 and R3 are not directly 1565 connected, but are "neighbors" by virtue of being the endpoints of an 1566 LSP tunnel. So the actual sequence of LSRs traversed by P is . 1569 When P travels from R1 to R2, it will have a label stack of depth 1. 1570 R2, switching on the label, determines that P must enter the tunnel. 1571 R2 first replaces the Incoming label with a label that is meaningful 1572 to R3. Then it pushes on a new label. This level 2 label has a value 1573 which is meaningful to R21. Switching is done on the level 2 label by 1574 R21, R22, R23. R23, which is the penultimate hop in the R2-R3 tunnel, 1575 pops the label stack before forwarding the packet to R3. When R3 sees 1576 packet P, P has only a level 1 label, having now exited the tunnel. 1577 Since R3 is the penultimate hop in P's level 1 LSP, it pops the label 1578 stack, and R4 receives P unlabeled. 1580 The label stack mechanism allows LSP tunneling to nest to any depth. 1582 2.27.5. Label Distribution Peering and Hierarchy 1584 Suppose that packet P travels along a Level 1 LSP , 1585 and when going from R2 to R3 travels along a Level 2 LSP . From the perspective of the Level 2 LSP, R2's label 1587 distribution peer is R21. From the perspective of the Level 1 LSP, 1588 R2's label distribution peers are R1 and R3. One can have label 1589 distribution peers at each layer of hierarchy. We will see in 1590 sections 3.6 and 3.7 some ways to make use of this hierarchy. Note 1591 that in this example, R2 and R21 must be IGP neighbors, but R2 and R3 1592 need not be. 1594 When two LSRs are IGP neighbors, we will refer to them as "local 1595 label distribution peers". When two LSRs may be label distribution 1596 peers, but are not IGP neighbors, we will refer to them as "remote 1597 label distribution peers". In the above example, R2 and R21 are 1598 local label distribution peers, but R2 and R3 are remote label 1599 distribution peers. 1601 The MPLS architecture supports two ways to distribute labels at 1602 different layers of the hierarchy: Explicit Peering and Implicit 1603 Peering. 1605 One performs label distribution with one's local label distribution 1606 peer by sending label distribution protocol messages which are 1607 addressed to the peer. One can perform label distribution with one's 1608 remote label distribution peers in one of two ways: 1610 1. Explicit Peering 1612 In explicit peering, one distributes labels to a peer by 1613 sending label distribution protocol messages which are 1614 addressed to the peer, exactly as one would do for local label 1615 distribution peers. This technique is most useful when the 1616 number of remote label distribution peers is small, or the 1617 number of higher level label bindings is large, or the remote 1618 label distribution peers are in distinct routing areas or 1619 domains. Of course, one needs to know which labels to 1620 distribute to which peers; this is addressed in section 3.1.2. 1622 Examples of the use of explicit peering is found in sections 1623 3.2.1 and 3.6. 1625 2. Implicit Peering 1627 In Implicit Peering, one does not send label distribution 1628 protocol messages which are addressed to one's peer. Rather, 1629 to distribute higher level labels to ones remote label 1630 distribution peers, one encodes a higher level label as an 1631 attribute of a lower level label, and then distributes the 1632 lower level label, along with this attribute, to one's local 1633 label distribution peers. The local label distribution peers 1634 then propagate the information to their local label 1635 distribution peers. This process continues till the information 1636 reaches the remote peer. 1638 This technique is most useful when the number of remote label 1639 distribution peers is large. Implicit peering does not require 1640 an n-square peering mesh to distribute labels to the remote 1641 label distribution peers because the information is piggybacked 1642 through the local label distribution peering. However, 1643 implicit peering requires the intermediate nodes to store 1644 information that they might not be directly interested in. 1646 An example of the use of implicit peering is found in section 1647 3.3. 1649 2.28. Label Distribution Protocol Transport 1651 A label distribution protocol is used between nodes in an MPLS 1652 network to establish and maintain the label bindings. In order for 1653 MPLS to operate correctly, label distribution information needs to be 1654 transmitted reliably, and the label distribution protocol messages 1655 pertaining to a particular FEC need to be transmitted in sequence. 1656 Flow control is also desirable, as is the capability to carry 1657 multiple label messages in a single datagram. 1659 One way to meet these goals is to use TCP as the underlying 1660 transport, as is done in [MPLS-LDP] and [MPLS-BGP]. 1662 2.29. Why More than one Label Distribution Protocol? 1664 This architecture does not establish hard and fast rules for choosing 1665 which label distribution protocol to use in which circumstances. 1666 However, it is possible to point out some of the considerations. 1668 2.29.1. BGP and LDP 1670 In many scenarios, it is desirable to bind labels to FECs which can 1671 be identified with routes to address prefixes (see section 3.1). If 1672 there is a standard, widely deployed routing algorithm which 1673 distributes those routes, it can be argued that label distribution is 1674 best achieved by piggybacking the label distribution on the 1675 distribution of the routes themselves. 1677 For example, BGP distributes such routes, and if a BGP speaker needs 1678 to also distribute labels to its BGP peers, using BGP to do the label 1679 distribution (see [MPLS-BGP]) has a number of advantages. In 1680 particular, it permits BGP route reflectors to distribute labels, 1681 thus providing a significant scalability advantage over using LDP to 1682 distribute labels between BGP peers. 1684 2.29.2. Labels for RSVP Flowspecs 1686 When RSVP is used to set up resource reservations for particular 1687 flows, it can be desirable to label the packets in those flows, so 1688 that the RSVP filterspec does not need to be applied at each hop. It 1689 can be argued that having RSVP distribute the labels as part of its 1690 path/reservation setup process is the most efficient method of 1691 distributing labels for this purpose. 1693 2.29.3. Labels for Explicitly Routed LSPs 1695 In some applications of MPLS, particularly those related to traffic 1696 engineering, it is desirable to set up an explicitly routed path, 1697 from ingress to egress. It is also desirable to apply resource 1698 reservations along that path. 1700 One can imagine two approaches to this: 1702 - Start with an existing protocol that is used for setting up 1703 resource reservations, and extend it to support explicit routing 1704 and label distribution. 1706 - Start with an existing protocol that is used for label 1707 distribution, and extend it to support explicit routing and 1708 resource reservations. 1710 The first approach has given rise to the protocol specified in 1711 [MPLS-RSVP-TUNNELS], the second to the approach specified in [MPLS- 1712 CR-LDP]. 1714 2.30. Multicast 1716 This section is for further study 1718 3. Some Applications of MPLS 1720 3.1. MPLS and Hop by Hop Routed Traffic 1722 A number of uses of MPLS require that packets with a certain label be 1723 forwarded along the same hop-by-hop routed path that would be used 1724 for forwarding a packet with a specified address in its network layer 1725 destination address field. 1727 3.1.1. Labels for Address Prefixes 1729 In general, router R determines the next hop for packet P by finding 1730 the address prefix X in its routing table which is the longest match 1731 for P's destination address. That is, the packets in a given FEC are 1732 just those packets which match a given address prefix in R's routing 1733 table. In this case, a FEC can be identified with an address prefix. 1735 Note that a packet P may be assigned to FEC F, and FEC F may be 1736 identified with address prefix X, even if P's destination address 1737 does not match X. 1739 3.1.2. Distributing Labels for Address Prefixes 1741 3.1.2.1. Label Distribution Peers for an Address Prefix 1743 LSRs R1 and R2 are considered to be label distribution peers for 1744 address prefix X if and only if one of the following conditions 1745 holds: 1747 1. R1's route to X is a route which it learned about via a 1748 particular instance of a particular IGP, and R2 is a neighbor 1749 of R1 in that instance of that IGP 1751 2. R1's route to X is a route which it learned about by some 1752 instance of routing algorithm A1, and that route is 1753 redistributed into an instance of routing algorithm A2, and R2 1754 is a neighbor of R1 in that instance of A2 1756 3. R1 is the receive endpoint of an LSP Tunnel that is within 1757 another LSP, and R2 is a transmit endpoint of that tunnel, and 1758 R1 and R2 are participants in a common instance of an IGP, and 1759 are in the same IGP area (if the IGP in question has areas), 1760 and R1's route to X was learned via that IGP instance, or is 1761 redistributed by R1 into that IGP instance 1763 4. R1's route to X is a route which it learned about via BGP, and 1764 R2 is a BGP peer of R1 1766 In general, these rules ensure that if the route to a particular 1767 address prefix is distributed via an IGP, the label distribution 1768 peers for that address prefix are the IGP neighbors. If the route to 1769 a particular address prefix is distributed via BGP, the label 1770 distribution peers for that address prefix are the BGP peers. In 1771 other cases of LSP tunneling, the tunnel endpoints are label 1772 distribution peers. 1774 3.1.2.2. Distributing Labels 1776 In order to use MPLS for the forwarding of packets according to the 1777 hop-by-hop route corresponding to any address prefix, each LSR MUST: 1779 1. bind one or more labels to each address prefix that appears in 1780 its routing table; 1782 2. for each such address prefix X, use a label distribution 1783 protocol to distribute the binding of a label to X to each of 1784 its label distribution peers for X. 1786 There is also one circumstance in which an LSR must distribute a 1787 label binding for an address prefix, even if it is not the LSR which 1788 bound that label to that address prefix: 1790 3. If R1 uses BGP to distribute a route to X, naming some other 1791 LSR R2 as the BGP Next Hop to X, and if R1 knows that R2 has 1792 assigned label L to X, then R1 must distribute the binding 1793 between L and X to any BGP peer to which it distributes that 1794 route. 1796 These rules ensure that labels corresponding to address prefixes 1797 which correspond to BGP routes are distributed to IGP neighbors if 1798 and only if the BGP routes are distributed into the IGP. Otherwise, 1799 the labels bound to BGP routes are distributed only to the other BGP 1800 speakers. 1802 These rules are intended only to indicate which label bindings must 1803 be distributed by a given LSR to which other LSRs. 1805 3.1.3. Using the Hop by Hop path as the LSP 1807 If the hop-by-hop path that packet P needs to follow is , then can be an LSP as long as: 1810 1. there is a single address prefix X, such that, for all i, 1811 1<=i, and the Hop-by-hop path for P2 is . Let's suppose that R3 binds label L3 to X, and distributes 2079 this binding to R2. R2 binds label L2 to X, and distributes this 2080 binding to both R1 and R4. When R2 receives packet P1, its incoming 2081 label will be L2. R2 will overwrite L2 with L3, and send P1 to R3. 2082 When R2 receives packet P2, its incoming label will also be L2. R2 2083 again overwrites L2 with L3, and send P2 on to R3. 2085 Note then that when P1 and P2 are traveling from R2 to R3, they carry 2086 the same label, and as far as MPLS is concerned, they cannot be 2087 distinguished. Thus instead of talking about two distinct LSPs, and , we might talk of a single "Multipoint-to- 2089 Point LSP Tree", which we might denote as <{R1, R4}, R2, R3>. 2091 This creates a difficulty when we attempt to use conventional ATM 2092 switches as LSRs. Since conventional ATM switches do not support 2093 multipoint-to-point connections, there must be procedures to ensure 2094 that each LSP is realized as a point-to-point VC. However, if ATM 2095 switches which do support multipoint-to-point VCs are in use, then 2096 the LSPs can be most efficiently realized as multipoint-to-point VCs. 2097 Alternatively, if the SVP Multipoint Encoding (section 2.25.2) can be 2098 used, the LSPs can be realized as multipoint-to-point SVPs. 2100 3.6. LSP Tunneling between BGP Border Routers 2102 Consider the case of an Autonomous System, A, which carries transit 2103 traffic between other Autonomous Systems. Autonomous System A will 2104 have a number of BGP Border Routers, and a mesh of BGP connections 2105 among them, over which BGP routes are distributed. In many such 2106 cases, it is desirable to avoid distributing the BGP routes to 2107 routers which are not BGP Border Routers. If this can be avoided, 2108 the "route distribution load" on those routers is significantly 2109 reduced. However, there must be some means of ensuring that the 2110 transit traffic will be delivered from Border Router to Border Router 2111 by the interior routers. 2113 This can easily be done by means of LSP Tunnels. Suppose that BGP 2114 routes are distributed only to BGP Border Routers, and not to the 2115 interior routers that lie along the Hop-by-hop path from Border 2116 Router to Border Router. LSP Tunnels can then be used as follows: 2118 1. Each BGP Border Router distributes, to every other BGP Border 2119 Router in the same Autonomous System, a label for each address 2120 prefix that it distributes to that router via BGP. 2122 2. The IGP for the Autonomous System maintains a host route for 2123 each BGP Border Router. Each interior router distributes its 2124 labels for these host routes to each of its IGP neighbors. 2126 3. Suppose that: 2128 a) BGP Border Router B1 receives an unlabeled packet P, 2130 b) address prefix X in B1's routing table is the longest 2131 match for the destination address of P, 2133 c) the route to X is a BGP route, 2135 d) the BGP Next Hop for X is B2, 2137 e) B2 has bound label L1 to X, and has distributed this 2138 binding to B1, 2140 f) the IGP next hop for the address of B2 is I1, 2142 g) the address of B2 is in B1's and I1's IGP routing tables 2143 as a host route, and 2145 h) I1 has bound label L2 to the address of B2, and 2146 distributed this binding to B1. 2148 Then before sending packet P to I1, B1 must create a label 2149 stack for P, then push on label L1, and then push on label L2. 2151 4. Suppose that BGP Border Router B1 receives a labeled Packet P, 2152 where the label on the top of the label stack corresponds to an 2153 address prefix, X, to which the route is a BGP route, and that 2154 conditions 3b, 3c, 3d, and 3e all hold. Then before sending 2155 packet P to I1, B1 must replace the label at the top of the 2156 label stack with L1, and then push on label L2. 2158 With these procedures, a given packet P follows a level 1 LSP all of 2159 whose members are BGP Border Routers, and between each pair of BGP 2160 Border Routers in the level 1 LSP, it follows a level 2 LSP. 2162 These procedures effectively create a Hop-by-Hop Routed LSP Tunnel 2163 between the BGP Border Routers. 2165 Since the BGP border routers are exchanging label bindings for 2166 address prefixes that are not even known to the IGP routing, the BGP 2167 routers should become explicit label distribution peers with each 2168 other. 2170 It is sometimes possible to create Hop-by-Hop Routed LSP Tunnels 2171 between two BGP Border Routers, even if they are not in the same 2172 Autonomous System. Suppose, for example, that B1 and B2 are in AS 1. 2173 Suppose that B3 is an EBGP neighbor of B2, and is in AS2. Finally, 2174 suppose that B2 and B3 are on some network which is common to both 2175 Autonomous Systems (a "Demilitarized Zone"). In this case, an LSP 2176 tunnel can be set up directly between B1 and B3 as follows: 2178 - B3 distributes routes to B2 (using EBGP), optionally assigning 2179 labels to address prefixes; 2181 - B2 redistributes those routes to B1 (using IBGP), indicating that 2182 the BGP next hop for each such route is B3. If B3 has assigned 2183 labels to address prefixes, B2 passes these labels along, 2184 unchanged, to B1. 2186 - The IGP of AS1 has a host route for B3. 2188 3.7. Other Uses of Hop-by-Hop Routed LSP Tunnels 2190 The use of Hop-by-Hop Routed LSP Tunnels is not restricted to tunnels 2191 between BGP Next Hops. Any situation in which one might otherwise 2192 have used an encapsulation tunnel is one in which it is appropriate 2193 to use a Hop-by-Hop Routed LSP Tunnel. Instead of encapsulating the 2194 packet with a new header whose destination address is the address of 2195 the tunnel's receive endpoint, the label corresponding to the address 2196 prefix which is the longest match for the address of the tunnel's 2197 receive endpoint is pushed on the packet's label stack. The packet 2198 which is sent into the tunnel may or may not already be labeled. 2200 If the transmit endpoint of the tunnel wishes to put a labeled packet 2201 into the tunnel, it must first replace the label value at the top of 2202 the stack with a label value that was distributed to it by the 2203 tunnel's receive endpoint. Then it must push on the label which 2204 corresponds to the tunnel itself, as distributed to it by the next 2205 hop along the tunnel. To allow this, the tunnel endpoints should be 2206 explicit label distribution peers. The label bindings they need to 2207 exchange are of no interest to the LSRs along the tunnel. 2209 3.8. MPLS and Multicast 2211 Multicast routing proceeds by constructing multicast trees. The tree 2212 along which a particular multicast packet must get forwarded depends 2213 in general on the packet's source address and its destination 2214 address. Whenever a particular LSR is a node in a particular 2215 multicast tree, it binds a label to that tree. It then distributes 2216 that binding to its parent on the multicast tree. (If the node in 2217 question is on a LAN, and has siblings on that LAN, it must also 2218 distribute the binding to its siblings. This allows the parent to 2219 use a single label value when multicasting to all children on the 2220 LAN.) 2222 When a multicast labeled packet arrives, the NHLFE corresponding to 2223 the label indicates the set of output interfaces for that packet, as 2224 well as the outgoing label. If the same label encoding technique is 2225 used on all the outgoing interfaces, the very same packet can be sent 2226 to all the children. 2228 4. Label Distribution Procedures (Hop-by-Hop) 2230 In this section, we consider only label bindings that are used for 2231 traffic to be label switched along its hop-by-hop routed path. In 2232 these cases, the label in question will correspond to an address 2233 prefix in the routing table. 2235 4.1. The Procedures for Advertising and Using labels 2237 There are a number of different procedures that may be used to 2238 distribute label bindings. Some are executed by the downstream LSR, 2239 and some by the upstream LSR. 2241 The downstream LSR must perform: 2243 - The Distribution Procedure, and 2245 - the Withdrawal Procedure. 2247 The upstream LSR must perform: 2249 - The Request Procedure, and 2251 - the NotAvailable Procedure, and 2253 - the Release Procedure, and 2255 - the labelUse Procedure. 2257 The MPLS architecture supports several variants of each procedure. 2259 However, the MPLS architecture does not support all possible 2260 combinations of all possible variants. The set of supported 2261 combinations will be described in section 4.2, where the 2262 interoperability between different combinations will also be 2263 discussed. 2265 4.1.1. Downstream LSR: Distribution Procedure 2267 The Distribution Procedure is used by a downstream LSR to determine 2268 when it should distribute a label binding for a particular address 2269 prefix to its label distribution peers. The architecture supports 2270 four different distribution procedures. 2272 Irrespective of the particular procedure that is used, if a label 2273 binding for a particular address prefix has been distributed by a 2274 downstream LSR Rd to an upstream LSR Ru, and if at any time the 2275 attributes (as defined above) of that binding change, then Rd must 2276 inform Ru of the new attributes. 2278 If an LSR is maintaining multiple routes to a particular address 2279 prefix, it is a local matter as to whether that LSR binds multiple 2280 labels to the address prefix (one per route), and hence distributes 2281 multiple bindings. 2283 4.1.1.1. PushUnconditional 2285 Let Rd be an LSR. Suppose that: 2287 1. X is an address prefix in Rd's routing table 2289 2. Ru is a label distribution peer of Rd with respect to X 2291 Whenever these conditions hold, Rd must bind a label to X and 2292 distribute that binding to Ru. It is the responsibility of Rd to 2293 keep track of the bindings which it has distributed to Ru, and to 2294 make sure that Ru always has these bindings. 2296 This procedure would be used by LSRs which are performing unsolicited 2297 downstream label assignment in the Independent LSP Control Mode. 2299 4.1.1.2. PushConditional 2301 Let Rd be an LSR. Suppose that: 2303 1. X is an address prefix in Rd's routing table 2305 2. Ru is a label distribution peer of Rd with respect to X 2307 3. Rd is either an LSP Egress or an LSP Proxy Egress for X, or 2308 Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and 2309 Rn has bound a label to X and distributed that binding to Rd. 2311 Then as soon as these conditions all hold, Rd should bind a label to 2312 X and distribute that binding to Ru. 2314 Whereas PushUnconditional causes the distribution of label bindings 2315 for all address prefixes in the routing table, PushConditional causes 2316 the distribution of label bindings only for those address prefixes 2317 for which one has received label bindings from one's LSP next hop, or 2318 for which one does not have an MPLS-capable L3 next hop. 2320 This procedure would be used by LSRs which are performing unsolicited 2321 downstream label assignment in the Ordered LSP Control Mode. 2323 4.1.1.3. PulledUnconditional 2325 Let Rd be an LSR. Suppose that: 2327 1. X is an address prefix in Rd's routing table 2329 2. Ru is a label distribution peer of Rd with respect to X 2331 3. Ru has explicitly requested that Rd bind a label to X and 2332 distribute the binding to Ru 2334 Then Rd should bind a label to X and distribute that binding to Ru. 2335 Note that if X is not in Rd's routing table, or if Rd is not a label 2336 distribution peer of Ru with respect to X, then Rd must inform Ru 2337 that it cannot provide a binding at this time. 2339 If Rd has already distributed a binding for address prefix X to Ru, 2340 and it receives a new request from Ru for a binding for address 2341 prefix X, it will bind a second label, and distribute the new binding 2342 to Ru. The first label binding remains in effect. 2344 This procedure would be used by LSRs performing downstream-on-demand 2345 label distribution using the Independent LSP Control Mode. 2347 4.1.1.4. PulledConditional 2349 Let Rd be an LSR. Suppose that: 2351 1. X is an address prefix in Rd's routing table 2353 2. Ru is a label distribution peer of Rd with respect to X 2355 3. Ru has explicitly requested that Rd bind a label to X and 2356 distribute the binding to Ru 2358 4. Rd is either an LSP Egress or an LSP Proxy Egress for X, or 2359 Rd's L3 next hop for X is Rn, where Rn is distinct from Ru, and 2360 Rn has bound a label to X and distributed that binding to Rd 2362 Then as soon as these conditions all hold, Rd should bind a label to 2363 X and distribute that binding to Ru. Note that if X is not in Rd's 2364 routing table and a binding for X is not obtainable via Rd's next hop 2365 for X, or if Rd is not a label distribution peer of Ru with respect 2366 to X, then Rd must inform Ru that it cannot provide a binding at this 2367 time. 2369 However, if the only condition that fails to hold is that Rn has not 2370 yet provided a label to Rd, then Rd must defer any response to Ru 2371 until such time as it has receiving a binding from Rn. 2373 If Rd has distributed a label binding for address prefix X to Ru, and 2374 at some later time, any attribute of the label binding changes, then 2375 Rd must redistribute the label binding to Ru, with the new attribute. 2376 It must do this even though Ru does not issue a new Request. 2378 This procedure would be used by LSRs that are performing downstream- 2379 on-demand label allocation in the Ordered LSP Control Mode. 2381 In section 4.2, we will discuss how to choose the particular 2382 procedure to be used at any given time, and how to ensure 2383 interoperability among LSRs that choose different procedures. 2385 4.1.2. Upstream LSR: Request Procedure 2387 The Request Procedure is used by the upstream LSR for an address 2388 prefix to determine when to explicitly request that the downstream 2389 LSR bind a label to that prefix and distribute the binding. There 2390 are three possible procedures that can be used. 2392 4.1.2.1. RequestNever 2394 Never make a request. This is useful if the downstream LSR uses the 2395 PushConditional procedure or the PushUnconditional procedure, but is 2396 not useful if the downstream LSR uses the PulledUnconditional 2397 procedure or the the PulledConditional procedures. 2399 This procedure would be used by an LSR when unsolicited downstream 2400 label distribution and Liberal Label Retention Mode are being used. 2402 4.1.2.2. RequestWhenNeeded 2404 Make a request whenever the L3 next hop to the address prefix 2405 changes, or when a new address prefix is learned, and one doesn't 2406 already have a label binding from that next hop for the given address 2407 prefix. 2409 This procedure would be used by an LSR whenever Conservative Label 2410 Retention Mode is being used. 2412 4.1.2.3. RequestOnRequest 2414 Issue a request whenever a request is received, in addition to 2415 issuing a request when needed (as described in section 4.1.2.2). If 2416 Ru is not capable of being an LSP ingress, it may issue a request 2417 only when it receives a request from upstream. 2419 If Rd receives such a request from Ru, for an address prefix for 2420 which Rd has already distributed Ru a label, Rd shall assign a new 2421 (distinct) label, bind it to X, and distribute that binding. 2422 (Whether Rd can distribute this binding to Ru immediately or not 2423 depends on the Distribution Procedure being used.) 2425 This procedure would be used by an LSR which is doing downstream-on- 2426 demand label distribution, but is not doing label merging, e.g., an 2427 ATM-LSR which is not capable of VC merge. 2429 4.1.3. Upstream LSR: NotAvailable Procedure 2431 If Ru and Rd are respectively upstream and downstream label 2432 distribution peers for address prefix X, and Rd is Ru's L3 next hop 2433 for X, and Ru requests a binding for X from Rd, but Rd replies that 2434 it cannot provide a binding at this time, because it has no next hop 2435 for X, then the NotAvailable procedure determines how Ru responds. 2436 There are two possible procedures governing Ru's behavior: 2438 4.1.3.1. RequestRetry 2440 Ru should issue the request again at a later time. That is, the 2441 requester is responsible for trying again later to obtain the needed 2442 binding. This procedure would be used when downstream-on-demand 2443 label distribution is used. 2445 4.1.3.2. RequestNoRetry 2447 Ru should never reissue the request, instead assuming that Rd will 2448 provide the binding automatically when it is available. This is 2449 useful if Rd uses the PushUnconditional procedure or the 2450 PushConditional procedure, i.e., if unsolicited downstream label 2451 distribution is used. 2453 Note that if Rd replies that it cannot provide a binding to Ru, 2454 because of some error condition, rather than because Rd has no next 2455 hop, the behavior of Ru will be governed by the error recovery 2456 conditions of the label distribution protocol, rather than by the 2457 NotAvailable procedure. 2459 4.1.4. Upstream LSR: Release Procedure 2461 Suppose that Rd is an LSR which has bound a label to address prefix 2462 X, and has distributed that binding to LSR Ru. If Rd does not happen 2463 to be Ru's L3 next hop for address prefix X, or has ceased to be Ru's 2464 L3 next hop for address prefix X, then Ru will not be using the 2465 label. The Release Procedure determines how Ru acts in this case. 2466 There are two possible procedures governing Ru's behavior: 2468 4.1.4.1. ReleaseOnChange 2470 Ru should release the binding, and inform Rd that it has done so. 2471 This procedure would be used to implement Conservative Label 2472 Retention Mode. 2474 4.1.4.2. NoReleaseOnChange 2476 Ru should maintain the binding, so that it can use it again 2477 immediately if Rd later becomes Ru's L3 next hop for X. This 2478 procedure would be used to implement Liberal Label Retention Mode. 2480 4.1.5. Upstream LSR: labelUse Procedure 2482 Suppose Ru is an LSR which has received label binding L for address 2483 prefix X from LSR Rd, and Ru is upstream of Rd with respect to X, and 2484 in fact Rd is Ru's L3 next hop for X. 2486 Ru will make use of the binding if Rd is Ru's L3 next hop for X. If, 2487 at the time the binding is received by Ru, Rd is NOT Ru's L3 next hop 2488 for X, Ru does not make any use of the binding at that time. Ru may 2489 however start using the binding at some later time, if Rd becomes 2490 Ru's L3 next hop for X. 2492 The labelUse Procedure determines just how Ru makes use of Rd's 2493 binding. 2495 There are two procedures which Ru may use: 2497 4.1.5.1. UseImmediate 2499 Ru may put the binding into use immediately. At any time when Ru has 2500 a binding for X from Rd, and Rd is Ru's L3 next hop for X, Rd will 2501 also be Ru's LSP next hop for X. This procedure is used when loop 2502 detection is not in use. 2504 4.1.5.2. UseIfLoopNotDetected 2506 This procedure is the same as UseImmediate, unless Ru has detected a 2507 loop in the LSP. If a loop has been detected, Ru will discontinue 2508 the use of label L for forwarding packets to Rd. 2510 This procedure is used when loop detection is in use. 2512 This will continue until the next hop for X changes, or until the 2513 loop is no longer detected. 2515 4.1.6. Downstream LSR: Withdraw Procedure 2517 In this case, there is only a single procedure. 2519 When LSR Rd decides to break the binding between label L and address 2520 prefix X, then this unbinding must be distributed to all LSRs to 2521 which the binding was distributed. 2523 It is required that the unbinding of L from X be distributed by Rd to 2524 a LSR Ru before Rd distributes to Ru any new binding of L to any 2525 other address prefix Y, where X != Y. If Ru were to learn of the new 2526 binding of L to Y before it learned of the unbinding of L from X, and 2527 if packets matching both X and Y were forwarded by Ru to Rd, then for 2528 a period of time, Ru would label both packets matching X and packets 2529 matching Y with label L. 2531 The distribution and withdrawal of label bindings is done via a label 2532 distribution protocol. All label distribution protocols require that 2533 a label distribution adjacency be established between two label 2534 distribution peers (except implicit peers). If LSR R1 has a label 2535 distribution adjacency to LSR R2, and has received label bindings 2536 from LSR R2 via that adjacency, then if adjacency is brought down by 2537 either peer (whether as a result of failure or as a matter of normal 2538 operation), all bindings received over that adjacency must be 2539 considered to have been withdrawn. 2541 As long as the relevant label distribution adjacency remains in 2542 place, label bindings that are withdrawn must always be withdrawn 2543 explicitly. If a second label is bound to an address prefix, the 2544 result is not to implicitly withdraw the first label, but to bind 2545 both labels; this is needed to support multi-path routing. If a 2546 second address prefix is bound to a label, the result is not to 2547 implicitly withdraw the binding of that label to the first address 2548 prefix, but to use that label for both address prefixes. 2550 4.2. MPLS Schemes: Supported Combinations of Procedures 2552 Consider two LSRs, Ru and Rd, which are label distribution peers with 2553 respect to some set of address prefixes, where Ru is the upstream 2554 peer and Rd is the downstream peer. 2556 The MPLS scheme which governs the interaction of Ru and Rd can be 2557 described as a quintuple of procedures: . (Since there is only one Withdraw Procedure, it 2560 need not be mentioned.) A "*" appearing in one of the positions is a 2561 wild-card, meaning that any procedure in that category may be 2562 present; an "N/A" appearing in a particular position indicates that 2563 no procedure in that category is needed. 2565 Only the MPLS schemes which are specified below are supported by the 2566 MPLS Architecture. Other schemes may be added in the future, if a 2567 need for them is shown. 2569 4.2.1. Schemes for LSRs that Support Label Merging 2571 If Ru and Rd are label distribution peers, and both support label 2572 merging, one of the following schemes must be used: 2574 1. 2577 This is unsolicited downstream label distribution with 2578 independent control, liberal label retention mode, and no loop 2579 detection. 2581 2. 2584 This is unsolicited downstream label distribution with 2585 independent control, liberal label retention, and loop 2586 detection. 2588 3. 2591 This is unsolicited downstream label distribution with ordered 2592 control (from the egress) and conservative label retention 2593 mode. Loop detection is optional. 2595 4. 2597 This is unsolicited downstream label distribution with ordered 2598 control (from the egress) and liberal label retention mode. 2599 Loop detection is optional. 2601 5. 2604 This is downstream-on-demand label distribution with ordered 2605 control (initiated by the ingress), conservative label 2606 retention mode, and optional loop detection. 2608 6. 2611 This is downstream-on-demand label distribution with 2612 independent control and conservative label retention mode, 2613 without loop detection. 2615 7. 2618 This is downstream-on-demand label distribution with 2619 independent control and conservative label retention mode, with 2620 loop detection. 2622 4.2.2. Schemes for LSRs that do not Support Label Merging 2624 Suppose that R1, R2, R3, and R4 are ATM switches which do not support 2625 label merging, but are being used as LSRs. Suppose further that the 2626 L3 hop-by-hop path for address prefix X is , and that 2627 packets destined for X can enter the network at any of these LSRs. 2628 Since there is no multipoint-to-point capability, the LSPs must be 2629 realized as point-to-point VCs, which means that there needs to be 2630 three such VCs for address prefix X: , , 2631 and . 2633 Therefore, if R1 and R2 are MPLS peers, and either is an LSR which is 2634 implemented using conventional ATM switching hardware (i.e., no cell 2635 interleave suppression), or is otherwise incapable of performing 2636 label merging, the MPLS scheme in use between R1 and R2 must be one 2637 of the following: 2639 1. 2642 This is downstream-on-demand label distribution with ordered 2643 control (initiated by the ingress), conservative label 2644 retention mode, and optional loop detection. 2646 The use of the RequestOnRequest procedure will cause R4 to 2647 distribute three labels for X to R3; R3 will distribute 2 2648 labels for X to R2, and R2 will distribute one label for X to 2649 R1. 2651 2. 2654 This is downstream-on-demand label distribution with 2655 independent control and conservative label retention mode, 2656 without loop detection. 2658 3. 2661 This is downstream-on-demand label distribution with 2662 independent control and conservative label retention mode, with 2663 loop detection. 2665 4.2.3. Interoperability Considerations 2667 It is easy to see that certain quintuples do NOT yield viable MPLS 2668 schemes. For example: 2670 - 2671 2673 In these MPLS schemes, the downstream LSR Rd distributes label 2674 bindings to upstream LSR Ru only upon request from Ru, but Ru 2675 never makes any such requests. Obviously, these schemes are not 2676 viable, since they will not result in the proper distribution of 2677 label bindings. 2679 - <*, RequestNever, *, *, ReleaseOnChange> 2681 In these MPLS schemes, Rd releases bindings when it isn't using 2682 them, but it never asks for them again, even if it later has a 2683 need for them. These schemes thus do not ensure that label 2684 bindings get properly distributed. 2686 In this section, we specify rules to prevent a pair of label 2687 distribution peers from adopting procedures which lead to infeasible 2688 MPLS Schemes. These rules require either the exchange of information 2689 between label distribution peers during the initialization of the 2690 label distribution adjacency, or apriori knowledge of the information 2691 (obtained through a means outside the scope of this document). 2693 1. Each must state whether it supports label merging. 2695 2. If Rd does not support label merging, Rd must choose either the 2696 PulledUnconditional procedure or the PulledConditional 2697 procedure. If Rd chooses PulledConditional, Ru is forced to 2698 use the RequestRetry procedure. 2700 That is, if the downstream LSR does not support label merging, 2701 its preferences take priority when the MPLS scheme is chosen. 2703 3. If Ru does not support label merging, but Rd does, Ru must 2704 choose either the RequestRetry or RequestNoRetry procedure. 2705 This forces Rd to use the PulledConditional or 2706 PulledUnConditional procedure respectively. 2708 That is, if only one of the LSRs doesn't support label merging, 2709 its preferences take priority when the MPLS scheme is chosen. 2711 4. If both Ru and Rd both support label merging, then the choice 2712 between liberal and conservative label retention mode belongs 2713 to Ru. That is, Ru gets to choose either to use 2714 RequestWhenNeeded/ReleaseOnChange (conservative) , or to use 2715 RequestNever/NoReleaseOnChange (liberal). However, the choice 2716 of "push" vs. "pull" and "conditional" vs. "unconditional" 2717 belongs to Rd. If Ru chooses liberal label retention mode, Rd 2718 can choose either PushUnconditional or PushConditional. If Ru 2719 chooses conservative label retention mode, Rd can choose 2720 PushConditional, PulledConditional, or PulledUnconditional. 2722 These choices together determine the MPLS scheme in use. 2724 5. Security Considerations 2726 Some routers may implement security procedures which depend on the 2727 network layer header being in a fixed place relative to the data link 2728 layer header. The MPLS generic encapsulation inserts a shim between 2729 the data link layer header and the network layer header. This may 2730 cause such any such security procedures to fail. 2732 An MPLS label has its meaning by virtue of an agreement between the 2733 LSR that puts the label in the label stack (the "label writer") , and 2734 the LSR that interprets that label (the "label reader"). If labeled 2735 packets are accepted from untrusted sources, or if a particular 2736 incoming label is accepted from an LSR to which that label has not 2737 been distributed, then packets may be routed in an illegitimate 2738 manner. 2740 6. Intellectual Property 2742 The IETF has been notified of intellectual property rights claimed in 2743 regard to some or all of the specification contained in this 2744 document. For more information consult the online list of claimed 2745 rights. 2747 7. Authors' Addresses 2749 Eric C. Rosen 2750 Cisco Systems, Inc. 2751 250 Apollo Drive 2752 Chelmsford, MA, 01824 2753 E-mail: erosen@cisco.com 2755 Arun Viswanathan 2756 Lucent Technologies 2757 101 Crawford Corner Rd., #4D-537 2758 Holmdel, NJ 07733 2759 732-332-5163 2760 E-mail: arunv@dnrc.bell-labs.com 2761 Ross Callon 2762 IronBridge Networks 2763 55 Hayden Avenue, 2764 Lexington, MA 02173 2765 +1-781-372-8117 2766 E-mail: rcallon@ironbridgenetworks.com 2768 8. References 2770 [MPLS-ATM] "MPLS using LDP and ATM VC Switching", Davie, Doolan, 2771 Lawrence, McGloghrie, Rekhter, Rosen, Swallow, work in progress, 2772 April 1999. 2774 [MPLS-BGP] "Carrying Label Information in BGP-4", Rekhter, Rosen, 2775 work in progress, February 1999. 2777 [MPLS-CR-LDP] "Constraint-Based LSP Setup using LDP", Jamoussi, 2778 editor, work in progress, March 1999. 2780 [MPLS-FRMWRK] "A Framework for Multiprotocol Label Switching", 2781 Callon, Doolan, Feldman, Fredette, Swallow, Viswanathan, work in 2782 progress, November 1997 2784 [MPLS-FRMRLY] "Use of Label Switching on Frame Relay Networks", 2785 Conta, Doolan, Malis, work in progress, November 1998 2787 [MPLS-LDP], "LDP Specification", Andersson, Doolan, Feldman, 2788 Fredette, Thomas, work in progress, April 1999. 2790 [MPLS-RSVP] "Use of Label Switching with RSVP", Davie, Rekhter, 2791 Rosen, Viswanathan, Srinivasan, work in progress, March 1998. 2793 [MPLS-RSVP-TUNNELS], "Extensions to RSVP for LSP Tunnels", Awduche, 2794 Berger, Gan, Li, Swallow, Srinvasan, work in progress, March 1999. 2796 [MPLS-SHIM] "MPLS Label Stack Encodings", Rosen, Rekhter, Tappan, 2797 Farinacci, Fedorkow, Li, Conta, work in progress, April 1999. 2799 [MPLS-TRFENG] "Requirements for Traffic Engineering Over MPLS", 2800 Awduche, Malcolm, Agogbua, O'Dell, McManus, work in progress, August 2801 1998.