idnits 2.17.1 draft-ietf-mpls-ldp-00.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** Cannot find the required boilerplate sections (Copyright, IPR, etc.) in this document. Expected boilerplate is as follows today (2024-04-18) according to https://trustee.ietf.org/license-info : IETF Trust Legal Provisions of 28-dec-2009, Section 6.a: This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 2: Copyright (c) 2024 IETF Trust and the persons identified as the document authors. All rights reserved. IETF Trust Legal Provisions of 28-dec-2009, Section 6.b(i), paragraph 3: This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** Missing expiration date. The document expiration date should appear on the first and last page. ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about the list of current Internet-Drafts. ** The document seems to lack a 1id_guidelines paragraph about the list of Shadow Directories. == 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. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. ** There are 33 instances of too long lines in the document, the longest one being 5 characters in excess of 72. ** The abstract seems to contain references ([ARCH], [FRAMEWORK]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. ** The document seems to lack a both a reference to RFC 2119 and the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. RFC 2119 keyword, line 839: '... LSR MUST wait until a label from a ...' RFC 2119 keyword, line 938: '... Each LSR MUST support the configura...' RFC 2119 keyword, line 1066: '...explicit request MUST specify the stre...' RFC 2119 keyword, line 1112: '...ase of strict ERLSP, the neighbor MUST...' RFC 2119 keyword, line 2106: '... MUST appear in the order specifie...' (3 more instances...) Miscellaneous warnings: ---------------------------------------------------------------------------- == Line 1287 has weird spacing: '...pstream down...' == Line 1309 has weird spacing: '...pstream time...' == Line 1342 has weird spacing: '...Awaited mes...' == Line 1451 has weird spacing: '...pstream rele...' == Line 1481 has weird spacing: '...pstream mess...' == (2 more instances...) -- 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 (August 1998) is 9378 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: 'FRAME' is mentioned on line 1020, but not defined == Outdated reference: A later version (-05) exists of draft-ietf-mpls-framework-01 -- Possible downref: Normative reference to a draft: ref. 'FRAMEWORK' == Outdated reference: A later version (-07) exists of draft-ietf-mpls-arch-02 == Outdated reference: A later version (-08) exists of draft-ietf-mpls-label-encaps-02 == Outdated reference: A later version (-06) exists of draft-ietf-mpls-fr-01 Summary: 11 errors (**), 0 flaws (~~), 12 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group Loa Andersson 2 Internet Draft Bay Networks Inc. 3 Expiration Date: February 1999 4 Paul Doolan 5 Ennovate Networks 7 Nancy Feldman 8 IBM Corp 10 Andre Fredette 11 Bay Networks Inc. 13 Bob Thomas 14 Cisco Systems, Inc. 16 August 1998 18 LDP Specification 20 draft-ietf-mpls-ldp-00.txt 22 Status of this Memo 24 This document is an Internet-Draft. Internet-Drafts are working 25 documents of the Internet Engineering Task Force (IETF), its areas, 26 and its working groups. Note that other groups may also distribute 27 working documents as Internet-Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 To learn the current status of any Internet-Draft, please check the 35 "1id-abstracts.txt" listing contained in the Internet-Drafts Shadow 36 Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe), 37 munnari.oz.au (Pacific Rim), ftp.ietf.org (US East Coast), or 38 ftp.isi.edu (US West Coast). 40 Abstract 42 An overview of Multi Protocol Label Switching (MPLS) is provided in 43 [FRAMEWORK] and a proposed architecture in [ARCH]. A fundamental 44 concept in MPLS is that two Label Switching Routers (LSRs) must agree 45 on the meaning of the labels used to forward traffic between and 46 through them. This common understanding is achieved by using the 47 Label Distribution Protocol (LDP) referenced in [FRAMEWORK] and 48 [ARCH]. This document defines the LDP protocol. 50 Open Issues 52 The following LDP issues are left unresolved with this version of the 53 spec: 55 - The loop prevention/detection mechanism to be employed by LDP. 56 This spec has retained the path vector mechanism from previous 57 drafts. However, draft-ohba-mpls-loop-prevention-01.txt has been 58 proposed as an alternative. 60 - Support for explicitly routed LSPs. The need for this feature 61 has been debated at length. This spec refines the previous 62 version of the spec in this area. However, there remains some 63 belief in the WG that explicitly routed LSPs should be supported 64 by enhancements to RSVP and not LDP. 66 The support for explicitly routed LSPs in the spec is independent 67 of other LDP features and could, should the WG decide to do so, 68 be removed without impact on other LDP features. 70 - Traffic engineering considerations beyond support for explicit 71 routing. 73 - The need for all of the FEC types (called FEC elements in this 74 version of the spec, SMDs in previous versions) is being debated. 75 This version of the spec defines fewer FEC types than previous 76 versions. 78 - LDP support for multicast is not defined in this version. 79 Multicast support will be addressed in a future version. 81 - The message and TLV encodings are likely to change in some minor 82 ways in the next draft of the spec. 84 Table of Contents 86 1 LDP Overview ....................................... 6 87 1.1 LDP Peers .......................................... 6 88 1.2 LDP Message Exchange ............................... 6 89 1.3 LDP Error Handling ................................. 7 90 1.4 LDP Extensibility and Future Compatibility ......... 8 91 2 LDP Operation ...................................... 8 92 2.1 FEC Types .......................................... 8 93 2.2 Mapping packets to FECs ........................... 9 94 2.3 Label Spaces, Identifiers, Sessions and Transport .. 10 95 2.4 LDP Sessions between non-Directly Connected LSRs ... 11 96 2.5 LDP Discovery ..................................... 12 97 2.5.1 Basic Discovery Mechanism .......................... 12 98 2.5.2 Extended Discovery Mechanism ....................... 12 99 2.6 Establishing and Maintaining LDP Sessions .......... 13 100 2.6.1 LDP Session Establishment .......................... 13 101 2.6.2 Transport Connection Establishment ................. 13 102 2.6.3 Session Initialization ............................. 14 103 2.6.4 Initialization State Machine ....................... 16 104 2.6.5 Maintaining Hello Adjacencies ...................... 19 105 2.6.6 Maintaining LDP Sessions ........................... 19 106 2.7 Label Distribution and Management .................. 20 107 2.7.1 Label Distribution Control Mode .................... 20 108 2.7.2 Label Retention Mode ............................... 21 109 2.7.3 Label Advertisement Mode ........................... 22 110 2.8 LDP Identifiers and Next Hop Addresses ............. 22 111 2.9 Loop Detection ..................................... 22 112 2.10 Loop Prevention via Diffusion ...................... 23 113 2.11 Explicitly Routing LSPs ............................ 24 114 2.12 ERLSP State Machine ................................ 28 115 2.12.1 Loose Segment Peg LSR Transitions: ................. 29 116 2.12.2 Loose Segment Non-Peg LSR Transitions: ............. 33 117 2.12.2.1 Strict Segment Transitions ......................... 35 118 2.12.3 ERLSP Timeouts ..................................... 35 119 2.12.4 ERLSP Error Codes .................................. 35 120 3 Protocol Specification ............................. 36 121 3.1 LDP PDUs ........................................... 36 122 3.2 Type-Length-Value Encoding ......................... 37 123 3.3 Commonly Used TLVs ................................. 38 124 3.3.1 FEC TLV ............................................ 38 125 3.3.1.1 FEC Procedures ..................................... 41 126 3.3.2 Label TLVs ......................................... 41 127 3.3.2.1 Generic Label TLV .................................. 42 128 3.3.2.2 ATM Label TLV ...................................... 42 129 3.3.2.3 Frame Relay Label TLV .............................. 43 130 3.3.3 Address List TLV ................................... 43 131 3.3.4 COS TLV ............................................ 44 132 3.3.5 Hop Count TLV ...................................... 45 133 3.3.5.1 Hop Count Procedures ............................... 45 134 3.3.6 Path Vector TLV .................................... 46 135 3.3.6.1 Path Vector Procedures ............................. 46 136 3.3.7 Status TLV ......................................... 47 137 3.4 LDP Messages ....................................... 48 138 3.4.1 Notification Message ............................... 50 139 3.4.1.1 Notification Message Procedures .................... 51 140 3.4.1.2 Events Signalled by Notification Messages .......... 51 141 3.4.1.2.1 Malformed PDU or Message ........................... 52 142 3.4.1.2.2 Unknown or Malformed TLV ........................... 52 143 3.4.1.2.3 Session Hold Timer Expiration ...................... 53 144 3.4.1.2.4 Unilateral Session Shutdown ........................ 53 145 3.4.1.2.5 Initialization Message Events ...................... 53 146 3.4.1.2.6 Events Resulting From Other Messages ............... 54 147 3.4.1.2.7 Explicitly Routed LSP Setup Events ................. 54 148 3.4.1.2.8 Miscellaneous Events ............................... 54 149 3.4.2 Hello Message ...................................... 54 150 3.4.2.1 Hello Message Procedures ........................... 55 151 3.4.3 Initialization Message ............................. 57 152 3.4.3.1 Initialization Message Procedures .................. 61 153 3.4.4 KeepAlive Message .................................. 61 154 3.4.4.1 KeepAlive Message Procedures ....................... 62 155 3.4.5 Address Message .................................... 62 156 3.4.5.1 Address Message Procedures ......................... 63 157 3.4.6 Address Withdraw Message ........................... 64 158 3.4.6.1 Address Withdraw Message Procedures ................ 64 159 3.4.7 Label Mapping Message .............................. 64 160 3.4.7.1 Label Mapping Message Procedures ................... 66 161 3.4.7.1.1 Independent Control Mapping ........................ 66 162 3.4.7.1.2 Ordered Control Mapping ............................ 67 163 3.4.7.1.3 Downstream-on-Demand Label Advertisement ........... 67 164 3.4.7.1.4 Downstream Allocation Label Advertisement .......... 68 165 3.4.8 Label Request Message .............................. 68 166 3.4.8.1 Label Request Message Procedures ................... 69 167 3.4.9 Label Withdraw Message ............................. 70 168 3.4.9.1 Label Withdraw Message Procedures .................. 71 169 3.4.10 Label Release Message .............................. 72 170 3.4.10.1 Label Release Message Procedures ................... 73 171 3.4.11 Label Query Message ................................ 73 172 3.4.11.1 Label Query Message Procecures ..................... 74 173 3.4.12 Explicit Route Request Message ..................... 74 174 3.4.12.1 Explicit Route Request Procedures .................. 78 175 3.4.13 Explicit Route Response Message .................... 78 176 3.4.13.1 Explicit Route Response Procedures ................. 79 177 3.5 Messages and TLVs for Extensibility ................ 80 178 3.5.1 Procedures for Unknown Messages and TLVs ........... 80 179 3.5.1.1 Unknown Message Types .............................. 80 180 3.5.1.2 Unknown TLV in Known Message Type .................. 80 181 3.5.2 LDP Vendor-Private Extensions ...................... 81 182 3.5.2.1 LDP Vendor-Private TLV ............................. 81 183 3.5.2.2 LDP Vendor-Private Messages ........................ 82 184 3.6 TLV Summary ........................................ 83 185 3.7 Status Code Summary ................................ 84 186 4 Security ........................................... 84 187 5 Acknowledgments .................................... 84 188 6 References ......................................... 84 189 7 Author Information ................................. 85 191 1. LDP Overview 193 LDP is the set of procedures and messages by which Label Switched 194 Routers (LSRs) establish Label Switched Paths (LSPs) through a 195 network by mapping network-layer routing information directly to 196 data-link layer switched paths. These LSPs may have an endpoint at a 197 directly attached neighbor (comparable to IP hop-by-hop forwarding), 198 or may have an endpoint at a network egress node, enabling switching 199 via all intermediary nodes. 201 LDP associates a forwarding equivalence class (FEC) [ARCH] with each 202 LSP it creates. The FEC associated with an LSP specifies which 203 packets are "mapped" to that LSP. LSPs are extended through a 204 network as each LSR "splices" incoming labels for a FEC to the 205 outgoing label assigned to the next hop for the given FEC. 207 Note that this document is written with respect to unicast routing 208 only. Multicast will be addressed in a future revision. 210 Note that this document is written with respect to control-driven 211 traffic. It describes mappings which are initiated for routes in the 212 forwarding table, regardless of traffic over those routes. However, 213 LDP does not preclude data-driven support. 215 1.1. LDP Peers 217 Two LSRs which use LDP to exchange label/stream mapping information 218 are known as "LDP Peers" with respect to that information and we 219 speak of there being an "LDP Session" between them. A single LDP 220 adjacency allows each peer to learn the other's label mappings i.e. 221 the protocol is bi-directional. 223 1.2. LDP Message Exchange 225 There are four categories of LDP messages: 227 1. Discovery messages, used to announce and maintain the presence 228 of an LSR in a network. 230 2. Session messages, used to establish and maintain terminate 231 sessions between LSR peers. 233 3. Advertisement messages, used to create, change, and delete 234 label mappings for FECs. 236 4. Notification messages, used to provide advisory information and 237 to signal errors. 239 Discovery messages provide a mechanism whereby LSRs continually 240 indicate their presence in a network via the Hello message. This is 241 transmitted as a UDP packet to the LDP port at the `all LSR routers' 242 group multicast address. When an LSR chooses to establish a session 243 with an LSR learned via the hello message, it uses the LDP 244 initialization procedure over TCP transport. Upon successful 245 completion of the initialization procedure, the two LSRs are LDP 246 peers, and may exchange advertisement messages. 248 When to request a label or advertise a label mapping to a peer is 249 largely a local decision made by an LSR. In general, the LSR 250 requests a label mapping from a neighboring LSR when it needs one, 251 and advertises a label mapping to a neighboring LSR when it wishes 252 the neighbor to use a label. 254 Correct operation of LDP requires reliable and in order delivery of 255 mappings (although there are circumstances when this second 256 requirement could be relaxed). To satisfy these requirements LDP uses 257 the TCP transport for adjacency, advertisement and notification 258 messages. 260 1.3. LDP Error Handling 262 LDP errors and other events of interest are signaled to an LSR peer 263 by notification messages. 265 There are two kinds of LDP notification messages: 267 1. Error notifications, used to signal fatal errors. If an LSR 268 receives an error notification for an LDP session with a peer, 269 it terminates the peer session by closing the TCP transport 270 connection for the session and discarding all label mappings 271 learned via the session. 273 2. Advisory notifications, used to pass an LSR information about 274 the LDP session or the status of some previous message received 275 from the peer. 277 1.4. LDP Extensibility and Future Compatibility 279 It is likely that functionality will be added to LDP after its 280 initial release. It is also likely that this additional 281 functionality will utilize new messages and object types (TLVs). It 282 may be desirable to employ such new messages and TLVs within a 283 network using older implementations that do not recognize them. 284 While it is not possible to make every future enhancement backwards 285 compatible, some prior planning can ease the introduction of new 286 capabilities. This specification defines rules for handling unknown 287 message types and unknown TLVs for this purpose. 289 2. LDP Operation 291 2.1. FEC Types 293 It is necessary to precisely define which IP packets may be mapped to 294 each LSP. This is done by providing a FEC specification for each LSP. 295 The FEC defines which IP packets may be mapped to the same LSP, using 296 a unique label. 298 LDP supports LSP granularity ranging from end-to-end flows to the 299 aggregation of all traffic through a common egress node; the choice 300 of granularity is determined by the FEC choice. 302 Each FEC is specified as a list of one or more FEC elements. Each FEC 303 element specifies a set of IP packets which may be mapped to the 304 corresponding LSP. 306 Following are the currently defined types of FEC elements. New 307 element types may be added as needed: 309 1. IP Address Prefix. 311 This element provides a list of one or more IP address 312 prefixes. Any IP packet whose destination address matches one 313 or more of the specified prefixes may be forwarded using the 314 associated LSP. 316 2. Router ID 318 This element provides a Router ID (ie, a 32 bit IP address of a 319 router). Any IP packet for which the path to the destination is 320 known to traverse the specified router may be forwarded using 321 the associated LSP. This element allows the full set of 322 destinations reachable via a specified router to be indicated 323 in a single FEC element. 325 3. Flow 327 This element specifies a set of datagram information, such as 328 port, dest-addr, src-addr, etc. This element provides LDP with 329 the ability to support MPLS flows with no aggregation. 331 Where a packet maps to more than one FEC it is transmitted on the LSP 332 associated with the FEC to which the packet has the 'most specific' 333 match. 335 2.2. Mapping packets to FECs 337 FEC objects (TLVs) are transmitted in the LDP messages that deal with 338 (advertise, request, release ad withdraw) FEC-Label mappings. 340 A stream of packets with a given destination network can be 341 characterized by a single Address Prefix FEC Element. This results 342 in each specified address prefix sustaining its own LSP tree. This 343 singular mapping is recommended in environments where little or no 344 aggregation information is provided by the routing protocols (such as 345 within a simple IGP), or in networks where the number of destination 346 prefixes is limited. 348 In environments where additional aggregation not provided by the 349 routing protocols is desired, an aggregation list may be created. In 350 this, all prefixes that are to share a common egress point may be 351 advertised within the same FEC. This type of aggregation is 352 configured. 354 The router ID FEC type may be used in any environment in which the 355 routing protocols allow routers to determine the egress point for 356 specific IP packets. For example, the router ID FEC type may be used 357 in combination with BGP, OSPF, and/or IS-IS. 359 For example, the mapping between IP packets and the router ID may be 360 provided via the BGP NEXT_HOP attribute. When a BGP border LSR 361 injects routes into the BGP mesh, it may use its own IP address or 362 the address of its external BGP peer as the value of the NEXT_HOP 363 attribute. If the BGP border ISR uses its own IP address as the 364 NEXT_HOP attribute, then one LSP is created which terminates at the 365 BGP border, and the border LSR will forward traffic at layer-3 366 towards its external BGP neighbors. If the BGP border LSR uses the 367 external BGP peer as the NEXT_HOP attribute, then a separate LSP may 368 be created for each external BGP neighbor, thereby allowing the 369 border LSR to switch traffic directly to each of its external BGP 370 neighbors. 372 Similarly, the mapping between IP packet and router ID may be 373 provided by OSPF. This is comprised of the Router ID of the router 374 that initiated the link state advertisement. The Router ID may also 375 be the OSPF Area Border Router. 377 Note that BGP and OSPF may share the same LSP when a given Router ID 378 is found in both protocol's Routing Information Base. 380 The Router ID FEC allows aggregation of multiple IP address prefixes 381 to the same LSP, without requiring that the prefixes be explicitly 382 listed in the FEC. Also, it allows addresses advertised using OSPF 383 and addresses advertised using BGP to be aggregated using the same 384 LSP. Finally, when the set of addresses reachable via a router 385 changes, and the changes are announced into the routing protocol 386 (BGP, OSPF, and/or IS-IS), use of the routerID FEC eliminates the 387 need to explicitly announce the route changes into LDP. 389 2.3. Label Spaces, Identifiers, Sessions and Transport 391 The notion of "label space" is useful for discussing the assignment 392 and distribution of labels. There are two types of label spaces: 394 - Per interface label space. Interface-specific incoming 395 labels are used for interfaces that use interface resources 396 for labels. An example of such an interface is a label- 397 controlled ATM interface which uses VCIs as labels, or a 398 frame Relay interface which uses DLCIs as labels. 400 Note that the use of a per interface label space only makes 401 sense when the LDP peers are "directly connected" over an 402 interface, and the label is only going to be used for 403 traffic sent over that interface. 405 - Per platform label space. Platform-wide incoming labels are 406 used for interfaces that can share the same labels. 408 An LDP identifier is a six octet quantity used to identify an 409 LSR label space. The first four octets encode an IP address 410 assigned to the LSR, and the last two octets identify a specific 411 label space within the LSR. The last two octets of LDP Identif- 412 iers for platform-wide label spaces are always both zero. This 413 document uses the following print representation for LDP Iden- 414 tifiers: 416 :