idnits 2.17.1 draft-ietf-mpls-ldp-upstream-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 443. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 416. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 423. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 429. 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 Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 18, 2007) is 5998 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 150, but not defined == Unused Reference: 'RFC3031' is defined on line 351, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 369, but no explicit reference was found in the text == Unused Reference: 'MVPN' is defined on line 377, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-03 -- No information found for draft-ietf-mpls-codepoint - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'MPLS-MCAST-ENCAPS' ** Obsolete normative reference: RFC 3036 (Obsoleted by RFC 5036) == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-02 -- No information found for draft-etf-mpls-ldp-p2mp - is the name correct? Summary: 3 errors (**), 0 flaws (~~), 8 warnings (==), 10 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: May 21, 2008 5 J. L. Le Roux 6 France Telecom 8 November 18, 2007 10 MPLS Upstream Label Assignment for LDP 12 draft-ietf-mpls-ldp-upstream-02.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet-Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document describes procedures for distributing upstream-assigned 40 labels for Label Distribution Protocol (LDP). It also describes how 41 these procedures can be used for avoiding branch LSR traffic 42 replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. 44 Table of Contents 46 1 Specification of requirements ......................... 2 47 2 Introduction .......................................... 2 48 3 LDP Upstream Label Assignment Capability .............. 3 49 4 Distributing Upstream-Assigned Labels in LDP .......... 4 50 4.1 Procedures ............................................ 4 51 5 LDP Tunnel Identifier Exchange ........................ 5 52 6 LDP Point-to-Multipoint LSPs on a LAN ................. 6 53 7 IANA Considerations ................................... 8 54 8 Acknowledgements ...................................... 8 55 9 References ............................................ 9 56 9.1 Normative References .................................. 9 57 9.2 Informative References ................................ 9 58 10 Author's Address ...................................... 10 59 11 Intellectual Property Statement ....................... 10 60 12 Full Copyright Statement .............................. 11 62 1. Specification of requirements 64 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 65 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 66 document are to be interpreted as described in [RFC2119]. 68 2. Introduction 70 This document describes procedures for distributing upstream-assigned 71 labels [MPLS-UPSTREAM] for Label Distribution Protocol (LDP). These 72 procedures follow the architecture for MPLS Upstream Label Assignment 73 described in [MPLS-UPSTREAM]. 75 This document describes extensions to LDP that a LSR can use to 76 advertise to its neighboring LSRs whether the LSR supports upstream 77 label assignment. 79 This document also describes extensions to LDP to distribute 80 upstream-assigned labels. 82 The usage of MPLS upstream label assignment using LDP for avoiding 83 branch LSR traffic replication on a LAN for LDP P2MP LSPs [MLDP] is 84 also described. 86 3. LDP Upstream Label Assignment Capability 88 According to [MPLS-UPSTREAM], upstream-assigned label bindings MUST 89 NOT be used unless it is known that a downstream LSR supports them. 90 This implies that there MUST be a mechanism to enable a LSR to 91 advertise to its LDP neighbor LSR(s) its support of upstream-assigned 92 labels. 94 A new Capability Parameter, the LDP Upstream Label Assignment 95 Capability, is introduced to allow an LDP peer to exchange with its 96 peers, its support of upstream label assignment. This parameter 97 follows the format and procedures for exchanging Capability 98 Parameters defined in [LDP-CAP]. 100 Following is the format of the LDP Upstream Label Assignment 101 Capability Parameter: 103 0 1 2 3 104 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 105 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 106 |1|0| Upstream Lbl Ass Cap(IANA)| Length (= 1) | 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 |1| Reserved | 109 +-+-+-+-+-+-+-+-+ 111 If a LSR includes the Upstream Label Assignment Capability in LDP 112 Initialization Messages it implies that the LSR is capable of both 113 distributing upstream-assigned label bindings and receiving upstream- 114 assigned label bindings. The reserved bits MUST be set to zero on 115 transmission and ignored on receipt. The Upstream Label Assignment 116 Capability Parameter can be exchanged only in LDP initialization 117 messages. 119 4. Distributing Upstream-Assigned Labels in LDP 121 An optional LDP TLV, Upstream-Assigned Label Request TLV, is 122 introduced. This TLV MUST be carried in a Label Request message if 123 an upstream-assigned label is being requested. 125 0 1 2 3 126 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 127 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 |0|0| Upstream Ass Lbl Req (TBD)| Length | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Reserved | 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 An optional LDP TLV, Upstream-Assigned Label TLV is introduced to 134 signal an upstream-assigned label. Upstream-Assigned Label TLVs are 135 carried by the messages used to advertise, release and withdraw 136 upstream assigned label mappings. 138 0 1 2 3 139 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 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 |0|0| Upstream Ass Label (TBD) | Length | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 143 | Reserved | 144 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 145 | Label | 146 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 148 Label 150 This is a 20-bit label value as specified in [RFC3032] represented as 151 a 20-bit number in a 4 octet field. 153 4.1. Procedures 155 Procedures for Label Mapping, Label Request, Label Abort, Label 156 Withdraw and Label Release follow [RFC3036] other than the 157 modifications pointed out in this section. 159 A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a 160 neighboring LSR if the neighboring LSR had not previously advertised 161 the Upstream Label Assignment Capability in its LDP Initialization 162 messages. A LDP LSR MUST NOT send the Upstream Assigned Label 163 Request TLV to a neighboring LSR if the neighboring LSR had not 164 previously advertised the Upstream Label Assignment Capability in its 165 LDP Initialization messages. 167 As described in [MPLS-UPSTREAM] the distribution of upstream-assigned 168 labels is similar to either ordered LSP control or independent LSP 169 control of the downstream assigned labels. 171 When the label distributed in a Label Mapping message is an upstream- 172 assigned label, the Upstream Assigned Label TLV MUST be included in 173 the Label Mapping message. When a LSR receives a Label Mapping 174 message with an Upstream Assigned Label TLV and it does not recognize 175 the TLV, it MUST generate a Notification message with a status code 176 of "Unknown TLV" [RFC3036]. If it does recognize the TLV but is 177 unable to process the upstream label, it MUST generate a Notification 178 message with a status code of "No Label Resources". If the Label 179 Mapping message was generated in response to a Label Request message, 180 the Label Request message MUST contain an Upstream Assigned Label 181 Request TLV. A LSR that generates an upstream assigned label request 182 to a neighbor LSR, for a given FEC, MUST NOT send a downstream label 183 mapping to the neighbor LSR for that FEC unless it withdraws the 184 upstream-assigned label binding. Similarly if a LSR generates a 185 downstream assigned label request to a neighbor LSR, for a given FEC, 186 it MUST NOT send an upstream label mapping to that LSR for that FEC, 187 unless it aborts the downstream assigned label request. 189 The Upstream Assigned Label TLV may be optionally included in Label 190 Withdraw and Label Release messages that withdraw/release a 191 particular upstream assigned label binding. 193 5. LDP Tunnel Identifier Exchange 195 As described in [MPLS-UPSTREAM] an upstream LSR Ru MAY transmit a 196 MPLS packet, the top label of which (L) is upstream-assigned, to a 197 downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In 198 this case the fact that L is upstream-assigned is determined by Rd by 199 the tunnel on which the packet is received. There must be a mechanism 200 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 201 used by Ru for transmitting MPLS packets with upstream-assigned MPLS 202 labels. 204 When LDP is used for upstream label assignment, the Interface ID TLV 205 [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an 206 IP or MPLS tunnel to transmit MPLS packets with upstream assigned 207 labels to Rd, Ru MUST include the Interface ID TLV in the Label 208 Mapping messages along with the Upstream Assigned Label TLV. Three 209 new Interface ID TLVs are introduced to support RSVP-TE P2MP LSPs, IP 210 Multicast Tunnels and context labels. The TLV value acts as the 211 tunnel identifier. 213 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE 214 P2MP Session Object and optionally the P2MP Sender Template Object 215 [RSVP-TE-P2MP]. The TLV value identifies the RSVP-TE P2MP LSP. It 216 allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is 217 upstream assigned, over an "outer" RSVP-TE P2MP LSP that has leaves 218 . The P2MP LSP IF_ID TLV allows Ru to signal to 219 the binding of the inner LDP P2MP LSP to the outer RSVP- 220 TE P2MP LSP. The control plane signaling between Ru and 221 for the inner P2MP LSP uses targeted LDP signaling messages 223 2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 224 a tuple. Source Address is 225 the IP address of the root of the tunnel i.e. Ru, and Multicast Group 226 Address is the Multicast Group Address used by the tunnel. 228 3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is 229 a tuple. The Source Address 230 belongs to Ru and the MPLS Context Label is an upstream assigned 231 label, assigned by Ru. This allows Ru to tunnel an "inner" LDP P2MP 232 LSP, the label of which is upstream assigned, over an "outer" one-hop 233 MPLS LSP, where the outer one-hop LSP has the following property: 235 + The label pushed by Ru for the outer MPLS LSP is an upstream 236 assigned context label, assigned by Ru. When perform 237 a MPLS label lookup on this label a combination of this label and 238 the incoming interface MUST be sufficient for to 239 uniquely determine Ru's context specific label space to lookup 240 the next label on the stack in. MUST receive the data 241 sent by Ru with the context specific label assigned by Ru being 242 the top label on the label stack. 244 Currently the usage of the context label TLV is limited only to LDP 245 P2MP LSPs on a LAN as specified in the next section. The context 246 label TLV MUST NOT be used for any other purposes. 248 6. LDP Point-to-Multipoint LSPs on a LAN 250 This section describes one application of upstream label assignment 251 using LDP. Further applications are to be described in separate 252 documents. 254 [MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the 255 solution relies on "ingress replication". A LSR on a LAN, that is a 256 branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet 257 that it receives on the P2MP LSP to each of the downstream LSRs on 258 the LAN (say that are adjacent to it in the P2MP LSP. 260 It is desirable for Ru to send a single copy of the packet for the 261 LDP P2MP LSP on the LAN, when there are multiple downstream routers 262 on the LAN that are adjacent to Ru in that LDP P2MP LSP. This 263 requires that each of must be able to associate the label 264 L, used by Ru to transmit packets for the P2MP LSP on the LAN, with 265 that P2MP LSP. It is possible to achieve this using LDP upstream- 266 assigned labels with the following procedures. 268 Consider a LSR Rd that receives the LDP P2MP FEC [MLDP] from its 269 downstream LDP peer. Further the upstream interface to reach LSR Ru 270 which is the next-hop to the P2MP LSP root address, Pr, in the LDP 271 P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream- 272 assigned labels. In this case Rd instead of sending a Label Mapping 273 message as described in [MLDP] sends a Label Request message to Ru. 274 This Label Request message MUST contain an Upstream Assigned Label 275 Request TLV. 277 Ru on receiving this message sends back a Label Mapping message to Rd 278 with an upstream-assigned label. This message also contains a MPLS 279 Context Label TLV, as described in the previous section, with the 280 value of the MPLS label set to a value assigned by Ru on inteface Li 281 as specified in [MPLS-UPSTREAM]. Processing of the Label Request and 282 Label Mapping messages for LDP upstream-assigned labels is as 283 described in section 4.2. If Ru receives a Label Request for an 284 upstream assigned label for the same P2MP FEC from multiple 285 downstream LSRs on the LAN, , it MUST send the same 286 upstream-assigned label to each of . 288 Ru transmits the MPLS packet using the procedures defined in [MPLS- 289 UPSTREAM] and [MPLS-MCAST-ENCAPS]. The MPLS packet transmitted by Ru 290 contains as the top label the context label assigned by Ru on the LAN 291 interface, Li. The bottom label is the upstream label assigned by Ru 292 to the LDP P2MP LSP. The top label is looked up in the context of the 293 LAN interface, Li, [MPLS-UPSTREAM] by a downstream LSR on the LAN. 294 This lookup enables the downstream LSR to determine the context 295 specific label space to lookup the inner label in. 297 Note that may have more than one equal cost next-hop on 298 the LAN to reach Pr. It MAY be desirable for all of them to send the 299 label request to the same upstream LSR and they MAY select one 300 upstream LSR using the following procedure: 302 1. The candidate upstream LSRs are numbered from lower to higher IP 303 address 305 2. The following hash is performed: H = (Sum Opaque value) modulo N, 306 where N is the number of candidate upstream LSRs. Opaque value is 307 defined in [MLDP] and comprises the P2MP LSP identifier. 309 3. The selected upstream LSR U is the LSR that has the number H. 311 This allows for load balancing of a set of LSPs among a set of 312 candidate upstream LSRs, while ensuring that on a LAN interface a 313 single upstream LSR is selected. It is also to be noted that the 314 procedures in this section can still be used by Rd and Ru if other 315 LSRs on the LAN do not support upstream label assignment. Ingress 316 replication and downstream label assignment will continue to be used 317 for LSRs that do not support upstream label assignment. 319 7. IANA Considerations 321 This document defines a new LDP Upstream Label Assignment Capability 322 Parameter. IANA is requested to assign the value 0x0507 to this 323 Parameter. 325 This document defines a new LDP Upstream-Assigned Label Request TLV, 326 IANA is requested to assign the type value of this TLV. 328 This document defines a new LDP Upstream-Assigned Label TLV, IANA is 329 requested to assign the type value of this TLV. 331 This document defines three new Interface ID TLVs: 333 - RSVP-TE P2MP LSP TLV 335 - IP Multicast Tunnel TLV 337 - MPLS Context Label TLV 339 IANA is requested to assign the type values of these TLVs. 341 8. Acknowledgements 343 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 344 Thomas Morin for their comments. The hashing algorithm used on LAN 345 interfaces is taken from [MLDP]. 347 9. References 349 9.1. Normative References 351 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 352 RFC 3031. 354 [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream 355 Label Assignment and Context Specific Label Space", draft-ietf-mpls- 356 upstream-label-03.txt 358 [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, 359 draft-ietf-mpls-codepoint-07.txt 361 [RFC2119] "Key words for use in RFCs to Indicate Requirement 362 Levels.", Bradner, March 1997 364 [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized 365 Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based 366 Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, 367 January 2003. 369 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label 370 Switching (GMPLS) Signaling Functional Description", RFC 3471 January 371 2003. 373 [RFC3036] L. Andersson, et. al., "LDP Specification", January 2001. 375 9.2. Informative References 377 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", 378 draft-ietf-l3vpn-2547bis-mcast-02.txt 380 [RSVP-TE-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 381 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf- 382 mpls-rsvp-te-p2mp-07.txt 384 [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for 385 Point-to-Multipoint Label Switched Paths", draft-etf-mpls-ldp- 386 p2mp-02.txt 388 [LDP-CAP] B. Thomas, et. al., "LDP Capabilities", draft-thomas-mpls- 389 ldp-capabilities-02.txt 391 10. Author's Address 393 Rahul Aggarwal 394 Juniper Networks 395 1194 North Mathilda Ave. 396 Sunnyvale, CA 94089 397 Phone: +1-408-936-2720 398 Email: rahul@juniper.net 400 Jean-Louis Le Roux 401 France Telecom 402 2, avenue Pierre-Marzin 403 22307 Lannion Cedex 404 France 405 E-mail: jeanlouis.leroux@orange-ftgroup.com 407 11. Intellectual Property Statement 409 The IETF takes no position regarding the validity or scope of any 410 Intellectual Property Rights or other rights that might be claimed to 411 pertain to the implementation or use of the technology described in 412 this document or the extent to which any license under such rights 413 might or might not be available; nor does it represent that it has 414 made any independent effort to identify any such rights. Information 415 on the procedures with respect to rights in RFC documents can be 416 found in BCP 78 and BCP 79. 418 Copies of IPR disclosures made to the IETF Secretariat and any 419 assurances of licenses to be made available, or the result of an 420 attempt made to obtain a general license or permission for the use of 421 such proprietary rights by implementers or users of this 422 specification can be obtained from the IETF on-line IPR repository at 423 http://www.ietf.org/ipr. 425 The IETF invites any interested party to bring to its attention any 426 copyrights, patents or patent applications, or other proprietary 427 rights that may cover technology that may be required to implement 428 this standard. Please address the information to the IETF at ietf- 429 ipr@ietf.org. 431 12. Full Copyright Statement 433 Copyright (C) The IETF Trust (2007). This document is subject to the 434 rights, licenses and restrictions contained in BCP 78, and except as 435 set forth therein, the authors retain all their rights. 437 This document and the information contained herein are provided on an 438 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 439 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 440 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 441 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 442 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 443 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.