idnits 2.17.1 draft-ietf-mpls-ldp-upstream-10.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 51 instances of too long lines in the document, the longest one being 2 characters in excess of 72. 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 (February 02, 2011) is 4830 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) == 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: 1 error (**), 0 flaws (~~), 3 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: August 2011 6 J. L. Le Roux 7 France Telecom 9 February 02, 2011 11 MPLS Upstream Label Assignment for LDP 13 draft-ietf-mpls-ldp-upstream-10.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) 2011 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 Label Switching 67 Router (LSR) traffic replication on a LAN for LDP point-to-multipoint 68 (P2MP) Label Switched Paths (LSPs). 70 Table of Contents 72 1 Specification of requirements ......................... 3 73 2 Introduction .......................................... 3 74 3 LDP Upstream Label Assignment Capability .............. 4 75 4 Distributing Upstream-Assigned Labels in LDP .......... 5 76 4.1 Procedures ............................................ 5 77 5 LDP Tunnel Identifier Exchange ........................ 6 78 6 LDP Point-to-Multipoint LSPs on a LAN ................. 10 79 7 IANA Considerations ................................... 12 80 7.1 LDP TLVs .............................................. 12 81 7.2 Interface Type Identifiers ............................ 12 82 8 Security Considerations ............................... 12 83 9 Acknowledgements ...................................... 13 84 10 References ............................................ 13 85 10.1 Normative References .................................. 13 86 10.2 Informative References ................................ 13 87 11 Author's Address ...................................... 14 89 1. Specification of requirements 91 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 92 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 93 document are to be interpreted as described in [RFC2119]. 95 2. Introduction 97 This document describes procedures for distributing upstream-assigned 98 labels [RFC5331] for Label Distribution Protocol (LDP) [RFC5036]. 99 These procedures follow the architecture for MPLS Upstream Label 100 Assignment described in [RFC5331]. 102 This document describes extensions to LDP that a Label Switching 103 Router (LSR) can use to advertise to its neighboring LSRs whether the 104 LSR supports upstream label assignment. 106 This document also describes extensions to LDP to distribute 107 upstream-assigned labels. 109 The usage of MPLS upstream label assignment using LDP for avoiding 110 branch LSR traffic replication on a LAN for LDP point-to-multipoint 111 (P2MP) Label Switched Paths (LSPs) [MLDP] is also described. 113 3. LDP Upstream Label Assignment Capability 115 According to [RFC5331], upstream-assigned label bindings MUST NOT be 116 used unless it is known that a downstream LSR supports them. This 117 implies that there MUST be a mechanism to enable an LSR to advertise 118 to its LDP neighbor LSR(s) its support of upstream-assigned labels. 120 A new Capability Parameter, the LDP Upstream Label Assignment 121 Capability, is introduced to allow an LDP peer to exchange with its 122 peers, its support of upstream label assignment. This parameter 123 follows the format and procedures for exchanging Capability 124 Parameters defined in [RFC5561]. 126 Following is the format of the LDP Upstream Label Assignment 127 Capability Parameter: 129 0 1 2 3 130 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 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 |1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) | 133 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 134 |1| Reserved | 135 +-+-+-+-+-+-+-+-+ 137 If an LSR includes the Upstream Label Assignment Capability in LDP 138 Initialization Messages it implies that the LSR is capable of both 139 distributing upstream-assigned label bindings and receiving upstream- 140 assigned label bindings. The reserved bits MUST be set to zero on 141 transmission and ignored on receipt. The Upstream Label Assignment 142 Capability Parameter MUST be carried only in LDP initialization 143 messages and MUST be ignored if received in LDP Capability messages. 145 4. Distributing Upstream-Assigned Labels in LDP 147 An optional LDP TLV, Upstream-Assigned Label Request TLV, is 148 introduced. To request an upstream-assigned label an LDP peer MUST 149 include this TLV in a Label Request message. 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 |0|0| Upstream Ass Lbl Req (TBD)| Length | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Reserved | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 An optional LDP TLV, Upstream-Assigned Label TLV is introduced to 160 signal an upstream-assigned label. Upstream-Assigned Label TLVs are 161 carried by the messages used to advertise, release and withdraw 162 upstream assigned label mappings. 164 0 1 2 3 165 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 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 167 |0|0| Upstream Ass Label (TBD) | Length | 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | Reserved | 170 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 171 | Label | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 The Label field is a 20-bit label value as specified in [RFC3032] 175 represented as a 20-bit number in a 4 octet field as specified in 176 section 3.4.2.1 of RFC5036 [RFC5036]. 178 4.1. Procedures 180 Procedures for Label Mapping, Label Request, Label Abort, Label 181 Withdraw and Label Release follow [RFC5036] other than the 182 modifications pointed out in this section. 184 A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a 185 neighboring LSR if the neighboring LSR had not previously advertised 186 the Upstream Label Assignment Capability in its LDP Initialization 187 messages. A LDP LSR MUST NOT send the Upstream Assigned Label 188 Request TLV to a neighboring LSR if the neighboring LSR had not 189 previously advertised the Upstream Label Assignment Capability in its 190 LDP Initialization messages. 192 As described in [RFC5331] the distribution of upstream-assigned 193 labels is similar to either ordered LSP control or independent LSP 194 control of the downstream assigned labels. 196 When the label distributed in a Label Mapping message is an upstream- 197 assigned label, the Upstream Assigned Label TLV MUST be included in 198 the Label Mapping message. When an LSR receives a Label Mapping 199 message with an Upstream Assigned Label TLV and it does not recognize 200 the TLV, it MUST generate a Notification message with a status code 201 of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is 202 unable to process the upstream label, it MUST generate a Notification 203 message with a status code of "No Label Resources". If the Label 204 Mapping message was generated in response to a Label Request message, 205 the Label Request message MUST contain an Upstream Assigned Label 206 Request TLV. A LSR that generates an upstream assigned label request 207 to a neighbor LSR, for a given FEC, MUST NOT send a downstream label 208 mapping to the neighbor LSR for that FEC unless it withdraws the 209 upstream-assigned label binding. Similarly if an LSR generates a 210 downstream assigned label request to a neighbor LSR, for a given FEC, 211 it MUST NOT send an upstream label mapping to that LSR for that FEC, 212 unless it aborts the downstream assigned label request. 214 The Upstream Assigned Label TLV may be optionally included in Label 215 Withdraw and Label Release messages that withdraw/release a 216 particular upstream assigned label binding. 218 5. LDP Tunnel Identifier Exchange 220 As described in [RFC5331] an upstream LSR Ru MAY transmit an MPLS 221 packet, the top label of which (L) is upstream-assigned, to a 222 downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In 223 this case the fact that L is upstream-assigned is determined by Rd by 224 the tunnel on which the packet is received. There must be a mechanism 225 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 226 used by Ru for transmitting MPLS packets with upstream-assigned MPLS 227 labels. 229 When LDP is used for upstream label assignment, the Interface ID TLV 230 [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an 231 IP or MPLS tunnel to transmit MPLS packets with upstream assigned 232 labels to Rd, Ru MUST include the Interface ID TLV in the Label 233 Mapping messages along with the Upstream Assigned Label TLV. The 234 IPv4/v6 Next/Previous Hop Address and the Logical Interface ID fields 235 in the Interface ID TLV SHOULD be set to 0 by the sender and ignored 236 by the receiver. The Length field indicates the total length of the 237 TLV, i.e., 4 + the length of the value field in octets. A value 238 field whose length is not a multiple of four MUST be zero-padded so 239 that the TLV is four- octet aligned. 241 Hence the IPv4 Interface ID TLV has the following format: 243 0 1 2 3 244 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 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 |0|0| Type (0x082d) | Length | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | IPv4 Next/Previous Hop Address (0) | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | Logical Interface ID (0) | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Sub-TLVs | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 The IPv6 Interface ID TLV has the following format: 257 0 1 2 3 258 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 259 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 260 |0|0| Type (0x082e) | Length | 261 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 262 | IPv6 Next/Previous Hop Address (0) | 263 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 | Logical Interface ID (0) | 265 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 266 | Sub-TLVs | 267 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 As shown in the above figures the Interface ID TLV carries sub-TLVs. 270 Four new Interface ID sub-TLVs are introduced to support RSVP-TE P2MP 271 LSPs, LDP P2MP LSPs, IP Multicast Tunnels and context labels. The 272 sub-TLV value in the sub-TLV acts as the tunnel identifier. 274 Following are the sub-TLVs that are introduced: 276 1. RSVP-TE P2MP LSP TLV. Type = 28 (To be assigned by IANA). Value of 277 the TLV is the RSVP-TE P2MP LSP SESSION Object [RFC4875]. 279 Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv4 280 Interface ID TLV: 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | Type (0x1c) | 16 | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | P2MP ID | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | MUST be zero | Tunnel ID | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 291 | Extended Tunnel ID | 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 294 Below is the RSVP-TE P2MP LSP TLV format when carried in the IPv6 295 Interface ID TLV: 297 0 1 2 3 298 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 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 300 | Type (0x1c) | 28 | 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 | P2MP ID | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | MUST be zero | Tunnel ID | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 | Extended Tunnel ID | 307 | | 308 | ....... | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 This TLV identifies the RSVP-TE P2MP LSP. It allows Ru to tunnel an 312 "inner" LDP P2MP LSP, the label for which is upstream assigned, over 313 an "outer" RSVP-TE P2MP LSP that has leaves . The RSVP-TE 314 P2MP LSP IF_ID TLV allows Ru to signal to the binding of 315 the inner LDP P2MP LSP to the outer RSVP-TE P2MP LSP. The control 316 plane signaling between Ru and for the inner P2MP LSP 317 uses targeted LDP signaling messages 319 2. LDP P2MP LSP TLV. Type = 29 (To be assigned by IANA). Value of the 320 TLV is the LDP P2MP FEC as defined in [MLDP] and has to be set as per 321 the procedures in [MLDP]. Here is the format of the LDP P2MP FEC as 322 defined in [MLDP]: 324 0 1 2 3 325 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 326 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 |P2MP Type | Address Family | Address Length| 328 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 ~ Root Node Address ~ 330 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 331 | Opaque Length | Opaque Value ... | 332 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ + 333 ~ ~ 334 | | 335 | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 336 | | 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 The Address Family MUST be set to IPv4, the Address Length MUST be 340 set to 4 and the Root Node Address MUST be set to an IPv4 address 341 when the LDP P2MP LSP TLV is carried in the IPv4 Interface ID TLV. 342 The Address Family MUST be set to IPv6, the Address Length MUST be 343 set to 16 and the Root Node Address MUST be set to an IPv6 address 344 when the LDP P2MP LSP TLV is carried in the IPv6 Interface ID TLV. 346 The TLV value identifies the LDP P2MP LSP. It allows Ru to tunnel an 347 "inner" LDP P2MP LSP, the label for which is upstream assigned, over 348 an "outer" LDP P2MP LSP that has leaves . The LDP P2MP LSP 349 IF_ID TLV allows Ru to signal to the binding of the 350 inner LDP P2MP LSP to the outer LDP- P2MP LSP. The control plane 351 signaling between Ru and for the inner P2MP LSP uses 352 targeted LDP signaling messages 354 3. IP Multicast Tunnel TLV. Type = 30 (To be assigned by IANA) In 355 this case the TLV value is a tuple. Source Address is the IP address of the root of the 357 tunnel i.e. Ru, and Multicast Group Address is the Multicast Group 358 Address used by the tunnel. The addresses MUST be IPv4 addresses when 359 the IP Multicast Tunnel TLV is included in the IPv4 Interface ID TLV. 360 The addresses MUST be IPv6 addresses when the IP Multicast Tunnel TLV 361 is included in the IPv6 Interface ID TLV. 363 4. MPLS Context Label TLV. Type = 31 (To be assigned by IANA). In 364 this case the TLV value is a 365 tuple. The Source Address belongs to Ru and the MPLS Context Label is 366 an upstream assigned label, assigned by Ru. The Source Address MUST 367 be set to an IPv4 address when the MPLS Context Label TLV is carried 368 in the IPv4 Interface ID TLV. The Source Address MUST be set to an 369 IPv6 address when the MPLS Context Label TLV is carried in the IPv6 370 Interface ID TLV. This allows Ru to tunnel an "inner" LDP P2MP LSP, 371 the label of which is upstream assigned, over an "outer" one-hop MPLS 372 LSP, where the outer one-hop LSP has the following property: 374 + The label pushed by Ru for the outer MPLS LSP is an upstream 375 assigned context label, assigned by Ru. When perform 376 an MPLS label lookup on this label a combination of this label 377 and the incoming interface MUST be sufficient for to 378 uniquely determine Ru's context specific label space to lookup 379 the next label on the stack in. MUST receive the data 380 sent by Ru with the context specific label assigned by Ru being 381 the top label on the label stack. 383 Currently the usage of the context label TLV is limited only to LDP 384 P2MP LSPs on a LAN as specified in the next section. The context 385 label TLV MUST NOT be used for any other purposes. 387 Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP 388 the above procedures assume that Ru has a priori knowledge of all the 389 . In the scenario where the outer P2MP LSP is signaled 390 using RSVP-TE, Ru can obtain this information from RSVP-TE. However, 391 in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP 392 does not provide this information to Ru. In this scenario the 393 procedures by which Ru could acquire this information are outside the 394 scope of this document. 396 6. LDP Point-to-Multipoint LSPs on a LAN 398 This section describes one application of upstream label assignment 399 using LDP. Further applications are to be described in separate 400 documents. 402 [MLDP] describes how to setup P2MP LSPs using LDP. On a LAN the 403 solution relies on "ingress replication". A LSR on a LAN, that is a 404 branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet 405 that it receives on the P2MP LSP to each of the downstream LSRs on 406 the LAN (say that are adjacent to it in the P2MP LSP. 408 It is desirable for Ru to send a single copy of the packet for the 409 LDP P2MP LSP on the LAN, when there are multiple downstream routers 410 on the LAN that are adjacent to Ru in that LDP P2MP LSP. This 411 requires that each of must be able to associate the label 412 L, used by Ru to transmit packets for the P2MP LSP on the LAN, with 413 that P2MP LSP. It is possible to achieve this using LDP upstream- 414 assigned labels with the following procedures. 416 Consider an LSR Rd that receives the LDP P2MP FEC [MLDP] from its 417 downstream LDP peer. Further the upstream interface to reach LSR Ru 418 which is the next-hop to the P2MP LSP root address, Pr, in the LDP 419 P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream- 420 assigned labels. In this case Rd instead of sending a Label Mapping 421 message as described in [MLDP] sends a Label Request message to Ru. 422 This Label Request message MUST contain an Upstream Assigned Label 423 Request TLV. 425 On receiving this message, Ru sends back a Label Mapping message to 426 Rd with an upstream-assigned label. This message also contains an 427 Interface ID TLV with a MPLS Context Label sub-TLV, as described in 428 the previous section, with the value of the MPLS label set to a value 429 assigned by Ru on inteface Li as specified in [RFC5331]. Processing 430 of the Label Request and Label Mapping messages for LDP upstream- 431 assigned labels is as described in section 4.1. If Ru receives a 432 Label Request for an upstream assigned label for the same P2MP FEC 433 from multiple downstream LSRs on the LAN, , it MUST send 434 the same upstream-assigned label to each of . 436 Ru transmits the MPLS packet using the procedures defined in 437 [RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains 438 as the top label the context label assigned by Ru on the LAN 439 interface, Li. The bottom label is the upstream label assigned by Ru 440 to the LDP P2MP LSP. The top label is looked up in the context of the 441 LAN interface, Li, [RFC5331] by a downstream LSR on the LAN. This 442 lookup enables the downstream LSR to determine the context specific 443 label space to lookup the inner label in. 445 Note that may have more than one equal cost next-hop on 446 the LAN to reach Pr. It MAY be desirable for all of them to send the 447 label request to the same upstream LSR and they MAY select one 448 upstream LSR using the following procedure: 450 1. The candidate upstream LSRs are numbered from lower to higher IP 451 address 453 2. The following hash is performed: H = (Sum Opaque value) modulo N, 454 where N is the number of candidate upstream LSRs. Opaque value is 455 defined in [MLDP] and comprises the P2MP LSP identifier. 457 3. The selected upstream LSR U is the LSR that has the number H. 459 This allows for load balancing of a set of LSPs among a set of 460 candidate upstream LSRs, while ensuring that on a LAN interface a 461 single upstream LSR is selected. It is also to be noted that the 462 procedures in this section can still be used by Rd and Ru if other 463 LSRs on the LAN do not support upstream label assignment. Ingress 464 replication and downstream label assignment will continue to be used 465 for LSRs that do not support upstream label assignment. 467 7. IANA Considerations 469 7.1. LDP TLVs 471 IANA maintains a registry of LDP TLVs at the registry "Label 472 Distribution Protocol" in the sub-registry called "TLV Type Name 473 Space". 475 This document defines a new LDP Upstream Label Assignment Capability 476 TLV (Section 3). IANA is requested to assign the value 0x0507 to this 477 TLV. 479 This document defines a new LDP Upstream-Assigned Label TLV (Section 480 4). IANA is requested to assign the type value of 0x204 to this TLV. 482 This document defines a new LDP Upstream-Assigned Label Request TLV 483 (Section 4). IANA is requested to assign the type value of 0x205 to 484 this TLV. 486 7.2. Interface Type Identifiers 488 [RFC3472] defines the LDP Interface ID IPv4 and IPv6 TLV. These top- 489 level TLVs can carry sub-TLVs dependent on the interface type. These 490 sub-TLVs are assigned "Interface ID Types". IANA maintains a registry 491 of Interface ID Types for use in GMPLS in the registry "Generalized 492 Multi-Protocol Label Switching (GMPLS) Signaling Parameters" and sub- 493 registry "Interface_ID Types". IANA is requested to make 494 corresponding allocations from this registry as follows: 496 - RSVP-TE P2MP LSP TLV (requested value 28) 498 - LDP P2MP LSP TLV (requested value 29) 500 - IP Multicast Tunnel TLV (requested value 30) 502 - MPLS Context Label TLV (requested value 31) 504 8. Security Considerations 506 The security considerations discussed in RFC 5036, RFC 5331 and RFC 507 5332 apply to this document. 509 More detailed discussion of security issues that are relevant in the 510 context of MPLS and GMPLS, including security threats, related 511 defensive techniques, and the mechanisms for detection and reporting, 512 are discussed in "Security Framework for MPLS and GMPLS Networks 514 [MPLS-SEC]. 516 9. Acknowledgements 518 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 519 Thomas Morin for their comments. The hashing algorithm used on LAN 520 interfaces is taken from [MLDP]. Thanks to Loa Andersson, Adrian 521 Farrel and Eric Rosen for their comments and review. 523 10. References 525 10.1. Normative References 527 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 528 Assignment and Context Specific Label Space", RFC5331 530 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 532 [RFC2119] "Key words for use in RFCs to Indicate Requirement 533 Levels.", Bradner, March 1997 535 [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036. 537 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 538 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 540 [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for 541 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 542 Paths", draft-ietf-mpls-ldp-p2mp-08.txt 544 10.2. Informative References 546 [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux, 547 "LDP Capabilities", RFC5561 549 [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS 550 Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt 552 [RFC3032] E. Rosen et. al, "MPLS Label Stack Encoding", RFC 3032 554 [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized 555 Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based 556 Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, 557 January 2003. 559 11. Author's Address 561 Rahul Aggarwal 562 Juniper Networks 563 1194 North Mathilda Ave. 564 Sunnyvale, CA 94089 565 Phone: +1-408-936-2720 566 Email: rahul@juniper.net 568 Jean-Louis Le Roux 569 France Telecom 570 2, avenue Pierre-Marzin 571 22307 Lannion Cedex 572 France 573 E-mail: jeanlouis.leroux@orange-ftgroup.com