idnits 2.17.1 draft-ietf-mpls-ldp-upstream-05.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 '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 a Security Considerations section. 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 (January 29, 2010) is 5201 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: 'RFC3032' is mentioned on line 170, but not defined == Unused Reference: 'RFC3031' is defined on line 396, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 412, but no explicit reference was found in the text == Unused Reference: 'MVPN' is defined on line 420, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-08 -- No information found for draft-etf-mpls-ldp-p2mp - is the name correct? -- Unexpected draft version: The latest known version of draft-thomas-mpls-ldp-capabilities is -02, but you're referring to -04. (However, the state information for draft-etf-mpls-ldp-p2mp is not up-to-date. The last update was unsuccessful) Summary: 2 errors (**), 0 flaws (~~), 7 warnings (==), 4 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 Expiration Date: July 2010 5 J. L. Le Roux 6 France Telecom 8 January 29, 2010 10 MPLS Upstream Label Assignment for LDP 12 draft-ietf-mpls-ldp-upstream-05.txt 14 Status of this Memo 16 This Internet-Draft is submitted to IETF in full conformance with the 17 provisions of BCP 78 and BCP 79. 19 Internet-Drafts are working documents of the Internet Engineering 20 Task Force (IETF), its areas, and its working groups. Note that other 21 groups may also distribute working documents as Internet-Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 Copyright and License Notice 36 Copyright (c) 2010 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents 41 (http://trustee.ietf.org/license-info) in effect on the date of 42 publication of this document. Please review these documents 43 carefully, as they describe your rights and restrictions with respect 44 to this document. Code Components extracted from this document must 45 include Simplified BSD License text as described in Section 4.e of 46 the Trust Legal Provisions and are provided without warranty as 47 described in the Simplified BSD License. 49 This document may contain material from IETF Documents or IETF 50 Contributions published or made publicly available before November 51 10, 2008. The person(s) controlling the copyright in some of this 52 material may not have granted the IETF Trust the right to allow 53 modifications of such material outside the IETF Standards Process. 54 Without obtaining an adequate license from the person(s) controlling 55 the copyright in such materials, this document may not be modified 56 outside the IETF Standards Process, and derivative works of it may 57 not be created outside the IETF Standards Process, except to format 58 it for publication as an RFC or to translate it into languages other 59 than English. 61 Abstract 63 This document describes procedures for distributing upstream-assigned 64 labels for Label Distribution Protocol (LDP). It also describes how 65 these procedures can be used for avoiding branch LSR traffic 66 replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. 68 Table of Contents 70 1 Specification of requirements ......................... 3 71 2 Introduction .......................................... 3 72 3 LDP Upstream Label Assignment Capability .............. 3 73 4 Distributing Upstream-Assigned Labels in LDP .......... 4 74 4.1 Procedures ............................................ 5 75 5 LDP Tunnel Identifier Exchange ........................ 6 76 6 LDP Point-to-Multipoint LSPs on a LAN ................. 7 77 7 IANA Considerations ................................... 9 78 8 Acknowledgements ...................................... 9 79 9 References ............................................ 10 80 9.1 Normative References .................................. 10 81 9.2 Informative References ................................ 10 82 10 Author's Address ...................................... 11 83 1. Specification of requirements 85 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 86 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 87 document are to be interpreted as described in [RFC2119]. 89 2. Introduction 91 This document describes procedures for distributing upstream-assigned 92 labels [RFC5331] for Label Distribution Protocol (LDP). These 93 procedures follow the architecture for MPLS Upstream Label Assignment 94 described in [RFC5331]. 96 This document describes extensions to LDP that a LSR can use to 97 advertise to its neighboring LSRs whether the LSR supports upstream 98 label assignment. 100 This document also describes extensions to LDP to distribute 101 upstream-assigned labels. 103 The usage of MPLS upstream label assignment using LDP for avoiding 104 branch LSR traffic replication on a LAN for LDP P2MP LSPs [MLDP] is 105 also described. 107 3. LDP Upstream Label Assignment Capability 109 According to [RFC5331], upstream-assigned label bindings MUST NOT be 110 used unless it is known that a downstream LSR supports them. This 111 implies that there MUST be a mechanism to enable a LSR to advertise 112 to its LDP neighbor LSR(s) its support of upstream-assigned labels. 114 A new Capability Parameter, the LDP Upstream Label Assignment 115 Capability, is introduced to allow an LDP peer to exchange with its 116 peers, its support of upstream label assignment. This parameter 117 follows the format and procedures for exchanging Capability 118 Parameters defined in [LDP-CAP]. 120 Following is the format of the LDP Upstream Label Assignment 121 Capability Parameter: 123 0 1 2 3 124 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 125 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 126 |1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) | 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 |1| Reserved | 129 +-+-+-+-+-+-+-+-+ 131 If a LSR includes the Upstream Label Assignment Capability in LDP 132 Initialization Messages it implies that the LSR is capable of both 133 distributing upstream-assigned label bindings and receiving upstream- 134 assigned label bindings. The reserved bits MUST be set to zero on 135 transmission and ignored on receipt. The Upstream Label Assignment 136 Capability Parameter can be exchanged only in LDP initialization 137 messages. 139 4. Distributing Upstream-Assigned Labels in LDP 141 An optional LDP TLV, Upstream-Assigned Label Request TLV, is 142 introduced. This TLV MUST be carried in a Label Request message if 143 an upstream-assigned label is being requested. 145 0 1 2 3 146 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 147 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 |0|0| Upstream Ass Lbl Req (TBD)| Length | 149 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 150 | Reserved | 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 153 An optional LDP TLV, Upstream-Assigned Label TLV is introduced to 154 signal an upstream-assigned label. Upstream-Assigned Label TLVs are 155 carried by the messages used to advertise, release and withdraw 156 upstream assigned label mappings. 158 0 1 2 3 159 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 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 |0|0| Upstream Ass Label (TBD) | Length | 162 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 163 | Reserved | 164 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 | Label | 166 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 168 Label 170 This is a 20-bit label value as specified in [RFC3032] represented as 171 a 20-bit number in a 4 octet field. 173 4.1. Procedures 175 Procedures for Label Mapping, Label Request, Label Abort, Label 176 Withdraw and Label Release follow [RFC3036] other than the 177 modifications pointed out in this section. 179 A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a 180 neighboring LSR if the neighboring LSR had not previously advertised 181 the Upstream Label Assignment Capability in its LDP Initialization 182 messages. A LDP LSR MUST NOT send the Upstream Assigned Label 183 Request TLV to a neighboring LSR if the neighboring LSR had not 184 previously advertised the Upstream Label Assignment Capability in its 185 LDP Initialization messages. 187 As described in [RFC5331] the distribution of upstream-assigned 188 labels is similar to either ordered LSP control or independent LSP 189 control of the downstream assigned labels. 191 When the label distributed in a Label Mapping message is an upstream- 192 assigned label, the Upstream Assigned Label TLV MUST be included in 193 the Label Mapping message. When a LSR receives a Label Mapping 194 message with an Upstream Assigned Label TLV and it does not recognize 195 the TLV, it MUST generate a Notification message with a status code 196 of "Unknown TLV" [RFC3036]. If it does recognize the TLV but is 197 unable to process the upstream label, it MUST generate a Notification 198 message with a status code of "No Label Resources". If the Label 199 Mapping message was generated in response to a Label Request message, 200 the Label Request message MUST contain an Upstream Assigned Label 201 Request TLV. A LSR that generates an upstream assigned label request 202 to a neighbor LSR, for a given FEC, MUST NOT send a downstream label 203 mapping to the neighbor LSR for that FEC unless it withdraws the 204 upstream-assigned label binding. Similarly if a LSR generates a 205 downstream assigned label request to a neighbor LSR, for a given FEC, 206 it MUST NOT send an upstream label mapping to that LSR for that FEC, 207 unless it aborts the downstream assigned label request. 209 The Upstream Assigned Label TLV may be optionally included in Label 210 Withdraw and Label Release messages that withdraw/release a 211 particular upstream assigned label binding. 213 5. LDP Tunnel Identifier Exchange 215 As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS 216 packet, the top label of which (L) is upstream-assigned, to a 217 downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In 218 this case the fact that L is upstream-assigned is determined by Rd by 219 the tunnel on which the packet is received. There must be a mechanism 220 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 221 used by Ru for transmitting MPLS packets with upstream-assigned MPLS 222 labels. 224 When LDP is used for upstream label assignment, the Interface ID TLV 225 [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an 226 IP or MPLS tunnel to transmit MPLS packets with upstream assigned 227 labels to Rd, Ru MUST include the Interface ID TLV in the Label 228 Mapping messages along with the Upstream Assigned Label TLV. The 229 IPv4 Next/Previous Hop Address and the Logical Interface ID fields in 230 the Interface ID TLV SHOULD be set to 0 by the sender and ignored by 231 the receiver. 233 Four new Interface ID TLVs are introduced to support RSVP-TE P2MP 234 LSPs, LDP P2MP LSPs, IP Multicast Tunnels and context labels. The TLV 235 value acts as the tunnel identifier. 237 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is 238 as carried in the 239 RSVP-TE P2MP LSP SESSION Object [RFC4875]. The TLV value identifies 240 the RSVP-TE P2MP LSP. It allows Ru to tunnel an "inner" LDP P2MP LSP, 241 the label for which is upstream assigned, over an "outer" RSVP-TE 242 P2MP LSP that has leaves . The P2MP LSP IF_ID TLV allows 243 Ru to signal to the binding of the inner LDP P2MP LSP to 244 the outer RSVP-TE P2MP LSP. The control plane signaling between Ru 245 and for the inner P2MP LSP uses targeted LDP signaling 246 messages 248 2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC 249 as defined in [MLDP]. The TLV value identifies the LDP P2MP LSP. It 250 allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is 251 upstream assigned, over an "outer" LDP P2MP LSP that has leaves 252 . The P2MP LSP IF_ID TLV allows Ru to signal to 253 the binding of the inner LDP P2MP LSP to the outer LDP- 254 P2MP LSP. The control plane signaling between Ru and for 255 the inner P2MP LSP uses targeted LDP signaling messages 257 3. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 258 a tuple. Source Address is 259 the IP address of the root of the tunnel i.e. Ru, and Multicast Group 260 Address is the Multicast Group Address used by the tunnel. 262 4. MPLS Context Label TLV. Type = TBD. In this case the TLV value is 263 a tuple. The Source Address 264 belongs to Ru and the MPLS Context Label is an upstream assigned 265 label, assigned by Ru. This allows Ru to tunnel an "inner" LDP P2MP 266 LSP, the label of which is upstream assigned, over an "outer" one-hop 267 MPLS LSP, where the outer one-hop LSP has the following property: 269 + The label pushed by Ru for the outer MPLS LSP is an upstream 270 assigned context label, assigned by Ru. When perform 271 a MPLS label lookup on this label a combination of this label and 272 the incoming interface MUST be sufficient for to 273 uniquely determine Ru's context specific label space to lookup 274 the next label on the stack in. MUST receive the data 275 sent by Ru with the context specific label assigned by Ru being 276 the top label on the label stack. 278 Currently the usage of the context label TLV is limited only to LDP 279 P2MP LSPs on a LAN as specified in the next section. The context 280 label TLV MUST NOT be used for any other purposes. 282 Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP 283 the above procedures assume that Ru has a priori knowledge of all the 284 . In the scenario where the outer P2MP LSP is signaled 285 using RSVP-TE, Ru can obtain this information from RSVP-TE. However, 286 in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP 287 does not provide this information to Ru. In this scenario the 288 procedures by which Ru could acquire this information are outside the 289 scope of this document. 291 6. LDP Point-to-Multipoint LSPs on a LAN 293 This section describes one application of upstream label assignment 294 using LDP. Further applications are to be described in separate 295 documents. 297 [MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the 298 solution relies on "ingress replication". A LSR on a LAN, that is a 299 branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet 300 that it receives on the P2MP LSP to each of the downstream LSRs on 301 the LAN (say that are adjacent to it in the P2MP LSP. 303 It is desirable for Ru to send a single copy of the packet for the 304 LDP P2MP LSP on the LAN, when there are multiple downstream routers 305 on the LAN that are adjacent to Ru in that LDP P2MP LSP. This 306 requires that each of must be able to associate the label 307 L, used by Ru to transmit packets for the P2MP LSP on the LAN, with 308 that P2MP LSP. It is possible to achieve this using LDP upstream- 309 assigned labels with the following procedures. 311 Consider a LSR Rd that receives the LDP P2MP FEC [MLDP] from its 312 downstream LDP peer. Further the upstream interface to reach LSR Ru 313 which is the next-hop to the P2MP LSP root address, Pr, in the LDP 314 P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream- 315 assigned labels. In this case Rd instead of sending a Label Mapping 316 message as described in [MLDP] sends a Label Request message to Ru. 317 This Label Request message MUST contain an Upstream Assigned Label 318 Request TLV. 320 Ru on receiving this message sends back a Label Mapping message to Rd 321 with an upstream-assigned label. This message also contains a MPLS 322 Context Label TLV, as described in the previous section, with the 323 value of the MPLS label set to a value assigned by Ru on inteface Li 324 as specified in [RFC5331]. Processing of the Label Request and Label 325 Mapping messages for LDP upstream-assigned labels is as described in 326 section 4.2. If Ru receives a Label Request for an upstream assigned 327 label for the same P2MP FEC from multiple downstream LSRs on the LAN, 328 , it MUST send the same upstream-assigned label to each of 329 . 331 Ru transmits the MPLS packet using the procedures defined in 332 [RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains 333 as the top label the context label assigned by Ru on the LAN 334 interface, Li. The bottom label is the upstream label assigned by Ru 335 to the LDP P2MP LSP. The top label is looked up in the context of the 336 LAN interface, Li, [RFC5331] by a downstream LSR on the LAN. This 337 lookup enables the downstream LSR to determine the context specific 338 label space to lookup the inner label in. 340 Note that may have more than one equal cost next-hop on 341 the LAN to reach Pr. It MAY be desirable for all of them to send the 342 label request to the same upstream LSR and they MAY select one 343 upstream LSR using the following procedure: 345 1. The candidate upstream LSRs are numbered from lower to higher IP 346 address 348 2. The following hash is performed: H = (Sum Opaque value) modulo N, 349 where N is the number of candidate upstream LSRs. Opaque value is 350 defined in [MLDP] and comprises the P2MP LSP identifier. 352 3. The selected upstream LSR U is the LSR that has the number H. 354 This allows for load balancing of a set of LSPs among a set of 355 candidate upstream LSRs, while ensuring that on a LAN interface a 356 single upstream LSR is selected. It is also to be noted that the 357 procedures in this section can still be used by Rd and Ru if other 358 LSRs on the LAN do not support upstream label assignment. Ingress 359 replication and downstream label assignment will continue to be used 360 for LSRs that do not support upstream label assignment. 362 7. IANA Considerations 364 This document defines a new LDP Upstream Label Assignment Capability 365 Parameter. IANA is requested to assign the value 0x0507 to this 366 Parameter. 368 This document defines a new LDP Upstream-Assigned Label Request TLV, 369 IANA is requested to assign the type value of this TLV. 371 This document defines a new LDP Upstream-Assigned Label TLV, IANA is 372 requested to assign the type value of this TLV. 374 This document defines four new Interface ID TLVs: 376 - RSVP-TE P2MP LSP TLV 378 - LDP P2MP LSP TLV 380 - IP Multicast Tunnel TLV 382 - MPLS Context Label TLV 384 IANA is requested to assign the type values of these TLVs. 386 8. Acknowledgements 388 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 389 Thomas Morin for their comments. The hashing algorithm used on LAN 390 interfaces is taken from [MLDP]. 392 9. References 394 9.1. Normative References 396 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 397 RFC 3031. 399 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 400 Assignment and Context Specific Label Space", RFC5331 402 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 404 [RFC2119] "Key words for use in RFCs to Indicate Requirement 405 Levels.", Bradner, March 1997 407 [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized 408 Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based 409 Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, 410 January 2003. 412 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label 413 Switching (GMPLS) Signaling Functional Description", RFC 3471 January 414 2003. 416 [RFC3036] L. Andersson, et. al., "LDP Specification", January 2001. 418 9.2. Informative References 420 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", 421 draft-ietf-l3vpn-2547bis-mcast-08.txt 423 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 424 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 426 [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for 427 Point-to-Multipoint Label Switched Paths", draft-etf-mpls-ldp- 428 p2mp-07.txt 430 [LDP-CAP] B. Thomas, et. al., "LDP Capabilities", draft-thomas-mpls- 431 ldp-capabilities-04.txt 433 10. Author's Address 435 Rahul Aggarwal 436 Juniper Networks 437 1194 North Mathilda Ave. 438 Sunnyvale, CA 94089 439 Phone: +1-408-936-2720 440 Email: rahul@juniper.net 442 Jean-Louis Le Roux 443 France Telecom 444 2, avenue Pierre-Marzin 445 22307 Lannion Cedex 446 France 447 E-mail: jeanlouis.leroux@orange-ftgroup.com