idnits 2.17.1 draft-ietf-mpls-rsvp-upstream-05.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 (March 08, 2010) is 5134 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 106, but not defined == Missing Reference: 'LSP-HIER' is mentioned on line 236, but not defined == Missing Reference: 'MLDP' is mentioned on line 229, but not defined == Unused Reference: 'RFC3031' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'MVPN' is defined on line 393, 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 == Outdated reference: A later version (-09) exists of draft-ietf-mpls-mpls-and-gmpls-security-framework-07 Summary: 0 errors (**), 0 flaws (~~), 10 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: September 2010 5 J. L. Le Roux 6 France Telecom 8 March 08, 2010 10 MPLS Upstream Label Assignment for RSVP-TE 12 draft-ietf-mpls-rsvp-upstream-05.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 Resource Reservation Protocol - Traffic Engineering (RSVP- 65 TE). It also describes how these procedures can be used for avoiding 66 branch LSR traffic replication on a LAN for RSVP-TE point-to- 67 multipoint (P2MP)LSPs. 69 Table of Contents 71 1 Specification of requirements ......................... 3 72 2 Introduction .......................................... 3 73 3 RSVP-TE Upstream Label Assignment Capability .......... 3 74 4 Distributing Upstream-Assigned Labels in RSVP-TE ...... 4 75 4.1 Procedures ............................................ 5 76 5 RSVP-TE Tunnel Identifier Exchange .................... 5 77 6 RSVP-TE Point-to-Multipoint LSPs on a LAN ............. 7 78 7 IANA Considerations ................................... 8 79 8 Security Considerations ............................... 8 80 9 Acknowledgements ...................................... 9 81 10 References ............................................ 9 82 10.1 Normative References .................................. 9 83 10.2 Informative References ................................ 9 84 11 Author's Address ...................................... 10 85 1. Specification of requirements 87 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 88 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 89 document are to be interpreted as described in [RFC2119]. 91 2. Introduction 93 This document describes procedures for distributing upstream-assigned 94 labels [RFC5331] for Resource Reservation Protocol with Traffic 95 Engineering (RSVP-TE). These procedures follow the architecture for 96 MPLS Upstream Label Assignment described in [RFC5331]. 98 This document describes extensions to RSVP-TE that a LSR can use to 99 advertise to its neighboring LSRs whether the LSR supports upstream 100 label assignment. 102 This document also describes extensions to RSVP-TE to distribute 103 upstream-assigned labels. 105 The usage of MPLS upstream label assignment using RSVP-TE for 106 avoiding branch LSR [RSVP-P2MP] traffic replication on a LAN for 107 RSVP-TE P2MP TE LSPs [RFC4875] is also described. 109 3. RSVP-TE Upstream Label Assignment Capability 111 According to [RFC5331], upstream-assigned label bindings MUST NOT be 112 used unless it is known that a downstream LSR supports them. This 113 implies that there MUST be a mechanism to enable a LSR to advertise 114 to its RSVP-TE neighbor LSR(s) its support of upstream-assigned 115 labels. 117 [RFC5063] defines a CAPABILITY object to be carried within Hello 118 messages, and used to indicate the set of capabilities supported by a 119 node. This object provides the ability to encode a set of capability 120 flags. This document defines a new flag, the U flag, to signal a 121 LSR's support of upstream label assignment to its RSVP-TE neighbors. 123 The format of a Capability object is: 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 | Length | Class-Num(TBA)| C-Type (1) | 129 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 130 | Reserved |U|T|R|S| 131 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 133 T, R and S flags are defined in [RFC5063]. 135 Upstream Label Assignement Capable (U): 1 bit When set this means 136 that the LSR is capable of both distributing upstream-assigned label 137 bindings and receiving upstream-assigned label bindings 139 Reserved bits MUST be set to zero on transmission and MUST be ignored 140 on receipt. 142 The usage of RSVP-TE Hello messages for exchanging upstream label 143 assignment capability implies that a LSR MAY exchange RSVP-TE Hellos 144 with a neighbor before sending/receiving any other RSVP-TE messages 145 to/from that neighbor. 147 4. Distributing Upstream-Assigned Labels in RSVP-TE 149 An optional RSVP-TE object, the UPSTREAM_ASSIGNED_LABEL object is 150 introduced to signal an upstream-assigned label. The Class-Num for 151 this object comes from the 0bbbbbbb space and is to be determined by 152 IANA. 154 UPSTREAM_ASSIGNED_LABEL C-Num = TBD 156 0 1 2 3 157 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 158 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 159 | Reserved | 160 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 161 | Label | 162 | .... | 163 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 165 The label can be encoded as in [RFC3209] when the C-Type is 1 or as a 166 Generalized Label [RFC3473] when the C-Type is 2 or 3. 168 4.1. Procedures 170 A RSVP-TE LSR that assigns Upstream-Assigned Labels, distributes them 171 to the downstream LSRs by including them in RSVP-TE Path messages. 173 A RSVP-TE LSR MUST NOT distribute the UPSTREAM_ASSIGNED_LABEL Object 174 to a downstream LSR if the downstream LSR had not previously 175 advertised the CAPABILITY object with the U bit set in its RSVP-TE 176 Hello messages. 178 If a downstream RSVP-TE LSR receives a Path message that carries an 179 UPSTREAM_ASSIGNED_LABEL Object and the LSR does not support the 180 object C-Num/C-Type it will return an "Unknown Object C-Num/C-Type" 181 error. If the LSR does support the object, but is unable to process 182 the upstream-assigned label as described in [RFC5331] it SHOULD send 183 a PathErr with the error code "Routing problem" and the error value 184 "MPLS Upstream Assigned Label Processing Failure". If the LSR 185 successfully processes the Path message and the upstream-assigned 186 label it MUST send a Resv message upstream as per [RFC3209] but it 187 MUST NOT include the LABEL object with a downstream assigned label in 188 the Resv Message. This is because as described in [RFC5331] two LSRs 189 Ru and Rd for a LSP that is bound to FEC F, MUST use either 190 downstream-assigned label distribution or upstream-assigned label 191 distribution,for FEC F, but NOT both, for packets that are to be 192 transmitted on the LSP from Ru to Rd. 194 5. RSVP-TE Tunnel Identifier Exchange 196 As described in [RFC5331] an upstream LSR Ru MAY transmit a MPLS 197 packet, the top label of which (L) is upstream-assigned, to a 198 downstream LSR Rd, by encapsulating it in an IP or MPLS tunnel. In 199 this case the fact that L is upstream-assigned is determined by Rd by 200 the tunnel on which the packet is received. There must be a mechanism 201 for Ru to inform Rd that a particular tunnel from Ru to Rd will be 202 used by Ru for transmitting MPLS packets with upstream-assigned MPLS 203 labels. 205 When RSVP-TE is used for upstream label assignment, the IF_ID 206 RSVP_HOP object is used for signaling the Tunnel Identifier. If Ru 207 uses an IP or MPLS tunnel to transmit MPLS packets with upstream 208 assigned labels to Rd, Ru MUST include the IF_ID RSVP_HOP object 209 [RFC3473] in Path messages along with the UPSTREAM_ASSIGNED_LABEL 210 Object. 212 Four new TLVs are introduced in the IF_ID RSVP_HOP object [RFC3471] 213 to support RSVP-TE P2MP LSPs, LDP P2MP LSPs, IP Multicast Tunnels and 214 context labels. The TLV value acts as the tunnel identifier. 216 1. RSVP-TE P2MP LSP TLV. Type = TBD. Value of the TLV is the RSVP-TE 217 P2MP Session Object and optionally the P2MP Sender Template Object 218 [RFC4875]. The TLV value identifies the RSVP-TE P2MP LSP. This 219 mechanism extends RSVP-TE P2P Hierarchy [LSP-HIER] to RSVP-TE P2MP 220 Hierarchy. It allows Ru to tunnel an "inner" RSVP-TE P2MP LSP, the 221 label for which is upstream assigned, over an "outer" RSVP-TE P2MP 222 LSP that has leaves . The P2MP LSP IF_ID TLV allows Ru to 223 signal to the binding of the inner P2MP LSP to the outer 224 P2MP LSP. The control plane signaling between Ru and for 225 the inner P2MP LSP uses directed RSVP-TE signaling messages as in 226 [LSP-HIER]. 228 2. LDP P2MP LSP TLV. Type = TBD. Value of the TLV is the LDP P2MP FEC 229 as defined in [MLDP]. The TLV value identifies the LDP P2MP LSP. It 230 allows Ru to tunnel an "inner" RSVP-TE P2MP LSP, the label for which 231 is upstream assigned, over an "outer" LDP P2MP LSP that has leaves 232 . The P2MP LSP IF_ID TLV allows Ru to signal to 233 the binding of the inner LDP P2MP LSP to the outer LDP- 234 P2MP LSP. The control plane signaling between Ru and for 235 the inner P2MP LSP uses directed RSVP-TE signaling messages as in 236 [LSP-HIER]. 238 2. IP Multicast Tunnel TLV. Type = TBD. In this case the TLV value is 239 a tuple. Source Address is 240 the IP address of the root of the tunnel i.e. Ru, and Multicast Group 241 Address is the Multicast Group Address used by the tunnel. 243 3. MPLS Context Label TLV. Type = TBD. In this case the TLV value is 244 a tuple. The Source Address 245 belongs to Ru and the MPLS Context Label is an upstream assigned 246 label, assigned by Ru. This allows Ru to tunnel an "inner" RSVP-TE 247 P2MP LSP, the label of which is upstream assigned, over an "outer" 248 MPLS LSP, where the outer LSP has the following property: 250 + The label pushed by Ru for the outer MPLS LSP is an upstream 251 assigned context label, assigned by Ru. When perform 252 a MPLS label lookup on this label a combination of this label and 253 the incoming interface MUST be sufficient for to 254 uniquely determine Ru's context specific label space to lookup 255 the next label on the stack in. MUST receive the data 256 sent by Ru with the context specific label assigned by Ru being 257 the top label on the label stack. 259 Currently the usage of the context label TLV is limited only to RSVP- 260 TE P2MP LSPs on a LAN as specified in the next section. The context 261 label TLV MUST NOT be used for any other purposes. 263 Note that when the outer P2MP LSP is signaled with RSVP-TE or MLDP 264 the above procedures assume that Ru has a priori knowledge of all the 265 . In the scenario where the outer P2MP LSP is signaled 266 using RSVP-TE, Ru can obtain this information from RSVP-TE. However, 267 in the scenario where the outer P2MP LSP is signaled using MLDP, MLDP 268 does not provide this information to Ru. In this scenario the 269 procedures by which Ru could acquire this information are outside the 270 scope of this document. 272 6. RSVP-TE Point-to-Multipoint LSPs on a LAN 274 This section describes one application of upstream label assignment 275 using RSVP-TE. Further applications are to be described in separate 276 documents. 278 [RFC4875] describes how to setup RSVP-TE P2MP LSPs. On a LAN the 279 solution described in [RFC4875] relies on "ingress replication". A 280 LSR on a LAN (say Il), that is a branch LSR for a P2MP LSP, (say Ru) 281 sends a separate copy of a packet that it receives on the P2MP LSP to 282 each of the downstream LSRs on the LAN (say that are 283 adjacent to it in the P2MP LSP. 285 In order to increase efficiency of bandwidth utilization, it is 286 desirable for Ru to send a single copy of the packet for the P2MP LSP 287 on the LAN, when there are multiple downstream routers on the LAN 288 that are adjacent in that P2MP LSP. This requires that each of 289 must be able to associate the label L, used by Ru to 290 transmit packets for the P2MP LSP on the LAN, with that P2MP LSP. It 291 is possible to achieve this using RSVP-TE upstream-assigned labels 292 with the following procedures. Assume that Ru and support 293 upstream label assignment. 295 Ru sends a Path message for the P2MP LSP to each of that 296 is adjacent on the P2MP LSP, with the same UPSTREAM_ASSIGNED_LABEL 297 object. This object carries an upstream assigned label, L. This 298 message also carries a MPLS Context Label TLV, as described in the 299 previous section, with the value of the MPLS label set to a value 300 assigned by Ru on inteface I1 as specified in [RFC5331]. 301 "reserve" the upstream assigned label in the separate Upstream 302 Neighbor Label Space that they maintain for Ru [RFC5331]. 304 Ru can then transmit a single packet for the P2MP LSP to 305 with a top label L using procedures defined in [RFC5331] and 306 [RFC5332]. The MPLS packet transmitted by Ru contains as the top 307 label the context label assigned by Ru on the LAN interface, I1. The 308 bottom label is the upstream label assigned by Ru to the RSVP-TE P2MP 309 LSP. The top label is looked up in the context of the LAN interface, 310 I1, [RFC5331] by a downstream LSR on the LAN. This lookup enables the 311 downstream LSR to determine the context specific label space to 312 lookup the inner label in. 314 If a subset of do not support upstream label assignment 315 these procedures can still be used between Ru and the remaining 316 subset of . Ingress replication and downstream label 317 assignment will continue to be used for LSRs that do not support 318 upstream label assignment. 320 7. IANA Considerations 322 This document defines a new U flag in the CAPABILITY object defined 323 by [RFC5063]. IANA is requested to assign a new bit to this flag from 324 the 32 bit flags field of the CAPABILITY object. 326 This document defines a new RSVP-TE object, the 327 UPSTREAM_ASSIGNED_LABEL object. The Class-Num for this object comes 328 from the 0bbbbbbb space and IANA is requested to assign this Class- 329 Num. 331 This document defines four new TLVs in the IF_ID RSVP_HOP object 332 [RFC3471]: 334 - RSVP-TE P2MP LSP TLV 336 - LDP P2MP LSP TLV 338 - IP Multicast Tunnel TLV 340 - MPLS Context Label TLV 342 IANA is requested to assign the type values of these TLVs. 344 8. Security Considerations 346 The security considerations discussed in RFC 5331 and RFC 5332 apply 347 to this document. 349 More detailed discussion of security issues that are relevant in the 350 context of MPLS and GMPLS, including security threats, related 351 defensive techniques, and the mechanisms for detection and reporting, 352 are discussed in "Security Framework for MPLS and GMPLS Networks 353 [MPLS-SEC]. 355 9. Acknowledgements 357 Thanks to Yakov Rekhter for his contribution. Thanks to Ina Minei and 358 Thomas Morin for their comments. 360 10. References 362 10.1. Normative References 364 [RFC3031] "MPLS Architecture", E. Rosen, A. Viswanathan, R. Callon, 365 RFC 3031. 367 [RFC5331] R. Aggarwal, Y. Rekhter, E. Rosen, "MPLS Upstream Label 368 Assignment and Context Specific Label Space", draft-ietf-mpls- 369 upstream-label-05.txt 371 [RFC5332] T. Eckert, E. Rosen, R. Aggarwal, Y. Rekhter, draft-ietf- 372 mpls-codepoint-08.txt 374 [RFC3209] Awduche et. al." "RSVP-TE: Extensions to RSVP for LSP 375 Tunnels", RFC 3209, December 2001. 377 [RFC2119] "Key words for use in RFCs to Indicate Requirement 378 Levels.", Bradner, March 1997 380 [RFC3473] Berger, L., Editor, "Generalized Multi-Protocol Label 381 Switching (GMPLS) Signaling - Resource ReserVation Protocol-Traffic 382 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 384 [RFC3471] Berger, L. Editor, "Generalized Multi-Protocol Label 385 Switching (GMPLS) Signaling Functional Description", RFC 3471 January 386 2003. 388 [RFC5063] A. Satyanarayana et. al., "Extensions to GMPLS Resource 389 Reservation Protocol (RSVP) Graceful Restart", RFC5063 391 10.2. Informative References 393 [MVPN] E. Rosen, R. Aggarwal [Editors], "Multicast in BGP/MPLS VPNs", 394 draft-ietf-l3vpn-2547bis-mcast-06.txt 396 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa [Editors], 397 "Extensions to RSVP-TE for Point to Multipoint TE LSPs", RFC 4875 399 [MPLS-SEC] L. fang, ed, "Security Framework for MPLS and GMPLS 400 Networks", draft-ietf-mpls-mpls-and-gmpls-security-framework-07.txt 402 11. Author's Address 404 Rahul Aggarwal 405 Juniper Networks 406 1194 North Mathilda Ave. 407 Sunnyvale, CA 94089 408 Phone: +1-408-936-2720 409 Email: rahul@juniper.net 411 Jean-Louis Le Roux 412 France Telecom 413 2, avenue Pierre-Marzin 414 22307 Lannion Cedex 415 France 416 E-mail: jeanlouis.leroux@orange-ftgroup.com