idnits 2.17.00 (12 Aug 2021) /tmp/idnits25244/draft-ietf-mpls-rfc3036bis-01.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 4352. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4365. ** 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 74 has weird spacing: '... 00: In the "...' == Line 126 has weird spacing: '... 19. 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 (November 2004) is 6395 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 1012, but not defined == Missing Reference: 'RFC2328' is mentioned on line 1068, but not defined == Missing Reference: 'Dobb' is mentioned on line 1422, but not defined == Unused Reference: 'RFC1483' is defined on line 4285, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 4314, but no explicit reference was found in the text == Unused Reference: 'DIFFSERV' is defined on line 4326, 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: May 2005 Bob Thomas 5 Editors 7 November 2004 9 LDP Specification 11 draft-ietf-mpls-rfc3036bis-01.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 ### 69 Changes from version 00 71 1. Removed the host address fec and the references to it. 72 2. Removed the text added in version 00 regarding use of wildcard 73 fec in label request messages, as it contradicts section 3.4.1. 74 3. Reversed the change from version 00: In the "receive label 75 mapping" procedures, removed unnecessary checks in step LMp.29. 76 The checks are left in place since they make the code more 77 readable. 79 Changes from RFC3036 81 Here is a list of changes from RFC3036 82 1. Removed the Host Address FEC and references to it, since it is 83 not used by any implementation. 84 2. Split the reference list into normative and non-normative 85 references 86 3. Removed "MPLS using ATM VP Switching" from the list of 87 normative references. 88 4. Clarified the use of the F bit. 90 5. Added option to allow split horizon when doing ordered control. 91 6. Clarified the processing of messages with the U-bit set during 92 the session initialization procedures 93 7. Clarified the processing of the E-bit during session 94 initialization procedures. 95 8. Added case for TLV length too short in the specification for 96 handling malformed TLVs. 97 9. In the section describing handling of unknown TLV, removed 98 reference to inexistent section (errata in original document) 99 10. In the "receive label request" procedures, if a loop is 100 detected, changed the procedure to send a notification before 101 aborting the rest of the processing. 102 11. In "receive label release" procedures, clarified the behavior 103 for merge-capable LSRs. 104 12. In "receive label release" procedures, clarified the behavior 105 for receipt of an unknown FEC. 106 13. In note 4 of "Detect Change in FEC Next Hop", modified the text 107 to reference the correct set of conditions for sending a label 108 request procedure (typo in the original document) 109 14. In the procedures for "LSR decides to no longer label switch a 110 FEC", clarified the fact that the label must not be reused 111 until a label release is received. 112 15. In the routine "Prepare_Label_Mapping_Attributes" added a note 113 regarding the treatment of unknown TLVs according to their U 114 and F bits. 115 16. In the address message processing procedures, clarified the 116 behavior for the case where an LSR receives re-advertisement of 117 an address previously advertised it, or withdrawal of an 118 address from an LSR that has not previously advertised that 119 address. 120 17. In the routine "Receive Label Mapping" clarified the meaning 121 of PrevAdvLabel when no label advertisement message has been 122 sent previously. 123 18. In the "receive label mapping" procedures, if a loop is 124 detected, modified the procedure to send a notification before 125 aborting the rest of the processing. 126 19. In the "receive label mapping" procedures, corrected step 127 LMp.10 to handle label mapping messages for additional (non- 128 merged) LSPs for the FEC. 129 20. In the routine "Receive Label Abort Request" clarified the 130 behavior for non-merging LSRs. 131 21. Added the following items to the section discussing areas for 132 future study: 133 o extensions for communicating the maximum transmission unit 134 o basic peer discovery on NBMA media 135 o option of shutting down an adjacency 136 o mechanisms for securing Hello messages 137 o detection of a stateless fast control plane restart 138 o o support of "end of LIB" message 139 o mechanisms for dealing with the case where different LSRs 140 advertise the same address. 142 #### 144 Abstract 146 The architecture for Multi Protocol Label Switching (MPLS) is 147 described in RFC 3031. A fundamental concept in MPLS is that two 148 Label Switching Routers (LSRs) must agree on the meaning of the 149 labels used to forward traffic between and through them. This common 150 understanding is achieved by using a set of procedures, called a 151 label distribution protocol, by which one LSR informs another of 152 label bindings it has made. This document defines a set of such 153 procedures called LDP (for Label Distribution Protocol) by which LSRs 154 distribute labels to support MPLS forwarding along normally routed 155 paths. 157 Table of Contents 159 How to read this document ............................. 1 160 Source of this document ............................... 2 161 Changes from version 00 ............................... 2 162 Changes from RFC3036 .................................. 2 163 1 LDP Overview .......................................... 9 164 1.1 LDP Peers ............................................. 10 165 1.2 LDP Message Exchange .................................. 10 166 1.3 LDP Message Structure ................................. 11 167 1.4 LDP Error Handling .................................... 11 168 1.5 LDP Extensibility and Future Compatibility ............ 11 169 1.6 Specification Language ................................ 11 170 2 LDP Operation ......................................... 12 171 2.1 FECs .................................................. 12 172 2.2 Label Spaces, Identifiers, Sessions and Transport ..... 13 173 2.2.1 Label Spaces .......................................... 13 174 2.2.2 LDP Identifiers ....................................... 14 175 2.2.3 LDP Sessions .......................................... 14 176 2.2.4 LDP Transport ......................................... 14 177 2.3 LDP Sessions between non-Directly Connected LSRs ...... 15 178 2.4 LDP Discovery ......................................... 15 179 2.4.1 Basic Discovery Mechanism ............................. 15 180 2.4.2 Extended Discovery Mechanism .......................... 16 181 2.5 Establishing and Maintaining LDP Sessions ............ 17 182 2.5.1 LDP Session Establishment ............................. 17 183 2.5.2 Transport Connection Establishment .................... 17 184 2.5.3 Session Initialization ................................ 18 185 2.5.4 Initialization State Machine .......................... 21 186 2.5.5 Maintaining Hello Adjacencies ......................... 24 187 2.5.6 Maintaining LDP Sessions .............................. 24 188 2.6 Label Distribution and Management ..................... 25 189 2.6.1 Label Distribution Control Mode ....................... 25 190 2.6.1.1 Independent Label Distribution Control ................ 25 191 2.6.1.2 Ordered Label Distribution Control .................... 25 192 2.6.2 Label Retention Mode .................................. 26 193 2.6.2.1 Conservative Label Retention Mode ..................... 26 194 2.6.2.2 Liberal Label Retention Mode .......................... 27 195 2.6.3 Label Advertisement Mode .............................. 27 196 2.7 LDP Identifiers and Next Hop Addresses ................ 27 197 2.8 Loop Detection ........................................ 28 198 2.8.1 Label Request Message ................................. 29 199 2.8.2 Label Mapping Message ................................. 30 200 2.8.3 Discussion ............................................ 32 201 2.9 Authenticity and Integrity of LDP Messages ............ 32 202 2.9.1 TCP MD5 Signature Option .............................. 33 203 2.9.2 LDP Use of TCP MD5 Signature Option ................... 34 204 2.10 Label Distribution for Explicitly Routed LSPs ......... 35 205 3 Protocol Specification ................................ 35 206 3.1 LDP PDUs .............................................. 35 207 3.2 LDP Procedures ........................................ 36 208 3.3 Type-Length-Value Encoding ............................ 37 209 3.4 TLV Encodings for Commonly Used Parameters ............ 39 210 3.4.1 FEC TLV ............................................... 39 211 3.4.1.1 FEC Procedures ........................................ 42 212 3.4.2 Label TLVs ............................................ 43 213 3.4.2.1 Generic Label TLV ..................................... 43 214 3.4.2.2 ATM Label TLV ......................................... 44 215 3.4.2.3 Frame Relay Label TLV ................................. 44 216 3.4.3 Address List TLV ...................................... 45 217 3.4.4 Hop Count TLV ......................................... 46 218 3.4.4.1 Hop Count Procedures .................................. 46 219 3.4.5 Path Vector TLV ....................................... 48 220 3.4.5.1 Path Vector Procedures ................................ 48 221 3.4.5.1.1 Label Request Path Vector ............................. 48 222 3.4.5.1.2 Label Mapping Path Vector ............................. 50 223 3.4.6 Status TLV ............................................ 51 224 3.5 LDP Messages .......................................... 53 225 3.5.1 Notification Message .................................. 55 226 3.5.1.1 Notification Message Procedures ....................... 56 227 3.5.1.2 Events Signaled by Notification Messages .............. 57 228 3.5.1.2.1 Malformed PDU or Message .............................. 57 229 3.5.1.2.2 Unknown or Malformed TLV .............................. 59 230 3.5.1.2.3 Session KeepAlive Timer Expiration .................... 60 231 3.5.1.2.4 Unilateral Session Shutdown ........................... 61 232 3.5.1.2.5 Initialization Message Events ......................... 61 233 3.5.1.2.6 Events Resulting From Other Messages .................. 61 234 3.5.1.2.7 Internal Errors ....................................... 61 235 3.5.1.2.8 Miscellaneous Events .................................. 61 236 3.5.2 Hello Message ......................................... 61 237 3.5.2.1 Hello Message Procedures .............................. 64 238 3.5.3 Initialization Message ................................ 65 239 3.5.3.1 Initialization Message Procedures ..................... 73 240 3.5.4 KeepAlive Message ..................................... 73 241 3.5.4.1 KeepAlive Message Procedures .......................... 74 242 3.5.5 Address Message ....................................... 74 243 3.5.5.1 Address Message Procedures ............................ 75 244 3.5.6 Address Withdraw Message .............................. 75 245 3.5.6.1 Address Withdraw Message Procedures ................... 76 246 3.5.7 Label Mapping Message ................................. 76 247 3.5.7.1 Label Mapping Message Procedures ...................... 78 248 3.5.7.1.1 Independent Control Mapping ........................... 78 249 3.5.7.1.2 Ordered Control Mapping ............................... 79 250 3.5.7.1.3 Downstream on Demand Label Advertisement .............. 79 251 3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 81 252 3.5.8 Label Request Message ................................. 81 253 3.5.8.1 Label Request Message Procedures ...................... 82 254 3.5.9 Label Abort Request Message ........................... 84 255 3.5.9.1 Label Abort Request Message Procedures ................ 85 256 3.5.10 Label Withdraw Message ................................ 86 257 3.5.10.1 Label Withdraw Message Procedures ..................... 87 258 3.5.11 Label Release Message ................................. 89 259 3.5.11.1 Label Release Message Procedures ...................... 90 260 3.6 Messages and TLVs for Extensibility ................... 91 261 3.6.1 LDP Vendor-private Extensions ......................... 91 262 3.6.1.1 LDP Vendor-private TLVs ............................... 91 263 3.6.1.2 LDP Vendor-private Messages ........................... 94 264 3.6.2 LDP Experimental Extensions ........................... 95 265 3.7 Message Summary ....................................... 95 266 3.8 TLV Summary ........................................... 96 267 3.9 Status Code Summary ................................... 97 268 3.10 Well-known Numbers .................................... 99 269 3.10.1 UDP and TCP Ports ..................................... 99 270 3.10.2 Implicit NULL Label ................................... 99 271 4 IANA Considerations ................................... 99 272 4.1 Message Type Name Space ............................... 99 273 4.2 TLV Type Name Space ................................... 101 274 4.3 FEC Type Name Space ................................... 101 275 4.4 Status Code Name Space ................................ 102 276 4.5 Experiment ID Name Space .............................. 102 277 5 Security Considerations ............................... 102 278 5.1 Spoofing .............................................. 102 279 5.2 Privacy ............................................... 104 280 5.3 Denial of Service ..................................... 104 281 6 Areas for Future Study ................................ 106 282 7 Acknowledgments ....................................... 107 283 8 References ............................................ 108 284 8.1 Normative references .................................. 108 285 8.2 Non-normative references .............................. 109 286 9 Intellectual Property Statement ....................... 111 287 10 Editors' Addresses .................................... 111 288 Appendix A LDP Label Distribution Procedures ..................... 113 289 A.1 Handling Label Distribution Events .................... 115 290 A.1.1 Receive Label Request ................................. 116 291 A.1.2 Receive Label Mapping ................................. 120 292 A.1.3 Receive Label Abort Request ........................... 130 293 A.1.4 Receive Label Release ................................. 133 294 A.1.5 Receive Label Withdraw ................................ 135 295 A.1.6 Recognize New FEC ..................................... 137 296 A.1.7 Detect Change in FEC Next Hop ......................... 140 297 A.1.8 Receive Notification / Label Request Aborted .......... 143 298 A.1.9 Receive Notification / No Label Resources ............. 144 299 A.1.10 Receive Notification / No Route ....................... 144 300 A.1.11 Receive Notification / Loop Detected .................. 146 301 A.1.12 Receive Notification / Label Resources Available ...... 146 302 A.1.13 Detect local label resources have become available .... 147 303 A.1.14 LSR decides to no longer label switch a FEC ........... 148 304 A.1.15 Timeout of deferred label request ..................... 149 305 A.2 Common Label Distribution Procedures .................. 150 306 A.2.1 Send_Label ............................................ 150 307 A.2.2 Send_Label_Request .................................... 151 308 A.2.3 Send_Label_Withdraw ................................... 153 309 A.2.4 Send_Notification ..................................... 154 310 A.2.5 Send_Message .......................................... 154 311 A.2.6 Check_Received_Attributes ............................. 155 312 A.2.7 Prepare_Label_Request_Attributes ...................... 156 313 A.2.8 Prepare_Label_Mapping_Attributes ...................... 158 314 Full Copyright Statement .............................. 162 316 1. LDP Overview 318 The MPLS architecture [RFC3031] defines a label distribution protocol 319 as a set of procedures by which one Label Switched Router (LSR) 320 informs another of the meaning of labels used to forward traffic 321 between and through them. 323 The MPLS architecture does not assume a single label distribution 324 protocol. In fact, a number of different label distribution proto- 325 cols are being standardized. Existing protocols have been extended 326 so that label distribution can be piggybacked on them. New protocols 327 have also been defined for the explicit purpose of distributing 328 labels. The MPLS architecture discusses some of the considerations 329 when choosing a label distribution protocol for use in particular 330 MPLS applications such as Traffic Engineering [RFC2702]. 332 ### New text to reflect that this document builds on 3036 334 The Label Distribution Protocol (LDP) is a protocol defined for dis- 335 tributing labels. It was originally published as RFC3036 in January 336 2001. It was produced by the MPLS working of the IETF and was jointly 337 authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette 338 and Bob Thomas. 340 ### 342 LDP is a protocol defined for distributing labels. It is the set of 343 procedures and messages by which Label Switched Routers (LSRs) estab- 344 lish Label Switched Paths (LSPs) through a network by mapping net- 345 work-layer routing information directly to data-link layer switched 346 paths. These LSPs may have an endpoint at a directly attached neigh- 347 bor (comparable to IP hop-by-hop forwarding), or may have an endpoint 348 at a network egress node, enabling switching via all intermediary 349 nodes. 351 LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with 352 each LSP it creates. The FEC associated with an LSP specifies which 353 packets are "mapped" to that LSP. LSPs are extended through a net- 354 work as each LSR "splices" incoming labels for a FEC to the outgoing 355 label assigned to the next hop for the given FEC. 357 More information about the applicability of LDP can be found in 358 [RFC3037]. 360 This document assumes familiarity with the MPLS architecture 361 [RFC3031]. Note that [RFC3031] includes a glossary of MPLS terminol- 362 ogy, such as ingress, label switched path, etc. 364 1.1. LDP Peers 366 Two LSRs which use LDP to exchange label/FEC mapping information are 367 known as "LDP Peers" with respect to that information and we speak of 368 there being an "LDP Session" between them. A single LDP session 369 allows each peer to learn the other's label mappings; i.e., the pro- 370 tocol is bi-directional. 372 1.2. LDP Message Exchange 374 There are four categories of LDP messages: 376 1. Discovery messages, used to announce and maintain the presence 377 of an LSR in a network. 379 2. Session messages, used to establish, maintain, and terminate 380 sessions between LDP peers. 382 3. Advertisement messages, used to create, change, and delete 383 label mappings for FECs. 385 4. to signal error information. 387 Discovery messages provide a mechanism whereby LSRs indicate their 388 presence in a network by sending a Hello message periodically. This 389 is transmitted as a UDP packet to the LDP port at the `all routers on 390 this subnet' group multicast address. When an LSR chooses to estab- 391 lish a session with another LSR learned via the Hello message, it 392 uses the LDP initialization procedure over TCP transport. Upon suc- 393 cessful completion of the initialization procedure, the two LSRs are 394 LDP peers, and may exchange advertisement messages. 396 When to request a label or advertise a label mapping to a peer is 397 largely a local decision made by an LSR. In general, the LSR 398 requests a label mapping from a neighboring LSR when it needs one, 399 and advertises a label mapping to a neighboring LSR when it wishes 400 the neighbor to use a label. 402 Correct operation of LDP requires reliable and in order delivery of 403 messages. To satisfy these requirements LDP uses the TCP transport 404 for session, advertisement and notification messages; i.e., for 405 everything but the UDP-based discovery mechanism. 407 1.3. LDP Message Structure 409 All LDP messages have a common structure that uses a Type-Length- 410 Value (TLV) encoding scheme; see Section "Type-Length-Value" encod- 411 ing. The Value part of a TLV-encoded object, or TLV for short, may 412 itself contain one or more TLVs. 414 1.4. LDP Error Handling 416 LDP errors and other events of interest are signaled to an LDP peer 417 by notification messages. 419 There are two kinds of LDP notification messages: 421 1. Error notifications, used to signal fatal errors. If an LSR 422 receives an error notification from a peer for an LDP session, 423 it terminates the LDP session by closing the TCP transport con- 424 nection for the session and discarding all label mappings 425 learned via the session. 427 2. Advisory notifications, used to pass an LSR information about 428 the LDP session or the status of some previous message received 429 from the peer. 431 1.5. LDP Extensibility and Future Compatibility 433 Functionality may be added to LDP in the future. It is likely that 434 future functionality will utilize new messages and object types 435 (TLVs). It may be desirable to employ such new messages and TLVs 436 within a network using older implementations that do not recognize 437 them. While it is not possible to make every future enhancement 438 backwards compatible, some prior planning can ease the introduction 439 of new capabilities. This specification defines rules for handling 440 unknown message types and unknown TLVs for this purpose. 442 1.6. Specification Language 444 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 445 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 446 document are to be interpreted as described in [RFC2119]. 448 2. LDP Operation 450 2.1. FECs 452 It is necessary to precisely specify which packets may be mapped to 453 each LSP. This is done by providing a FEC specification for each 454 LSP. The FEC identifies the set of IP packets which may be mapped to 455 that LSP. 457 Each FEC is specified as a set of one or more FEC elements. Each FEC 458 element identifies a set of packets which may be mapped to the corre- 459 sponding LSP. When an LSP is shared by multiple FEC elements, that 460 LSP is terminated at (or before) the node where the FEC elements can 461 no longer share the same path. 463 ### 465 Changed the text to the end of the section to reflect removal of the 466 host address fec. This includes changing the processing rules (remov- 467 ing the unnecessary ones). 469 ### 471 This specification defines a single type of FEC element, the "Address 472 Prefix FEC element". This element is an address prefix of any length 473 from 0 to a full address, inclusive. 475 Additional FEC elements may be defined, as needed, by other specifi- 476 cations. 478 In the remainder of this section we give the rules to be used for 479 mapping packets to LSPs that have been set up using an Address Prefix 480 FEC element. 482 We say that a particular address "matches" a particular address pre- 483 fix if and only if that address begins with that prefix. We also say 484 that a particular packet matches a particular LSP if and only if that 485 LSP has an Address Prefix FEC element which matches the packet's des- 486 tination address. With respect to a particular packet and a particu- 487 lar LSP, we refer to any Address Prefix FEC element which matches the 488 packet as the "matching prefix". 490 The procedure for mapping a particular packet to a particular LSP 491 uses the following rules. Each rule is applied in turn until the 492 packet can be mapped to an LSP. 494 - If a packet matches exactly one LSP, the packet is mapped to that 495 LSP. 497 - If a packet matches multiple LSPs, it is mapped to the LSP whose 498 matching prefix is the longest. If there is no one LSP whose 499 matching prefix is longest, the packet is mapped to one from the 500 set of LSPs whose matching prefix is longer than the others. The 501 procedure for selecting one of those LSPs is beyond the scope of 502 this document. 504 - If it is known that a packet must traverse a particular egress 505 router, and there is an LSP which has an Address Prefix FEC ele- 506 ment which is a /32 address of that router, then the packet is 507 mapped to that LSP. The procedure for obtaining this knowledge 508 is beyond the scope of this document. 510 The procedure for determining that a packet must traverse a particu- 511 lar egress router is beyond the scope of this document. (As an exam- 512 ple, if one is running a link state routing algorithm, it may be pos- 513 sible to obtain this information from the link state data base. As 514 another example, if one is running BGP, it may be possible to obtain 515 this information from the BGP next hop attribute of the packet's 516 route.) 518 2.2. Label Spaces, Identifiers, Sessions and Transport 520 2.2.1. Label Spaces 522 The notion of "label space" is useful for discussing the assignment 523 and distribution of labels. There are two types of label spaces: 525 - Per interface label space. Interface-specific incoming labels 526 are used for interfaces that use interface resources for labels. 527 An example of such an interface is a label-controlled ATM inter- 528 face that uses VCIs as labels, or a Frame Relay interface that 529 uses DLCIs as labels. 531 Note that the use of a per interface label space only makes sense 532 when the LDP peers are "directly connected" over an interface, 533 and the label is only going to be used for traffic sent over that 534 interface. 536 - Per platform label space. Platform-wide incoming labels are used 537 for interfaces that can share the same labels. 539 2.2.2. LDP Identifiers 541 An LDP identifier is a six octet quantity used to identify an LSR 542 label space. The first four octets identify the LSR and must be a 543 globally unique value, such as a 32-bit router Id assigned to the 544 LSR. The last two octets identify a specific label space within the 545 LSR. The last two octets of LDP Identifiers for platform-wide label 546 spaces are always both zero. This document uses the following print 547 representation for LDP Identifiers: 549 :