idnits 2.17.1 draft-ietf-mpls-ldp-upstream-01.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 419. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 392. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 399. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 405. 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. ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) 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 (March 2007) is 6244 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 149, but not defined == Unused Reference: 'RFC3031' is defined on line 328, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'MVPN' is defined on line 354, but no explicit reference was found in the text == Outdated reference: A later version (-07) exists of draft-ietf-mpls-upstream-label-02 -- 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: 4 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: September 2007 5 J. L. Le Roux 6 France Telecom 8 March 2007 10 MPLS Upstream Label Assignment for LDP 12 draft-ietf-mpls-ldp-upstream-01.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 .......... 3 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 Acknowledgements ...................................... 8 54 8 References ............................................ 8 55 8.1 Normative References .................................. 8 56 8.2 Informative References ................................ 9 57 9 Author Information .................................... 9 58 10 Intellectual Property Statement ....................... 9 59 11 Full Copyright Statement .............................. 10 61 1. Specification of requirements 63 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 64 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 65 document are to be interpreted as described in [RFC2119]. 67 2. Introduction 69 This document describes procedures for distributing upstream-assigned 70 labels [MPLS-UPSTREAM] for Label Distribution Protocol (LDP). These 71 procedures follow the architecture for MPLS Upstream Label Assignment 72 described in [MPLS-UPSTREAM]. 74 This document describes extensions to LDP that a LSR can use to 75 advertise to its neighboring LSRs whether the LSR supports upstream 76 label assignment. 78 This document also describes extensions to LDP to distribute 79 upstream-assigned labels. 81 The usage of MPLS upstream label assignment using LDP for avoiding 82 branch LSR traffic replication on a LAN for LDP P2MP LSPs [MLDP] is 83 also described. 85 3. LDP Upstream Label Assignment Capability 87 According to [MPLS-UPSTREAM], upstream-assigned label bindings MUST 88 NOT be used unless it is known that a downstream LSR supports them. 89 This implies that there MUST be a mechanism to enable a LSR to 90 advertise to its LDP neighbor LSR(s) its support of upstream-assigned 91 labels. 93 A new Capability Parameter, the LDP Upstream Label Assignment 94 Capability, is introduced to allow an LDP peer to exchange with its 95 peers, its support of upstream label assignment. This parameter 96 follows the format and procedures for exchanging Capability 97 Parameters defined in [LDP-CAP]. 99 Following is the format of the LDP Upstream Label Assignment 100 Capability Parameter: 102 0 1 2 3 103 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 104 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 105 |1|0| Upstream Lbl Ass Cap(IANA)| Length (= 5) | 106 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 107 |1| Reserved | 108 +-+-+-+-+-+-+-+-+ 110 If a LSR includes the Upstream Label Assignment Capability in LDP 111 Initialization Messages it implies that the LSR is capable of both 112 distributing upstream-assigned label bindings and receiving upstream- 113 assigned label bindings. The reserved bits MUST be set to zero on 114 transmission and ignored on receipt. The Upstream Label Assignment 115 Capability Parameter can be exchanged only in LDP initialization 116 messages. 118 4. Distributing Upstream-Assigned Labels in LDP 120 An optional LDP TLV, Upstream-Assigned Label Request TLV, is 121 introduced. This TLV MUST be carried in a Label Request message if 122 an upstream-assigned label is being requested. 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 |0|0| Upstream Ass Lbl Req (TBD)| Length | 128 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 129 | Reserved | 130 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 132 An optional LDP TLV, Upstream-Assigned Label TLV is introduced to 133 signal an upstream-assigned label. Upstream-Assigned Label TLVs are 134 carried by the messages used to advertise, release and withdraw 135 upstream assigned label mappings. 137 0 1 2 3 138 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 139 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 140 |0|0| Upstream Ass Label (TBD) | Length | 141 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 142 | Reserved | 143 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 | Label | 145 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 147 Label 149 This is a 20-bit label value as specified in [RFC3032] represented as 150 a 20-bit number in a 4 octet field. 152 4.1. Procedures 154 Procedures for Label Mapping, Label Request, Label Abort, Label 155 Withdraw and Label Release follow [RFC3036] other than the 156 modifications pointed out in this section. 158 A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a 159 neighboring LSR if the neighboring LSR had not previously advertised 160 the Upstream Label Assignment Capability in its LDP Initialization 161 messages. A LDP LSR MUST NOT send the Upstream Assigned Label 162 Request TLV to a neighboring LSR if the neighboring LSR had not 163 previously advertised the Upstream Label Assignment Capability in its 164 LDP Initialization messages. 166 As described in [MPLS-UPSTREAM] the distribution of upstream-assigned 167 labels is similar to either ordered LSP control or independent LSP 168 control of the downstream assigned labels. 170 When the label distributed in a Label Mapping message is an upstream- 171 assigned label, the Upstream Assigned Label TLV MUST be included in 172 the Label Mapping message. When a LSR receives a Label Mapping 173 message with an Upstream Assigned Label TLV and it does not recognize 174 the TLV, it MUST generate a Notification message with a status code 175 of "Unknown TLV" [RFC3036]. If it does recognize the TLV but is 176 unable to process the upstream label, it MUST generate a Notification 177 message with a status code of "No Label Resources". If the Label 178 Mapping message was generated in response to a Label Request message, 179 the Label Request message MUST contain an Upstream Assigned Label 180 Request TLV. A LSR that generates an upstream assigned label request 181 to a neighbor LSR, for a given FEC, MUST NOT send a downstream label 182 mapping to the neighbor LSR for that FEC unless it withdraws the 183 upstream-assigned label binding. Similarly if a LSR generates a 184 downstream assigned label request to a neighbor LSR, for a given FEC, 185 it MUST NOT send an upstream label mapping to that LSR for that FEC, 186 unless it aborts the downstream assigned label request. 188 The Upstream Assigned Label TLV may be optionally included in Label 189 Withdraw and Label Release messages that withdraw/release a 190 particular upstream assigned label binding. 192 5. LDP Tunnel Identifier Exchange 194 As described in [MPLS-UPSTREAM] an upstream LSR Ru MAY transmit a 195 MPLS packet, the top label of which (L) is upstream-assigned, to a 196 downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In 197 this case the fact that L is upstream-assigned is determined by Rd by 198 the tunnel on which the packet is received. There must be a mechanism 199 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 200 used by Ru for transmitting MPLS packets with upstream-assigned MPLS 201 labels. 203 When LDP is used for upstream label assignment, the Interface ID TLV 204 [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an 205 IP or MPLS tunnel to transmit MPLS packets with upstream assigned 206 labels to Rd, Ru MUST include the Interface ID TLV in the Label 207 Mapping messages along with the Upstream Assigned Label TLV. Three 208 new Interface ID TLVs are introduced to support RSVP-TE P2MP LSPs, IP 209 Multicast Tunnels and context labels. The TLV value acts as the 210 tunnel identifier. 212 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE 213 P2MP Session Object and optionally the P2MP Sender Template Object 214 [RSVP-TE-P2MP]. The TLV value identifies the RSVP-TE P2MP LSP. It 215 allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is 216 upstream assigned, over an "outer" RSVP-TE P2MP LSP that has leaves 217 . The P2MP LSP IF_ID TLV allows Ru to signal to 218 the binding of the inner LDP P2MP LSP to the outer RSVP- 219 TE P2MP LSP. The control plane signaling between Ru and 220 for the inner P2MP LSP uses targeted LDP signaling messages 222 2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 223 a tuple. Source Address is 224 the IP address of the root of the tunnel i.e. Ru, and Multicast Group 225 Address is the Multicast Group Address used by the tunnel. 227 3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is 228 a tuple. The Source Address 229 belongs to Ru and the MPLS Context Label is an upstream assigned 230 label, assigned by Ru. This allows Ru to tunnel an "inner" LDP P2MP 231 LSP, the label of which is upstream assigned, over an "outer" one-hop 232 MPLS LSP, where the outer one-hop LSP has the following property: 234 + The label pushed by Ru for the outer MPLS LSP is an upstream 235 assigned context label, assigned by Ru. When perform 236 a MPLS label lookup on this label a combination of this label and 237 the incoming interface MUST be sufficient for to 238 uniquely determine Ru's context specific label space to lookup 239 the next label on the stack in. MUST receive the data 240 sent by Ru with the context specific label assigned by Ru being 241 the top label on the label stack. 243 Currently the usage of the context label TLV is limited only to LDP 244 P2MP LSPs on a LAN as specified in the next section. The context 245 label TLV MUST NOT be used for any other purposes. 247 6. LDP Point-to-Multipoint LSPs on a LAN 249 This section describes one application of upstream label assignment 250 using LDP. Further applications are to be described in separate 251 documents. 253 [MLDP] describe how to setup P2MP LSPs using LDP. On a LAN the 254 solution relies on "ingress replication". A LSR on a LAN, that is a 255 branch LSR for a P2MP LSP, (say Ru) sends a separate copy of a packet 256 that it receives on the P2MP LSP to each of the downstream LSRs on 257 the LAN (say that are adjacent to it in the P2MP LSP. 259 It is desirable for Ru to send a single copy of the packet for the 260 LDP P2MP LSP on the LAN, when there are multiple downstream routers 261 on the LAN that are adjacent to Ru in that LDP P2MP LSP. This 262 requires that each of must be able to associate the label 263 L, used by Ru to transmit packets for the P2MP LSP on the LAN, with 264 that P2MP LSP. It is possible to achieve this using LDP upstream- 265 assigned labels with the following procedures. 267 Consider a LSR Rd that receives the LDP P2MP FEC [MLDP] from its 268 downstream LDP peer. Further the upstream interface to reach LSR Ru 269 which is the next-hop to the P2MP LSP root address, Pr, in the LDP 270 P2MP FEC, is a LAN interface, Li. Further Rd and Ru support upstream- 271 assigned labels. In this case Rd instead of sending a Label Mapping 272 message as described in [MLDP] sends a Label Request message to Ru. 273 This Label Request message MUST contain an Upstream Assigned Label 274 Request TLV. 276 Ru on receiving this message sends back a Label Mapping message to Rd 277 with an upstream-assigned label. This message also contains a MPLS 278 Context Label TLV, as described in the previous section, with the 279 value of the MPLS label set to a value assigned by Ru on inteface Li 280 as specified in [MPLS-UPSTREAM]. Processing of the Label Request and 281 Label Mapping messages for LDP upstream-assigned labels is as 282 described in section 4.2. If Ru receives a Label Request for an 283 upstream assigned label for the same P2MP FEC from multiple 284 downstream LSRs on the LAN, , it MUST send the same 285 upstream-assigned label to each of . 287 Ru transmits the MPLS packet using the procedures defined in [MPLS- 288 UPSTREAM] and [MPLS-MCAST-ENCAPS]. The MPLS packet transmitted by Ru 289 contains as the top label the context label assigned by Ru on the LAN 290 interface, Li. The bottom label is the upstream label assigned by Ru 291 to the LDP P2MP LSP. The top label is looked up in the context of the 292 LAN interface, Li, [MPLS-UPSTREAM] by a downstream LSR on the LAN. 293 This lookup enables the downstream LSR to determine the context 294 specific label space to lookup the inner label in. 296 Note that may have more than one equal cost next-hop on 297 the LAN to reach Pr. It MAY be desirable for all of them to send the 298 label request to the same upstream LSR and they MAY select one 299 upstream LSR using the following procedure: 301 1. The candidate upstream LSRs are numbered from lower to higher IP 302 address 304 2. The following hash is performed: H = (Sum Opaque value) modulo N, 305 where N is the number of candidate upstream LSRs. Opaque value is 306 defined in [MLDP] and comprises the P2MP LSP identifier. 308 3. The selected upstream LSR U is the LSR that has the number H. 310 This allows for load balancing of a set of LSPs among a set of 311 candidate upstream LSRs, while ensuring that on a LAN interface a 312 single upstream LSR is selected. It is also to be noted that the 313 procedures in this section can still be used by Rd and Ru if other 314 LSRs on the LAN do not support upstream label assignment. Ingress 315 replication and downstream label assignment will continue to be used 316 for LSRs that do not support upstream label assignment. 318 7. Acknowledgements 320 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 321 Thomas Morin for their comments. The hashing algorithm used on LAN 322 interfaces is taken from [MLDP]. 324 8. References 326 8.1. Normative References 328 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 329 RFC 3031. 331 [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream 332 Label Assignment and Context Specific Label Space", draft-ietf-mpls- 333 upstream-label-02.txt 335 [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, 336 draft-ietf-mpls-codepoint-01.txt 338 [RFC2119] "Key words for use in RFCs to Indicate Requirement 339 Levels.", Bradner, March 1997 341 [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized 342 Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based 343 Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, 344 January 2003. 346 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label 347 Switching (GMPLS) Signaling Functional Description", RFC 3471 January 348 2003. 350 [RFC3036] L. Andersson, et. al., "LDP Specification", January 2001. 352 8.2. Informative References 354 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", 355 draft-ietf-l3vpn-2547bis-mcast-02.txt 357 [RSVP-TE-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 358 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", draft-ietf- 359 mpls-rsvp-te-p2mp-07.txt 361 [MLDP] I. Minei et. al, "Label Distribution Protocol Extensions for 362 Point-to-Multipoint Label Switched Paths", draft-etf-mpls-ldp- 363 p2mp-02.txt 365 [LDP-CAP] B. Thomas, et. al., "LDP Capabilities", draft-thomas-mpls- 366 ldp-capabilities-02.txt 368 9. Author Information 370 Rahul Aggarwal 371 Juniper Networks 372 1194 North Mathilda Ave. 373 Sunnyvale, CA 94089 374 Email: rahul@juniper.net 376 Jean-Louis Le Roux 377 France Telecom 378 2, avenue Pierre-Marzin 379 22307 Lannion Cedex 380 France 381 E-mail: jeanlouis.leroux@orange-ftgroup.com 383 10. Intellectual Property Statement 385 The IETF takes no position regarding the validity or scope of any 386 Intellectual Property Rights or other rights that might be claimed to 387 pertain to the implementation or use of the technology described in 388 this document or the extent to which any license under such rights 389 might or might not be available; nor does it represent that it has 390 made any independent effort to identify any such rights. Information 391 on the procedures with respect to rights in RFC documents can be 392 found in BCP 78 and BCP 79. 394 Copies of IPR disclosures made to the IETF Secretariat and any 395 assurances of licenses to be made available, or the result of an 396 attempt made to obtain a general license or permission for the use of 397 such proprietary rights by implementers or users of this 398 specification can be obtained from the IETF on-line IPR repository at 399 http://www.ietf.org/ipr. 401 The IETF invites any interested party to bring to its attention any 402 copyrights, patents or patent applications, or other proprietary 403 rights that may cover technology that may be required to implement 404 this standard. Please address the information to the IETF at ietf- 405 ipr@ietf.org. 407 11. Full Copyright Statement 409 Copyright (C) The IETF Trust (2007). This document is subject to the 410 rights, licenses and restrictions contained in BCP 78, and except as 411 set forth therein, the authors retain all their rights. 413 This document and the information contained herein are provided on an 414 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 415 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 416 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 417 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 418 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 419 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.