idnits 2.17.1 draft-ietf-teas-p2mp-loose-path-reopt-08.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 (December 8, 2016) is 2695 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: June 11, 2017 Cisco Systems, Inc. 6 R. Venator 7 Defense Information Systems Agency 8 Y. Kamite 9 NTT Communications Corporation 10 December 8, 2016 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-08 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) 2016 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 . . . . . . . . . . . . . . . . . . . . . 7 74 3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP 75 Re-optimization . . . . . . . . . . . . . . . . . . . . . 8 76 4. Signaling Extensions For Loosely Routed P2MP-TE LSP 77 Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 9 78 4.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 9 79 4.2. Sub-Group-Based Re-optimization Using Fragment 80 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . 12 85 6. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 13 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 . . . . 14 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 TE LSP: Traffic Engineering Label Switched Path. 160 TE LSP ingress: Head-end/source node of the TE LSP. 162 TE LSP egress: Tail-end/destination node of the TE LSP. 164 2.3. Terminology 166 Domain: Routing or administrative domain such as an IGP area and an 167 autonomous system. 169 Interior Gateway Protocol Area (IGP Area): OSPF area or IS-IS level. 171 Inter-area TE LSP: A TE LSP whose path transits across at least two 172 different IGP areas. 174 Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least 175 two different Autonomous Systems (ASes) or sub-ASes (BGP 176 confederations). 178 S2L sub-LSP: Source-to-leaf sub Label Switched Path. 180 The reader is assumed to be familiar with the terminology in 181 [RFC4875] and [RFC4736]. 183 3. Overview 185 [RFC4736] defines RSVP signaling extensions for re-optimizing loosely 186 routed P2P TE LSPs as follows: 188 o A mid-point LSR that expands loose next-hop(s) sends a solicited 189 or unsolicited PathErr with the Notify error code 25 (as defined 190 in [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists" 191 to the ingress node. 193 o An ingress node triggers a path re-evaluation request at all 194 mid-point LSR(s) that expands loose next-hop(s) by setting the 195 "Path Re-evaluation Request" flag (0x20) in SESSION_ATTRIBUTES 196 Object in the Path message. 198 o The ingress node upon receiving this PathErr with the Notify error 199 code either solicited or unsolicited initiates re-optimization of 200 the LSP using the MBB method with a different LSP-ID. 202 The following sections discuss the issues that may arise when 203 applying the mechanisms defined in [RFC4736] for re-optimizing 204 loosely routed P2MP-TE LSPs. 206 3.1. Loosely Routed Inter-domain P2MP-TE LSP Tree 208 An example of a loosely routed inter-domain P2MP-TE LSP tree is shown 209 in Figure 1. In this example, the P2MP-TE LSP tree consists of 3 S2L 210 sub-LSPs, to destinations (i.e. leafs) R10, R11 and R12 from the 211 ingress node (i.e. source) R1. Nodes R2 and R5 are branch nodes and 212 nodes ABR3, ABR4, ABR7, ABR8 and ABR9 are area border routers. For 213 the S2L sub-LSP to destination R10, nodes ABR3, ABR7 and R10 are 214 defined as loose next-hops. For the S2L sub-LSP to destination R11, 215 nodes ABR3, ABR8 and R11 are defined as loose next-hops. For the S2L 216 sub-LSP to destination R12, nodes ABR4, ABR9 and R12 are defined as 217 loose next-hops. 219 <--area1--><--area0--><-area2-> 221 ABR7---R10 222 / 223 / 224 ABR3---R5 225 / \ 226 / \ 227 R1---R2 ABR8---R11 228 \ 229 \ 230 ABR4---R6 231 \ 232 \ 233 ABR9---R12 235 Figure 1: An Example of Loosely Routed Inter-domain P2MP-TE LSP Tree 237 3.2. Existing Mechanism For Tree-Based P2MP-TE LSP Re-optimization 239 Mechanisms defined in [RFC4736] can be easily applied to trigger the 240 re-optimization of individual or group of S2L sub-LSP(s). However, 241 to apply these [RFC4736] mechanisms for triggering the 242 re-optimization of a P2MP-TE LSP tree, an ingress node needs to send 243 path re-evaluation requests on all (typically 100s of) S2L sub-LSPs 244 and the mid-point LSR needs to send PathErrs with the Notify error 245 code for all S2L sub-LSPs. Such mechanisms may lead to the following 246 issues: 248 o A mid-point LSR that expands loose next-hop(s) may have to 249 accumulate the received path re-evaluation request(s) for all S2L 250 sub-LSPs (e.g. by using a wait timer) and interpret them as a 251 re-optimization request for the whole P2MP-TE LSP tree. 252 Otherwise, a mid-point LSR may prematurely notify "Preferable Path 253 Exists" for one or a sub-set of S2L sub-LSPs. 255 o Similarly, the ingress node may have to heuristically determine 256 when to perform P2MP-TE LSP tree re-optimization and when to 257 perform S2L sub-LSP re-optimization. For example, an 258 implementation may choose to delay re-optimization long enough to 259 allow all PathErr(s) to be received. Such timer-based procedures 260 may produce undesired results. 262 o The ingress node that receives (un)solicited PathErr(s) with the 263 Notify error code for individual S2L sub-LSP(s), may prematurely 264 start re-optimizing the sub-set of S2L sub-LSPs. However, as 265 mentioned in [RFC4875] Section 14.2, such sub-group based re- 266 optimization procedure may result in data duplication that can be 267 avoided if the entire P2MP-TE LSP tree is re-optimized using the 268 Make-Before-Break method with a different LSP-ID, especially if 269 the ingress node eventually receives PathErrs with the Notify 270 error code for all S2L sub-LSPs of the P2MP-TE LSP tree. 272 In order to address above mentioned issues and to align 273 re-optimization of P2MP-TE LSP with P2P LSP [RFC4736], there is a 274 need for a mechanism to trigger re-optimization of the LSP tree by 275 re-signaling all S2L sub-LSPs with a different LSP-ID. To meet this 276 requirement, this document defines RSVP-TE signaling extensions for 277 the ingress node to trigger the re-evaluation of the P2MP LSP tree on 278 every hop that has a next-hop defined as a loose or abstract hop for 279 one or more S2L sub-LSP path, and a mid-point LSR to signal to the 280 ingress node that a preferable LSP tree exists (compared to the 281 current path) or that the whole P2MP-TE LSP must be re-optimized 282 (because of maintenance required on the TE LSP path) (see Section 283 4.1). 285 3.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP Re-optimization 287 Applying the procedures discussed in RFC4736 in conjunction with the 288 Sub-Group-Based Re-Optimization procedures ([RFC4875], Section 14.2), 289 an ingress node MAY trigger path re-evaluation requests for a set of 290 S2L sub-LSPs in a single Path message using S2L sub-LSP descriptor 291 list. Similarly, a mid-point LSR may send a PathErr with the Notify 292 error code 25 and sub-code 6 containing a list of S2L sub-LSPs 293 transiting through the LSR using an S2L sub-LSP descriptor list to 294 notify the ingress node. This method can be used for re-optimizing a 295 sub-group of S2L sub-LSPs within an LSP tree using the same LSP-ID. 296 This method can alleviate the scale issue associated with sending 297 RSVP messages for individual S2L sub-LSPs. However, this procedure 298 can lead to the following issues when used to re-optimize the LSP 299 tree: 301 o Path message that is intended to carry the path re-evaluation 302 request as defined in [RFC4736] with a full list of S2L sub-LSPs 303 in S2L sub-LSPs descriptor list will be decomposed at branching 304 LSRs, and only a subset of the S2L sub-LSPs that are routed over 305 the same next-hop will be added in the descriptor list of the Path 306 message propagated to downstream mid-point LSRs. Consequently, 307 when a preferable path exists at such mid-point LSRs, the PathErr 308 with the Notify error code can only include the sub-set of S2L 309 sub-LSPs traversing the LSR. In this case, at the ingress node 310 there is no way to distinguish which mode of re-optimization to 311 invoke, i.e. sub-group based re-optimization using the same LSP-ID 312 or tree based re-optimization using a different LSP-ID. 314 o An LSR may semantically fragment a large RSVP message (when a 315 combined message may not be large enough to fit all S2L sub-LSPs). 316 In this case, the ingress node may receive multiple PathErrs with 317 sub-sets of S2L sub-LSPs in each (due to either the combined Path 318 message getting fragmented or the combined PathErr message getting 319 fragmented) and would require additional logic to determine how to 320 re-optimize the LSP tree (for example, waiting for some time to 321 aggregate all possible PathErr messages before taking an action). 322 When fragmented, RSVP messages may arrive out of order, and the 323 receiver has no way of knowing the beginning and end of the S2L 324 sub-LSP list. 326 In order to address the above mentioned issues caused by RSVP message 327 semantic fragmentation, this document defines new fragment identifier 328 object for the S2L sub-LSP descriptor list when combining large 329 number of S2L sub-LSPs in an RSVP message (see Section 4.2). 331 4. Signaling Extensions For Loosely Routed P2MP-TE LSP Re-optimization 333 4.1. Tree-Based Re-optimization 335 To evaluate a P2MP-TE LSP tree on mid-point LSRs that expand loose 336 next-hop(s), an ingress node MAY send a Path message with "P2MP-TE 337 Tree Re-evaluation Request (value TBA1)" defined in this document. 338 The ingress node selects one of the S2L sub-LSPs of the P2MP-TE LSP 339 tree transiting a mid-point LSR to trigger the re-evaluation request. 340 The ingress node MAY send a re-evaluation request to each border LSR 341 on the path of the LSP tree. 343 A mid-point LSR that expands loose next-hop(s) for one or more S2L 344 sub-LSP path(s) does the following upon receiving a Path message with 345 the "P2MP-TE Tree Re-evaluation Request" flag set: 347 o The mid-point LSR MUST check for a preferable P2MP-TE LSP tree by 348 re-evaluating all S2L sub-LSP(s) that are expanded paths of the 349 loose next-hops of the P2MP-TE LSP. 351 o If a preferable P2MP-TE LSP tree is found, the mid-point LSR MUST 352 send an RSVP PathErr with the Notify error code 25 defined in 353 [RFC3209] and sub-code "Preferable P2MP-TE Tree Exists (value 354 TBA2)" defined in this document to the ingress node. The mid- 355 point LSR, in turn, SHOULD NOT propagate the "P2MP-TE Tree Re- 356 evaluation Request" flag in the subsequent RSVP Path messages sent 357 downstream for the re-evaluated P2MP-TE LSP. 359 o If no preferable tree for P2MP-TE LSP can be found, the mid-point 360 LSR that expands loose next-hop(s) for one or more S2L sub-LSP 361 path(s) MUST propagate the request downstream by setting the 362 "P2MP-TE Tree Re-evaluation Request" flag in the LSP_ATTRIBUTES 363 Object of the RSVP Path message. 365 A mid-point LSR MAY send an unsolicited PathErr with the Notify error 366 code and sub-code "Preferable P2MP-TE Tree Exists" to the ingress 367 node to notify of a preferred P2MP-TE LSP tree when it determines it 368 exists. In this case, the mid-point LSR that expands loose next- 369 hop(s) for one or more S2L sub-LSP path(s) selects one of the S2L 370 sub-LSP(s) of the P2MP-TE LSP tree to send this PathErr message to 371 the ingress node. 373 The sending of an RSVP PathErr with the Notify error code and 374 "Preferable P2MP-TE Tree Exists" sub-code to the ingress node 375 notifies the ingress node of the existence of a preferable P2MP-TE 376 LSP tree and upon receiving this PathErr, the ingress node MUST 377 trigger re-optimization of the LSP using the MBB method with a 378 different LSP-ID. 380 4.2. Sub-Group-Based Re-optimization Using Fragment Identifier 382 It might be preferable, as per [RFC4875], to re-optimize the entire 383 P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1, 384 "Make-before-Break") or to re-optimize individual or group of S2L 385 sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2 386 "Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same 387 LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved by 388 using the procedures defined in [RFC4736] to re-optimize one or more 389 S2L sub-LSP(s) of the P2MP-TE LSP. 391 An ingress node may trigger path re-evaluation requests using the 392 procedures defined in [RFC4736] for a set of S2L sub-LSPs by 393 combining multiple Path messages using an S2L sub-LSP descriptor list 394 [RFC4875]. An S2L sub-LSP descriptor list is created using a series 395 of S2L_SUB_LSP Objects as defined in [RFC4875]. Similarly, a mid- 396 point LSR may send a PathErr with the Notify error code (value 25) 397 and "Preferable Path Exists" (sub-code 6) containing a list of S2L 398 sub-LSPs transiting through the LSR using an S2L sub-LSP descriptor 399 list to notify the ingress node of preferable paths available. 401 As per [RFC4875] (Section 5.2.3, "Transit Fragmentation of Path State 402 Information"), when a Path message is not large enough to fit all S2L 403 sub-LSPs in the descriptor list, an LSR may semantically fragment the 404 message. In this case, the LSR MUST add the S2L_SUB_LSP_FRAG Object 405 defined in this document in the S2L sub-LSP descriptor to be able to 406 rebuild the list from the received fragments that may arrive out of 407 order. 409 The S2L_SUB_LSP_FRAG Object defined in this document is optional. 410 However, a node MUST add the S2L_SUB_LSP_FRAG Object for each 411 fragment in S2L sub-LSP descriptor when the RSVP message needs to be 412 fragmented. 414 A mid-point LSR SHOULD wait to accumulate all S2L sub-LSPs before 415 attempting to re-evaluate preferable path when a Path message for 416 "Path Re-evaluation Request" is received with S2L_SUB_LSP_FRAG 417 Object. If a mid-point LSR does not receive all fragments of the 418 Path message (for example, when fragments are lost) within a 419 configurable time interval, it SHOULD trigger re-evaluation of all 420 S2L sub-LSPs of the P2MP-TE LSP transiting on the node. A mid-point 421 LSR MUST receive at least one fragment of the Path message to trigger 422 this behaviour. 424 An ingress node SHOULD wait to accumulate all S2L sub-LSPs before 425 attempting to trigger re-optimization when a PathErr with Notify 426 error code and "Preferable Path Exists" sub-code is received with a 427 S2L_SUB_LSP_FRAG Object. If an ingress node does not receive all 428 fragments of the PathErr message (for example, when fragments are 429 lost) within a configurable time interval, it SHOULD trigger re- 430 optimization of all S2L sub-LSPs of the P2MP-TE LSP transiting on the 431 mid-point node that had sent the PathErr message. An ingress node 432 MUST receive at least one fragment of the PathErr message to trigger 433 this behaviour. 435 The S2L_SUB_LSP_FRAG Object defined in this document has a wider 436 applicability in addition to the P2MP-TE LSP re-optimization. It can 437 also be used (in Path and Resv messages) to setup a new P2MP-TE LSP, 438 send other PathErr messages as well as Path Tear and Resv Tear 439 messages for a set of S2L sub-LSPs. This is outside the scope of 440 this document. 442 5. Message and Object Definitions 444 5.1. P2MP-TE Tree Re-evaluation Request Flag 446 In order to trigger a tree re-evaluation request, a new flag is 447 defined in Attributes Flags TLV of the LSP_ATTRIBUTES Object 448 [RFC5420] as follows: 450 Bit Number (TBA1, to be assigned by IANA): P2MP-TE Tree 451 Re-evaluation Request flag 453 The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path 454 message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node 455 using the message format defined in [RFC6510]. 457 5.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 459 In order to indicate to an ingress node that a preferable P2MP-TE LSP 460 tree exists, the following new sub-code for PathErr with Notify error 461 code 25 [RFC3209] is defined: 463 Sub-code (TBA2, to be assigned by IANA): Preferable P2MP-TE Tree 464 Exists sub-code 466 When a preferable path for P2MP-TE LSP tree exists, the mid-point LSR 467 sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" 468 sub-code with PathErr with Notify error code 25 to the ingress node 469 of the P2MP-TE LSP. 471 5.3. Fragment Identifier For S2L sub-LSP Descriptor 473 The S2L_SUB_LSP Object [RFC4875] identifies a particular S2L sub-LSP 474 belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is 475 created using a series of S2L_SUB_LSP Objects as defined in 476 [RFC4875]. The RSVP message may need to be semantically fragmented 477 [RFC4875] due to large number of S2L sub-LSPs added in the descriptor 478 list, and such fragments may be received our of order. To be able to 479 rebuild the fragmented S2L sub-LSP descriptor list correctly, the 480 following Object is defined to identify the fragments. 482 S2L_SUB_LSP_FRAG: Class-Num TBA3 by IANA 484 +---------------+---------------+---------------+---------------+ 485 | Length (8 bytes) | Class-Num TBA3| C-Type 1 | 486 +---------------+---------------+---------------+---------------+ 487 | Fragment ID | Fragments Tot | Fragment Num | 488 +---------------+---------------+---------------+---------------+ 490 Fragment ID: 16-bit integer in the range of 1 to 65535. 492 This value is incremented for each new RSVP message that needs to 493 be semantically fragmented. The fragment ID is reset to 1 when it 494 reaches the maximum value of 65535. The scope of the fragment ID 495 is limited to the RSVP message type (e.g. Path) carrying the 496 fragment. In other words, fragment IDs do not have any 497 correlation between different RSVP message types (e.g. Path and 498 PathErr). The receiver does not check to ensure if the 499 consecutive new RSVP messages (e.g. Path messages) are received 500 with fragment IDs incremented by 1. 502 Fragments Total: 8-bit integer in the range of 1 to 255. 504 This value indicates the number of fragments sent for the given 505 RSVP message. This value MUST be the same in all fragmented RSVP 506 messages with a common Fragment ID. 508 Fragment Number: 8-bit integer in the range of 1 to 255. 510 This value indicates the position of this fragment in the given 511 RSVP message. 513 The format of an S2L sub-LSP descriptor message is as follows: 515 ::= 516 [ ] 517 518 [ ] 520 The S2L_SUB_LSP_FRAG Object is added before adding the S2L_SUB_LSP 521 Object in the semantically fragmented RSVP message. 523 6. Compatibility 525 The LSP_ATTRIBUTES Object has been defined in [RFC5420] and its 526 message formats in [RFC6510] with class numbers in the form 11bbbbbb, 527 which ensures compatibility with non-supporting nodes. Per 528 [RFC2205], nodes not supporting this extension will ignore the new 529 flag defined for this Object in this document but forward it without 530 modification. 532 The S2L_SUB_LSP_FRAG Object has been defined with class numbers in 533 the form 11bbbbbb, which ensures compatibility with non-supporting 534 nodes. Per [RFC2205], nodes not supporting this Object will ignore 535 the Object but forward it without modification. 537 7. IANA Considerations 539 IANA is requested to administer assignment of new values for 540 namespace defined in this document and summarized in this section. 542 7.1. P2MP-TE Tree Re-evaluation Request Flag 544 IANA maintains a name space for RSVP-TE TE parameters "Resource 545 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" (see 546 http://www.iana.org/assignments/rsvp-te-parameters). From the 547 registries in this name space "Attribute Flags", allocation of new 548 flag is requested (Section 5.1). 550 The following new flag is defined for the Attributes Flags TLV in the 551 LSP_ATTRIBUTES Object [RFC5420]. The numeric value is to be assigned 552 by IANA. 554 o P2MP-TE Tree Re-evaluation Request Flag: 556 +--------+---------------+---------+---------+---------+------------+ 557 | Bit No | Attribute | Carried | Carried | Carried | Reference | 558 | | Flag Name | in Path | in Resv | in RRO | | 559 +--------+---------------+---------+---------+---------+------------+ 560 | TBA1 by| P2MP-TE Tree | Yes | No | No | This | 561 | IANA | Re-evaluation | | | | document | 562 +--------+---------------+---------+---------+---------+------------+ 564 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 566 IANA maintains a name space for RSVP protocol parameters "Resource 567 Reservation Protocol (RSVP) Parameters" (see 568 http://www.iana.org/assignments/rsvp-parameters). From the 569 sub-registry "Sub-Codes - 25 Notify Error" in registry "Error Codes 570 and Globally-Defined Error Value Sub-Codes", allocation of a new 571 error code is requested (Section 5.2). 573 As defined in [RFC3209], the Error Code 25 in the ERROR SPEC Object 574 corresponds to PathErr with Notify error. This document adds a new 575 sub-code for this PathErr as follows: 577 o Preferable P2MP-TE Tree Exists sub-code: 579 +----------+--------------------+---------+---------+-----------+ 580 | Sub-code | Sub-code | PathErr | PathErr | Reference | 581 | value | Description | Code | Name | | 582 +----------+--------------------+---------+---------+-----------+ 583 | TBA2 by | Preferable P2MP-TE | 25 | Notify | This | 584 | IANA | Tree Exists | | Error | document | 585 +----------+--------------------+---------+---------+-----------+ 587 7.3. Fragment Identifier For S2L sub-LSP Descriptor 589 IANA maintains a name space for RSVP protocol parameters "Resource 590 Reservation Protocol (RSVP) Parameters" (see 591 http://www.iana.org/assignments/rsvp-parameters). From the registry 592 "Class Names, Class Numbers, and Class Types", allocation of new 593 Class-Num is requested (Section 5.3). 595 o S2L_SUB_LSP_FRAG Object: 597 +-----------------+---------------------------+-----------------+ 598 | Class-Num value | Description | Reference | 599 +-----------------+---------------------------+-----------------+ 600 | TBA3 by IANA | S2L_SUB_LSP_FRAG | This document | 601 +-----------------+---------------------------+-----------------+ 603 8. Security Considerations 605 This document defines RSVP-TE signaling extensions to allow an 606 ingress node of a P2MP-TE LSP to request the re-evaluation of the LSP 607 tree downstream of a node, and for a mid-point LSR to notify the 608 ingress node of the existence of a preferable tree by sending a 609 PathErr. As per [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP 610 spanning multiple domains, it may be desirable for a mid-point LSR to 611 modify the RSVP PathErr message defined in this document to preserve 612 confidentiality across domains. 614 This document also defines fragment identifier for the S2L sub-LSP 615 descriptor when combining large number of S2L sub-LSPs in an RSVP 616 message and the message needs to be semantically fragmented. The 617 introduction of the fragment identifier, by itself, introduces no 618 additional information to signaling. For a general discussion on 619 MPLS and GMPLS related security issues, see the MPLS/GMPLS security 620 framework [RFC5920]. 622 9. References 624 9.1. Normative References 626 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 627 Requirement Levels", BCP 14, RFC 2119, March 1997. 629 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 630 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 631 Functional Specification", RFC 2205, September 1997. 633 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 634 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 635 Tunnels", RFC 3209, December 2001. 637 [RFC4736] Vasseur, JP., Ikejiri, Y. and Zhang, R, "Reoptimization of 638 Multiprotocol Label Switching (MPLS) Traffic Engineering 639 (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, 640 November 2006. 642 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 643 "Extensions to Resource Reservation Protocol Traffic 644 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 645 Switched Paths (LSPs)", RFC 4875, May 2007. 647 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and Ayyangar, 648 A., "Encoding of Attributes for MPLS LSP Establishment 649 Using Resource Reservation Protocol Traffic Engineering 650 (RSVP-TE)", RFC 5420, February 2009. 652 9.2. Informative References 654 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 655 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 656 Engineering (RSVP-TE) Extensions", RFC 3473, January 2003. 658 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation 659 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 660 March 2009. 662 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 663 Networks", RFC 5920, July 2010. 665 [RFC6510] Berger, L. and G. Swallow, "Resource Reservation Protocol 666 (RSVP) Message Formats for Label Switched Path (LSP) 667 Attributes Objects", RFC 6510, February 2012. 669 Acknowledgments 671 The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis 672 Villamizar, Dimitri Papadimitriou, Nobo Akiya, Vishnu Pavan Beeram 673 and Joel M. Halpern for reviewing this document and providing many 674 useful comments and suggestions. The authors would also like to 675 thank Ling Zeng with Cisco Systems for implementing mechanisms 676 defined in this document. A special thanks to Adrian Farrel for his 677 thorough review of this document. 679 Author's Addresses 681 Tarek Saad (editor) 682 Cisco Systems 684 EMail: tsaad@cisco.com 686 Rakesh Gandhi (editor) 687 Cisco Systems 689 EMail: rgandhi@cisco.com 691 Zafar Ali 692 Cisco Systems 694 EMail: zali@cisco.com 696 Robert H. Venator 697 Defense Information Systems Agency 699 EMail: robert.h.venator.civ@mail.mil 701 Yuji Kamite 702 NTT Communications Corporation 704 EMail: y.kamite@ntt.com