idnits 2.17.1 draft-ietf-teas-p2mp-loose-path-reopt-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 date (February 2, 2017) is 2638 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) ** Downref: Normative reference to an Informational RFC: RFC 4736 Summary: 1 error (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group T. Saad, Ed. 3 Internet-Draft R. Gandhi, Ed. 4 Intended status: Standards Track Z. Ali 5 Expires: August 6, 2017 Cisco Systems, Inc. 6 R. Venator 7 Defense Information Systems Agency 8 Y. Kamite 9 NTT Communications Corporation 10 February 2, 2017 12 RSVP Extensions For Re-optimization of Loosely Routed 13 Point-to-Multipoint Traffic Engineering Label Switched Paths (LSPs) 14 draft-ietf-teas-p2mp-loose-path-reopt-09 16 Abstract 18 Re-optimization of a Point-to-Multipoint (P2MP) Traffic Engineered 19 (TE) Label Switched Path (LSP) may be triggered based on the need to 20 re-optimize an individual source-to-leaf (S2L) sub-LSP or a set of 21 S2L sub-LSPs, both using Sub-Group-Based Re-optimization method, or 22 the entire P2MP-TE LSP tree using the Make-Before-Break (MBB) method. 23 This document discusses the application of the existing mechanisms 24 for path re-optimization of loosely routed Point-to-Point (P2P) TE 25 LSPs to the P2MP-TE LSPs, identifies issues in doing so and defines 26 procedures to address them. When re-optimizing a large number of S2L 27 sub-LSPs in a tree using the Sub-Group-Based Re-optimization method, 28 the S2L sub-LSP descriptor list may need to be semantically 29 fragmented. This document defines the notion of a fragment 30 identifier to help recipient nodes unambiguously reconstruct the 31 fragmented S2L sub-LSP descriptor list. 33 Status of this Memo 35 This Internet-Draft is submitted in full conformance with the 36 provisions of BCP 78 and BCP 79. 38 Internet-Drafts are working documents of the Internet Engineering 39 Task Force (IETF). Note that other groups may also distribute 40 working documents as Internet-Drafts. The list of current Internet- 41 Drafts is at http://datatracker.ietf.org/drafts/current/. 43 Internet-Drafts are draft documents valid for a maximum of six months 44 and may be updated, replaced, or obsoleted by other documents at any 45 time. It is inappropriate to use Internet-Drafts as reference 46 material or to cite them other than as "work in progress." 48 Copyright Notice 50 Copyright (c) 2017 IETF Trust and the persons identified as the 51 document authors. All rights reserved. 53 This document is subject to BCP 78 and the IETF Trust's Legal 54 Provisions Relating to IETF Documents 55 (http://trustee.ietf.org/license-info) in effect on the date of 56 publication of this document. Please review these documents 57 carefully, as they describe your rights and restrictions with respect 58 to this document. Code Components extracted from this document must 59 include Simplified BSD License text as described in Section 4.e of 60 the Trust Legal Provisions and are provided without warranty as 61 described in the Simplified BSD License. 63 Table of Contents 65 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 66 2. Conventions Used in This Document . . . . . . . . . . . . . . 4 67 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 4 68 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 5 69 2.3. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree . . . . . . . 6 72 3.2. Existing Mechanism For Tree-Based P2MP-TE LSP 73 Re-optimization . . . . . . . . . . . . . . . . . . . . . 6 74 3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP 75 Re-optimization . . . . . . . . . . . . . . . . . . . . . 7 76 4. Signaling Extensions For Loosely Routed P2MP-TE LSP 77 Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 8 78 4.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 8 79 4.2. Sub-Group-Based Re-optimization Using Fragment 80 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9 81 5. Message and Object Definitions . . . . . . . . . . . . . . . . 11 82 5.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 11 83 5.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 11 84 5.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 11 85 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 12 86 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 87 7.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 13 88 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 13 89 7.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 14 90 8. Security Considerations . . . . . . . . . . . . . . . . . . . 14 91 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 92 9.1. Normative References . . . . . . . . . . . . . . . . . . . 16 93 9.2. Informative References . . . . . . . . . . . . . . . . . . 16 94 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 17 95 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 97 1. Introduction 99 This document defines Resource Reservation Protocol - Traffic 100 Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for 101 re-optimizing loosely routed Point-to-Multipoint (P2MP) Traffic 102 Engineered (TE) Label Switched Paths (LSPs) [RFC4875] in a 103 Multi-Protocol Label Switching (MPLS) or Generalized MPLS (GMPLS) 104 [RFC3473] network. 106 A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L) 107 sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one 108 whose path does not contain the full explicit route identifying each 109 node along the path to the egress node at the time of its signaling 110 by the ingress node. Such an S2L sub-LSP is signaled with no 111 Explicit Route Object (ERO) [RFC3209], or with an ERO that contains 112 at least one loose next-hop, or with an ERO that contains an abstract 113 node which identifies more than one node. This is often the case 114 with inter-domain P2MP-TE LSPs where Path Computation Element (PCE) 115 is not used [RFC5440]. 117 As per [RFC4875], an ingress node may re-optimize the entire P2MP-TE 118 LSP tree by re-signaling all its S2L sub-LSP(s) using the 119 Make-Before-Break (MBB) method or may re-optimize individual S2L sub- 120 LSP or a set of S2L sub-LSPs i.e. individual destination or a set of 121 destinations, both using the Sub-Group-Based Re-optimization method. 123 [RFC4736] defines RSVP signaling procedure for re-optimizing the 124 path(s) of loosely routed Point-to-Point (P2P) TE LSP(s). Those 125 mechanisms include a method for the ingress node to trigger a new 126 path re-evaluation request and a method for the mid-point node to 127 notify availability of a preferred path. This document discusses the 128 application of those mechanisms to the re-optimization of loosely 129 routed P2MP-TE LSPs, identifies issues in doing so and defines 130 procedures to address them. 132 For re-optimizing a group of S2L sub-LSPs in a tree using the Sub- 133 Group-Based Re-optimization method, an S2L sub-LSP descriptor list 134 can be used to signal one or more S2L sub-LSPs in an RSVP message. 135 This RSVP message may need to be semantically fragmented when large 136 number of S2L sub-LSPs are added to the descriptor list. This 137 document defines the notion of a fragment identifier to help 138 recipient nodes unambiguously reconstruct the fragmented S2L sub-LSP 139 descriptor list. 141 2. Conventions Used in This Document 143 2.1. Key Word Definitions 144 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 145 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 146 document are to be interpreted as described in [RFC2119]. 148 2.2. Abbreviations 150 ABR: Area Border Router. 152 AS: Autonomous System. 154 ERO: Explicit Route Object. 156 LSR: Label Switching Router. 158 S2L sub-LSP: Source-to-leaf sub Label Switched Path. 160 TE LSP: Traffic Engineering Label Switched Path. 162 TE LSP ingress: Head-end/source node of the TE LSP. 164 TE LSP egress: Tail-end/destination node of the TE LSP. 166 2.3. Terminology 168 The reader is assumed to be familiar with the terminology in 169 [RFC4736] and [RFC4875]. 171 3. Overview 173 [RFC4736] defines RSVP signaling extensions for re-optimizing loosely 174 routed P2P TE LSPs as follows: 176 o A mid-point LSR that expands loose next-hop(s) sends a solicited 177 or unsolicited PathErr with the Notify error code 25 (as defined 178 in [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists" 179 to the ingress node. 181 o An ingress node triggers a path re-evaluation request at all 182 mid-point LSR(s) that expands loose next-hop(s) by setting the 183 "Path Re-evaluation Request" flag (0x20) in SESSION_ATTRIBUTES 184 Object in the Path message. 186 o The ingress node upon receiving this PathErr with the Notify error 187 code either solicited or unsolicited initiates re-optimization of 188 the LSP using the MBB method with a different LSP-ID. 190 The following sections discuss the issues that may arise when 191 applying the mechanisms defined in [RFC4736] for re-optimizing 192 loosely routed P2MP-TE LSPs. 194 3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree 196 An example of a loosely routed inter-domain P2MP-TE LSP tree is shown 197 in Figure 1. In this example, the P2MP-TE LSP tree consists of 3 S2L 198 sub-LSPs, to destinations (i.e. leafs) R10, R11 and R12 from the 199 ingress node (i.e. source) R1. Nodes R2 and R5 are branch nodes and 200 nodes ABR3, ABR4, ABR7, ABR8 and ABR9 are area border routers. For 201 the S2L sub-LSP to destination R10, nodes ABR3, ABR7 and R10 are 202 defined as loose next-hops. For the S2L sub-LSP to destination R11, 203 nodes ABR3, ABR8 and R11 are defined as loose next-hops. For the S2L 204 sub-LSP to destination R12, nodes ABR4, ABR9 and R12 are defined as 205 loose next-hops. 207 <--area1--><--area0--><-area2-> 209 ABR7---R10 210 / 211 / 212 ABR3---R5 213 / \ 214 / \ 215 R1---R2 ABR8---R11 216 \ 217 \ 218 ABR4---R6 219 \ 220 \ 221 ABR9---R12 223 Figure 1: An Example of Loosely Routed Inter-domain P2MP-TE LSP Tree 225 3.2. Existing Mechanism For Tree-Based P2MP-TE LSP Re-optimization 227 Mechanisms defined in [RFC4736] can be easily applied to trigger the 228 re-optimization of individual or group of S2L sub-LSP(s). However, 229 to apply these [RFC4736] mechanisms for triggering the 230 re-optimization of a P2MP-TE LSP tree, an ingress node needs to send 231 path re-evaluation requests on all (typically 100s of) S2L sub-LSPs 232 and the mid-point LSR needs to send PathErrs with the Notify error 233 code for all S2L sub-LSPs. Such mechanisms may lead to the following 234 issues: 236 o A mid-point LSR that expands loose next-hop(s) may have to 237 accumulate the received path re-evaluation request(s) for all S2L 238 sub-LSPs (e.g. by using a wait timer) and interpret them as a 239 re-optimization request for the whole P2MP-TE LSP tree. 240 Otherwise, a mid-point LSR may prematurely notify "Preferable Path 241 Exists" for one or a sub-set of S2L sub-LSPs. 243 o Similarly, the ingress node may have to heuristically determine 244 when to perform P2MP-TE LSP tree re-optimization and when to 245 perform S2L sub-LSP re-optimization. For example, an 246 implementation may choose to delay re-optimization long enough to 247 allow all PathErr(s) to be received. Such timer-based procedures 248 may produce undesired results. 250 o The ingress node that receives (un)solicited PathErr(s) with the 251 Notify error code for individual S2L sub-LSP(s), may prematurely 252 start re-optimizing the sub-set of S2L sub-LSPs. However, as 253 mentioned in [RFC4875] Section 14.2, such sub-group based re- 254 optimization procedure may result in data duplication that can be 255 avoided if the entire P2MP-TE LSP tree is re-optimized using the 256 Make-Before-Break method with a different LSP-ID, especially if 257 the ingress node eventually receives PathErrs with the Notify 258 error code for all S2L sub-LSPs of the P2MP-TE LSP tree. 260 In order to address above mentioned issues and to align 261 re-optimization of P2MP-TE LSP with P2P LSP [RFC4736], there is a 262 need for a mechanism to trigger re-optimization of the LSP tree by 263 re-signaling all S2L sub-LSPs with a different LSP-ID. To meet this 264 requirement, this document defines RSVP-TE signaling extensions for 265 the ingress node to trigger the re-evaluation of the P2MP LSP tree on 266 every hop that has a next-hop defined as a loose or abstract hop for 267 one or more S2L sub-LSP path, and a mid-point LSR to signal to the 268 ingress node that a preferable LSP tree exists (compared to the 269 current path) or that the whole P2MP-TE LSP must be re-optimized 270 (because of maintenance required on the TE LSP path) (see Section 271 4.1). 273 3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP Re-optimization 275 Applying the procedures discussed in RFC4736 in conjunction with the 276 Sub-Group-Based Re-Optimization procedures ([RFC4875], Section 14.2), 277 an ingress node MAY trigger path re-evaluation requests for a set of 278 S2L sub-LSPs in a single Path message using S2L sub-LSP descriptor 279 list. Similarly, a mid-point LSR may send a PathErr with the Notify 280 error code 25 and sub-code 6 containing a list of S2L sub-LSPs 281 transiting through the LSR using an S2L sub-LSP descriptor list to 282 notify the ingress node. This method can be used for re-optimizing a 283 sub-group of S2L sub-LSPs within an LSP tree using the same LSP-ID. 285 This method can alleviate the scale issue associated with sending 286 RSVP messages for individual S2L sub-LSPs. However, this procedure 287 can lead to the following issues when used to re-optimize the LSP 288 tree: 290 o Path message that is intended to carry the path re-evaluation 291 request as defined in [RFC4736] with a full list of S2L sub-LSPs 292 in S2L sub-LSPs descriptor list will be decomposed at branching 293 LSRs, and only a subset of the S2L sub-LSPs that are routed over 294 the same next-hop will be added in the descriptor list of the Path 295 message propagated to downstream mid-point LSRs. Consequently, 296 when a preferable path exists at such mid-point LSRs, the PathErr 297 with the Notify error code can only include the sub-set of S2L 298 sub-LSPs traversing the LSR. In this case, at the ingress node 299 there is no way to distinguish which mode of re-optimization to 300 invoke, i.e. sub-group based re-optimization using the same LSP-ID 301 or tree based re-optimization using a different LSP-ID. 303 o An LSR may semantically fragment a large RSVP message (when a 304 combined message may not be large enough to fit all S2L sub-LSPs). 305 In this case, the ingress node may receive multiple PathErrs with 306 sub-sets of S2L sub-LSPs in each (due to either the combined Path 307 message getting fragmented or the combined PathErr message getting 308 fragmented) and would require additional logic to determine how to 309 re-optimize the LSP tree (for example, waiting for some time to 310 aggregate all possible PathErr messages before taking an action). 311 When fragmented, RSVP messages may arrive out of order, and the 312 receiver has no way of knowing the beginning and end of the S2L 313 sub-LSP list. 315 In order to address the above mentioned issues caused by RSVP message 316 semantic fragmentation, this document defines new fragment identifier 317 object for the S2L sub-LSP descriptor list when combining large 318 number of S2L sub-LSPs in an RSVP message (see Section 4.2). 320 4. Signaling Extensions For Loosely Routed P2MP-TE LSP Re-optimization 322 4.1. Tree-Based Re-optimization 324 To evaluate a P2MP-TE LSP tree on mid-point LSRs that expand loose 325 next-hop(s), an ingress node MAY send a Path message with "P2MP-TE 326 Tree Re-evaluation Request (value TBA1)" defined in this document. 327 The ingress node selects one of the S2L sub-LSPs of the P2MP-TE LSP 328 tree transiting a mid-point LSR to trigger the re-evaluation request. 329 The ingress node MAY send a re-evaluation request to each border LSR 330 on the path of the LSP tree. 332 A mid-point LSR that expands loose next-hop(s) for one or more S2L 333 sub-LSP path(s) does the following upon receiving a Path message with 334 the "P2MP-TE Tree Re-evaluation Request" flag set: 336 o The mid-point LSR MUST check for a preferable P2MP-TE LSP tree by 337 re-evaluating all S2L sub-LSP(s) that are expanded paths of the 338 loose next-hops of the P2MP-TE LSP. 340 o If a preferable P2MP-TE LSP tree is found, the mid-point LSR MUST 341 send an RSVP PathErr with the Notify error code 25 defined in 342 [RFC3209] and sub-code "Preferable P2MP-TE Tree Exists (value 343 TBA2)" defined in this document to the ingress node. The mid- 344 point LSR, in turn, SHOULD NOT propagate the "P2MP-TE Tree Re- 345 evaluation Request" flag in the subsequent RSVP Path messages sent 346 downstream for the re-evaluated P2MP-TE LSP. 348 o If no preferable tree for P2MP-TE LSP can be found, the mid-point 349 LSR that expands loose next-hop(s) for one or more S2L sub-LSP 350 path(s) MUST propagate the request downstream by setting the 351 "P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES 352 Object of the RSVP Path message. 354 A mid-point LSR MAY send an unsolicited PathErr with the Notify error 355 code and sub-code "Preferable P2MP-TE Tree Exists" to the ingress 356 node to notify of a preferred P2MP-TE LSP tree when it determines it 357 exists. In this case, the mid-point LSR that expands loose next- 358 hop(s) for one or more S2L sub-LSP path(s) selects one of the S2L 359 sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to 360 the ingress node. The mid-point LSR SHOULD consider how frequently 361 it chooses to send such a PathErr - considering both that a PathErr 362 may be lost on its transit to the ingress node and that the ingress 363 node may choose not to re-optimize the LSP when such a PathErr is 364 received. 366 The sending of an RSVP PathErr with the Notify error code and 367 "Preferable P2MP-TE Tree Exists" sub-code to the ingress node 368 notifies the ingress node of the existence of a preferable P2MP-TE 369 LSP tree and upon receiving this PathErr, the ingress node SHOULD 370 trigger re-optimization of the LSP using the MBB method with a 371 different LSP-ID. 373 4.2. Sub-Group-Based Re-optimization Using Fragment Identifier 375 It might be preferable, as per [RFC4875], to re-optimize the entire 376 P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1, 377 "Make-before-Break") or to re-optimize individual or group of S2L 378 sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2 379 "Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same 380 LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved by 381 using the procedures defined in [RFC4736] to re-optimize one or more 382 S2L sub-LSP(s) of the P2MP-TE LSP. 384 An ingress node may trigger path re-evaluation requests using the 385 procedures defined in [RFC4736] for a set of S2L sub-LSPs by 386 combining multiple Path messages using an S2L sub-LSP descriptor list 387 [RFC4875]. An S2L sub-LSP descriptor list is created using a series 388 of S2L_SUB_LSP Objects as defined in [RFC4875]. Similarly, a mid- 389 point LSR may send a PathErr with the Notify error code (value 25) 390 and "Preferable Path Exists" (sub-code 6) containing a list of S2L 391 sub-LSPs transiting through the LSR using an S2L sub-LSP descriptor 392 list to notify the ingress node of preferable paths available. 394 As per [RFC4875] (Section 5.2.3, "Transit Fragmentation of Path State 395 Information"), when a Path message is not large enough to fit all S2L 396 sub-LSPs in the descriptor list, an LSR may semantically fragment the 397 message. In this case, the LSR MUST add the S2L_SUB_LSP_FRAG Object 398 defined in this document in the S2L sub-LSP descriptor to be able to 399 rebuild the list from the received fragments that may arrive out of 400 order. 402 The S2L_SUB_LSP_FRAG Object defined in this document is optional. 403 However, a node MUST add the S2L_SUB_LSP_FRAG Object for each 404 fragment in S2L sub-LSP descriptor when the RSVP message needs to be 405 fragmented. 407 A mid-point LSR SHOULD wait to accumulate all S2L sub-LSPs before 408 attempting to re-evaluate preferable path when a Path message for 409 "Path Re-evaluation Request" is received with S2L_SUB_LSP_FRAG 410 Object. If a mid-point LSR does not receive all fragments of the 411 Path message (for example, when fragments are lost) within a 412 configurable time interval, it SHOULD trigger re-evaluation of all 413 S2L sub-LSPs of the P2MP-TE LSP transiting on the node. A mid-point 414 LSR MUST receive at least one fragment of the Path message to trigger 415 this behaviour. 417 An ingress node SHOULD wait to accumulate all S2L sub-LSPs before 418 attempting to trigger re-optimization when a PathErr with Notify 419 error code and "Preferable Path Exists" sub-code is received with a 420 S2L_SUB_LSP_FRAG Object. If an ingress node does not receive all 421 fragments of the PathErr message (for example, when fragments are 422 lost) within a configurable time interval, it SHOULD trigger re- 423 optimization of all S2L sub-LSPs of the P2MP-TE LSP transiting on the 424 mid-point node that had sent the PathErr message. An ingress node 425 MUST receive at least one fragment of the PathErr message to trigger 426 this behaviour. 428 The S2L_SUB_LSP_FRAG Object defined in this document has a wider 429 applicability in addition to the P2MP-TE LSP re-optimization. It can 430 also be used (in Path and Resv messages) to setup a new P2MP-TE LSP, 431 send other PathErr messages as well as Path Tear and Resv Tear 432 messages for a set of S2L sub-LSPs. This is outside the scope of 433 this document. 435 5. Message and Object Definitions 437 5.1. P2MP-TE Tree Re-evaluation Request Flag 439 In order to trigger a tree re-evaluation request, a new flag is 440 defined in Attributes Flags TLV of the LSP_ATTRIBUTES Object 441 [RFC5420] as follows: 443 Bit Number (TBA1, to be assigned by IANA): P2MP-TE Tree 444 Re-evaluation Request flag 446 The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path 447 message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node 448 using the message format defined in [RFC6510]. 450 5.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 452 In order to indicate to an ingress node that a preferable P2MP-TE LSP 453 tree exists, the following new sub-code for PathErr with Notify error 454 code 25 [RFC3209] is defined: 456 Sub-code (TBA2, to be assigned by IANA): Preferable P2MP-TE Tree 457 Exists sub-code 459 When a preferable path for P2MP-TE LSP tree exists, the mid-point LSR 460 sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" 461 sub-code with PathErr with Notify error code 25 to the ingress node 462 of the P2MP-TE LSP. 464 5.3. Fragment Identifier For S2L sub-LSP Descriptor 466 The S2L_SUB_LSP Object [RFC4875] identifies a particular S2L sub-LSP 467 belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is 468 created using a series of S2L_SUB_LSP Objects as defined in 469 [RFC4875]. The RSVP message may need to be semantically fragmented 470 [RFC4875] due to large number of S2L sub-LSPs added in the descriptor 471 list, and such fragments may be received our of order. To be able to 472 rebuild the fragmented S2L sub-LSP descriptor list correctly, the 473 following Object is defined to identify the fragments. 475 S2L_SUB_LSP_FRAG: Class-Num TBA3 by IANA 477 +---------------+---------------+---------------+---------------+ 478 | Length (8 bytes) | Class-Num TBA3| C-Type 1 | 479 +---------------+---------------+---------------+---------------+ 480 | Fragment ID | Fragments Tot | Fragment Num | 481 +---------------+---------------+---------------+---------------+ 483 Fragment ID: 16-bit integer in the range of 1 to 65535. 485 This value is incremented for each new RSVP message that needs to 486 be semantically fragmented. The fragment ID is reset to 1 when it 487 reaches the maximum value of 65535. The scope of the fragment ID 488 is limited to the RSVP message type (e.g. Path) carrying the 489 fragment. In other words, fragment IDs do not have any 490 correlation between different RSVP message types (e.g. Path and 491 PathErr). The receiver does not check to ensure if the 492 consecutive new RSVP messages (e.g. Path messages) are received 493 with fragment IDs incremented by 1. 495 Fragments Total: 8-bit integer in the range of 1 to 255. 497 This value indicates the number of fragments sent for the given 498 RSVP message. This value MUST be the same in all fragmented RSVP 499 messages with a common Fragment ID. 501 Fragment Number: 8-bit integer in the range of 1 to 255. 503 This value indicates the position of this fragment in the given 504 RSVP message. 506 The format of an S2L sub-LSP descriptor message is as follows: 508 ::= 509 [ ] 510 511 [ ] 513 The S2L_SUB_LSP_FRAG Object is added before adding the S2L_SUB_LSP 514 Object in the semantically fragmented RSVP message. 516 6. Compatibility 517 The LSP_ATTRIBUTES Object has been defined in [RFC5420] and its 518 message formats in [RFC6510] with class numbers in the form 11bbbbbb, 519 which ensures compatibility with non-supporting nodes. Per 520 [RFC2205], nodes not supporting this extension will ignore the new 521 flag defined for this Object in this document but forward it without 522 modification. 524 The S2L_SUB_LSP_FRAG Object has been defined with class numbers in 525 the form 11bbbbbb, which ensures compatibility with non-supporting 526 nodes. Per [RFC2205], nodes not supporting this Object will ignore 527 the Object but forward it without modification. 529 7. IANA Considerations 531 IANA is requested to administer assignment of new values for 532 namespace defined in this document and summarized in this section. 534 7.1. P2MP-TE Tree Re-evaluation Request Flag 536 IANA maintains a name space for RSVP-TE TE parameters "Resource 537 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" (see 538 http://www.iana.org/assignments/rsvp-te-parameters). From the 539 registries in this name space "Attribute Flags", allocation of new 540 flag is requested (Section 5.1). 542 The following new flag is defined for the Attributes Flags TLV in the 543 LSP_ATTRIBUTES Object [RFC5420]. The numeric value is to be assigned 544 by IANA. 546 o P2MP-TE Tree Re-evaluation Request Flag: 548 +--------+---------------+---------+---------+---------+-----------+ 549 | Bit No | Attribute | Carried | Carried | Carried | Reference | 550 | | Flag Name | in Path | in Resv | in RRO | | 551 | | | | | or ERO | | 552 +--------+---------------+---------+---------+---------+-----------+ 553 | TBA1 by| P2MP-TE Tree | Yes | No | No | This | 554 | IANA | Re-evaluation | | | | document | 555 +--------+---------------+---------+---------+---------+-----------+ 557 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 559 IANA maintains a name space for RSVP protocol parameters "Resource 560 Reservation Protocol (RSVP) Parameters" (see 561 http://www.iana.org/assignments/rsvp-parameters). From the 562 sub-registry "Sub-Codes - 25 Notify Error" in registry "Error Codes 563 and Globally-Defined Error Value Sub-Codes", allocation of a new 564 error code is requested (Section 5.2). 566 As defined in [RFC3209], the Error Code 25 in the ERROR SPEC Object 567 corresponds to PathErr with Notify error. This document adds a new 568 sub-code for this PathErr as follows: 570 o Preferable P2MP-TE Tree Exists sub-code: 572 +----------+--------------------+---------+---------+-----------+ 573 | Sub-code | Sub-code | PathErr | PathErr | Reference | 574 | value | Description | Code | Name | | 575 +----------+--------------------+---------+---------+-----------+ 576 | TBA2 by | Preferable P2MP-TE | 25 | Notify | This | 577 | IANA | Tree Exists | | Error | document | 578 +----------+--------------------+---------+---------+-----------+ 580 7.3. Fragment Identifier For S2L sub-LSP Descriptor 582 IANA maintains a name space for RSVP protocol parameters "Resource 583 Reservation Protocol (RSVP) Parameters" (see 584 http://www.iana.org/assignments/rsvp-parameters). From the registry 585 "Class Names, Class Numbers, and Class Types", allocation of new 586 Class-Num is requested (Section 5.3). 588 o S2L_SUB_LSP_FRAG Object: 590 +-----------------+---------------------------+-----------------+ 591 | Class-Num value | Description | Reference | 592 +-----------------+---------------------------+-----------------+ 593 | TBA3 by IANA | S2L_SUB_LSP_FRAG | This document | 594 +-----------------+---------------------------+-----------------+ 596 8. Security Considerations 598 This document defines RSVP-TE signaling extensions to allow an 599 ingress node of a P2MP-TE LSP to request the re-evaluation of the LSP 600 tree downstream of a node, and for a mid-point LSR to notify the 601 ingress node of the existence of a preferable tree by sending a 602 PathErr. As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP 603 spanning multiple domains, it may be desirable for a mid-point LSR to 604 modify the RSVP PathErr message defined in this document to preserve 605 confidentiality across domains. 607 This document also defines fragment identifier for the S2L sub-LSP 608 descriptor when combining large number of S2L sub-LSPs in an RSVP 609 message and the message needs to be semantically fragmented. The 610 introduction of the fragment identifier, by itself, introduces no 611 additional information to signaling. For a general discussion on 612 MPLS and GMPLS related security issues, see the MPLS/GMPLS security 613 framework [RFC5920]. 615 9. References 617 9.1. Normative References 619 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 620 Requirement Levels", BCP 14, RFC 2119, March 1997. 622 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 623 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 624 Functional Specification", RFC 2205, September 1997. 626 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 627 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 628 Tunnels", RFC 3209, December 2001. 630 [RFC4736] Vasseur, JP., Ikejiri, Y. and Zhang, R, "Reoptimization of 631 Multiprotocol Label Switching (MPLS) Traffic Engineering 632 (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, 633 November 2006. 635 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 636 "Extensions to Resource Reservation Protocol Traffic 637 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 638 Switched Paths (LSPs)", RFC 4875, May 2007. 640 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and Ayyangar, 641 A., "Encoding of Attributes for MPLS LSP Establishment 642 Using Resource Reservation Protocol Traffic Engineering 643 (RSVP-TE)", RFC 5420, February 2009. 645 9.2. Informative References 647 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 648 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 649 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 651 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation 652 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 653 March 2009. 655 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 656 Networks", RFC 5920, July 2010. 658 [RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol 659 (RSVP) Message Formats for Label Switched Path (LSP) 660 Attributes Objects", RFC 6510, February 2012. 662 Acknowledgments 664 The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis 665 Villamizar, Dimitri Papadimitriou, Nobo Akiya, Vishnu Pavan Beeram 666 and Joel M. Halpern for reviewing this document and providing many 667 useful comments and suggestions. The authors would also like to 668 thank Ling Zeng with Cisco Systems for implementing mechanisms 669 defined in this document. A special thanks to Adrian Farrel for his 670 thorough review of this document. 672 Author's Addresses 674 Tarek Saad (editor) 675 Cisco Systems 677 EMail: tsaad@cisco.com 679 Rakesh Gandhi (editor) 680 Cisco Systems 682 EMail: rgandhi@cisco.com 684 Zafar Ali 685 Cisco Systems 687 EMail: zali@cisco.com 689 Robert H. Venator 690 Defense Information Systems Agency 692 EMail: robert.h.venator.civ@mail.mil 694 Yuji Kamite 695 NTT Communications Corporation 697 EMail: y.kamite@ntt.com