idnits 2.17.1 draft-ietf-mpls-rsvp-upstream-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) 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 (July 12, 2009) is 5395 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: 'RSVP-P2MP' is mentioned on line 101, but not defined == Missing Reference: 'LSP-HIER' is mentioned on line 231, but not defined == Missing Reference: 'MLDP' is mentioned on line 224, but not defined == Unused Reference: 'RFC3031' is defined on line 348, 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-05 -- No information found for draft-ietf-mpls-codepoint - is the name correct? -- Possible downref: Normative reference to a draft: ref. 'RFC5332' == Outdated reference: A later version (-10) exists of draft-ietf-l3vpn-2547bis-mcast-06 Summary: 2 errors (**), 0 flaws (~~), 9 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: January 2010 5 J. L. Le Roux 6 France Telecom 8 July 12, 2009 10 MPLS Upstream Label Assignment for RSVP-TE 12 draft-ietf-mpls-rsvp-upstream-04.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) 2009 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 in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 This document may contain material from IETF Documents or IETF 46 Contributions published or made publicly available before November 47 10, 2008. The person(s) controlling the copyright in some of this 48 material may not have granted the IETF Trust the right to allow 49 modifications of such material outside the IETF Standards Process. 50 Without obtaining an adequate license from the person(s) controlling 51 the copyright in such materials, this document may not be modified 52 outside the IETF Standards Process, and derivative works of it may 53 not be created outside the IETF Standards Process, except to format 54 it for publication as an RFC or to translate it into languages other 55 than English. 57 Abstract 59 This document describes procedures for distributing upstream-assigned 60 labels for Resource Reservation Protocol - Traffic Engineering (RSVP- 61 TE). It also describes how these procedures can be used for avoiding 62 branch LSR traffic replication on a LAN for RSVP-TE point-to- 63 multipoint (P2MP)LSPs. 65 Table of Contents 67 1 Specification of requirements ......................... 3 68 2 Introduction .......................................... 3 69 3 RSVP-TE Upstream Label Assignment Capability .......... 3 70 4 Distributing Upstream-Assigned Labels in RSVP-TE ...... 4 71 4.1 Procedures ............................................ 5 72 5 RSVP-TE Tunnel Identifier Exchange .................... 5 73 6 RSVP-TE Point-to-Multipoint LSPs on a LAN ............. 7 74 7 IANA Considerations ................................... 8 75 8 Acknowledgements ...................................... 8 76 9 References ............................................ 9 77 9.1 Normative References .................................. 9 78 9.2 Informative References ................................ 9 79 10 Author's Address ...................................... 10 80 1. Specification of requirements 82 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 83 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 84 document are to be interpreted as described in [RFC2119]. 86 2. Introduction 88 This document describes procedures for distributing upstream-assigned 89 labels [RFC5331] for Resource Reservation Protocol with Traffic 90 Engineering (RSVP-TE). These procedures follow the architecture for 91 MPLS Upstream Label Assignment described in [RFC5331]. 93 This document describes extensions to RSVP-TE that a LSR can use to 94 advertise to its neighboring LSRs whether the LSR supports upstream 95 label assignment. 97 This document also describes extensions to RSVP-TE to distribute 98 upstream-assigned labels. 100 The usage of MPLS upstream label assignment using RSVP-TE for 101 avoiding branch LSR [RSVP-P2MP] traffic replication on a LAN for 102 RSVP-TE P2MP TE LSPs [RFC4875] is also described. 104 3. RSVP-TE Upstream Label Assignment Capability 106 According to [RFC5331], upstream-assigned label bindings MUST NOT be 107 used unless it is known that a downstream LSR supports them. This 108 implies that there MUST be a mechanism to enable a LSR to advertise 109 to its RSVP-TE neighbor LSR(s) its support of upstream-assigned 110 labels. 112 [RFC5063] defines a CAPABILITY object to be carried within Hello 113 messages, and used to indicate the set of capabilities supported by a 114 node. This object provides the ability to encode a set of capability 115 flags. This document defines a new flag, the U flag, to signal a 116 LSR's support of upstream label assignment to its RSVP-TE neighbors. 118 The format of a Capability object is: 120 0 1 2 3 121 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 122 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 123 | Length | Class-Num(TBA)| C-Type (1) | 124 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 125 | Reserved |U|T|R|S| 126 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 128 T, R and S flags are defined in [RFC5063]. 130 Upstream Label Assignement Capable (U): 1 bit When set this means 131 that the LSR is capable of both distributing upstream-assigned label 132 bindings and receiving upstream-assigned label bindings 134 Reserved bits MUST be set to zero on transmission and MUST be ignored 135 on receipt. 137 The usage of RSVP-TE Hello messages for exchanging upstream label 138 assignment capability implies that a LSR MAY exchange RSVP-TE Hellos 139 with a neighbor before sending/receiving any other RSVP-TE messages 140 to/from that neighbor. 142 4. Distributing Upstream-Assigned Labels in RSVP-TE 144 An optional RSVP-TE object, the UPSTREAM_ASSIGNED_LABEL object is 145 introduced to signal an upstream-assigned label. The Class-Num for 146 this object comes from the 0bbbbbbb space and is to be determined by 147 IANA. 149 UPSTREAM_ASSIGNED_LABEL C-Num = TBD 151 0 1 2 3 152 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 153 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 154 | Reserved | 155 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 156 | Label | 157 | .... | 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 160 The label can be encoded as in [RFC3209] when the C-Type is 1 or as a 161 Generalized Label [RFC3473] when the C-Type is 2 or 3. 163 4.1. Procedures 165 A RSVP-TE LSR that assigns Upstream-Assigned Labels, distributes them 166 to the downstream LSRs by including them in RSVP-TE Path messages. 168 A RSVP-TE LSR MUST NOT distribute the UPSTREAM_ASSIGNED_LABEL Object 169 to a downstream LSR if the downstream LSR had not previously 170 advertised the CAPABILITY object with the U bit set in its RSVP-TE 171 Hello messages. 173 If a downstream RSVP-TE LSR receives a Path message that carries an 174 UPSTREAM_ASSIGNED_LABEL Object and the LSR does not support the 175 object C-Num/C-Type it will return an "Unknown Object C-Num/C-Type" 176 error. If the LSR does support the object, but is unable to process 177 the upstream-assigned label as described in [RFC5331] it SHOULD send 178 a PathErr with the error code "Routing problem" and the error value 179 "MPLS Upstream Assigned Label Processing Failure". If the LSR 180 successfully processes the Path message and the upstream-assigned 181 label it MUST send a Resv message upstream as per [RFC3209] but it 182 MUST NOT include the LABEL object with a downstream assigned label in 183 the Resv Message. This is because as described in [RFC5331] two LSRs 184 Ru and Rd for a LSP that is bound to FEC F, MUST use either 185 downstream-assigned label distribution or upstream-assigned label 186 distribution,for FEC F, but NOT both, for packets that are to be 187 transmitted on the LSP from Ru to Rd. 189 5. RSVP-TE Tunnel Identifier Exchange 191 As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS 192 packet, the top label of which (L) is upstream-assigned, to a 193 downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In 194 this case the fact that L is upstream-assigned is determined by Rd by 195 the tunnel on which the packet is received. There must be a mechanism 196 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 197 used by Ru for transmitting MPLS packets with upstream-assigned MPLS 198 labels. 200 When RSVP-TE is used for upstream label assignment, the IF_ID 201 RSVP_HOP object is used for signaling the Tunnel Identifier. If Ru 202 uses an IP or MPLS tunnel to transmit MPLS packets with upstream 203 assigned labels to Rd, Ru MUST include the IF_ID RSVP_HOP object 204 [RFC3473] in Path messages along with the UPSTREAM_ASSIGNED_LABEL 205 Object. 207 Four new TLVs are introduced in the IF_ID RSVP_HOP object [RFC3471] 208 to support RSVP-TE P2MP LSPs, LDP P2MP LSPs, IP Multicast Tunnels and 209 context labels. The TLV value acts as the tunnel identifier. 211 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE 212 P2MP Session Object and optionally the P2MP Sender Template Object 213 [RFC4875]. The TLV value identifies the RSVP-TE P2MP LSP. This 214 mechanism extends RSVP-TE P2P Hierarchy [LSP-HIER] to RSVP-TE P2MP 215 Hierarchy. It allows Ru to tunnel an "inner" RSVP-TE P2MP LSP, the 216 label for which is upstream assigned, over an "outer" RSVP-TE P2MP 217 LSP that has leaves . The P2MP LSP IF_ID TLV allows Ru to 218 signal to the binding of the inner P2MP LSP to the outer 219 P2MP LSP. The control plane signaling between Ru and for 220 the inner P2MP LSP uses directed RSVP-TE signaling messages as in 221 [LSP-HIER]. 223 2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC 224 as defined in [MLDP]. The TLV value identifies the LDP P2MP LSP. It 225 allows Ru to tunnel an "inner" RSVP-TE P2MP LSP, the label for which 226 is upstream assigned, over an "outer" LDP P2MP LSP that has leaves 227 . The P2MP LSP IF_ID TLV allows Ru to signal to 228 the binding of the inner LDP P2MP LSP to the outer LDP- 229 P2MP LSP. The control plane signaling between Ru and for 230 the inner P2MP LSP uses directed RSVP-TE signaling messages as in 231 [LSP-HIER]. 233 2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 234 a tuple. Source Address is 235 the IP address of the root of the tunnel i.e. Ru, and Multicast Group 236 Address is the Multicast Group Address used by the tunnel. 238 3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is 239 a tuple. The Source Address 240 belongs to Ru and the MPLS Context Label is an upstream assigned 241 label, assigned by Ru. This allows Ru to tunnel an "inner" RSVP-TE 242 P2MP LSP, the label of which is upstream assigned, over an "outer" 243 MPLS LSP, where the outer LSP has the following property: 245 + The label pushed by Ru for the outer MPLS LSP is an upstream 246 assigned context label, assigned by Ru. When perform 247 a MPLS label lookup on this label a combination of this label and 248 the incoming interface MUST be sufficient for to 249 uniquely determine Ru's context specific label space to lookup 250 the next label on the stack in. MUST receive the data 251 sent by Ru with the context specific label assigned by Ru being 252 the top label on the label stack. 254 Currently the usage of the context label TLV is limited only to RSVP- 255 TE P2MP LSPs on a LAN as specified in the next section. The context 256 label TLV MUST NOT be used for any other purposes. 258 Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP 259 the above procedures assume that Ru has a priori knowledge of all the 260 . In the scenario where the outer P2MP LSP is signaled 261 using RSVP-TE, Ru can obtain this information from RSVP-TE. However, 262 in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP 263 does not provide this information to Ru. In this scenario the 264 procedures by which Ru could acquire this information are outside the 265 scope of this document. 267 6. RSVP-TE Point-to-Multipoint LSPs on a LAN 269 This section describes one application of upstream label assignment 270 using RSVP-TE. Further applications are to be described in separate 271 documents. 273 [RFC4875] describes how to setup RSVP-TE P2MP LSPs. On a LAN the 274 solution described in [RFC4875] relies on "ingress replication". A 275 LSR on a LAN (say Il), that is a branch LSR for a P2MP LSP, (say Ru) 276 sends a separate copy of a packet that it receives on the P2MP LSP to 277 each of the downstream LSRs on the LAN (say that are 278 adjacent to it in the P2MP LSP. 280 In order to increase efficiency of bandwidth utilization, it is 281 desirable for Ru to send a single copy of the packet for the P2MP LSP 282 on the LAN, when there are multiple downstream routers on the LAN 283 that are adjacent in that P2MP LSP. This requires that each of 284 must be able to associate the label L, used by Ru to 285 transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It 286 is possible to achieve this using RSVP-TE upstream-assigned labels 287 with the following procedures. Assume that Ru and support 288 upstream label assignment. 290 Ru sends a Path message for the P2MP LSP to each of that 291 is adjacent on the P2MP LSP, with the same UPSTREAM_ASSIGNED_LABEL 292 object. This object carries an upstream assigned label, L. This 293 message also carries a MPLS Context Label TLV, as described in the 294 previous section, with the value of the MPLS label set to a value 295 assigned by Ru on inteface I1 as specified in [RFC5331]. 296 "reserve" the upstream assigned label in the separate Upstream 297 Neighbor Label Space that they maintain for Ru [RFC5331]. 299 Ru can then transmit a single packet for the P2MP LSP to 300 with a top label L using procedures defined in [RFC5331] and 301 [RFC5332]. The MPLS packet transmitted by Ru contains as the top 302 label the context label assigned by Ru on the LAN interface, I1. The 303 bottom label is the upstream label assigned by Ru to the RSVP-TE P2MP 304 LSP. The top label is looked up in the context of the LAN interface, 305 I1, [RFC5331] by a downstream LSR on the LAN. This lookup enables the 306 downstream LSR to determine the context specific label space to 307 lookup the inner label in. 309 If a subset of do not support upstream label assignment 310 these procedures can still be used between Ru and the remaining 311 subset of . Ingress replication and downstream label 312 assignment will continue to be used for LSRs that do not support 313 upstream label assignment. 315 7. IANA Considerations 317 This document defines a new U flag in the CAPABILITY object defined 318 by [RFC5063]. IANA is requested to assign a new bit to this flag from 319 the 32 bit flags field of the CAPABILITY object. 321 This document defines a new RSVP-TE object, the 322 UPSTREAM_ASSIGNED_LABEL object. The Class-Num for this object comes 323 from the 0bbbbbbb space and IANA is requested to assign this Class- 324 Num. 326 This document defines four new TLVs in the IF_ID RSVP_HOP object 327 [RFC3471]: 329 - RSVP-TE P2MP LSP TLV 331 - LDP P2MP LSP TLV 333 - IP Multicast Tunnel TLV 335 - MPLS Context Label TLV 337 IANA is requested to assign the type values of these TLVs. 339 8. Acknowledgements 341 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 342 Thomas Morin for their comments. 344 9. References 346 9.1. Normative References 348 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 349 RFC 3031. 351 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 352 Assignment and Context Specific Label Space", draft-ietf-mpls- 353 upstream-label-05.txt 355 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, draft-ietf- 356 mpls-codepoint-08.txt 358 [RFC3209] Awduche et. al." "RSVP-TE: Extensions to RSVP for LSP 359 Tunnels", RFC 3209, December 2001. 361 [RFC2119] "Key words for use in RFCs to Indicate Requirement 362 Levels.", Bradner, March 1997 364 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 365 Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic 366 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 368 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label 369 Switching (GMPLS) Signaling Functional Description", RFC 3471 January 370 2003. 372 [RFC5063] A. Satyanarayana et. al., "Extensions to GMPLS Resource 373 Reservation Protocol (RSVP) Graceful Restart", RFC5063 375 9.2. Informative References 377 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", 378 draft-ietf-l3vpn-2547bis-mcast-06.txt 380 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 381 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 383 10. Author's Address 385 Rahul Aggarwal 386 Juniper Networks 387 1194 North Mathilda Ave. 388 Sunnyvale, CA 94089 389 Phone: +1-408-936-2720 390 Email: rahul@juniper.net 392 Jean-Louis Le Roux 393 France Telecom 394 2, avenue Pierre-Marzin 395 22307 Lannion Cedex 396 France 397 E-mail: jeanlouis.leroux@orange-ftgroup.com