idnits 2.17.1 draft-ietf-mpls-ldp-upstream-07.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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document seems to contain a disclaimer for pre-RFC5378 work, and may have content which was first submitted before 10 November 2008. The disclaimer is necessary when there are original authors that you have been unable to contact, or if some do not wish to grant the BCP78 rights to the IETF Trust. If you are able to get all authors (current and original) to grant those rights, 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 (March 2, 2010) is 5162 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) == Unused Reference: 'RFC3471' is defined on line 439, but no explicit reference was found in the text == Outdated reference: A later version (-15) exists of draft-ietf-mpls-ldp-p2mp-08 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Aggarwal 3 Internet Draft Juniper Networks 4 Category: Standards Track 5 Expiration Date: September 2010 6 J. L. Le Roux 7 France Telecom 9 March 2, 2010 11 MPLS Upstream Label Assignment for LDP 13 draft-ietf-mpls-ldp-upstream-07.txt 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and 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 Copyright and License Notice 37 Copyright (c) 2010 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) in effect on the date of 43 publication of this document. Please review these documents 44 carefully, as they describe your rights and restrictions with respect 45 to this document. Code Components extracted from this document must 46 include Simplified BSD License text as described in Section 4.e of 47 the Trust Legal Provisions and are provided without warranty as 48 described in the Simplified BSD License. 50 This document may contain material from IETF Documents or IETF 51 Contributions published or made publicly available before November 52 10, 2008. The person(s) controlling the copyright in some of this 53 material may not have granted the IETF Trust the right to allow 54 modifications of such material outside the IETF Standards Process. 55 Without obtaining an adequate license from the person(s) controlling 56 the copyright in such materials, this document may not be modified 57 outside the IETF Standards Process, and derivative works of it may 58 not be created outside the IETF Standards Process, except to format 59 it for publication as an RFC or to translate it into languages other 60 than English. 62 Abstract 64 This document describes procedures for distributing upstream-assigned 65 labels for Label Distribution Protocol (LDP). It also describes how 66 these procedures can be used for avoiding branch LSR traffic 67 replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. 69 Table of Contents 71 1 Specification of requirements ......................... 3 72 2 Introduction .......................................... 3 73 3 LDP Upstream Label Assignment Capability .............. 4 74 4 Distributing Upstream-Assigned Labels in LDP .......... 5 75 4.1 Procedures ............................................ 5 76 5 LDP Tunnel Identifier Exchange ........................ 6 77 6 LDP Point-to-Multipoint LSPs on a LAN ................. 8 78 7 IANA Considerations ................................... 9 79 7.1 LDP TLVs .............................................. 9 80 7.2 Interface Type Identifiers ............................ 10 81 8 Security Considerations ............................... 10 82 9 Acknowledgements ...................................... 11 83 10 References ............................................ 11 84 10.1 Normative References .................................. 11 85 10.2 Informative References ................................ 11 86 11 Author's Address ...................................... 12 88 1. Specification of requirements 90 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 91 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 92 document are to be interpreted as described in [RFC2119]. 94 2. Introduction 96 This document describes procedures for distributing upstream-assigned 97 labels [RFC5331] for Label Distribution Protocol (LDP). These 98 procedures follow the architecture for MPLS Upstream Label Assignment 99 described in [RFC5331]. 101 This document describes extensions to LDP that a LSR can use to 102 advertise to its neighboring LSRs whether the LSR supports upstream 103 label assignment. 105 This document also describes extensions to LDP to distribute 106 upstream-assigned labels. 108 The usage of MPLS upstream label assignment using LDP for avoiding 109 branch LSR traffic replication on a LAN for LDP P2MP LSPs [MLDP] is 110 also described. 112 3. LDP Upstream Label Assignment Capability 114 According to [RFC5331], upstream-assigned label bindings MUST NOT be 115 used unless it is known that a downstream LSR supports them. This 116 implies that there MUST be a mechanism to enable a LSR to advertise 117 to its LDP neighbor LSR(s) its support of upstream-assigned labels. 119 A new Capability Parameter, the LDP Upstream Label Assignment 120 Capability, is introduced to allow an LDP peer to exchange with its 121 peers, its support of upstream label assignment. This parameter 122 follows the format and procedures for exchanging Capability 123 Parameters defined in [RFC5561]. 125 Following is the format of the LDP Upstream Label Assignment 126 Capability Parameter: 128 0 1 2 3 129 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 131 |1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) | 132 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 |1| Reserved | 134 +-+-+-+-+-+-+-+-+ 136 If a LSR includes the Upstream Label Assignment Capability in LDP 137 Initialization Messages it implies that the LSR is capable of both 138 distributing upstream-assigned label bindings and receiving upstream- 139 assigned label bindings. The reserved bits MUST be set to zero on 140 transmission and ignored on receipt. The Upstream Label Assignment 141 Capability Parameter can be exchanged only in LDP initialization 142 messages. 144 4. Distributing Upstream-Assigned Labels in LDP 146 An optional LDP TLV, Upstream-Assigned Label Request TLV, is 147 introduced. This TLV MUST be carried in a Label Request message if 148 an upstream-assigned label is being requested. 150 0 1 2 3 151 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 |0|0| Upstream Ass Lbl Req (TBD)| Length | 154 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 155 | Reserved | 156 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 158 An optional LDP TLV, Upstream-Assigned Label TLV is introduced to 159 signal an upstream-assigned label. Upstream-Assigned Label TLVs are 160 carried by the messages used to advertise, release and withdraw 161 upstream assigned label mappings. 163 0 1 2 3 164 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 |0|0| Upstream Ass Label (TBD) | Length | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 | Reserved | 169 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 170 | Label | 171 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 173 This is a 20-bit label value as specified in [RFC3032] represented as 174 a 20-bit number in a 4 octet field. 176 4.1. Procedures 178 Procedures for Label Mapping, Label Request, Label Abort, Label 179 Withdraw and Label Release follow [RFC5036] other than the 180 modifications pointed out in this section. 182 A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a 183 neighboring LSR if the neighboring LSR had not previously advertised 184 the Upstream Label Assignment Capability in its LDP Initialization 185 messages. A LDP LSR MUST NOT send the Upstream Assigned Label 186 Request TLV to a neighboring LSR if the neighboring LSR had not 187 previously advertised the Upstream Label Assignment Capability in its 188 LDP Initialization messages. 190 As described in [RFC5331] the distribution of upstream-assigned 191 labels is similar to either ordered LSP control or independent LSP 192 control of the downstream assigned labels. 194 When the label distributed in a Label Mapping message is an upstream- 195 assigned label, the Upstream Assigned Label TLV MUST be included in 196 the Label Mapping message. When a LSR receives a Label Mapping 197 message with an Upstream Assigned Label TLV and it does not recognize 198 the TLV, it MUST generate a Notification message with a status code 199 of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is 200 unable to process the upstream label, it MUST generate a Notification 201 message with a status code of "No Label Resources". If the Label 202 Mapping message was generated in response to a Label Request message, 203 the Label Request message MUST contain an Upstream Assigned Label 204 Request TLV. A LSR that generates an upstream assigned label request 205 to a neighbor LSR, for a given FEC, MUST NOT send a downstream label 206 mapping to the neighbor LSR for that FEC unless it withdraws the 207 upstream-assigned label binding. Similarly if a LSR generates a 208 downstream assigned label request to a neighbor LSR, for a given FEC, 209 it MUST NOT send an upstream label mapping to that LSR for that FEC, 210 unless it aborts the downstream assigned label request. 212 The Upstream Assigned Label TLV may be optionally included in Label 213 Withdraw and Label Release messages that withdraw/release a 214 particular upstream assigned label binding. 216 5. LDP Tunnel Identifier Exchange 218 As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS 219 packet, the top label of which (L) is upstream-assigned, to a 220 downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In 221 this case the fact that L is upstream-assigned is determined by Rd by 222 the tunnel on which the packet is received. There must be a mechanism 223 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 224 used by Ru for transmitting MPLS packets with upstream-assigned MPLS 225 labels. 227 When LDP is used for upstream label assignment, the Interface ID TLV 228 [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an 229 IP or MPLS tunnel to transmit MPLS packets with upstream assigned 230 labels to Rd, Ru MUST include the Interface ID TLV in the Label 231 Mapping messages along with the Upstream Assigned Label TLV. The 232 IPv4/v6 Next/Previous Hop Address and the Logical Interface ID fields 233 in the Interface ID TLV SHOULD be set to 0 by the sender and ignored 234 by the receiver. 236 The Interface ID TLV carries sub-TLVs. Four new Interface ID sub-TLVs 237 are introduced to support RSVP-TE P2MP LSPs, LDP P2MP LSPs, IP 238 Multicast Tunnels and context labels. The TLV value in the sub-TLV 239 acts as the tunnel identifier. Following are the sub-TLVs that are 240 introduced: 242 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is 243 as carried in the 244 RSVP-TE P2MP LSP SESSION Object [RFC4875]. The TLV value identifies 245 the RSVP-TE P2MP LSP. It allows Ru to tunnel an "inner" LDP P2MP LSP, 246 the label for which is upstream assigned, over an "outer" RSVP-TE 247 P2MP LSP that has leaves . The RSVP-TE P2MP LSP IF_ID TLV 248 allows Ru to signal to the binding of the inner LDP P2MP 249 LSP to the outer RSVP-TE P2MP LSP. The control plane signaling 250 between Ru and for the inner P2MP LSP uses targeted LDP 251 signaling messages 253 2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC 254 as defined in [MLDP]. The TLV value identifies the LDP P2MP LSP. It 255 allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is 256 upstream assigned, over an "outer" LDP P2MP LSP that has leaves 257 . The LDP P2MP LSP IF_ID TLV allows Ru to signal to 258 the binding of the inner LDP P2MP LSP to the outer LDP- 259 P2MP LSP. The control plane signaling between Ru and for 260 the inner P2MP LSP uses targeted LDP signaling messages 262 3. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 263 a tuple. Source Address is 264 the IP address of the root of the tunnel i.e. Ru, and Multicast Group 265 Address is the Multicast Group Address used by the tunnel. 267 4. MPLS Context Label TLV. Type = TBD. In this case the TLV value is 268 a tuple. The Source Address 269 belongs to Ru and the MPLS Context Label is an upstream assigned 270 label, assigned by Ru. This allows Ru to tunnel an "inner" LDP P2MP 271 LSP, the label of which is upstream assigned, over an "outer" one-hop 272 MPLS LSP, where the outer one-hop LSP has the following property: 274 + The label pushed by Ru for the outer MPLS LSP is an upstream 275 assigned context label, assigned by Ru. When perform 276 a MPLS label lookup on this label a combination of this label and 277 the incoming interface MUST be sufficient for to 278 uniquely determine Ru's context specific label space to lookup 279 the next label on the stack in. MUST receive the data 280 sent by Ru with the context specific label assigned by Ru being 281 the top label on the label stack. 283 Currently the usage of the context label TLV is limited only to LDP 284 P2MP LSPs on a LAN as specified in the next section. The context 285 label TLV MUST NOT be used for any other purposes. 287 Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP 288 the above procedures assume that Ru has a priori knowledge of all the 289 . In the scenario where the outer P2MP LSP is signaled 290 using RSVP-TE, Ru can obtain this information from RSVP-TE. However, 291 in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP 292 does not provide this information to Ru. In this scenario the 293 procedures by which Ru could acquire this information are outside the 294 scope of this document. 296 6. LDP Point-to-Multipoint LSPs on a LAN 298 This section describes one application of upstream label assignment 299 using LDP. Further applications are to be described in separate 300 documents. 302 [MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the 303 solution relies on "ingress replication". A LSR on a LAN, that is a 304 branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet 305 that it receives on the P2MP LSP to each of the downstream LSRs on 306 the LAN (say that are adjacent to it in the P2MP LSP. 308 It is desirable for Ru to send a single copy of the packet for the 309 LDP P2MP LSP on the LAN, when there are multiple downstream routers 310 on the LAN that are adjacent to Ru in that LDP P2MP LSP. This 311 requires that each of must be able to associate the label 312 L, used by Ru to transmit packets for the P2MP LSP on the LAN, with 313 that P2MP LSP. It is possible to achieve this using LDP upstream- 314 assigned labels with the following procedures. 316 Consider a LSR Rd that receives the LDP P2MP FEC [MLDP] from its 317 downstream LDP peer. Further the upstream interface to reach LSR Ru 318 which is the next-hop to the P2MP LSP root address, Pr, in the LDP 319 P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream- 320 assigned labels. In this case Rd instead of sending a Label Mapping 321 message as described in [MLDP] sends a Label Request message to Ru. 322 This Label Request message MUST contain an Upstream Assigned Label 323 Request TLV. 325 Ru on receiving this message sends back a Label Mapping message to Rd 326 with an upstream-assigned label. This message also contains an 327 Interface ID TLV with a MPLS Context Label sub-TLV, as described in 328 the previous section, with the value of the MPLS label set to a value 329 assigned by Ru on inteface Li as specified in [RFC5331]. Processing 330 of the Label Request and Label Mapping messages for LDP upstream- 331 assigned labels is as described in section 4.2. If Ru receives a 332 Label Request for an upstream assigned label for the same P2MP FEC 333 from multiple downstream LSRs on the LAN, , it MUST send 334 the same upstream-assigned label to each of . 336 Ru transmits the MPLS packet using the procedures defined in 337 [RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains 338 as the top label the context label assigned by Ru on the LAN 339 interface, Li. The bottom label is the upstream label assigned by Ru 340 to the LDP P2MP LSP. The top label is looked up in the context of the 341 LAN interface, Li, [RFC5331] by a downstream LSR on the LAN. This 342 lookup enables the downstream LSR to determine the context specific 343 label space to lookup the inner label in. 345 Note that may have more than one equal cost next-hop on 346 the LAN to reach Pr. It MAY be desirable for all of them to send the 347 label request to the same upstream LSR and they MAY select one 348 upstream LSR using the following procedure: 350 1. The candidate upstream LSRs are numbered from lower to higher IP 351 address 353 2. The following hash is performed: H = (Sum Opaque value) modulo N, 354 where N is the number of candidate upstream LSRs. Opaque value is 355 defined in [MLDP] and comprises the P2MP LSP identifier. 357 3. The selected upstream LSR U is the LSR that has the number H. 359 This allows for load balancing of a set of LSPs among a set of 360 candidate upstream LSRs, while ensuring that on a LAN interface a 361 single upstream LSR is selected. It is also to be noted that the 362 procedures in this section can still be used by Rd and Ru if other 363 LSRs on the LAN do not support upstream label assignment. Ingress 364 replication and downstream label assignment will continue to be used 365 for LSRs that do not support upstream label assignment. 367 7. IANA Considerations 369 7.1. LDP TLVs 371 IANA maintains a registry of LDP TLVs at the registry "Label 372 Distribution Protocol" in the sub-registry called "TLV Type Name 373 Space". 375 This document defines a new LDP Upstream Label Assignment Capability 376 TLV (Section 3). IANA is requested to assign the value 0x0507 to this 377 TLV. 379 This document defines a new LDP Upstream-Assigned Label TLV (Section 380 4). IANA is requested to assign the type value of 0x204 to this TLV. 382 This document defines a new LDP Upstream-Assigned Label Request TLV 383 (Section 4). IANA is requested to assign the type value of 0x205 to 384 this TLV. 386 7.2. Interface Type Identifiers 388 [RFC3472] defines the LDP Interface ID IPv4 and IPv6 TLV. These top- 389 level TLVs can carry sub-TLVs dependent on the interface type. These 390 sub-TLVs are assigned "Interface ID Types". IANA maintains a registry 391 of Interface ID Types for use in GMPLS in the registry "Generalized 392 Multi-Protocol Label Switching (GMPLS) Signaling Parameters" and sub- 393 registry "Interface_ID Types". IANA is requested to make 394 corresponding allocations from this registry as follows: 396 - RSVP-TE P2MP LSP TLV (requested value 28) 398 - LDP P2MP LSP TLV (requested value 29) 400 - IP Multicast Tunnel TLV (requested value 30) 402 - MPLS Context Label TLV (requested value 31) 404 8. Security Considerations 406 The security considerations discussed in RFC 5331 and RFC 5332 apply 407 to this document. 409 More detailed discussion of security issues that are relevant in the 410 context of MPLS and GMPLS, including security threats, related 411 defensive techniques, and the mechanisms for detection and reporting, 412 are discussed in "Security Framework for MPLS and GMPLS Networks 413 [MPLS-SEC]. 415 9. Acknowledgements 417 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 418 Thomas Morin for their comments. The hashing algorithm used on LAN 419 interfaces is taken from [MLDP]. Thanks to Loa Andersson and Adrian 420 Farrel for their comments on the IANA section. 422 10. References 424 10.1. Normative References 426 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 427 Assignment and Context Specific Label Space", RFC5331 429 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 431 [RFC2119] "Key words for use in RFCs to Indicate Requirement 432 Levels.", Bradner, March 1997 434 [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized 435 Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based 436 Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, 437 January 2003. 439 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label 440 Switching (GMPLS) Signaling Functional Description", RFC 3471 January 441 2003. 443 [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036. 445 10.2. Informative References 447 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 448 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 450 [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for 451 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 452 Paths", draft-ietf-mpls-ldp-p2mp-08.txt 454 [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux, 455 "LDP Capabilities", RFC5561 457 [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS 458 Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt 460 [RFC3032] E. Rosen et. al, "MPLS Label Stack Encoding", RFC 3032 462 11. Author's Address 464 Rahul Aggarwal 465 Juniper Networks 466 1194 North Mathilda Ave. 467 Sunnyvale, CA 94089 468 Phone: +1-408-936-2720 469 Email: rahul@juniper.net 471 Jean-Louis Le Roux 472 France Telecom 473 2, avenue Pierre-Marzin 474 22307 Lannion Cedex 475 France 476 E-mail: jeanlouis.leroux@orange-ftgroup.com