idnits 2.17.1 draft-ietf-mpls-rfc3036bis-03.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 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 4245. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 4258. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** 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? 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 8 instances of too long lines in the document, the longest one being 7 characters in excess of 72. ** The abstract seems to contain references ([RFC3031]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 4132 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 (October 2005) is 6739 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: 'RF3031' is mentioned on line 898, but not defined == Missing Reference: 'RFC2328' is mentioned on line 954, but not defined == Missing Reference: 'Dobb' is mentioned on line 1308, but not defined == Missing Reference: 'ATM-VP' is mentioned on line 2731, but not defined == Unused Reference: 'RFC1483' is defined on line 4180, but no explicit reference was found in the text == Unused Reference: 'RFC2205' is defined on line 4209, but no explicit reference was found in the text == Unused Reference: 'DIFFSERV' is defined on line 4221, but no explicit reference was found in the text ** 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) -- Obsolete informational reference (is this intentional?): RFC 1771 (Obsoleted by RFC 4271) Summary: 12 errors (**), 0 flaws (~~), 10 warnings (==), 7 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: April 2006 Bob Thomas 5 Editors 7 October 2005 9 LDP Specification 11 draft-ietf-mpls-rfc3036bis-03.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet-Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Source of this document 37 This document is produced as part of advancing the LDP specification 38 to draft standard status. The LDP specification was originally 39 published as RFC 3036 in January 2001. It was produced by the MPLS 40 working of the IETF and was jointly authored by Loa Andersson, Paul 41 Doolan, Nancy Feldman, Andre Fredette and Bob Thomas. 43 Abstract 45 The architecture for Multi Protocol Label Switching (MPLS) is 46 described in RFC 3031 [RFC3031]. A fundamental concept in MPLS is 47 that two Label Switching Routers (LSRs) must agree on the meaning of 48 the labels used to forward traffic between and through them. This 49 common understanding is achieved by using a set of procedures, called 50 a label distribution protocol, by which one LSR informs another of 51 label bindings it has made. This document defines a set of such 52 procedures called LDP (for Label Distribution Protocol) by which LSRs 53 distribute labels to support MPLS forwarding along normally routed 54 paths. 56 Table of Contents 58 Source of this document ............................... 1 59 1 LDP Overview .......................................... 7 60 1.1 LDP Peers ............................................. 8 61 1.2 LDP Message Exchange .................................. 8 62 1.3 LDP Message Structure ................................. 9 63 1.4 LDP Error Handling .................................... 9 64 1.5 LDP Extensibility and Future Compatibility ............ 9 65 1.6 Specification Language ................................ 9 66 2 LDP Operation ......................................... 10 67 2.1 FECs .................................................. 10 68 2.2 Label Spaces, Identifiers, Sessions and Transport ..... 11 69 2.2.1 Label Spaces .......................................... 11 70 2.2.2 LDP Identifiers ....................................... 11 71 2.2.3 LDP Sessions .......................................... 12 72 2.2.4 LDP Transport ......................................... 12 73 2.3 LDP Sessions between non-Directly Connected LSRs ...... 12 74 2.4 LDP Discovery ......................................... 13 75 2.4.1 Basic Discovery Mechanism ............................. 13 76 2.4.2 Extended Discovery Mechanism .......................... 13 77 2.5 Establishing and Maintaining LDP Sessions ............ 14 78 2.5.1 LDP Session Establishment ............................. 14 79 2.5.2 Transport Connection Establishment .................... 15 80 2.5.3 Session Initialization ................................ 16 81 2.5.4 Initialization State Machine .......................... 19 82 2.5.5 Maintaining Hello Adjacencies ......................... 21 83 2.5.6 Maintaining LDP Sessions .............................. 21 84 2.6 Label Distribution and Management ..................... 22 85 2.6.1 Label Distribution Control Mode ....................... 22 86 2.6.1.1 Independent Label Distribution Control ................ 22 87 2.6.1.2 Ordered Label Distribution Control .................... 22 88 2.6.2 Label Retention Mode .................................. 23 89 2.6.2.1 Conservative Label Retention Mode ..................... 23 90 2.6.2.2 Liberal Label Retention Mode .......................... 24 91 2.6.3 Label Advertisement Mode .............................. 24 92 2.7 LDP Identifiers and Next Hop Addresses ................ 24 93 2.8 Loop Detection ........................................ 25 94 2.8.1 Label Request Message ................................. 26 95 2.8.2 Label Mapping Message ................................. 27 96 2.8.3 Discussion ............................................ 29 97 2.9 Authenticity and Integrity of LDP Messages ............ 29 98 2.9.1 TCP MD5 Signature Option .............................. 29 99 2.9.2 LDP Use of TCP MD5 Signature Option ................... 31 100 2.10 Label Distribution for Explicitly Routed LSPs ......... 32 101 3 Protocol Specification ................................ 32 102 3.1 LDP PDUs .............................................. 32 103 3.2 LDP Procedures ........................................ 33 104 3.3 Type-Length-Value Encoding ............................ 34 105 3.4 TLV Encodings for Commonly Used Parameters ............ 35 106 3.4.1 FEC TLV ............................................... 36 107 3.4.1.1 FEC Procedures ........................................ 37 108 3.4.2 Label TLVs ............................................ 38 109 3.4.2.1 Generic Label TLV ..................................... 38 110 3.4.2.2 ATM Label TLV ......................................... 38 111 3.4.2.3 Frame Relay Label TLV ................................. 39 112 3.4.3 Address List TLV ...................................... 40 113 3.4.4 Hop Count TLV ......................................... 40 114 3.4.4.1 Hop Count Procedures .................................. 41 115 3.4.5 Path Vector TLV ....................................... 42 116 3.4.5.1 Path Vector Procedures ................................ 43 117 3.4.5.1.1 Label Request Path Vector ............................. 43 118 3.4.5.1.2 Label Mapping Path Vector ............................. 43 119 3.4.6 Status TLV ............................................ 44 120 3.5 LDP Messages .......................................... 46 121 3.5.1 Notification Message .................................. 48 122 3.5.1.1 Notification Message Procedures ....................... 49 123 3.5.1.2 Events Signaled by Notification Messages .............. 49 124 3.5.1.2.1 Malformed PDU or Message .............................. 50 125 3.5.1.2.2 Unknown or Malformed TLV .............................. 51 126 3.5.1.2.3 Session KeepAlive Timer Expiration .................... 51 127 3.5.1.2.4 Unilateral Session Shutdown ........................... 51 128 3.5.1.2.5 Initialization Message Events ......................... 51 129 3.5.1.2.6 Events Resulting From Other Messages .................. 52 130 3.5.1.2.7 Internal Errors ....................................... 52 131 3.5.1.2.8 Miscellaneous Events .................................. 52 132 3.5.2 Hello Message ......................................... 52 133 3.5.2.1 Hello Message Procedures .............................. 54 134 3.5.3 Initialization Message ................................ 56 135 3.5.3.1 Initialization Message Procedures ..................... 64 136 3.5.4 KeepAlive Message ..................................... 64 137 3.5.4.1 KeepAlive Message Procedures .......................... 64 138 3.5.5 Address Message ....................................... 65 139 3.5.5.1 Address Message Procedures ............................ 65 140 3.5.6 Address Withdraw Message .............................. 66 141 3.5.6.1 Address Withdraw Message Procedures ................... 67 142 3.5.7 Label Mapping Message ................................. 67 143 3.5.7.1 Label Mapping Message Procedures ...................... 68 144 3.5.7.1.1 Independent Control Mapping ........................... 69 145 3.5.7.1.2 Ordered Control Mapping ............................... 69 146 3.5.7.1.3 Downstream on Demand Label Advertisement .............. 70 147 3.5.7.1.4 Downstream Unsolicited Label Advertisement ............ 70 148 3.5.8 Label Request Message ................................. 71 149 3.5.8.1 Label Request Message Procedures ...................... 72 150 3.5.9 Label Abort Request Message ........................... 73 151 3.5.9.1 Label Abort Request Message Procedures ................ 74 152 3.5.10 Label Withdraw Message ................................ 76 153 3.5.10.1 Label Withdraw Message Procedures ..................... 77 154 3.5.11 Label Release Message ................................. 77 155 3.5.11.1 Label Release Message Procedures ...................... 78 156 3.6 Messages and TLVs for Extensibility ................... 79 157 3.6.1 LDP Vendor-private Extensions ......................... 79 158 3.6.1.1 LDP Vendor-private TLVs ............................... 79 159 3.6.1.2 LDP Vendor-private Messages ........................... 81 160 3.6.2 LDP Experimental Extensions ........................... 82 161 3.7 Message Summary ....................................... 82 162 3.8 TLV Summary ........................................... 83 163 3.9 Status Code Summary ................................... 84 164 3.10 Well-known Numbers .................................... 85 165 3.10.1 UDP and TCP Ports ..................................... 85 166 3.10.2 Implicit NULL Label ................................... 85 167 4 IANA Considerations ................................... 85 168 4.1 Message Type Name Space ............................... 85 169 4.2 TLV Type Name Space ................................... 86 170 4.3 FEC Type Name Space ................................... 86 171 4.4 Status Code Name Space ................................ 87 172 4.5 Experiment ID Name Space .............................. 87 173 5 Security Considerations ............................... 87 174 5.1 Spoofing .............................................. 87 175 5.2 Privacy ............................................... 88 176 5.3 Denial of Service ..................................... 89 177 6 Areas for Future Study ................................ 90 178 7 Changes from RFC3036 .................................. 91 179 8 Acknowledgments ....................................... 93 180 9 References ............................................ 93 181 9.1 Normative references .................................. 93 182 9.2 Non-normative references .............................. 94 183 10 Intellectual Property Statement ....................... 95 184 11 Editors' Addresses .................................... 95 185 Appendix A LDP Label Distribution Procedures ..................... 96 186 A.1 Handling Label Distribution Events .................... 98 187 A.1.1 Receive Label Request ................................. 99 188 A.1.2 Receive Label Mapping ................................. 102 189 A.1.3 Receive Label Abort Request ........................... 108 190 A.1.4 Receive Label Release ................................. 110 191 A.1.5 Receive Label Withdraw ................................ 112 192 A.1.6 Recognize New FEC ..................................... 113 193 A.1.7 Detect Change in FEC Next Hop ......................... 116 194 A.1.8 Receive Notification / Label Request Aborted .......... 119 195 A.1.9 Receive Notification / No Label Resources ............. 119 196 A.1.10 Receive Notification / No Route ....................... 120 197 A.1.11 Receive Notification / Loop Detected .................. 121 198 A.1.12 Receive Notification / Label Resources Available ...... 121 199 A.1.13 Detect local label resources have become available .... 122 200 A.1.14 LSR decides to no longer label switch a FEC ........... 123 201 A.1.15 Timeout of deferred label request ..................... 124 202 A.2 Common Label Distribution Procedures .................. 124 203 A.2.1 Send_Label ............................................ 125 204 A.2.2 Send_Label_Request .................................... 126 205 A.2.3 Send_Label_Withdraw ................................... 127 206 A.2.4 Send_Notification ..................................... 128 207 A.2.5 Send_Message .......................................... 128 208 A.2.6 Check_Received_Attributes ............................. 129 209 A.2.7 Prepare_Label_Request_Attributes ...................... 130 210 A.2.8 Prepare_Label_Mapping_Attributes ...................... 132 211 Full Copyright Statement .............................. 135 213 1. LDP Overview 215 The MPLS architecture [RFC3031] defines a label distribution protocol 216 as a set of procedures by which one Label Switched Router (LSR) 217 informs another of the meaning of labels used to forward traffic 218 between and through them. 220 The MPLS architecture does not assume a single label distribution 221 protocol. In fact, a number of different label distribution proto- 222 cols are being standardized. Existing protocols have been extended 223 so that label distribution can be piggybacked on them. New protocols 224 have also been defined for the explicit purpose of distributing 225 labels. The MPLS architecture discusses some of the considerations 226 when choosing a label distribution protocol for use in particular 227 MPLS applications such as Traffic Engineering [RFC2702]. 229 The Label Distribution Protocol (LDP) is a protocol defined for dis- 230 tributing labels. It was originally published as RFC3036 in January 231 2001. It was produced by the MPLS working of the IETF and was jointly 232 authored by Loa Andersson, Paul Doolan, Nancy Feldman, Andre Fredette 233 and Bob Thomas. 235 LDP is a protocol defined for distributing labels. It is the set of 236 procedures and messages by which Label Switched Routers (LSRs) estab- 237 lish Label Switched Paths (LSPs) through a network by mapping net- 238 work-layer routing information directly to data-link layer switched 239 paths. These LSPs may have an endpoint at a directly attached neigh- 240 bor (comparable to IP hop-by-hop forwarding), or may have an endpoint 241 at a network egress node, enabling switching via all intermediary 242 nodes. 244 LDP associates a Forwarding Equivalence Class (FEC) [RFC3031] with 245 each LSP it creates. The FEC associated with an LSP specifies which 246 packets are "mapped" to that LSP. LSPs are extended through a net- 247 work as each LSR "splices" incoming labels for a FEC to the outgoing 248 label assigned to the next hop for the given FEC. 250 More information about the applicability of LDP can be found in 251 [RFC3037]. 253 This document assumes familiarity with the MPLS architecture 254 [RFC3031]. Note that [RFC3031] includes a glossary of MPLS terminol- 255 ogy, such as ingress, label switched path, etc. 257 1.1. LDP Peers 259 Two LSRs which use LDP to exchange label/FEC mapping information are 260 known as "LDP Peers" with respect to that information and we speak of 261 there being an "LDP Session" between them. A single LDP session 262 allows each peer to learn the other's label mappings; i.e., the pro- 263 tocol is bi-directional. 265 1.2. LDP Message Exchange 267 There are four categories of LDP messages: 269 1. Discovery messages, used to announce and maintain the presence 270 of an LSR in a network. 272 2. Session messages, used to establish, maintain, and terminate 273 sessions between LDP peers. 275 3. Advertisement messages, used to create, change, and delete 276 label mappings for FECs. 278 4. to signal error information. 280 Discovery messages provide a mechanism whereby LSRs indicate their 281 presence in a network by sending a Hello message periodically. This 282 is transmitted as a UDP packet to the LDP port at the `all routers on 283 this subnet' group multicast address. When an LSR chooses to estab- 284 lish a session with another LSR learned via the Hello message, it 285 uses the LDP initialization procedure over TCP transport. Upon suc- 286 cessful completion of the initialization procedure, the two LSRs are 287 LDP peers, and may exchange advertisement messages. 289 When to request a label or advertise a label mapping to a peer is 290 largely a local decision made by an LSR. In general, the LSR 291 requests a label mapping from a neighboring LSR when it needs one, 292 and advertises a label mapping to a neighboring LSR when it wishes 293 the neighbor to use a label. 295 Correct operation of LDP requires reliable and in order delivery of 296 messages. To satisfy these requirements LDP uses the TCP transport 297 for session, advertisement and notification messages; i.e., for 298 everything but the UDP-based discovery mechanism. 300 1.3. LDP Message Structure 302 All LDP messages have a common structure that uses a Type-Length- 303 Value (TLV) encoding scheme; see Section "Type-Length-Value" encod- 304 ing. The Value part of a TLV-encoded object, or TLV for short, may 305 itself contain one or more TLVs. 307 1.4. LDP Error Handling 309 LDP errors and other events of interest are signaled to an LDP peer 310 by notification messages. 312 There are two kinds of LDP notification messages: 314 1. Error notifications, used to signal fatal errors. If an LSR 315 receives an error notification from a peer for an LDP session, 316 it terminates the LDP session by closing the TCP transport con- 317 nection for the session and discarding all label mappings 318 learned via the session. 320 2. Advisory notifications, used to pass an LSR information about 321 the LDP session or the status of some previous message received 322 from the peer. 324 1.5. LDP Extensibility and Future Compatibility 326 Functionality may be added to LDP in the future. It is likely that 327 future functionality will utilize new messages and object types 328 (TLVs). It may be desirable to employ such new messages and TLVs 329 within a network using older implementations that do not recognize 330 them. While it is not possible to make every future enhancement 331 backwards compatible, some prior planning can ease the introduction 332 of new capabilities. This specification defines rules for handling 333 unknown message types and unknown TLVs for this purpose. 335 1.6. Specification Language 337 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 338 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 339 document are to be interpreted as described in [RFC2119]. 341 2. LDP Operation 343 2.1. FECs 345 It is necessary to precisely specify which packets may be mapped to 346 each LSP. This is done by providing a FEC specification for each 347 LSP. The FEC identifies the set of IP packets which may be mapped to 348 that LSP. 350 Each FEC is specified as a set of one or more FEC elements. Each FEC 351 element identifies a set of packets which may be mapped to the corre- 352 sponding LSP. When an LSP is shared by multiple FEC elements, that 353 LSP is terminated at (or before) the node where the FEC elements can 354 no longer share the same path. 356 This specification defines a single type of FEC element, the "Address 357 Prefix FEC element". This element is an address prefix of any length 358 from 0 to a full address, inclusive. 360 Additional FEC elements may be defined, as needed, by other specifi- 361 cations. 363 In the remainder of this section we give the rules to be used for 364 mapping packets to LSPs that have been set up using an Address Prefix 365 FEC element. 367 We say that a particular address "matches" a particular address pre- 368 fix if and only if that address begins with that prefix. We also say 369 that a particular packet matches a particular LSP if and only if that 370 LSP has an Address Prefix FEC element which matches the packet's des- 371 tination address. With respect to a particular packet and a particu- 372 lar LSP, we refer to any Address Prefix FEC element which matches the 373 packet as the "matching prefix". 375 The procedure for mapping a particular packet to a particular LSP 376 uses the following rules. Each rule is applied in turn until the 377 packet can be mapped to an LSP. 379 - If a packet matches exactly one LSP, the packet is mapped to that 380 LSP. 382 - If a packet matches multiple LSPs, it is mapped to the LSP whose 383 matching prefix is the longest. If there is no one LSP whose 384 matching prefix is longest, the packet is mapped to one from the 385 set of LSPs whose matching prefix is longer than the others. The 386 procedure for selecting one of those LSPs is beyond the scope of 387 this document. 389 - If it is known that a packet must traverse a particular egress 390 router, and there is an LSP which has an Address Prefix FEC ele- 391 ment which is a /32 address of that router, then the packet is 392 mapped to that LSP. The procedure for obtaining this knowledge 393 is beyond the scope of this document. 395 The procedure for determining that a packet must traverse a particu- 396 lar egress router is beyond the scope of this document. (As an exam- 397 ple, if one is running a link state routing algorithm, it may be pos- 398 sible to obtain this information from the link state data base. As 399 another example, if one is running BGP, it may be possible to obtain 400 this information from the BGP next hop attribute of the packet's 401 route.) 403 2.2. Label Spaces, Identifiers, Sessions and Transport 405 2.2.1. Label Spaces 407 The notion of "label space" is useful for discussing the assignment 408 and distribution of labels. There are two types of label spaces: 410 - Per interface label space. Interface-specific incoming labels 411 are used for interfaces that use interface resources for labels. 412 An example of such an interface is a label-controlled ATM inter- 413 face that uses VCIs as labels, or a Frame Relay interface that 414 uses DLCIs as labels. 416 Note that the use of a per interface label space only makes sense 417 when the LDP peers are "directly connected" over an interface, 418 and the label is only going to be used for traffic sent over that 419 interface. 421 - Per platform label space. Platform-wide incoming labels are used 422 for interfaces that can share the same labels. 424 2.2.2. LDP Identifiers 426 An LDP identifier is a six octet quantity used to identify an LSR 427 label space. The first four octets identify the LSR and must be a 428 globally unique value, such as a 32-bit router Id assigned to the 429 LSR. The last two octets identify a specific label space within the 430 LSR. The last two octets of LDP Identifiers for platform-wide label 431 spaces are always both zero. This document uses the following print 432 representation for LDP Identifiers: 434 :