idnits 2.17.1 draft-raggarwa-mpls-ldp-upstream-00.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 18. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 356. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 369. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** The document seems to lack an RFC 3978 Section 5.5 (updated by RFC 4748) Disclaimer -- however, there's a paragraph with a matching beginning. Boilerplate error? ** The document seems to lack an RFC 3979 Section 5, para. 2 IPR Disclosure Acknowledgement -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == No 'Intended status' indicated for this document; assuming Proposed Standard == It seems as if not all pages are separated by form feeds - found 0 form feeds but 9 pages 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 RFC 3978 Section 5.4 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 (October 2005) is 6766 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 161, but not defined == Unused Reference: 'RFC3031' is defined on line 294, but no explicit reference was found in the text == Unused Reference: 'RFC3471' is defined on line 312, but no explicit reference was found in the text == Unused Reference: 'MVPN' is defined on line 320, but no explicit reference was found in the text == Outdated reference: A later version (-01) exists of draft-raggarwa-mpls-upstream-label-00 -- Possible downref: Normative reference to a draft: ref. 'MPLS-UPSTREAM' -- No information found for draft-rosen-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 (-01) exists of draft-minei-mpls-ldp-p2mp-00 Summary: 7 errors (**), 0 flaws (~~), 9 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group R. Aggarwal 2 Internet Draft Juniper Networks 3 Expiration Date: April 2006 4 J. L. Le Roux 5 France Telecom 7 October 2005 9 MPLS Upstream Label Assignment for LDP 11 draft-raggarwa-mpls-ldp-upstream-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 This document describes procedures for distributing upstream-assigned 39 labels for Label Distribution Protocol (LDP). It also describes how 40 these procedures can be used for avoiding branch LSR traffic 41 replication on a LAN for LDP point-to-multipoint (P2MP)LSPs. 43 Table of Contents 45 1 Specification of requirements ......................... 2 46 2 Introduction .......................................... 2 47 3 LDP Upstream Label Assignment Capability .............. 3 48 4 Distributing Upstream-Assigned Labels in LDP .......... 4 49 4.1 Procedures ............................................ 4 50 5 LDP Tunnel Identifier Exchange ........................ 5 51 6 LDP Point-to-Multipoint LSPs on a LAN ................. 6 52 7 Acknowledgements ...................................... 7 53 8 References ............................................ 7 54 8.1 Normative References .................................. 7 55 8.2 Informative References ................................ 8 56 9 Author Information .................................... 8 57 10 Intellectual Property Statement ....................... 8 58 11 Full Copyright Statement .............................. 9 60 1. Specification of requirements 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in [RFC2119]. 66 2. Introduction 68 This document describes procedures for distributing upstream-assigned 69 labels [MPLS-UPSTREAM] for Label Distribution Protocol (LDP). These 70 procedures follow the architecture for MPLS Upstream Label Assignment 71 described in [MPLS-UPSTREAM]. 73 This document describes extensions to LDP that a LSR can use to 74 advertise to its neighboring LSRs whether the LSR supports upstream 75 label assignment. 77 This document also describes extensions to LDP to distribute 78 upstream-assigned labels. 80 The usage of MPLS upstream label assignment using LDP for avoiding 81 branch LSR traffic replication on a LAN for LDP P2MP LSPs [LDP-P2MP1, 82 LDP-P2MP2] is also described. 84 3. LDP Upstream Label Assignment Capability 86 According to [MPLS-UPSTREAM], upstream-assigned label bindings MUST 87 NOT be used unless it is known that a downstream LSR supports them. 88 This implies that there MUST be a mechanism to enable a LSR to adver- 89 tise to its LDP neighbor LSR(s) its support of upstream-assigned 90 labels. 92 A new optional parameter, the LDP Capability TLV, is introduced to 93 allow LDP peers to exchange capabilities as part of LDP Initializa- 94 tion messages. This TLV contains one or more sub-TLVs, each to sig- 95 nal a specific capability. LDP Capability TLV and detailed procedures 96 for supporting LDP Capability signaling will be described in a sepa- 97 rate document. 99 A Upstream Label Assignment Capability sub-TLV is introduced to sig- 100 nal a LSR's support of upstream label assignment, to its LDP peers. 101 This sub-TLV is carried in the LDP Capability TLV. 103 Following is the format of the LDP Capability TLV: 105 0 1 2 3 106 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 107 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 108 |1|0| Capability TLV (TBD) | Length (= 4) | 109 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 110 | Sub-TLVs... | 111 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 113 Following is the format of the Upstream Label Assignment Capability 114 sub-TLV: 116 0 1 2 3 117 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 118 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 119 |Upstream Lbl Ass Cap = 1 | Length (= 4) | 120 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 121 | Reserved | 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 124 If a LSR includes the Upstream Label Assignment Capability sub-TLV in 125 LDP Initialization Messages it implies that the LSR is capable of 126 both distributing upstream-assigned label bindings and receiving 127 upstream-assigned label bindings. Reserved bits MUST be set to zero 128 on transmission and MUST be ignored on receipt. 130 4. Distributing Upstream-Assigned Labels in LDP 132 An optional LDP TLV, Upstream-Assigned Label Request TLV, is intro- 133 duced. This TLV MUST be carried in a Label Request message if an 134 upstream-assigned label is being requested. 136 0 1 2 3 137 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 138 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 139 |0|0| Upstream Ass Lbl Req (TBD)| Length | 140 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 141 | Reserved | 142 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 144 An optional LDP TLV, Upstream-Assigned Label TLV is introduced to 145 signal an upstream-assigned label. Upstream-Assigned Label TLVs are 146 carried by the messages used to advertise, release and withdraw 147 upstream assigned label mappings. 149 0 1 2 3 150 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 151 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 152 |0|0| Upstream Ass Label (TBD) | Length | 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Reserved | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Label | 157 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 Label 161 This is a 20-bit label value as specified in [RFC3032] represented as 162 a 20-bit number in a 4 octet field. 164 4.1. Procedures 166 Procedures for Label Mapping, Label Request, Label Abort, Label With- 167 draw and Label Release follow [RFC3036] other than the modifications 168 pointed out in this section. 170 A LDP LSR MUST NOT distribute the Upstream Assigned Label TLV to a 171 neighboring LSR if the neighboring LSR had not previously advertised 172 the Upstream Label Assignment Capability in its LDP Initialization 173 messages. A LDP LSR MUST NOT send the Upstream Assigned Label 174 Request TLV to a neighboring LSR if the neighboring LSR had not pre- 175 viously advertised the Upstream Label Assignment Capability in its 176 LDP Initialization messages. 178 As described in [MPLS-UPSTREAM] the distribution of upstream-assigned 179 labels is similar to either ordered LSP control or independent LSP 180 control of the downstream assigned labels. 182 When the label distributed in a Label Mapping message is an upstream- 183 assigned label, the Upstream Assigned Label TLV MUST be included in 184 the Label Mapping message. When a LSR receives a Label Mapping mes- 185 sage with an Upstream Assigned Label TLV and if it does not recognize 186 the TLV, it MUST generate a Notification message with a status code 187 of "Unknown TLV" [RFC3036]. If it does recognize the TLV but is 188 unable to process the upstream label, it MUST generate a Notification 189 message with a status code of "No Label Resources". If the Label Map- 190 ping message was generated in response to a Label Request message, 191 the Label Request message MUST contain an Upstream Assigned Label 192 Request TLV. A LSR that generates an upstream assigned label request 193 to a neighbor LSR, for a given FEC, MUST NOT send a downstream label 194 mapping to the neighbor LSR for that FEC unless it withdraws the 195 upstream-assigned label binding. Similarly if a LSR generates a down- 196 stream assigned label request to a neighbor LSR, for a given FEC, it 197 MUST NOT send an upstream label mapping to that LSR for that FEC, 198 unless it aborts the downstream assigned label request. 200 The Upstream Assigned Label TLV may be optionally included in Label 201 Withdraw and Label Release messages that withdraw/release a particu- 202 lar upstream assigned label binding. 204 5. LDP Tunnel Identifier Exchange 206 As described in [MPLS-UPSTREAM] an upstream LSR Ru MAY transmit a 207 MPLS packet, the top label of which (L) is upstream-assigned, to a 208 downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In 209 this case the fact that L is upstream-assigned is determined by Rd by 210 the tunnel on which the packet is received. There must be a mechanism 211 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 212 used by Ru for transmitting MPLS packets with upstream-assigned MPLS 213 labels. 215 When LDP is used for upstream label assignment, the Interface ID TLV 216 [RFC3472] is used for signaling the Tunnel Identifier. If Ru uses an 217 IP or MPLS tunnel to transmit MPLS packets with upstream assigned 218 labels to Rd, Ru MUST include the Interface ID TLV in the Label Map- 219 ping messages along with the Upstream Assigned Label TLV. Two new 220 Interface ID TLVs are introduced to support RSVP-TE P2MP LSPs and IP 221 Multicast Tunnels. The TLV value acts as the tunnel identifier. 223 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE 224 P2MP Session Object and optionally the P2MP Sender Template Object 225 [RSVP-TE-P2MP]. The TLV value identifies the RSVP-TE P2MP LSP. It 226 allows Ru to tunnel an "inner" LDP P2MP LSP, the label for which is 227 upstream assigned, over an "outer" RSVP-TE P2MP LSP that has leaves 228 . The P2MP LSP IF_ID TLV allows Ru to signal to 229 the binding of the inner LDP P2MP LSP to the outer RSVP- 230 TE P2MP LSP. The control plane signaling between Ru and 231 for the inner P2MP LSP uses targeted LDP signaling messages 233 2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 234 a tuple. 236 6. LDP Point-to-Multipoint LSPs on a LAN 238 This section describes one application of upstream label assignment 239 using LDP. Further applications are to be described in separate docu- 240 ments. 242 [LDP-P2MP1, LDP-P2MP2] describe how to setup P2MP LSPs using LDP. On 243 a LAN the solution relies on "ingress replication". A LSR on a LAN, 244 that is a branch LSR for a P2MP LSP, (say Ru) sends a separate copy 245 of a packet that it receives on the P2MP LSP to each of the down- 246 stream LSRs on the LAN (say that are adjacent to it in 247 the P2MP LSP. 249 It is desirable for Ru to send a single copy of the packet for the 250 LDP P2MP LSP on the LAN, when there are multiple downstream routers 251 on the LAN that are adjacent to Ru in that LDP P2MP LSP. This 252 requires that each of must be able to associate the label 253 L, used by Ru to transmit packets for the P2MP LSP on the LAN, with 254 that P2MP LSP. It is possible to achieve this using LDP upstream- 255 assigned labels with the following procedures. 257 Consider a LSR Rd that receives the LDP P2MP FEC [LDP-P2MP1, LDP- 258 P2MP2] from its downstream LDP peer. Further the upstream interface 259 to reach LSR Ru which is the next-hop to the P2MP LSP root address, 260 Pr, in the LDP P2MP FEC, is a LAN interface. Further Rd and Ru sup- 261 port upstream-assigned labels. In this case Rd instead of sending a 262 Label Mapping message as described in [LDP-P2MP1, LDP-P2MP2] sends a 263 Label Request message to Ru. This Label Request message MUST contain 264 an Upstream Assigned Label Request TLV. Ru on receiving this message 265 sends back a Label Mapping message to Rd with an upstream-assigned 266 label. Processing of the Label Request and Label Mapping messages for 267 LDP upstream-assigned labels is as described in section 4.2. If Ru 268 receives a Label Request for an upstream assigned label for the same 269 P2MP FEC from multiple downstream LSRs on the LAN, , it 270 MUST send the same upstream-assigned label to each of . Ru 271 transmits the MPLS packet with an upstream-assigned label on the LAN 272 using the procedures defined in [MPLS-UPSTREAM] and [MPLS-MCAST- 273 ENCAPS]. 275 Note that may have more than one equal cost next-hop on 276 the LAN to reach Pr. In this case they MAY be configured to send the 277 upstream assigned label request to the next-hop LSR with the lowest 278 Router ID, if it is desirable for all of them to send the label 279 request to the same upstream LSR. It is also to be noted that these 280 procedures can still be used by Rd and Ru if other LSRs on the LAN do 281 not support upstream label assignment. Ingress replication and down- 282 stream label assignment will continue to be used for LSRs that do not 283 support upstream label assignment. 285 7. Acknowledgements 287 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 288 Thomas Morin for their comments. 290 8. References 292 8.1. Normative References 294 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 295 RFC 3031. 297 [MPLS-UPSTREAM] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream 298 Label Assignment and Context Specific Label Space", draft-raggarwa- 299 mpls-upstream-label-00.txt 301 [MPLS-MCAST-ENCAPS] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, 302 draft-rosen-mpls-codepoint-00.txt 304 [RFC2119] "Key words for use in RFCs to Indicate Requirement Lev- 305 els.", Bradner, March 1997 307 [RFC3472] Ashwood-Smith, P. and L. Berger, Editors, " Generalized 308 Multi-Protocol Label Switching (GMPLS) Signaling - Constraint-based 309 Routed Label Distribution Protocol (CR-LDP) Extensions", RFC 3472, 310 January 2003. 312 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label 313 Switching (GMPLS) Signaling Functional Description", RFC 3471 January 314 2003. 316 [RFC3036] L. Andersson, et. al., "LDP Specification", January 2001. 318 8.2. Informative References 320 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs" 322 [RSVP-TE-P2MP] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 323 "Extensions to RSVP-TE for Point to Multipoint TE LSPs" 325 [LDP-P2MP1] I. Minei et. al, "Label Distribution Protocol Extensions 326 for Point-to-Multipoint Label Switched Paths", draft-minei-mpls-ldp- 327 p2mp-00.txt 329 [LDP-P2MP2] I. Wijnands et. al., "Multicast Extensions for LDP", 330 draft-wijnands-mpls-ldp-mcast-ext-00.txt 332 9. Author Information 334 Rahul Aggarwal 335 Juniper Networks 336 1194 North Mathilda Ave. 337 Sunnyvale, CA 94089 338 Email: rahul@juniper.net 340 Jean-Louis Le Roux 341 France Telecom 342 2, avenue Pierre-Marzin 343 22307 Lannion Cedex 344 France 345 E-mail: jeanlouis.leroux@francetelecom.com 347 10. Intellectual Property Statement 349 The IETF takes no position regarding the validity or scope of any 350 Intellectual Property Rights or other rights that might be claimed to 351 pertain to the implementation or use of the technology described in 352 this document or the extent to which any license under such rights 353 might or might not be available; nor does it represent that it has 354 made any independent effort to identify any such rights. Information 355 on the procedures with respect to rights in RFC documents can be 356 found in BCP 78 and BCP 79. 358 Copies of IPR disclosures made to the IETF Secretariat and any assur- 359 ances of licenses to be made available, or the result of an attempt 360 made to obtain a general license or permission for the use of such 361 proprietary rights by implementers or users of this specification can 362 be obtained from the IETF on-line IPR repository at 363 http://www.ietf.org/ipr. 365 The IETF invites any interested party to bring to its attention any 366 copyrights, patents or patent applications, or other proprietary 367 rights that may cover technology that may be required to implement 368 this standard. Please address the information to the IETF at ietf- 369 ipr@ietf.org. 371 11. Full Copyright Statement 373 Copyright (C) The Internet Society (2005). This document is subject 374 to the rights, licenses and restrictions contained in BCP 78, and 375 except as set forth therein, the authors retain all their rights. 377 This document and the information contained herein are provided on an 378 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 379 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 380 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 381 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFOR- 382 MATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES 383 OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE.