idnits 2.17.00 (12 Aug 2021) /tmp/idnits64813/draft-ijln-mpls-rfc5036bis-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- == There are 16 instances of lines with non-RFC6890-compliant IPv4 addresses in the document. If these are example addresses, they should be changed. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Line 75 has weird spacing: '...will be remov...' == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (April 26, 2017) is 1844 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) == Missing Reference: 'Dobb' is mentioned on line 1389, but not defined == Unused Reference: 'RFC5860' is defined on line 4593, but no explicit reference was found in the text == Unused Reference: 'RFC5921' is defined on line 4599, but no explicit reference was found in the text == Unused Reference: 'RFC6371' is defined on line 4604, but no explicit reference was found in the text == Unused Reference: 'RFC6372' is defined on line 4609, but no explicit reference was found in the text == Unused Reference: 'RFC7361' is defined on line 4671, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 1321 ** Obsolete normative reference: RFC 2385 (Obsoleted by RFC 5925) ** Obsolete normative reference: RFC 2434 (Obsoleted by RFC 5226) ** Downref: Normative reference to an Informational RFC: RFC 2702 ** Downref: Normative reference to an Informational RFC: RFC 3037 ** Downref: Normative reference to an Experimental RFC: RFC 3988 ** Obsolete normative reference: RFC 5226 (Obsoleted by RFC 8126) ** Downref: Normative reference to an Informational RFC: RFC 5921 ** Downref: Normative reference to an Informational RFC: RFC 6371 ** Downref: Normative reference to an Informational RFC: RFC 6372 Summary: 10 errors (**), 0 flaws (~~), 10 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group X. Chen 3 Internet-Draft L. Andersson 4 Intended status: Standards Track Huawei Technologies 5 Expires: October 28, 2017 N. Leymann 6 Deutsche Telekom 7 I. Minei 8 Google 9 K. Raza 10 Cisco Systems, Inc. 11 April 26, 2017 13 LDP Specification 14 draft-ijln-mpls-rfc5036bis-04.txt 16 Abstract 18 The architecture for Multiprotocol Label Switching (MPLS) is 19 described in RFC 3031. A fundamental concept in MPLS is that two 20 Label Switching Routers (LSRs) must agree on the meaning of the 21 labels used to forward traffic between and through them. This common 22 understanding is achieved by using a set of procedures, called a 23 label distribution protocol, by which one LSR informs another of 24 label bindings it has made. This document defines a set of such 25 procedures called LDP (for Label Distribution Protocol) by which LSRs 26 distribute labels to support MPLS forwarding along normally routed 27 paths. 29 Status of This Memo 31 This Internet-Draft is submitted in full conformance with the 32 provisions of BCP 78 and BCP 79. 34 Internet-Drafts are working documents of the Internet Engineering 35 Task Force (IETF). Note that other groups may also distribute 36 working documents as Internet-Drafts. The list of current Internet- 37 Drafts is at http://datatracker.ietf.org/drafts/current/. 39 Internet-Drafts are draft documents valid for a maximum of six months 40 and may be updated, replaced, or obsoleted by other documents at any 41 time. It is inappropriate to use Internet-Drafts as reference 42 material or to cite them other than as "work in progress." 44 This Internet-Draft will expire on October 28, 2017. 46 Copyright Notice 48 Copyright (c) 2017 IETF Trust and the persons identified as the 49 document authors. All rights reserved. 51 This document is subject to BCP 78 and the IETF Trust's Legal 52 Provisions Relating to IETF Documents 53 (http://trustee.ietf.org/license-info) in effect on the date of 54 publication of this document. Please review these documents 55 carefully, as they describe your rights and restrictions with respect 56 to this document. Code Components extracted from this document must 57 include Simplified BSD License text as described in Section 4.e of 58 the Trust Legal Provisions and are provided without warranty as 59 described in the Simplified BSD License. 61 This document may contain material from IETF Documents or IETF 62 Contributions published or made publicly available before November 63 10, 2008. The person(s) controlling the copyright in some of this 64 material may not have granted the IETF Trust the right to allow 65 modifications of such material outside the IETF Standards Process. 66 Without obtaining an adequate license from the person(s) controlling 67 the copyright in such materials, this document may not be modified 68 outside the IETF Standards Process, and derivative works of it may 69 not be created outside the IETF Standards Process, except to format 70 it for publication as an RFC or to translate it into languages other 71 than English. 73 Table of Contents 75 1. Editors notes - this section will be removed before 76 publication . . . . . . . . . . . . . . . . . . . . . . . . . 5 77 1.1. Scope of RFC5036bis work . . . . . . . . . . . . . . . . 5 78 1.2. ToDo . . . . . . . . . . . . . . . . . . . . . . . . . . 6 79 2. LDP Overview . . . . . . . . . . . . . . . . . . . . . . . . 7 80 2.1. LDP Peers . . . . . . . . . . . . . . . . . . . . . . . . 8 81 2.2. LDP Message Exchange . . . . . . . . . . . . . . . . . . 8 82 2.3. LDP Message Structure . . . . . . . . . . . . . . . . . . 9 83 2.4. LDP Error Handling . . . . . . . . . . . . . . . . . . . 9 84 2.5. LDP Extensibility and Future Compatibility . . . . . . . 9 85 2.6. Specification Language . . . . . . . . . . . . . . . . . 9 86 3. LDP Operation . . . . . . . . . . . . . . . . . . . . . . . . 9 87 3.1. FECs . . . . . . . . . . . . . . . . . . . . . . . . . . 9 88 3.2. Label Spaces, Identifiers, Sessions, and Transport . . . 11 89 3.2.1. Label Spaces . . . . . . . . . . . . . . . . . . . . 11 90 3.2.2. LDP Identifiers . . . . . . . . . . . . . . . . . . . 11 91 3.2.3. LDP Sessions . . . . . . . . . . . . . . . . . . . . 12 92 3.2.4. LDP Transport . . . . . . . . . . . . . . . . . . . . 12 93 3.3. LDP Sessions between Non-Directly Connected LSRs . . . . 12 94 3.4. LDP Discovery . . . . . . . . . . . . . . . . . . . . . . 13 95 3.4.1. Basic Discovery Mechanism . . . . . . . . . . . . . . 13 96 3.4.2. Extended Discovery Mechanism . . . . . . . . . . . . 13 97 3.5. Establishing and Maintaining LDP Sessions . . . . . . . . 14 98 3.5.1. LDP Session Establishment . . . . . . . . . . . . . . 14 99 3.5.2. Transport Connection Establishment . . . . . . . . . 14 100 3.5.3. Session Initialization . . . . . . . . . . . . . . . 16 101 3.5.4. Initialization State Machine . . . . . . . . . . . . 18 102 3.5.5. Maintaining Hello Adjacencies . . . . . . . . . . . . 20 103 3.5.6. Maintaining LDP Sessions . . . . . . . . . . . . . . 21 104 3.6. Label Distribution and Management . . . . . . . . . . . . 21 105 3.6.1. Label Distribution Control Mode . . . . . . . . . . . 22 106 3.6.1.1. Independent Label Distribution Control . . . . . 22 107 3.6.1.2. Ordered Label Distribution Control . . . . . . . 22 108 3.6.2. Label Retention Mode . . . . . . . . . . . . . . . . 23 109 3.6.2.1. Conservative Label Retention Mode . . . . . . . . 23 110 3.6.2.2. Liberal Label Retention Mode . . . . . . . . . . 23 111 3.6.3. Label Advertisement Mode . . . . . . . . . . . . . . 24 112 3.7. LDP Identifiers and Next Hop Addresses . . . . . . . . . 24 113 3.8. Loop Detection . . . . . . . . . . . . . . . . . . . . . 24 114 3.8.1. Label Request Message . . . . . . . . . . . . . . . . 25 115 3.8.2. Label Mapping Message . . . . . . . . . . . . . . . . 26 116 3.8.3. Discussion . . . . . . . . . . . . . . . . . . . . . 28 117 3.9. Authenticity and Integrity of LDP Messages . . . . . . . 29 118 3.9.1. TCP MD5 Signature Option . . . . . . . . . . . . . . 29 119 3.9.2. LDP Use of TCP MD5 Signature Option . . . . . . . . . 31 120 4. Protocol Specification . . . . . . . . . . . . . . . . . . . 31 121 4.1. LDP PDUs . . . . . . . . . . . . . . . . . . . . . . . . 31 122 4.2. LDP Procedures . . . . . . . . . . . . . . . . . . . . . 32 123 4.3. Type-Length-Value Encoding . . . . . . . . . . . . . . . 33 124 4.4. TLV Encodings for Commonly Used Parameters . . . . . . . 35 125 4.4.1. FEC TLV . . . . . . . . . . . . . . . . . . . . . . . 35 126 4.4.1.1. FEC Procedures . . . . . . . . . . . . . . . . . 37 127 4.4.2. Label TLVs . . . . . . . . . . . . . . . . . . . . . 37 128 4.4.2.1. Generic Label TLV . . . . . . . . . . . . . . . . 37 129 4.4.2.2. ATM Label TLV . . . . . . . . . . . . . . . . . . 38 130 4.4.2.3. Frame Relay Label TLV . . . . . . . . . . . . . . 39 131 4.4.3. Address List TLV . . . . . . . . . . . . . . . . . . 40 132 4.4.4. Hop Count TLV . . . . . . . . . . . . . . . . . . . . 41 133 4.4.4.1. Hop Count Procedures . . . . . . . . . . . . . . 42 134 4.4.5. Path Vector TLV . . . . . . . . . . . . . . . . . . . 43 135 4.4.5.1. Path Vector Procedures . . . . . . . . . . . . . 44 136 4.4.6. Status TLV . . . . . . . . . . . . . . . . . . . . . 45 137 4.5. LDP Messages . . . . . . . . . . . . . . . . . . . . . . 47 138 4.5.1. Notification Message . . . . . . . . . . . . . . . . 49 139 4.5.1.1. Notification Message Procedures . . . . . . . . . 50 140 4.5.1.2. Events Signaled by Notification Messages . . . . 51 141 4.5.2. Hello Message . . . . . . . . . . . . . . . . . . . . 53 142 4.5.2.1. Hello Message Procedures . . . . . . . . . . . . 56 143 4.5.3. Initialization Message . . . . . . . . . . . . . . . 57 144 4.5.3.1. Initialization Message Procedures . . . . . . . . 66 145 4.5.4. KeepAlive Message . . . . . . . . . . . . . . . . . . 67 146 4.5.4.1. KeepAlive Message Procedures . . . . . . . . . . 67 147 4.5.5. Address Message . . . . . . . . . . . . . . . . . . . 67 148 4.5.5.1. Address Message Procedures . . . . . . . . . . . 68 149 4.5.6. Address Withdraw Message . . . . . . . . . . . . . . 69 150 4.5.6.1. Address Withdraw Message Procedures . . . . . . . 70 151 4.5.7. Label Mapping Message . . . . . . . . . . . . . . . . 70 152 4.5.7.1. Label Mapping Message Procedures . . . . . . . . 71 153 4.5.8. Label Request Message . . . . . . . . . . . . . . . . 74 154 4.5.8.1. Label Request Message Procedures . . . . . . . . 75 155 4.5.9. Label Abort Request Message . . . . . . . . . . . . . 77 156 4.5.9.1. Label Abort Request Message Procedures . . . . . 77 157 4.5.10. Label Withdraw Message . . . . . . . . . . . . . . . 79 158 4.5.10.1. Label Withdraw Message Procedures . . . . . . . 80 159 4.5.11. Label Release Message . . . . . . . . . . . . . . . . 81 160 4.5.11.1. Label Release Message Procedures . . . . . . . . 82 161 4.6. Messages and TLVs for Extensibility . . . . . . . . . . . 82 162 4.6.1. LDP Vendor-Private Extensions . . . . . . . . . . . . 83 163 4.6.1.1. LDP Vendor-Private TLVs . . . . . . . . . . . . . 83 164 4.6.1.2. LDP Vendor-Private Messages . . . . . . . . . . . 84 165 4.6.2. LDP Experimental Extensions . . . . . . . . . . . . . 86 166 4.7. Message Summary . . . . . . . . . . . . . . . . . . . . . 86 167 4.8. TLV Summary . . . . . . . . . . . . . . . . . . . . . . . 87 168 4.9. Status Code Summary . . . . . . . . . . . . . . . . . . . 89 169 4.10. Well-Known Numbers . . . . . . . . . . . . . . . . . . . 90 170 4.10.1. UDP and TCP Ports . . . . . . . . . . . . . . . . . 90 171 4.10.2. Implicit NULL Label . . . . . . . . . . . . . . . . 90 172 5. RFC 5036 IANA Considerations . . . . . . . . . . . . . . . . 90 173 5.1. Message Type Name Space . . . . . . . . . . . . . . . . . 91 174 5.2. TLV Type Name Space . . . . . . . . . . . . . . . . . . . 92 175 5.3. FEC Type Name Space . . . . . . . . . . . . . . . . . . . 92 176 5.4. Status Code Name Space . . . . . . . . . . . . . . . . . 92 177 5.5. Experiment ID Name Space . . . . . . . . . . . . . . . . 93 178 6. Security Considerations . . . . . . . . . . . . . . . . . . . 93 179 6.1. Spoofing . . . . . . . . . . . . . . . . . . . . . . . . 93 180 6.2. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 94 181 6.3. Denial of Service . . . . . . . . . . . . . . . . . . . . 95 182 7. Areas for Future Study . . . . . . . . . . . . . . . . . . . 96 183 8. Changes from RFC 5036 . . . . . . . . . . . . . . . . . . . . 97 184 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 97 185 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 98 186 10.1. Normative References . . . . . . . . . . . . . . . . . . 98 187 10.2. Informative References . . . . . . . . . . . . . . . . . 100 188 Appendix A. LDP Label Distribution Procedures . . . . . . . . . 101 189 A.1. Handling Label Distribution Events . . . . . . . . . . . 104 190 A.1.1. Receive Label Request . . . . . . . . . . . . . . . . 104 191 A.1.2. Receive Label Mapping . . . . . . . . . . . . . . . . 108 192 A.1.3. Receive Label Abort Request . . . . . . . . . . . . . 114 193 A.1.4. Receive Label Release . . . . . . . . . . . . . . . . 115 194 A.1.5. Receive Label Withdraw . . . . . . . . . . . . . . . 117 195 A.1.6. Recognize New FEC . . . . . . . . . . . . . . . . . . 119 196 A.1.7. Detect Change in FEC Next Hop . . . . . . . . . . . . 122 197 A.1.8. Receive Notification / Label Request Aborted . . . . 124 198 A.1.9. Receive Notification / No Label Resources . . . . . . 125 199 A.1.10. Receive Notification / No Route . . . . . . . . . . . 126 200 A.1.11. Receive Notification / Loop Detected . . . . . . . . 127 201 A.1.12. Receive Notification / Label Resources Available . . 127 202 A.1.13. Detect Local Label Resources Have Become Available . 128 203 A.1.14. LSR Decides to No Longer Label Switch a FEC . . . . . 129 204 A.1.15. Timeout of Deferred Label Request . . . . . . . . . . 130 205 A.2. Common Label Distribution Procedures . . . . . . . . . . 130 206 A.2.1. Send_Label . . . . . . . . . . . . . . . . . . . . . 130 207 A.2.2. Send_Label_Request . . . . . . . . . . . . . . . . . 132 208 A.2.3. Send_Label_Withdraw . . . . . . . . . . . . . . . . . 133 209 A.2.4. Send_Notification . . . . . . . . . . . . . . . . . . 133 210 A.2.5. Send_Message . . . . . . . . . . . . . . . . . . . . 134 211 A.2.6. Check_Received_Attributes . . . . . . . . . . . . . . 134 212 A.2.7. Prepare_Label_Request_Attributes . . . . . . . . . . 136 213 A.2.8. Prepare_Label_Mapping_Attributes . . . . . . . . . . 137 214 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 140 215 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 141 217 1. Editors notes - this section will be removed before publication 219 This entire section will be removed before publication. 221 1.1. Scope of RFC5036bis work 223 The goal of this document is to take the LDP specification to 224 Internet Standard. 226 Currently RFC 5036 - the LDP Specification - is a Draft Standard; 227 this step on the Standards Track has been removed. It is therefore 228 the plan to move the document to Internet Standard. 230 Thhis document includes updates to the LDP Specification defined 231 since the document was published, including: 233 1. Updates all references and citations. 235 RFC 5036 obsoleted RFC 3036, and will in turn be obsoleted by the 236 RFC5036-bis-to-be. 238 2. RFC 5036 is updated by RFC 6720, RFC 6790, RFC 7358, RFC 7552. 240 3. Incorporate all outstanding Errata. 242 These include the following approved Erratum with IDs: 3156, 243 2133, 3155, 3415, 3425. 245 [Ed Note: Done in rev -01] 247 4. Close loops with Stephen on the security section. 249 5. Have IANA review the IANA section. 251 1.2. ToDo 253 1. Evaluation of which of the RFCs that updated RFC 5036 need to be 254 incorporated into the rfc5036bis document. Specifically, these 255 RFCs updated RFC 5036: RFC 6720, RFC 6790, RFC 7358, RFC 7552. 256 RFCs that updated RFC 5036 and will be incorporated into this 257 rfc5036bis, will be Obsoleted by rfc5036bis. 259 2. Review IANA Allocations. Review the IANA sections (there are 260 currently two) and merge them into one. 262 3. Evaluate if there are things, based on e.g. non-deployment, that 263 should be removed from the rfc5036bis-to-be. 265 4. Evaluate what to do about RFC 7349, it is not listed as an update 266 of LDP, but it is an extension of the LDP security mechanisms 267 (Hello crypto). 269 5. RFC 2385 (The TCP Authentication Option) has been obsoleted by 270 RFC 5925, the changes are such that the text we refer to is no 271 longer there. We probably need a minor re-write of section 272 2.9.1. 274 6. This document now carries a pre RFC 5378 copyright statement, 275 since there clearly are material included in the document prior 276 to RFC 5378 (10 Nov 2008), Verify that this is the right 277 approach. 279 7. Revisit section 4.5.3 "Initialization Message" if we decide to 280 remove ATM and FR. 282 8. Check if how to forward messages relating path-vector and hop- 283 count from multiple downstreams needs to be specified/clarified. 285 2. LDP Overview 287 The MPLS architecture RFC 3031 [RFC3031] defines a label distribution 288 protocol as a set of procedures by which one Label Switched Router 289 (LSR) informs another of the meaning of labels used to forward 290 traffic between and through them. 292 The MPLS architecture does not assume a single label distribution 293 protocol. In fact, a number of different label distribution 294 protocols are being standardized. Existing protocols have been 295 extended so that label distribution can be piggybacked on them. New 296 protocols have also been defined for the explicit purpose of 297 distributing labels. The MPLS architecture discusses some of the 298 considerations when choosing a label distribution protocol for use in 299 particular MPLS applications such as Traffic Engineering RFC 2702 300 [RFC2702]. 302 The Label Distribution Protocol (LDP) is a protocol defined for 303 distributing labels. It was originally published as RFC 3036 in 304 January 2001. It was produced by the MPLS Working Group of the IETF 305 and was jointly authored by Loa Andersson, Paul Doolan, Nancy 306 Feldman, Andre Fredette, and Bob Thomas. 308 LDP is a protocol defined for distributing labels. It is the set of 309 procedures and messages by which Label Switched Routers (LSRs) 310 establish Label Switched Paths (LSPs) through a network by mapping 311 network-layer routing information directly to data-link layer 312 switched paths. These LSPs may have an endpoint at a directly 313 attached neighbor (comparable to IP hop-by-hop forwarding), or may 314 have an endpoint at a network egress node, enabling switching via all 315 intermediary nodes. 317 LDP associates a Forwarding Equivalence Class (FEC) RFC 3031 318 [RFC3031] with each LSP it creates. The FEC associated with an LSP 319 specifies which packets are "mapped" to that LSP. LSPs are extended 320 through a network as each LSR "splices" incoming labels for a FEC to 321 the outgoing label assigned to the next hop for the given FEC. 323 More information about the applicability of LDP can be found in RFC 324 3037 [RFC3037]. 326 This document assumes (but does not require) familiarity with the 327 MPLS architecture RFC 3031 [RFC3031]. Note that RFC 3031 [RFC3031] 328 includes a glossary of MPLS terminology, such as ingress, label 329 switched path, etc. 331 2.1. LDP Peers 333 Two LSRs that use LDP to exchange label/FEC mapping information are 334 known as "LDP Peers" with respect to that information, and we speak 335 of there being an "LDP Session" between them. A single LDP session 336 allows each peer to learn the other's label mappings; i.e., the 337 protocol is bidirectional. 339 2.2. LDP Message Exchange 341 There are four categories of LDP messages: 343 1. Discovery messages, used to announce and maintain the presence of 344 an LSR in a network. 346 2. Session messages, used to establish, maintain, and terminate 347 sessions between LDP peers. 349 3. Advertisement messages, used to create, change, and delete label 350 mappings for FECs. 352 4. Notification messages, used to provide advisory information and 353 to signal error information. 355 Discovery messages provide a mechanism whereby LSRs indicate their 356 presence in a network by sending a Hello message periodically. This 357 is transmitted as a UDP packet to the LDP port at the 'all routers on 358 this subnet' group multicast address. When an LSR chooses to 359 establish a session with another LSR learned via the Hello message, 360 it uses the LDP initialization procedure over TCP transport. Upon 361 successful completion of the initialization procedure, the two LSRs 362 are LDP peers, and may exchange advertisement messages. 364 When to request a label or advertise a label mapping to a peer is 365 largely a local decision made by an LSR. In general, the LSR 366 requests a label mapping from a neighboring LSR when it needs one, 367 and advertises a label mapping to a neighboring LSR when it wishes 368 the neighbor to use a label. 370 Correct operation of LDP requires reliable and in-order delivery of 371 messages. To satisfy these requirements, LDP uses the TCP transport 372 for Session, Advertisement, and Notification messages, i.e., for 373 everything but the UDP-based discovery mechanism. 375 2.3. LDP Message Structure 377 All LDP messages have a common structure that uses a Type-Length- 378 Value (TLV) encoding scheme; see Section "Type-Length-Value 379 Encoding". The Value part of a TLV-encoded object, or TLV for short, 380 may itself contain one or more TLVs. 382 2.4. LDP Error Handling 384 LDP errors and other events of interest are signaled to an LDP peer 385 by Notification messages. 387 There are two kinds of LDP Notification messages: 389 1. Error Notifications, used to signal fatal errors. If an LSR 390 receives an Error Notification from a peer for an LDP session, it 391 terminates the LDP session by closing the TCP transport 392 connection for the session and discarding all label mappings 393 learned via the session. 395 2. Advisory Notifications, used to pass on LSR information about the 396 LDP session or the status of some previous message received from 397 the peer. 399 2.5. LDP Extensibility and Future Compatibility 401 Functionality may be added to LDP in the future. It is likely that 402 future functionality will utilize new messages and object types 403 (TLVs). It may be desirable to employ such new messages and TLVs 404 within a network using older implementations that do not recognize 405 them. While it is not possible to make every future enhancement 406 backwards compatible, some prior planning can ease the introduction 407 of new capabilities. This specification defines rules for handling 408 unknown message types and unknown TLVs for this purpose. 410 2.6. Specification Language 412 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 413 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 414 document are to be interpreted as described in RFC 2119 [RFC2119]. 416 3. LDP Operation 418 3.1. FECs 420 It is necessary to precisely specify which packets may be mapped to 421 each LSP. This is done by providing a FEC specification for each 422 LSP. The FEC identifies the set of IP packets that may be mapped to 423 that LSP. 425 Each FEC is specified as a set of one or more FEC elements. Each FEC 426 element identifies a set of packets that may be mapped to the 427 corresponding LSP. When an LSP is shared by multiple FEC elements, 428 that LSP is terminated at (or before) the node where the FEC elements 429 can no longer share the same path. 431 This specification defines a single type of FEC element, the "Address 432 Prefix FEC element". This element is an address prefix of any length 433 from 0 to a full address, inclusive. 435 Additional FEC elements may be defined, as needed, by other 436 specifications. 438 In the remainder of this section, we give the rules to be used for 439 mapping packets to LSPs that have been set up using an Address Prefix 440 FEC element. 442 We say that a particular address "matches" a particular address 443 prefix if and only if that address begins with that prefix. We also 444 say that a particular packet matches a particular LSP if and only if 445 that LSP has an Address Prefix FEC element that matches the packet's 446 destination address. With respect to a particular packet and a 447 particular LSP, we refer to any Address Prefix FEC element that 448 matches the packet as the "matching prefix". 450 The procedure for mapping a particular packet to a particular LSP 451 uses the following rules. Each rule is applied in turn until the 452 packet can be mapped to an LSP. 454 - If a packet matches exactly one LSP, the packet is mapped to that 455 LSP. 457 - If a packet matches multiple LSPs, it is mapped to the LSP whose 458 matching prefix is the longest. If there is no one LSP whose 459 matching prefix is longest, the packet is mapped to one from the 460 set of LSPs whose matching prefix is longer than the others. The 461 procedure for selecting one of those LSPs is beyond the scope of 462 this document. 464 - If it is known that a packet must traverse a particular egress 465 router, and there is an LSP that has an Address Prefix FEC element 466 that is a /32 address of that router, then the packet is mapped to 467 that LSP. The procedure for obtaining this knowledge is beyond 468 the scope of this document. 470 The procedure for determining that a packet must traverse a 471 particular egress router is beyond the scope of this document. (As 472 an example, if one is running a link state routing algorithm, it may 473 be possible to obtain this information from the link state data base. 474 As another example, if one is running BGP, it may be possible to 475 obtain this information from the BGP next hop attribute of the 476 packet's route.) 478 3.2. Label Spaces, Identifiers, Sessions, and Transport 480 3.2.1. Label Spaces 482 The notion of "label space" is useful for discussing the assignment 483 and distribution of labels. There are two types of label spaces: 485 - Per interface label space. Interface-specific incoming labels are 486 used for interfaces that use interface resources for labels. An 487 example of such an interface is a label-controlled ATM interface 488 that uses VCIs (Virtual Channel Identifiers) as labels, or a Frame 489 Relay interface that uses DLCIs (Data Link Connection Identifiers) 490 as labels. 492 Note that the use of a per interface label space only makes sense 493 when the LDP peers are "directly connected" over an interface, and 494 the label is only going to be used for traffic sent over that 495 interface. 497 - Per platform label space. Platform-wide incoming labels are used 498 for interfaces that can share the same labels. 500 3.2.2. LDP Identifiers 502 An LDP Identifier is a six octet quantity used to identify an LSR 503 label space. The first four octets identify the LSR and must be a 504 globally unique value, such as a 32-bit router Id assigned to the 505 LSR. The last two octets identify a specific label space within the 506 LSR. The last two octets of LDP Identifiers for platform-wide label 507 spaces are always both zero. This document uses the following print 508 representation for LDP Identifiers: 510 :