idnits 2.17.00 (12 Aug 2021) /tmp/idnits21527/draft-ietf-mpls-rfc3036bis-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3667, Section 5.1 on line 18. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4381. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4394. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** The document seems to lack an RFC 3978 Section 5.1 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3978 Section 5.4 (updated by RFC 4748) Copyright Line. ** The document seems to lack an RFC 3978 Section 5.4 Reference to BCP 78. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document uses RFC 3667 boilerplate or RFC 3978-like boilerplate instead of verbatim RFC 3978 boilerplate. After 6 May 2005, submission of drafts without verbatim RFC 3978 boilerplate is not accepted. The following non-3978 patterns matched text found in the document. That text should be removed or replaced: By submitting this Internet-Draft, I certify that any applicable patent or other IPR claims of which I am aware have been disclosed, or will be disclosed, and any of which I become aware will be disclosed, in accordance with RFC 3668. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' overview.' ) ** There are 7 instances of too long lines in the document, the longest one being 7 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 117 has weird spacing: '... 19. In the "...' == Line 120 has weird spacing: '... 20. In the "...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (September 2004) is 6456 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RF3031' is mentioned on line 1021, but not defined == Missing Reference: 'RFC2328' is mentioned on line 1077, but not defined == Missing Reference: 'Dobb' is mentioned on line 1431, but not defined == Unused Reference: 'RFC1483' is defined on line 4314, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 4343, but no explicit reference was found in the text == Unused Reference: 'DIFFSERV' is defined on line 4355, but no explicit reference was found in the text -- Possible downref: Non-RFC (?) normative reference: ref. 'ATM-VP' ** Obsolete normative reference: RFC 2434 (ref. 'IANA') (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 1483 (Obsoleted by RFC 2684) ** Obsolete normative reference: RFC 1700 (Obsoleted by RFC 3232) ** Downref: Normative reference to an Informational RFC: RFC 3037 -- Obsolete informational reference (is this intentional?): RFC 2385 (Obsoleted by RFC 5925) == Outdated reference: draft-ietf-mpls-ldp-mtu-extensions has been published as RFC 3988 -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) Summary: 15 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Loa Andersson 3 Internet Draft Ina Minei 4 Expiration Date: March 2005 Bob Thomas 5 Editors 7 September 2004 9 LDP Specification 11 draft-ietf-mpls-rfc3036bis-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, we certify that any applicable 16 patent or other IPR claims of which we are aware have been disclosed, 17 or will be disclosed, and any of which we become aware will be 18 disclosed, in accordance with RFC 3668. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that other 25 groups may also distribute working documents as Internet-Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 How to read this document 40 This section will be removed prior to publication. 42 This document is produced as part of advancing the LDP specification 43 to draft standard status. This document contains the original text 44 of RFC3036, with a few changes that are the result of the experience 45 gained with the protocol. 47 Sections that changed from RFC3036 are marked ### in the body of this 48 document, to facilitate the review process. The marking will be 49 removed prior to publication. 51 A list of changes from RFC 3036 is also included. This list will 52 remain in the final version of the document, but will move towards 53 the end of the document. 55 Source of this document 57 ### 59 This document is produced as part of advancing the LDP specification 60 to draft standard status. The LDP specification was originally 61 published as RFC 3036 in January 2001. It was produced by the MPLS 62 working of the IETF and was jointly authored by Loa Andersson, Paul 63 Doolan, Nancy Feldman, Andre Fredette and Bob Thomas. 65 ### 67 Changes from RFC3036 69 ### 71 Here is a list of changes from RFC3036 73 1. Split the reference list into normative and non-normative 74 references 75 2. Removed "MPLS using ATM VP Switching" from the list of 76 normative references. 77 3. Clarified the use of the F bit. 78 4. Added option to allow split horizon when doing ordered control. 79 5. Clarified the processing of messages with the U-bit set during 80 the session initialization procedures 81 6. Clarified the processing of the E-bit during session 82 initialization procedures. 83 7. Added case for TLV length too short in the specification for 84 handling malformed TLVs. 85 8. Clarified the use of the Wildcard FEC in label request 86 messages. 87 9. In the section describing handling of unknown TLV, removed 88 reference to inexistent section (errata in original document) 89 10. In the "receive label request" procedures, if a loop is 90 detected, changed the procedure to send a notification before 91 aborting the rest of the processing. 93 11. In "receive label release" procedures, clarified the behavior 94 for merge-capable LSRs. 95 12. In "receive label release" procedures, clarified the behavior 96 for receipt of an unknown FEC. 97 13. In note 4 of "Detect Change in FEC Next Hop", modified the text 98 to reference the correct set of conditions for sending a label 99 request procedure (typo in the original document) 100 14. In the procedures for "LSR decides to no longer label switch a 101 FEC", clarified the fact that the label must not be reused 102 until a label release is received. 103 15. In the routine "Prepare_Label_Mapping_Attributes" added a note 104 regarding the treatment of unknown TLVs according to their U 105 and F bits. 106 16. In the address message processing procedures, clarified the 107 behavior for the case where an LSR receives re-advertisement of 108 an address previously advertised it, or withdrawal of an 109 address from an LSR that has not previously advertised that 110 address. 111 17. In the routine "Receive Label Mapping" clarified the meaning 112 of PrevAdvLabel when no label advertisement message has been 113 sent previously. 114 18. In the "receive label mapping" procedures, if a loop is 115 detected, modified the procedure to send a notification before 116 aborting the rest of the processing. 117 19. In the "receive label mapping" procedures, corrected step 118 LMp.10 to handle label mapping messages for additional (non- 119 merged) LSPs for the FEC. 120 20. In the "receive label mapping" procedures, removed unnecessary 121 checks in step LMp.29. 122 21. In the routine "Receive Label Abort Request" clarified the 123 behavior for non-merging LSRs. 124 22. Added the following items to the section discussing areas for 125 future study: 126 o extensions for communicating the maximum transmission unit 127 o basic peer discovery on NBMA media 128 o option of shutting down an adjacency 129 o mechanisms for securing Hello messages 130 o detection of a stateless fast control plane restart 131 o o support of "end of LIB" message 132 o mechanisms for dealing with the case where different LSRs 133 advertise the same address. 135 #### 137 Abstract 139 The architecture for Multi Protocol Label Switching (MPLS) is 140 described in RFC 3031. A fundamental concept in MPLS is that two 141 Label Switching Routers (LSRs) must agree on the meaning of the 142 labels used to forward traffic between and through them. This common 143 understanding is achieved by using a set of procedures, called a 144 label distribution protocol, by which one LSR informs another of 145 label bindings it has made. This document defines a set of such 146 procedures called LDP (for Label Distribution Protocol) by which LSRs 147 distribute labels to support MPLS forwarding along normally routed 148 paths. 150 Table of Contents 152 How to read this document ............................. 1 153 Source of this document ............................... 2 154 Changes from RFC3036 .................................. 2 155 1 LDP Overview .......................................... 9 156 1.1 LDP Peers ............................................. 10 157 1.2 LDP Message Exchange .................................. 10 158 1.3 LDP Message Structure ................................. 11 159 1.4 LDP Error Handling .................................... 11 160 1.5 LDP Extensibility and Future Compatibility ............ 11 161 1.6 Specification Language ................................ 11 162 2 LDP Operation ......................................... 12 163 2.1 FECs .................................................. 12 164 2.2 Label Spaces, Identifiers, Sessions and Transport ..... 13 165 2.2.1 Label Spaces .......................................... 13 166 2.2.2 LDP Identifiers ....................................... 14 167 2.2.3 LDP Sessions .......................................... 14 168 2.2.4 LDP Transport ......................................... 15 169 2.3 LDP Sessions between non-Directly Connected LSRs ...... 15 170 2.4 LDP Discovery ......................................... 15 171 2.4.1 Basic Discovery Mechanism ............................. 16 172 2.4.2 Extended Discovery Mechanism .......................... 16 173 2.5 Establishing and Maintaining LDP Sessions ............ 17 174 2.5.1 LDP Session Establishment ............................. 17 175 2.5.2 Transport Connection Establishment .................... 17 176 2.5.3 Session Initialization ................................ 19 177 2.5.4 Initialization State Machine .......................... 21 178 2.5.5 Maintaining Hello Adjacencies ......................... 24 179 2.5.6 Maintaining LDP Sessions .............................. 24 180 2.6 Label Distribution and Management ..................... 25 181 2.6.1 Label Distribution Control Mode ....................... 25 182 2.6.1.1 Independent Label Distribution Control ................ 25 183 2.6.1.2 Ordered Label Distribution Control .................... 25 184 2.6.2 Label Retention Mode .................................. 26 185 2.6.2.1 Conservative Label Retention Mode ..................... 26 186 2.6.2.2 Liberal Label Retention Mode .......................... 27 187 2.6.3 Label Advertisement Mode .............................. 27 188 2.7 LDP Identifiers and Next Hop Addresses ................ 27 189 2.8 Loop Detection ........................................ 28 190 2.8.1 Label Request Message ................................. 29 191 2.8.2 Label Mapping Message ................................. 30 192 2.8.3 Discussion ............................................ 32 193 2.9 Authenticity and Integrity of LDP Messages ............ 32 194 2.9.1 TCP MD5 Signature Option .............................. 33 195 2.9.2 LDP Use of TCP MD5 Signature Option ................... 34 196 2.10 Label Distribution for Explicitly Routed LSPs ......... 35 197 3 Protocol Specification ................................ 35 198 3.1 LDP PDUs .............................................. 35 199 3.2 LDP Procedures ........................................ 36 200 3.3 Type-Length-Value Encoding ............................ 37 201 3.4 TLV Encodings for Commonly Used Parameters ............ 39 202 3.4.1 FEC TLV ............................................... 39 203 3.4.1.1 FEC Procedures ........................................ 42 204 3.4.2 Label TLVs ............................................ 42 205 3.4.2.1 Generic Label TLV ..................................... 42 206 3.4.2.2 ATM Label TLV ......................................... 43 207 3.4.2.3 Frame Relay Label TLV ................................. 43 208 3.4.3 Address List TLV ...................................... 44 209 3.4.4 Hop Count TLV ......................................... 45 210 3.4.4.1 Hop Count Procedures .................................. 45 211 3.4.5 Path Vector TLV ....................................... 47 212 3.4.5.1 Path Vector Procedures ................................ 47 213 3.4.5.1.1 Label Request Path Vector ............................. 47 214 3.4.5.1.2 Label Mapping Path Vector ............................. 49 215 3.4.6 Status TLV ............................................ 50 216 3.5 LDP Messages .......................................... 52 217 3.5.1 Notification Message .................................. 54 218 3.5.1.1 Notification Message Procedures ....................... 55 219 3.5.1.2 Events Signaled by Notification Messages .............. 56 220 3.5.1.2.1 Malformed PDU or Message .............................. 56 221 3.5.1.2.2 Unknown or Malformed TLV .............................. 58 222 3.5.1.2.3 Session KeepAlive Timer Expiration .................... 59 223 3.5.1.2.4 Unilateral Session Shutdown ........................... 60 224 3.5.1.2.5 Initialization Message Events ......................... 60 225 3.5.1.2.6 Events Resulting From Other Messages .................. 60 226 3.5.1.2.7 Internal Errors ....................................... 60 227 3.5.1.2.8 Miscellaneous Events .................................. 60 228 3.5.2 Hello Message ......................................... 60 229 3.5.2.1 Hello Message Procedures .............................. 63 230 3.5.3 Initialization Message ................................ 64 231 3.5.3.1 Initialization Message Procedures ..................... 72 232 3.5.4 KeepAlive Message ..................................... 72 233 3.5.4.1 KeepAlive Message Procedures .......................... 73 234 3.5.5 Address Message ....................................... 73 235 3.5.5.1 Address Message Procedures ............................ 74 236 3.5.6 Address Withdraw Message .............................. 74 237 3.5.6.1 Address Withdraw Message Procedures ................... 75 238 3.5.7 Label Mapping Message ................................. 75 239 3.5.7.1 Label Mapping Message Procedures ...................... 77 240 3.5.7.1.1 Independent Control Mapping ........................... 77 241 3.5.7.1.2 Ordered Control Mapping ............................... 78 242 3.5.7.1.3 Downstream on Demand Label Advertisement .............. 78 243 3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 80 244 3.5.8 Label Request Message ................................. 80 245 3.5.8.1 Label Request Message Procedures ...................... 81 246 3.5.9 Label Abort Request Message ........................... 84 247 3.5.9.1 Label Abort Request Message Procedures ................ 85 248 3.5.10 Label Withdraw Message ................................ 86 249 3.5.10.1 Label Withdraw Message Procedures ..................... 87 250 3.5.11 Label Release Message ................................. 89 251 3.5.11.1 Label Release Message Procedures ...................... 90 252 3.6 Messages and TLVs for Extensibility ................... 91 253 3.6.1 LDP Vendor-private Extensions ......................... 91 254 3.6.1.1 LDP Vendor-private TLVs ............................... 91 255 3.6.1.2 LDP Vendor-private Messages ........................... 94 256 3.6.2 LDP Experimental Extensions ........................... 95 257 3.7 Message Summary ....................................... 95 258 3.8 TLV Summary ........................................... 96 259 3.9 Status Code Summary ................................... 97 260 3.10 Well-known Numbers .................................... 99 261 3.10.1 UDP and TCP Ports ..................................... 99 262 3.10.2 Implicit NULL Label ................................... 99 263 4 IANA Considerations ................................... 99 264 4.1 Message Type Name Space ............................... 99 265 4.2 TLV Type Name Space ................................... 101 266 4.3 FEC Type Name Space ................................... 101 267 4.4 Status Code Name Space ................................ 102 268 4.5 Experiment ID Name Space .............................. 102 269 5 Security Considerations ............................... 102 270 5.1 Spoofing .............................................. 102 271 5.2 Privacy ............................................... 104 272 5.3 Denial of Service ..................................... 104 273 6 Areas for Future Study ................................ 106 274 7 Acknowledgments ....................................... 107 275 8 References ............................................ 108 276 8.1 Normative references .................................. 108 277 8.2 Non-normative references .............................. 109 278 9 Intellectual Property Statement ....................... 111 279 10 Editors' Addresses .................................... 111 280 Appendix A LDP Label Distribution Procedures ..................... 113 281 A.1 Handling Label Distribution Events .................... 115 282 A.1.1 Receive Label Request ................................. 116 283 A.1.2 Receive Label Mapping ................................. 120 284 A.1.3 Receive Label Abort Request ........................... 130 285 A.1.4 Receive Label Release ................................. 133 286 A.1.5 Receive Label Withdraw ................................ 135 287 A.1.6 Recognize New FEC ..................................... 137 288 A.1.7 Detect Change in FEC Next Hop ......................... 140 289 A.1.8 Receive Notification / Label Request Aborted .......... 143 290 A.1.9 Receive Notification / No Label Resources ............. 144 291 A.1.10 Receive Notification / No Route ....................... 144 292 A.1.11 Receive Notification / Loop Detected .................. 146 293 A.1.12 Receive Notification / Label Resources Available ...... 146 294 A.1.13 Detect local label resources have become available .... 147 295 A.1.14 LSR decides to no longer label switch a FEC ........... 148 296 A.1.15 Timeout of deferred label request ..................... 149 297 A.2 Common Label Distribution Procedures .................. 150 298 A.2.1 Send_Label ............................................ 150 299 A.2.2 Send_Label_Request .................................... 151 300 A.2.3 Send_Label_Withdraw ................................... 153 301 A.2.4 Send_Notification ..................................... 154 302 A.2.5 Send_Message .......................................... 154 303 A.2.6 Check_Received_Attributes ............................. 155 304 A.2.7 Prepare_Label_Request_Attributes ...................... 156 305 A.2.8 Prepare_Label_Mapping_Attributes ...................... 158 306 Full Copyright Statement .............................. 162 308 1. LDP Overview 310 The MPLS architecture [RFC3031] defines a label distribution protocol 311 as a set of procedures by which one Label Switched Router (LSR) 312 informs another of the meaning of labels used to forward traffic 313 between and through them. 315 The MPLS architecture does not assume a single label distribution 316 protocol. In fact, a number of different label distribution proto- 317 cols are being standardized. Existing protocols have been extended 318 so that label distribution can be piggybacked on them. New protocols 319 have also been defined for the explicit purpose of distributing 320 labels. The MPLS architecture discusses some of the considerations 321 when choosing a label distribution protocol for use in particular 322 MPLS applications such as Traffic Engineering [RFC2702]. 324 ### New text to reflect that this document builds on 3036 326 The Label Distribution Protocol (LDP) is a protocol defined for dis- 327 tributing labels. It was originally published as RFC3036 in January 328 2001. It was produced by the MPLS working of the IETF and was jointly 329 authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette 330 and Bob Thomas. 332 ### 334 LDP is a protocol defined for distributing labels. It is the set of 335 procedures and messages by which Label Switched Routers (LSRs) estab- 336 lish Label Switched Paths (LSPs) through a network by mapping net- 337 work-layer routing information directly to data-link layer switched 338 paths. These LSPs may have an endpoint at a directly attached neigh- 339 bor (comparable to IP hop-by-hop forwarding), or may have an endpoint 340 at a network egress node, enabling switching via all intermediary 341 nodes. 343 LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with 344 each LSP it creates. The FEC associated with an LSP specifies which 345 packets are "mapped" to that LSP. LSPs are extended through a net- 346 work as each LSR "splices" incoming labels for a FEC to the outgoing 347 label assigned to the next hop for the given FEC. 349 More information about the applicability of LDP can be found in 350 [RFC3037]. 352 This document assumes familiarity with the MPLS architecture 353 [RFC3031]. Note that [RFC3031] includes a glossary of MPLS terminol- 354 ogy, such as ingress, label switched path, etc. 356 1.1. LDP Peers 358 Two LSRs which use LDP to exchange label/FEC mapping information are 359 known as "LDP Peers" with respect to that information and we speak of 360 there being an "LDP Session" between them. A single LDP session 361 allows each peer to learn the other's label mappings; i.e., the pro- 362 tocol is bi-directional. 364 1.2. LDP Message Exchange 366 There are four categories of LDP messages: 368 1. Discovery messages, used to announce and maintain the presence 369 of an LSR in a network. 371 2. Session messages, used to establish, maintain, and terminate 372 sessions between LDP peers. 374 3. Advertisement messages, used to create, change, and delete 375 label mappings for FECs. 377 4. to signal error information. 379 Discovery messages provide a mechanism whereby LSRs indicate their 380 presence in a network by sending a Hello message periodically. This 381 is transmitted as a UDP packet to the LDP port at the `all routers on 382 this subnet' group multicast address. When an LSR chooses to estab- 383 lish a session with another LSR learned via the Hello message, it 384 uses the LDP initialization procedure over TCP transport. Upon suc- 385 cessful completion of the initialization procedure, the two LSRs are 386 LDP peers, and may exchange advertisement messages. 388 When to request a label or advertise a label mapping to a peer is 389 largely a local decision made by an LSR. In general, the LSR 390 requests a label mapping from a neighboring LSR when it needs one, 391 and advertises a label mapping to a neighboring LSR when it wishes 392 the neighbor to use a label. 394 Correct operation of LDP requires reliable and in order delivery of 395 messages. To satisfy these requirements LDP uses the TCP transport 396 for session, advertisement and notification messages; i.e., for 397 everything but the UDP-based discovery mechanism. 399 1.3. LDP Message Structure 401 All LDP messages have a common structure that uses a Type-Length- 402 Value (TLV) encoding scheme; see Section "Type-Length-Value" encod- 403 ing. The Value part of a TLV-encoded object, or TLV for short, may 404 itself contain one or more TLVs. 406 1.4. LDP Error Handling 408 LDP errors and other events of interest are signaled to an LDP peer 409 by notification messages. 411 There are two kinds of LDP notification messages: 413 1. Error notifications, used to signal fatal errors. If an LSR 414 receives an error notification from a peer for an LDP session, 415 it terminates the LDP session by closing the TCP transport con- 416 nection for the session and discarding all label mappings 417 learned via the session. 419 2. Advisory notifications, used to pass an LSR information about 420 the LDP session or the status of some previous message received 421 from the peer. 423 1.5. LDP Extensibility and Future Compatibility 425 Functionality may be added to LDP in the future. It is likely that 426 future functionality will utilize new messages and object types 427 (TLVs). It may be desirable to employ such new messages and TLVs 428 within a network using older implementations that do not recognize 429 them. While it is not possible to make every future enhancement 430 backwards compatible, some prior planning can ease the introduction 431 of new capabilities. This specification defines rules for handling 432 unknown message types and unknown TLVs for this purpose. 434 1.6. Specification Language 436 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 437 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 438 document are to be interpreted as described in [RFC2119]. 440 2. LDP Operation 442 2.1. FECs 444 It is necessary to precisely specify which packets may be mapped to 445 each LSP. This is done by providing a FEC specification for each 446 LSP. The FEC identifies the set of IP packets which may be mapped to 447 that LSP. 449 Each FEC is specified as a set of one or more FEC elements. Each FEC 450 element identifies a set of packets which may be mapped to the corre- 451 sponding LSP. When an LSP is shared by multiple FEC elements, that 452 LSP is terminated at (or before) the node where the FEC elements can 453 no longer share the same path. 455 Following are the currently defined types of FEC elements. New ele- 456 ment types may be added as needed: 458 1. Address Prefix. This element is an address prefix of any 459 length from 0 to a full address, inclusive. 461 2. Host Address. This element is a full host address. 463 (We will see below that an Address Prefix FEC element which is a full 464 address has a different effect than a Host Address FEC element which 465 has the same address.) 467 We say that a particular address "matches" a particular address pre- 468 fix if and only if that address begins with that prefix. We also say 469 that a particular packet matches a particular LSP if and only if that 470 LSP has an Address Prefix FEC element which matches the packet's des- 471 tination address. With respect to a particular packet and a particu- 472 lar LSP, we refer to any Address Prefix FEC element which matches the 473 packet as the "matching prefix". 475 The procedure for mapping a particular packet to a particular LSP 476 uses the following rules. Each rule is applied in turn until the 477 packet can be mapped to an LSP. 479 - If there is exactly one LSP which has a Host Address FEC element 480 that is identical to the packet's destination address, then the 481 packet is mapped to that LSP. 483 - If there are multiple LSPs, each containing a Host Address FEC 484 element that is identical to the packet's destination address, 485 then the packet is mapped to one of those LSPs. The procedure 486 for selecting one of those LSPs is beyond the scope of this docu- 487 ment. 489 - If a packet matches exactly one LSP, the packet is mapped to that 490 LSP. 492 - If a packet matches multiple LSPs, it is mapped to the LSP whose 493 matching prefix is the longest. If there is no one LSP whose 494 matching prefix is longest, the packet is mapped to one from the 495 set of LSPs whose matching prefix is longer than the others. The 496 procedure for selecting one of those LSPs is beyond the scope of 497 this document. 499 - If it is known that a packet must traverse a particular egress 500 router, and there is an LSP which has an Address Prefix FEC ele- 501 ment which is an address of that router, then the packet is 502 mapped to that LSP. The procedure for obtaining this knowledge 503 is beyond the scope of this document. 505 The procedure for determining that a packet must traverse a particu- 506 lar egress router is beyond the scope of this document. (As an exam- 507 ple, if one is running a link state routing algorithm, it may be pos- 508 sible to obtain this information from the link state data base. As 509 another example, if one is running BGP, it may be possible to obtain 510 this information from the BGP next hop attribute of the packet's 511 route.) 513 It is worth pointing out a few consequences of these rules: 515 - A packet may be sent on the LSP whose Address Prefix FEC element 516 is the address of the packet's egress router ONLY if there is no 517 LSP matching the packet's destination address. 519 - A packet may match two LSPs, one with a Host Address FEC element 520 and one with an Address Prefix FEC element. In this case, the 521 packet is always assigned to the former. 523 - A packet which does not match a particular Host Address FEC ele- 524 ment may not be sent on the corresponding LSP, even if the Host 525 Address FEC element identifies the packet's egress router. 527 2.2. Label Spaces, Identifiers, Sessions and Transport 529 2.2.1. Label Spaces 531 The notion of "label space" is useful for discussing the assignment 532 and distribution of labels. There are two types of label spaces: 534 - Per interface label space. Interface-specific incoming labels 535 are used for interfaces that use interface resources for labels. 536 An example of such an interface is a label-controlled ATM inter- 537 face that uses VCIs as labels, or a Frame Relay interface that 538 uses DLCIs as labels. 540 Note that the use of a per interface label space only makes sense 541 when the LDP peers are "directly connected" over an interface, 542 and the label is only going to be used for traffic sent over that 543 interface. 545 - Per platform label space. Platform-wide incoming labels are used 546 for interfaces that can share the same labels. 548 2.2.2. LDP Identifiers 550 An LDP identifier is a six octet quantity used to identify an LSR 551 label space. The first four octets identify the LSR and must be a 552 globally unique value, such as a 32-bit router Id assigned to the 553 LSR. The last two octets identify a specific label space within the 554 LSR. The last two octets of LDP Identifiers for platform-wide label 555 spaces are always both zero. This document uses the following print 556 representation for LDP Identifiers: 558 :