idnits 2.17.1 draft-ietf-mpls-ldp-upstream-06.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 : ---------------------------------------------------------------------------- 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 (February 25, 2010) is 5145 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: 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 Expiration Date: August 2010 5 J. L. Le Roux 6 France Telecom 8 February 25, 2010 10 MPLS Upstream Label Assignment for LDP 12 draft-ietf-mpls-ldp-upstream-06.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 Security Considerations ............................... 9 79 9 Acknowledgements ...................................... 10 80 10 References ............................................ 10 81 10.1 Normative References .................................. 10 82 10.2 Informative References ................................ 10 83 11 Author's Address ...................................... 11 84 1. Specification of requirements 86 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 87 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 88 document are to be interpreted as described in [RFC2119]. 90 2. Introduction 92 This document describes procedures for distributing upstream-assigned 93 labels [RFC5331] for Label Distribution Protocol (LDP). These 94 procedures follow the architecture for MPLS Upstream Label Assignment 95 described in [RFC5331]. 97 This document describes extensions to LDP that a LSR can use to 98 advertise to its neighboring LSRs whether the LSR supports upstream 99 label assignment. 101 This document also describes extensions to LDP to distribute 102 upstream-assigned labels. 104 The usage of MPLS upstream label assignment using LDP for avoiding 105 branch LSR traffic replication on a LAN for LDP P2MP LSPs [MLDP] is 106 also described. 108 3. LDP Upstream Label Assignment Capability 110 According to [RFC5331], upstream-assigned label bindings MUST NOT be 111 used unless it is known that a downstream LSR supports them. This 112 implies that there MUST be a mechanism to enable a LSR to advertise 113 to its LDP neighbor LSR(s) its support of upstream-assigned labels. 115 A new Capability Parameter, the LDP Upstream Label Assignment 116 Capability, is introduced to allow an LDP peer to exchange with its 117 peers, its support of upstream label assignment. This parameter 118 follows the format and procedures for exchanging Capability 119 Parameters defined in [RFC5561]. 121 Following is the format of the LDP Upstream Label Assignment 122 Capability Parameter: 124 0 1 2 3 125 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 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 127 |1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 |1| Reserved | 130 +-+-+-+-+-+-+-+-+ 132 If a LSR includes the Upstream Label Assignment Capability in LDP 133 Initialization Messages it implies that the LSR is capable of both 134 distributing upstream-assigned label bindings and receiving upstream- 135 assigned label bindings. The reserved bits MUST be set to zero on 136 transmission and ignored on receipt. The Upstream Label Assignment 137 Capability Parameter can be exchanged only in LDP initialization 138 messages. 140 4. Distributing Upstream-Assigned Labels in LDP 142 An optional LDP TLV, Upstream-Assigned Label Request TLV, is 143 introduced. This TLV MUST be carried in a Label Request message if 144 an upstream-assigned label is being requested. 146 0 1 2 3 147 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 148 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 149 |0|0| Upstream Ass Lbl Req (TBD)| Length | 150 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 151 | Reserved | 152 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 An optional LDP TLV, Upstream-Assigned Label TLV is introduced to 155 signal an upstream-assigned label. Upstream-Assigned Label TLVs are 156 carried by the messages used to advertise, release and withdraw 157 upstream assigned label mappings. 159 0 1 2 3 160 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 161 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 162 |0|0| Upstream Ass Label (TBD) | Length | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 164 | Reserved | 165 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 166 | Label | 167 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 This is a 20-bit label value as specified in [RFC3032] represented as 170 a 20-bit number in a 4 octet field. 172 4.1. Procedures 174 Procedures for Label Mapping, Label Request, Label Abort, Label 175 Withdraw and Label Release follow [RFC5036] other than the 176 modifications pointed out in this section. 178 A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a 179 neighboring LSR if the neighboring LSR had not previously advertised 180 the Upstream Label Assignment Capability in its LDP Initialization 181 messages. A LDP LSR MUST NOT send the Upstream Assigned Label 182 Request TLV to a neighboring LSR if the neighboring LSR had not 183 previously advertised the Upstream Label Assignment Capability in its 184 LDP Initialization messages. 186 As described in [RFC5331] the distribution of upstream-assigned 187 labels is similar to either ordered LSP control or independent LSP 188 control of the downstream assigned labels. 190 When the label distributed in a Label Mapping message is an upstream- 191 assigned label, the Upstream Assigned Label TLV MUST be included in 192 the Label Mapping message. When a LSR receives a Label Mapping 193 message with an Upstream Assigned Label TLV and it does not recognize 194 the TLV, it MUST generate a Notification message with a status code 195 of "Unknown TLV" [RFC5036]. If it does recognize the TLV but is 196 unable to process the upstream label, it MUST generate a Notification 197 message with a status code of "No Label Resources". If the Label 198 Mapping message was generated in response to a Label Request message, 199 the Label Request message MUST contain an Upstream Assigned Label 200 Request TLV. A LSR that generates an upstream assigned label request 201 to a neighbor LSR, for a given FEC, MUST NOT send a downstream label 202 mapping to the neighbor LSR for that FEC unless it withdraws the 203 upstream-assigned label binding. Similarly if a LSR generates a 204 downstream assigned label request to a neighbor LSR, for a given FEC, 205 it MUST NOT send an upstream label mapping to that LSR for that FEC, 206 unless it aborts the downstream assigned label request. 208 The Upstream Assigned Label TLV may be optionally included in Label 209 Withdraw and Label Release messages that withdraw/release a 210 particular upstream assigned label binding. 212 5. LDP Tunnel Identifier Exchange 214 As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS 215 packet, the top label of which (L) is upstream-assigned, to a 216 downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In 217 this case the fact that L is upstream-assigned is determined by Rd by 218 the tunnel on which the packet is received. There must be a mechanism 219 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 220 used by Ru for transmitting MPLS packets with upstream-assigned MPLS 221 labels. 223 When LDP is used for upstream label assignment, the Interface ID TLV 224 [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an 225 IP or MPLS tunnel to transmit MPLS packets with upstream assigned 226 labels to Rd, Ru MUST include the Interface ID TLV in the Label 227 Mapping messages along with the Upstream Assigned Label TLV. The 228 IPv4 Next/Previous Hop Address and the Logical Interface ID fields in 229 the Interface ID TLV SHOULD be set to 0 by the sender and ignored by 230 the receiver. 232 Four new Interface ID TLVs are introduced to support RSVP-TE P2MP 233 LSPs, LDP P2MP LSPs, IP Multicast Tunnels and context labels. The TLV 234 value acts as the tunnel identifier. 236 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is 237 as carried in the 238 RSVP-TE P2MP LSP SESSION Object [RFC4875]. The TLV value identifies 239 the RSVP-TE P2MP LSP. It allows Ru to tunnel an "inner" LDP P2MP LSP, 240 the label for which is upstream assigned, over an "outer" RSVP-TE 241 P2MP LSP that has leaves . The P2MP LSP IF_ID TLV allows 242 Ru to signal to the binding of the inner LDP P2MP LSP to 243 the outer RSVP-TE P2MP LSP. The control plane signaling between Ru 244 and for the inner P2MP LSP uses targeted LDP signaling 245 messages 247 2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC 248 as defined in [MLDP]. The TLV value identifies the LDP P2MP LSP. It 249 allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is 250 upstream assigned, over an "outer" LDP P2MP LSP that has leaves 251 . The P2MP LSP IF_ID TLV allows Ru to signal to 252 the binding of the inner LDP P2MP LSP to the outer LDP- 253 P2MP LSP. The control plane signaling between Ru and for 254 the inner P2MP LSP uses targeted LDP signaling messages 256 3. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 257 a tuple. Source Address is 258 the IP address of the root of the tunnel i.e. Ru, and Multicast Group 259 Address is the Multicast Group Address used by the tunnel. 261 4. MPLS Context Label TLV. Type = TBD. In this case the TLV value is 262 a tuple. The Source Address 263 belongs to Ru and the MPLS Context Label is an upstream assigned 264 label, assigned by Ru. This allows Ru to tunnel an "inner" LDP P2MP 265 LSP, the label of which is upstream assigned, over an "outer" one-hop 266 MPLS LSP, where the outer one-hop LSP has the following property: 268 + The label pushed by Ru for the outer MPLS LSP is an upstream 269 assigned context label, assigned by Ru. When perform 270 a MPLS label lookup on this label a combination of this label and 271 the incoming interface MUST be sufficient for to 272 uniquely determine Ru's context specific label space to lookup 273 the next label on the stack in. MUST receive the data 274 sent by Ru with the context specific label assigned by Ru being 275 the top label on the label stack. 277 Currently the usage of the context label TLV is limited only to LDP 278 P2MP LSPs on a LAN as specified in the next section. The context 279 label TLV MUST NOT be used for any other purposes. 281 Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP 282 the above procedures assume that Ru has a priori knowledge of all the 283 . In the scenario where the outer P2MP LSP is signaled 284 using RSVP-TE, Ru can obtain this information from RSVP-TE. However, 285 in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP 286 does not provide this information to Ru. In this scenario the 287 procedures by which Ru could acquire this information are outside the 288 scope of this document. 290 6. LDP Point-to-Multipoint LSPs on a LAN 292 This section describes one application of upstream label assignment 293 using LDP. Further applications are to be described in separate 294 documents. 296 [MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the 297 solution relies on "ingress replication". A LSR on a LAN, that is a 298 branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet 299 that it receives on the P2MP LSP to each of the downstream LSRs on 300 the LAN (say that are adjacent to it in the P2MP LSP. 302 It is desirable for Ru to send a single copy of the packet for the 303 LDP P2MP LSP on the LAN, when there are multiple downstream routers 304 on the LAN that are adjacent to Ru in that LDP P2MP LSP. This 305 requires that each of must be able to associate the label 306 L, used by Ru to transmit packets for the P2MP LSP on the LAN, with 307 that P2MP LSP. It is possible to achieve this using LDP upstream- 308 assigned labels with the following procedures. 310 Consider a LSR Rd that receives the LDP P2MP FEC [MLDP] from its 311 downstream LDP peer. Further the upstream interface to reach LSR Ru 312 which is the next-hop to the P2MP LSP root address, Pr, in the LDP 313 P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream- 314 assigned labels. In this case Rd instead of sending a Label Mapping 315 message as described in [MLDP] sends a Label Request message to Ru. 316 This Label Request message MUST contain an Upstream Assigned Label 317 Request TLV. 319 Ru on receiving this message sends back a Label Mapping message to Rd 320 with an upstream-assigned label. This message also contains a MPLS 321 Context Label TLV, as described in the previous section, with the 322 value of the MPLS label set to a value assigned by Ru on inteface Li 323 as specified in [RFC5331]. Processing of the Label Request and Label 324 Mapping messages for LDP upstream-assigned labels is as described in 325 section 4.2. If Ru receives a Label Request for an upstream assigned 326 label for the same P2MP FEC from multiple downstream LSRs on the LAN, 327 , it MUST send the same upstream-assigned label to each of 328 . 330 Ru transmits the MPLS packet using the procedures defined in 331 [RFC5331] and [RFC5332]. The MPLS packet transmitted by Ru contains 332 as the top label the context label assigned by Ru on the LAN 333 interface, Li. The bottom label is the upstream label assigned by Ru 334 to the LDP P2MP LSP. The top label is looked up in the context of the 335 LAN interface, Li, [RFC5331] by a downstream LSR on the LAN. This 336 lookup enables the downstream LSR to determine the context specific 337 label space to lookup the inner label in. 339 Note that may have more than one equal cost next-hop on 340 the LAN to reach Pr. It MAY be desirable for all of them to send the 341 label request to the same upstream LSR and they MAY select one 342 upstream LSR using the following procedure: 344 1. The candidate upstream LSRs are numbered from lower to higher IP 345 address 347 2. The following hash is performed: H = (Sum Opaque value) modulo N, 348 where N is the number of candidate upstream LSRs. Opaque value is 349 defined in [MLDP] and comprises the P2MP LSP identifier. 351 3. The selected upstream LSR U is the LSR that has the number H. 353 This allows for load balancing of a set of LSPs among a set of 354 candidate upstream LSRs, while ensuring that on a LAN interface a 355 single upstream LSR is selected. It is also to be noted that the 356 procedures in this section can still be used by Rd and Ru if other 357 LSRs on the LAN do not support upstream label assignment. Ingress 358 replication and downstream label assignment will continue to be used 359 for LSRs that do not support upstream label assignment. 361 7. IANA Considerations 363 This document defines a new LDP Upstream Label Assignment Capability 364 Parameter. IANA is requested to assign the value 0x0507 to this 365 Parameter. 367 This document defines a new LDP Upstream-Assigned Label TLV, IANA is 368 requested to assign the type value of 0x204 to this TLV. 370 This document defines a new LDP Upstream-Assigned Label Request TLV, 371 IANA is requested to assign the type value of 0x205 to this TLV. 373 This document defines four new Interface ID TLVs: 375 - RSVP-TE P2MP LSP TLV 377 - LDP P2MP LSP TLV 379 - IP Multicast Tunnel TLV 381 - MPLS Context Label TLV 383 These values are assigned from the Interface_ID Type space defined in 384 [RFC3471]. IANA is requested to assign the type value 6 to RSVP-TE 385 P2MP LSP TLV, type value 7 to LDP P2MP LSP TLV, type value 8 to IP 386 Multicast Tunnel TLV and type value 9 to MPLS Context Label TLV. 388 8. Security Considerations 390 The security considerations discussed in RFC 5331 and RFC 5332 apply 391 to this document. 393 More detailed discussion of security issues that are relevant in the 394 context of MPLS and GMPLS, including security threats, related 395 defensive techniques, and the mechanisms for detection and reporting, 396 are discussed in "Security Framework for MPLS and GMPLS Networks 397 [MPLS-SEC]. 399 9. Acknowledgements 401 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 402 Thomas Morin for their comments. The hashing algorithm used on LAN 403 interfaces is taken from [MLDP]. 405 10. References 407 10.1. Normative References 409 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 410 Assignment and Context Specific Label Space", RFC5331 412 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, RFC5332 414 [RFC2119] "Key words for use in RFCs to Indicate Requirement 415 Levels.", Bradner, March 1997 417 [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized 418 Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based 419 Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, 420 January 2003. 422 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label 423 Switching (GMPLS) Signaling Functional Description", RFC 3471 January 424 2003. 426 [RFC5036] L. Andersson, et. al., "LDP Specification", RFC5036. 428 10.2. Informative References 430 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 431 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 433 [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for 434 Point-to-Multipoint and Multipoint-to-Multipoint Label Switched 435 Paths", draft-ietf-mpls-ldp-p2mp-08.txt 437 [RFC5561] B. Thomas, K. Raza, S. Aggarwal, R. Aggarwal, JL. Le Roux, 438 "LDP Capabilities", RFC5561 440 [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS 441 Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt 443 [RFC3032] E. Rosen et. al, "MPLS Label Stack Encoding", RFC 3032 445 11. Author's Address 447 Rahul Aggarwal 448 Juniper Networks 449 1194 North Mathilda Ave. 450 Sunnyvale, CA 94089 451 Phone: +1-408-936-2720 452 Email: rahul@juniper.net 454 Jean-Louis Le Roux 455 France Telecom 456 2, avenue Pierre-Marzin 457 22307 Lannion Cedex 458 France 459 E-mail: jeanlouis.leroux@orange-ftgroup.com