idnits 2.17.00 (12 Aug 2021) /tmp/idnits14834/draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.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 issues found here. 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 (August 17, 2011) is 3923 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) == Outdated reference: draft-ietf-ccamp-attribute-bnf has been published as RFC 6510 == Outdated reference: draft-ietf-l3vpn-2547bis-mcast has been published as RFC 6513 -- Obsolete informational reference (is this intentional?): RFC 4379 (Obsoleted by RFC 8029) == Outdated reference: draft-ietf-mpls-p2mp-lsp-ping has been published as RFC 6425 Summary: 0 errors (**), 0 flaws (~~), 4 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 MPLS Working Group Z. Ali 2 G. Swallow 3 Internet Draft Cisco Systems, Inc. 4 R. Aggarwal 5 Juniper Networks 6 Intended status: Standard Track August 17, 2011 7 Expires: February 16, 2012 9 Non Penultimate Hop Popping Behavior and out-of-band mapping for 10 RSVP-TE Label Switched Paths 11 draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 13 Status of this Memo 15 This Internet-Draft is submitted in full conformance with the 16 provisions of BCP 78 and BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF). Note that other groups may also distribute 20 working documents as Internet-Drafts. The list of current Internet- 21 Drafts is at http://datatracker.ietf.org/drafts/current/. 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 This Internet-Draft will expire on February 16, 2012. 30 Copyright Notice 32 Copyright (c) 2011 IETF Trust and the persons identified as the 33 document authors. All rights reserved. 35 This document is subject to BCP 78 and the IETF Trust's Legal 36 Provisions Relating to IETF Documents 37 (http://trustee.ietf.org/license-info) in effect on the date of 38 publication of this document. Please review these documents 39 carefully, as they describe your rights and restrictions with respect 40 to this document. Code Components extracted from this document must 41 include Simplified BSD License text as described in Section 4.e of 42 the Trust Legal Provisions and are provided without warranty as 43 described in the Simplified BSD License. 45 Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 47 This document may contain material from IETF Documents or IETF 48 Contributions published or made publicly available before November 49 10, 2008. The person(s) controlling the copyright in some of this 50 material may not have granted the IETF Trust the right to allow 51 modifications of such material outside the IETF Standards Process. 52 Without obtaining an adequate license from the person(s) controlling 53 the copyright in such materials, this document may not be modified 54 outside the IETF Standards Process, and derivative works of it may 55 not be created outside the IETF Standards Process, except to format 56 it for publication as an RFC or to translate it into languages other 57 than English. 59 Abstract 61 There are many deployment scenarios which require Egress Label 62 Switching Router (LSR) to receive binding of the Resource 63 ReserVation Protocol Traffic Engineered (RSVP-TE) Label Switched 64 Path (LSP) to an application, and payload identification, using 65 some "out-of-band" (OOB) mechanism. This document defines 66 protocol mechanisms to address this requirement. The procedures 67 described in this document are equally applicable for point-to- 68 point (P2P) and point-to-multipoint (P2MP) LSPs. 70 Conventions used in this document 72 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 73 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 74 "OPTIONAL" in this document are to be interpreted as described in 75 RFC 2119 [RFC2119]. 77 Table of Contents 79 Copyright Notice ..............................................1 80 1. Introduction ...............................................3 81 2. RSVP-TE signaling extensions ...............................4 82 2.1. Signaling non-PHP behavior ............................4 83 2.2. Signaling OOB Mapping Indication ......................5 84 2.3. Relationship between OOB and non-PHP flags ............7 85 2.4. Egress Procedure for label binding ....................7 86 3. Security Considerations ....................................8 87 4. IANA Considerations ........................................8 88 4.1. Attribute Flags for LSP_ATTRIBUTES object .............8 89 4.2. New RSVP error sub-code ...............................9 91 Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 93 5. Acknowledgments ............................................9 94 6. References .................................................9 95 6.1. Normative References ..................................9 96 6.2. Informative References ...............................10 98 1. Introduction 100 When Resource ReserVation Protocol Traffic Engineered (RSVP-TE) 101 is used for applications like Multicast Virtual Private Network 102 (MVPN) [MVPN] and Virtual Private LAN Service (VPLS) [RFC4761], 103 an Egress Label Switching Router (LSR) receives the binding of 104 the RSVP-TE Label Switched Path (LSP) to an application, and 105 payload identification, using an "out-of-band" (OOB) mechanism 106 (e.g., using Border Gateway Protocol (BGP)). In such cases, the 107 Egress LSR cannot make correct forwarding decision until such OOB 108 mapping information is received. Furthermore, in order to apply 109 the binding information, the Egress LSR needs to identify the 110 incoming LSP on which traffic is coming. Therefore, non 111 Penultimate Hop Popping (non-PHP) behavior is required to apply 112 OOB mapping. Non-PHP behavior requires the egress LSRs to assign 113 a non-NULL label for the LSP being signaled. 115 There are other applications that require non-PHP behavior. When 116 RSVP-TE point-to-multipoint (P2MP) LSPs are used to carry IP 117 multicast traffic non-PHP behavior enables a leaf LSR to identify 118 the P2MP TE LSP, on which traffic is received. Hence the egress 119 LSR can determine whether traffic is received on the expected P2MP 120 LSP and discard traffic that is not received on the expected P2MP 121 LSP. Non-PHP behavior is also required to determine the context of 122 upstream assigned labels when the context is a MPLS LSP. Non-PHP 123 behavior may also be required for MPLS-TP LSPs [RFC5921]. 125 This document defines two new flags in the Attributes Flags TLV 126 of the LSP_ATTRIBUTES object defined in [RFC5420]: one flag for 127 communication of non-PHP behavior, and one flag to indicate that 128 the binding of the LSP to an application and payload identifier 129 (payload-Id) needs to be learned via an out-of-band mapping 130 mechanism. As there is one-to-one correspondence between bits in 131 the Attribute Flags TLV and the RRO Attributes subobject, 132 corresponding flags to be carried in RRO Attributes subobject are 133 also defined. 135 The procedures described in this document are equally applicable 136 for P2P and P2MP LSPs. Specification of the OOB communication 137 mechanism(s) is beyond the scope of this document. 139 Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 141 2. RSVP-TE signaling extensions 143 This section describes the signaling extensions required to 144 address the above-mentioned requirements. 146 2.1. Signaling non-PHP behavior 148 In order to request non-PHP behavior for an RSVP-TE LSP, this 149 document defines a new flag in the Attributes Flags TLV of the 150 LSP_ATTRIBUTES object defined in [RFC5420]: 152 Bit Number (to be assigned by IANA): non-PHP behavior requested flag. 154 In order to indicate to the Ingress LSR that the Egress LSR 155 recognizes the "non-PHP behavior requested flag", the following 156 new bit is defined in the Flags field of the Record Route object 157 (RRO) Attributes subobject: 159 Bit Number (same as bit number assigned for non-PHP behavior 160 requested flag): Non-PHP behavior acknowledgement flag. 162 An Ingress LSR sets the "non-PHP behavior requested flag" to 163 signal the egress LSRs SHOULD assign non-NULL label for the LSP 164 being signaled. This flag MUST NOT be modified by any other LSRs 165 in the network. LSRs other than the Egress LSRs SHOULD ignore 166 this flag. 168 If an egress LSR receiving the Path message, supports the 169 LSP_ATTRIBUTES object and the Attributes Flags TLV, and also 170 recognizes the "non-PHP behavior requested flag", it MUST 171 allocate a non-NULL local label. The egress LSR MUST also set the 172 "Non-PHP behavior acknowledgement flag" in the Flags field of the 173 RRO Attribute subobject. 175 If the egress LSR 177 - supports the LSP_ATTRIBUTES object but does not recognize the 178 Attributes Flags TLV; or 180 - supports the LSP_ATTRIBUTES object and recognize the Attributes 181 Flags TLV, but does not recognize the "non-PHP behavior requested 182 flag"; 184 Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 186 then it silently ignores this request according to the processing 187 rules of [RFC5420]. 189 An ingress LSR requesting non-PHP behavior SHOULD examine "Non- 190 PHP behavior acknowledgement flag" in the Flags field of the RRO 191 Attribute subobject and MAY send a Path Tear to the Egress which 192 has not set the "Non-PHP behavior acknowledgement flag". An 193 ingress LSR requesting non-PHP behavior MAY also examine the 194 label value corresponding to the Egress LSR(s) in the RRO, and 195 MAY send a Path Tear to the Egress which assigns a Null label 196 value. 198 When signaling a P2MP LSP, a source node may wish to solicit 199 individual response to the "non-PHP behavior requested flag" from 200 the leaf nodes. Given the constraints on how the LSP_ATTRIBUTES may 201 be carried in Path and Resv Messages according to RFC5420, in 202 this situation the source node MUST use a separate Path message for 203 each leaf in networks where [ATTRIBUTE-BNF] is not supported. In 204 networks with [ATTRIBUTE-BNF] deployed either separate Path 205 message for each leaf or multiple leafs per Path message MAY be 206 used by the source node. 208 2.2. Signaling OOB Mapping Indication 210 This document defines a single flag to indicate that the normal 211 binding mechanism of an RSVP session is overridden. The actual 212 out-of-band mappings are beyond the scope of this document. The 213 flag is carried in the Attributes Flags TLV of the LSP_ATTRIBUTES 214 object defined in [RFC5420] and is defined as follows: 216 Bit Number (to be assigned by IANA): OOB mapping indication flag. 218 In order to indicate to the Ingress LSR that the Egress LSR 219 recognizes the "OOB mapping indication flag", the following new 220 bit is defined in the Flags field of the Record Route object 221 (RRO) Attributes subobject: 223 Bit Number (same as bit number assigned for OOB mapping 224 indication flag): OOB mapping acknowledgement flag. 226 Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 228 An Ingress LSR sets the OOB mapping indication flag to signal the 229 Egress LSR that binding of RSVP-TE LSP to an application and 230 payload identification is being signaled out-of-band. This flag 231 MUST NOT be modified by any other LSRs in the network. LSRs 232 other than the Egress LSRs SHOULD ignore this flag. 234 When an Egress LSR which supports the "OOB mapping indication 235 flag", receives a Path message with that flag set, the Egress LSR 236 MUST set the "OOB mapping acknowledgement flag" in the Flags 237 field of the RRO Attribute subobject. The rest of the RSVP 238 signaling proceeds as normal. However, the LSR MUST have 239 received the OOB mapping before accepting traffic on the LSP. 240 This implies that the Egress LSR MUST NOT setup forwarding state 241 for the LSP before it receives the OOB mapping. 243 Note that the payload information SHOULD be supplied by the OOB 244 mapping. If the egress LSR receives the payload information from 245 OOB mapping then the LSR MUST ignore L3PID in the Label Request 246 Object [RFC3209]. 248 If the egress LSR 250 - supports the LSP_ATTRIBUTES object but does not recognize the 251 Attributes Flags TLV; or 253 - supports the LSP_ATTRIBUTES object and recognizes the 254 Attributes Flags TLV, but does not recognize the "OOB mapping 255 indication flag"; 257 then it silently ignores this request according to the processing 258 rules of [RFC5420]. 260 An ingress LSR requesting OOB mapping SHOULD examine "OOB mapping 261 acknowledgement flag" in the Flags field of the RRO Attribute 262 subobject and MAY send a Path Tear to the Egress which has not 263 set the "OOB mapping acknowledgement flag". 265 When signaling a P2MP LSP, a source node may wish to solicit 266 individual response to the "OOB mapping indication flag" from the 267 the leaf nodes. Given the constraints on how the LSP_ATTRIBUTES 268 may be carried in Path and Resv Messages according to RFC5420, in 269 this situation the source node MUST use a separate Path message for 270 each leaf in networks where [ATTRIBUTE-BNF] is not supported. In 271 Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 273 networks with [ATTRIBUTE-BNF] deployed either separate Path 274 message for each leaf or multiple leafs per Path message MAY be 275 used by the source node. 277 In deploying applications where Egress LSR receives the binding 278 of the RSVP-TE LSP to an application, and payload identification, 279 using OOB mechanism, it is important to recognize that the OOB 280 mapping is sent asynchronously with respect to the signaling of 281 RSVP-TE LSP. Egress LSR only installs forwarding state for the LSP 282 after it receives the OOB mapping. In deploying applications using 283 OOB mechanism, an Ingress LSR may need to know when the Egress is 284 properly setup for forwarding (i.e., has received the OOB mapping). 285 How the Ingress LSR determines that the LSR is properly setup for 286 forwarding at the Egress LSR is beyond the scope of this document. 287 Nonetheless, if the OOB mapping is not received by the Egress LSR 288 within a reasonable time, the procedure defined in section 2.4 to 289 tear down the LSP is followed. 291 2.3. Relationship between OOB and non-PHP flags 293 "Non-PHP behavior desired" and "OOB mapping indication" flags can 294 appear and be processed independently of each other. However, as 295 mentioned earlier, in the context of the applications discussed in 296 this document, OOB mapping requires non-PHP behavior. An Ingress 297 LSR requesting the OOB mapping MAY also set the "non-PHP behavior 298 requested flag" in the LSP_ATTRIBUTES object in the Path message. 300 2.4. Egress Procedure for label binding 302 RSVP-TE signaling completion and the OOB mapping information 303 reception happen asynchronously at the Egress. As mentioned in 304 Section 2.2, Egress waits for the OOB mapping before accepting 305 traffic on the LSP. Nonetheless, MPLS OAM mechanisms, e.g., LSP 306 Ping and Trace route as defined in [RFC4379], [P2MP-OAM], are 307 expected to work independent of OOB mapping learning process. 309 In order to avoid unnecessary use of the resources and possible 310 black-holing of traffic, an Egress LSR MAY send a Path Error 311 message if the OOB mapping information is not received within a 312 reasonable time. This Path Error message SHOULD include the error 313 code/sub-code "Notify Error/ no OOB mapping received" for all 314 affected LSPs. If notify request was included when the LSP was 315 initially setup, Notify message (as defined in [RFC3473]) MAY 316 also be used for delivery of this information to the Ingress LSR. 317 An Egress LSR MAY implement a cleanup timer for this purpose. The 318 Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 320 time-out value is a local decision at the Egress, with a 321 RECOMMENDED default value of 60 seconds. 323 3. Security Considerations 325 Addition of "non-PHP behavior" adds a variable of attacks on the 326 label assigned by the Egress node. As change in the value of the 327 egress label reported in the RRO can cause the LSP to be torn 328 down, additional security considerations for protecting label 329 assigned by the Egress node are required. Security mechanisms as 330 identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], 331 [RFC5420] and [RFC4875] can be used for this purpose. This 332 document does not introduce any additional security issues above 333 those identified in [RFC5920], [RFC2205], [RFC3209], [RFC3473], 334 [RFC5420] and [RFC4875]. 336 4. IANA Considerations 338 The following changes to the Resource Reservation Protocol-Traffic 339 Engineering (RSVP-TE) Parameters registry are required. 341 4.1. Attribute Flags for LSP_ATTRIBUTES object 343 The following new flags are defined for the Attributes Flags TLV 344 in the LSP_ATTRIBUTES object. The numeric values are to be 345 assigned by IANA. 346 o Non-PHP behavior flag: 347 This flags is used in the Attributes Flags TLV in a Path message. 348 The flags have corresponding new flag to be used in the RRO 349 Attributes subobject. As per [RFC5420], the bit numbering in the 350 Attribute Flags TLV and the RRO Attributes subobject is 351 identical. That is, the same attribute is indicated by the same 352 bit in both places. This flag is not allowed in the Attributes 353 Flags TLV in a Resv message. Specifically, Attributes of this 354 flag are as follows: 356 - Bit Number: To be assigned by IANA. 358 - Attribute flag carried in Path message: Yes 360 - Attribute flag carried in Resv message: No 362 - Attribute flag carried in RRO message: Yes 364 Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 366 o OOB mapping flag: 368 This flags is used in the Attributes Flags TLV in a Path message. 369 The flags have corresponding new flag to be used in the RRO 370 Attributes subobject. As per [RFC5420], the bit numbering in the 371 Attribute Flags TLV and the RRO Attributes subobject is 372 identical. That is, the same attribute is indicated by the same 373 bit in both places. This flag is not allowed in the Attributes 374 Flags TLV in a Resv message. Specifically, Attributes of this 375 flag are as follows: 377 - Bit Number: To be assigned by IANA. 379 - Attribute flag carried in Path message: Yes 381 - Attribute flag carried in Resv message: No 383 - Attribute flag carried in RRO message: Yes 385 4.2. New RSVP error sub-code 387 For Error Code = 25 "Notify Error" (see [RFC3209]) the following 388 sub-code is defined. 390 Sub-code Value 391 -------- ----- 393 No OOB mapping received to be assigned by IANA. 395 5. Acknowledgments 397 The authors would like to thank Yakov Rekhter for his suggestions 398 on the draft. 400 6. References 402 6.1. Normative References 404 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 405 Requirement Levels", BCP 14, RFC 2119, March 1997. 407 Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 409 [RFC5420] A. Farrel, D. Papadimitriou, J. P. Vasseur and A. 410 Ayyangar, "Encoding of Attributes for Multiprotocol 411 Label Switching (MPLS) Label Switched Path (LSP) 412 Establishment Using RSVP-TE", RFC 5420, February 2006. 414 [RFC3209] D. Awduche, L. Berger, D. Gan, T. Li, V. Srinivasan, 415 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 416 Tunnels", RFC 3209, December 2001. 418 [RFC4875] R. Aggarwal, D. Papadimitriou, S. Yasukawa, et al, 419 "Extensions to RSVP-TE for Point-to-Multipoint TE 420 LSPs", RFC 4875. 422 [RFC3473] Berger, L., Ed., "Generalized Multi-Protocol Label 423 Switching (GMPLS) Signaling Resource ReserVation 424 Protocol-Traffic Engineering (RSVP-TE) Extensions", RFC 425 3473, January 2003.. 427 [RFC2205] R. Braden, Ed., "Resource ReSerVation Protocol (RSVP) - 428 - Version 1 Functional Specification", RFC 2205, 429 September 1997. 431 [ATTRIBUTE-BNF] Berger, L. and Swallow, G., "LSP Attributes Related 432 Routing Backus-Naur Form", draft-ietf-ccamp-attribute- 433 bnf, work in progress. 435 6.2. Informative References 437 [MVPN] E. Rosen, R. Aggarwal et al, "Multicast in MPLS/BGP IP 438 VPNs", draft-ietf-l3vpn-2547bis-mcast-10.txt, work in 439 progress. 441 [RFC4761] Kompella, K., Ed., and Y. Rekhter, Ed., "Virtual 442 Private LAN Service (VPLS) Using BGP for Auto-Discovery 443 and Signaling", RFC 4761, January 2007. 445 [RFC5921] M. Bocci, S. Bryant, et al, "A Framework for 446 MPLS in Transport Networks", RFC 5921, January 2007. 448 [RFC5920] L. Fang, Ed., "Security Framework for MPLS and GMPLS 449 Networks", RFC 5920, July 2010. 451 Internet-Draft draft-ietf-mpls-rsvp-te-no-php-oob-mapping-09.txt 453 [RFC4379] K. Kompella, and G. Swallow, "Detecting Multi-Protocol 454 Label Switched (MPLS) Data Plane Failures", RFC 4379, 455 February 2006. 456 [P2MP-OAM] S. Saxena, Ed., G. Swallow, Z. Ali, A. Farrel, S. 457 Yasukawa, T. Nadeau, "Detecting Data Plane Failures in 458 Point-to-Multipoint Multiprotocol Label Switching 459 (MPLS) - Extensions to LSP Ping", draft-ietf-mpls-p2mp- 460 lsp-ping-17.txt, work in progress. 462 Author's Addresses 464 Zafar Ali 465 Cisco Systems, Inc. 466 Email: zali@cisco.com 468 George Swallow 469 Cisco Systems, Inc. 470 Email: swallow@cisco.com 472 Rahul Aggarwal 473 Juniper Networks 474 rahul@juniper.net