idnits 2.17.1 draft-ietf-teas-p2mp-loose-path-reopt-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 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 (March 11, 2016) is 2960 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: September 12, 2016 Cisco Systems, Inc. 6 R. Venator 7 Defense Information Systems Agency 8 Y. Kamite 9 NTT Communications Corporation 10 March 11, 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-05 16 Abstract 18 For a Traffic Engineered (TE) Point-to-Multipoint (P2MP) Label 19 Switched Path (LSP), it is preferable in some cases to re-evaluate 20 and re-optimize the entire P2MP-TE LSP by re-signaling all its 21 Source-to-Leaf (S2L) sub-LSP(s). Existing mechanisms, a mechanism 22 for an ingress Label Switched Router (LSR) to trigger a new path 23 re-evaluation request and a mechanism for a mid-point LSR to notify 24 an availability of a preferred path, operate on an individual or a 25 sub-group of S2L sub-LSP(s) basis only. 27 This document defines Resource Reservation Protocol (RSVP) signaling 28 extensions to allow an ingress node of a P2MP-TE LSP to request the 29 re-evaluation of the entire LSP tree containing one or more S2L 30 sub-LSPs whose paths are loose (or abstract) hop expanded, and for a 31 mid-point LSR to notify to the ingress node that a preferable tree 32 exists for the entire P2MP-TE LSP. For re-optimizing a group of S2L 33 sub-LSP(s) in a tree, an S2L sub-LSP descriptor list can be used to 34 signal one or more S2L sub-LSPs in an RSVP message. This document 35 defines fragment identifier for the S2L sub-LSP descriptor list when 36 the RSVP message needs to be fragmented due to large number of S2L 37 sub-LSPs in the message when performing sub-group based 38 re-optimization. 40 Status of this Memo 42 This Internet-Draft is submitted in full conformance with the 43 provisions of BCP 78 and BCP 79. 45 Internet-Drafts are working documents of the Internet Engineering 46 Task Force (IETF). Note that other groups may also distribute 47 working documents as Internet-Drafts. The list of current Internet- 48 Drafts is at http://datatracker.ietf.org/drafts/current/. 50 Internet-Drafts are draft documents valid for a maximum of six months 51 and may be updated, replaced, or obsoleted by other documents at any 52 time. It is inappropriate to use Internet-Drafts as reference 53 material or to cite them other than as "work in progress." 55 Copyright Notice 57 Copyright (c) 2016 IETF Trust and the persons identified as the 58 document authors. All rights reserved. 60 This document is subject to BCP 78 and the IETF Trust's Legal 61 Provisions Relating to IETF Documents 62 (http://trustee.ietf.org/license-info) in effect on the date of 63 publication of this document. Please review these documents 64 carefully, as they describe your rights and restrictions with respect 65 to this document. Code Components extracted from this document must 66 include Simplified BSD License text as described in Section 4.e of 67 the Trust Legal Provisions and are provided without warranty as 68 described in the Simplified BSD License. 70 Table of Contents 72 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 73 1.1. Loosely Routed Inter-domain P2MP-TE LSP Tree . . . . . . . 5 74 1.2. Existing Mechanism For Tree-Based P2MP-TE LSP 75 Re-optimization . . . . . . . . . . . . . . . . . . . . . 5 76 1.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP 77 Re-optimization . . . . . . . . . . . . . . . . . . . . . 6 78 2. Conventions Used in This Document . . . . . . . . . . . . . . 7 79 2.1. Key Word Definitions . . . . . . . . . . . . . . . . . . . 7 80 2.2. Abbreviations . . . . . . . . . . . . . . . . . . . . . . 7 81 2.3. Nomenclatures . . . . . . . . . . . . . . . . . . . . . . 8 82 3. Signaling Procedure For Loosely Routed P2MP-TE LSP 83 Re-optimization . . . . . . . . . . . . . . . . . . . . . . . 8 84 3.1. Tree-Based Re-optimization . . . . . . . . . . . . . . . . 8 85 3.2. Sub-Group-Based Re-optimization Using Fragment 86 Identifier . . . . . . . . . . . . . . . . . . . . . . . . 9 87 4. Message and Object Definitions . . . . . . . . . . . . . . . . 10 88 4.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 10 89 4.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 10 90 4.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 11 91 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 12 92 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 6.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 12 94 6.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 12 95 6.3. Fragment Identifier For S2L sub-LSP Descriptor . . . . . . 13 96 7. Security Considerations . . . . . . . . . . . . . . . . . . . 14 97 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 99 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 100 Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . . . 16 101 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 103 1. Introduction 105 This document defines Resource Reservation Protocol - Traffic 106 Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for 107 re-optimizing loosely routed Point-to-Multipoint (P2MP) Traffic 108 Engineered (TE) Label Switched Paths (LSPs) [RFC4875] in an 109 Multi-Protocol Label Switching (MPLS) and/or Generalized MPLS (GMPLS) 110 networks. 112 A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L) 113 sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one 114 whose path does not contain the full explicit route identifying each 115 node along the path to the egress node at the time of its signaling 116 by the ingress node. Such an S2L sub-LSP is signaled with no 117 Explicit Route Object (ERO) [RFC3209], or with an ERO that contains 118 at least one loose hop, or with an ERO that contains an abstract node 119 that is not a simple abstract node (that is, an abstract node that 120 identifies more than one node). This is often the case with 121 inter-domain P2MP-TE LSPs where Path Computation Element (PCE) is not 122 used [RFC5440]. 124 As per [RFC4875], an ingress node may re-optimize the entire P2MP-TE 125 LSP by re-signaling all its S2L sub-LSP(s) or may re-optimize 126 individual or group of S2L sub-LSP(s) i.e. individual or group of 127 destination(s). 129 [RFC4736] defines RSVP signaling extensions for re-optimizing loosely 130 routed Point-to-Point (P2P) TE LSP(s) as follows: 132 o A mid-point LSR that expands loose next-hop(s) sends a solicited 133 or unsolicited PathErr with the Notify error code (25 as defined in 134 [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists" to 135 the ingress node. 137 o An ingress node triggers a path re-evaluation request at all 138 mid-point LSR(s) that expands loose next-hop(s) by setting the "Path 139 Re-evaluation Request" flag (0x20) in SESSION_ATTRIBUTES Object in 140 the Path message. 142 o The ingress node upon receiving this PathErr either solicited or 143 unsolicited initiates re-optimization of the LSP with a different 144 LSP-ID. 146 Following sections discuss the issues that may arise when using 147 existing mechanisms defined in [RFC4736] for re-optimizing loosely 148 routed P2MP-TE LSPs. 150 1.1. Loosely Routed Inter-domain P2MP-TE LSP Tree 152 An example of a loosely routed inter-domain P2MP-TE LSP tree is shown 153 in Figure 1. In this example, the P2MP-TE LSP tree consists of 3 S2L 154 sub-LSPs, to destinations (i.e. leafs) R10, R11 and R12 from the 155 ingress node (i.e. source) R1. Nodes R2 and R5 are branch nodes and 156 nodes ABR3, ABR4, ABR7, ABR8 and ABR9 are area border routers. For 157 the S2L sub-LSP to destination R10, nodes ABR3, ABR7 and R10 are 158 defined as loose hops. For the S2L sub-LSP to destination R11, nodes 159 ABR3, ABR8 and R11 are defined as loose hops. For the S2L sub-LSP to 160 destination R12, nodes ABR4, ABR9 and R12 are defined as loose hops. 162 <--area1--><--area0--><-area2-> 164 ABR7---R10 165 / 166 / 167 ABR3---R5 168 / \ 169 / \ 170 R1---R2 ABR8---R11 171 \ 172 \ 173 ABR4---R6 174 \ 175 \ 176 ABR9---R12 178 Figure 1: An Example of Loosely Routed Inter-domain P2MP-TE LSP Tree 180 1.2. Existing Mechanism For Tree-Based P2MP-TE LSP Re-optimization 182 [RFC4736] does not define signaling extensions specific for 183 re-optimizing entire P2MP-TE LSP tree. Mechanisms defined in 184 [RFC4736] can be used for signaling the re-optimization of individual 185 or group of S2L sub-LSP(s). However, to use [RFC4736] mechanisms for 186 re-optimizing an entire P2MP-TE LSP tree, an ingress node needs to 187 send the path re-evaluation requests on all (typically 100s of) S2L 188 sub-LSPs and the mid-point LSR to notify PathErrs for all S2L 189 sub-LSPs. Such mechanisms may lead to the following issues: 191 o A mid-point LSR that expands loose next-hop(s) may have to 192 accumulate the received path re-evaluation request(s) for all S2L 193 sub-LSPs (e.g. by using a wait timer) and interpret them as a 194 re-optimization request for the whole P2MP-TE LSP tree. Otherwise, a 195 mid-point LSR may prematurely notify "Preferable Path Exists" for one 196 or a sub-set of S2L sub-LSPs. 198 o Similarly, the ingress node may have to heuristically determine 199 when to perform entire P2MP-TE LSP tree re-optimization versus per 200 S2L sub-LSP re-optimization, for example, to delay re-optimization 201 long enough to allow all PathErr(s) to be received. Such procedures 202 may produce undesired results due to timing related issues. 204 o The ingress node that receives (un)solicited PathErr 205 notification(s) for individual S2L sub-LSP(s), may prematurely start 206 re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in 207 [RFC4875] Section 14.2, such sub-group based re-optimization 208 procedure may result in data duplication that can be avoided if the 209 entire P2MP-TE LSP tree is re-optimized using a different LSP-ID, 210 especially if the ingress node eventually receives PathErr 211 notifications for all S2L sub-LSPs of the P2MP-TE LSP tree. 213 In order to address above mentioned issues and to align 214 re-optimization of P2MP-TE LSP with P2P LSP [RFC4736], there is a 215 need for a mechanism to trigger re-optimization of the LSP tree by 216 re-signaling all S2L sub-LSPs with a different LSP-ID. To meet this 217 requirement, this document defines RSVP-TE signaling extensions for 218 the ingress node to trigger the re-evaluation of the P2MP LSP tree on 219 every hop that has a next-hop defined as a loose or abstract hop for 220 one or more S2L sub-LSP path, and a mid-point LSR to signal to the 221 ingress node that a preferable LSP tree exists (compared to the 222 current path) or that the whole P2MP-TE LSP must be re-optimized 223 (because of maintenance required on the TE LSP path). 225 1.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP Re-optimization 227 Based on [RFC4875] (Section 14.2 "Sub-Group-Based Re-Optimization"), 228 an ingress node may trigger path re-evaluation requests using the 229 procedures defined in [RFC4736] for a set of S2L sub-LSPs and 230 combining multiple Path messages using S2L sub-LSP descriptor list. 231 Similarly, a mid-point LSR may send a PathErr message (with Error 232 code 25, sub-code 6) containing a list of S2L sub-LSPs transiting 233 through the LSR using an S2L sub-LSP descriptor list to notify the 234 ingress node. This method can be used for re-optimizing a sub-group 235 of S2L sub-LSPs within an LSP tree using the same LSP-ID. This 236 method can alleviate the scale issue associated with sending RSVP 237 messages for individual S2L sub-LSPs. However, this procedure can 238 lead to the following issues when used to re-optimize the LSP tree: 240 o Path message that is intended to carry the path re-evaluation 241 request as defined in [RFC4736] with a full list of S2L sub-LSPs in 242 S2L sub-LSPs descriptor list will be decomposed at branching LSRs, 243 and only a subset of the S2L sub-LSPs that are routed over the same 244 next-hop will be added in the descriptor list of the Path message 245 propagated to downstream mid-point LSRs. Consequently, when a 246 preferable path exists at such mid-point LSRs, the PathErr can only 247 include the sub-set of S2L sub-LSPs traversing the LSR. In this 248 case, at the ingress node there is no way to distinguish which mode 249 of re-optimization to invoke, i.e. sub-group based re-optimization 250 using the same LSP-ID or tree based re-optimization using a different 251 LSP-ID. 253 o An LSR may fragment a large RSVP message (when a combined message 254 may not be large enough to fit all S2L sub-LSPs). In this case, the 255 ingress node may receive multiple PathErrs with sub-sets of S2L 256 sub-LSPs in each (either due to the combined Path message got 257 fragmented or combined PathErr message got fragmented) and would 258 require additional logic to infer to re-optimize the LSP tree (for 259 example, waiting for some time to aggregate all possible PathErr 260 messages before taking an action). When fragmented, RSVP messages 261 may arrive out of order, and the receiver has no way of knowing the 262 beginning and end of the S2L sub-LSP list. 264 In order to address the above mentioned issues due to the RSVP 265 message fragmentation, this document defines fragment identifier for 266 the S2L sub-LSP descriptor list when combining large number of S2L 267 sub-LSPs in an RSVP message. 269 2. Conventions Used in This Document 271 2.1. Key Word Definitions 273 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 274 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 275 document are to be interpreted as described in [RFC2119]. 277 2.2. Abbreviations 279 ABR: Area Border Router. 281 AS: Autonomous System. 283 ERO: Explicit Route Object. 285 LSR: Label Switching Router. 287 TE LSP: Traffic Engineering Label Switched Path. 289 TE LSP ingress: Head-end/source of the TE LSP. 291 TE LSP egress: Tail-end/destination of the TE LSP. 293 2.3. Nomenclatures 295 Domain: Routing or administrative domain such as an IGP area and an 296 autonomous system. 298 Interior Gateway Protocol Area (IGP Area): OSPF area or IS-IS level. 300 Inter-area TE LSP: A TE LSP whose path transits across at least two 301 different IGP areas. 303 Inter-AS MPLS TE LSP: A TE LSP whose path transits across at least 304 two different Autonomous Systems (ASes) or sub-ASes (BGP 305 confederations). 307 S2L sub-LSP: Source-to-leaf sub Label Switched Path. 309 The reader is assumed to be familiar with the terminology in 310 [RFC4875] and [RFC4736]. 312 3. Signaling Procedure For Loosely Routed P2MP-TE LSP Re-optimization 314 3.1. Tree-Based Re-optimization 316 To evaluate an entire P2MP-TE LSP tree on mid-point LSRs that expand 317 loose next-hop(s), an ingress node MAY send a Path message with 318 "P2MP-TE Tree Re-evaluation Request" defined in this document. The 319 ingress node SHOULD select one of the S2L sub-LSPs of the P2MP-TE LSP 320 tree transiting a mid-point LSR to trigger the re-evaluation request. 321 The ingress node MAY send a re-evaluation request to each border LSR 322 on the path of the LSP tree. 324 A mid-point LSR that expands loose next-hop(s) for one or more S2L 325 sub-LSP path(s), and that receives a Path message with the "P2MP-TE 326 Tree Re-evaluation Request" bit set: 328 o The mid-point LSR SHOULD check for a preferable P2MP-TE LSP tree 329 by re-evaluating all S2L sub-LSP(s) that are expanded paths of the 330 loose next-hops of the P2MP-TE LSP. 332 o If a preferable P2MP-TE LSP tree is found, the mid-point LSR MAY 333 send an RSVP PathErr to the ingress node with Error code 25 (Notify 334 defined in [RFC3209] and sub-code "Preferable P2MP-TE Tree Exists" 335 defined in this document. The mid-point LSR, in turn, SHOULD NOT 336 propagate the "P2MP-TE Tree Re-evaluation Request" bit in subsequent 337 RSVP Path messages sent downstream for the re-evaluated P2MP-TE LSP. 339 o If no preferable tree for P2MP-TE LSP can be found, the 340 recommended mode is that the mid-point LSR that expands loose next- 341 hop(s) for one or more S2L sub-LSP path(s) SHOULD propagate the 342 request downstream by setting the "P2MP-TE Tree Re-evaluation 343 Request" bit in the LSP_ATTRIBUTES Object of RSVP Path message. 345 A mid-point LSR MAY send an unsolicited PathErr message with 346 "Preferable P2MP-TE Tree Exists" PathErr to the ingress node to 347 notify of a preferred P2MP-TE LSP tree when it determines it exists. 348 In this case, the mid-point LSR that expands loose next-hop(s) for 349 one or more S2L sub-LSP path(s) SHOULD select one of the S2L sub- 350 LSP(s) of the P2MP-TE LSP tree to send this PathErr message to the 351 ingress node. 353 The sending of an RSVP PathErr Notify message "Preferable P2MP-TE 354 Tree Exists" to the ingress node SHALL notify the ingress node of the 355 existence of a preferable P2MP-TE LSP tree and upon receiving this 356 PathErr, the ingress node MAY trigger re-optimization of the LSP 357 using a different LSP-ID. 359 3.2. Sub-Group-Based Re-optimization Using Fragment Identifier 361 It might be preferable, as per [RFC4875], to re-optimize the entire 362 P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1, 363 "Make-before-Break") or to re-optimize individual or group of S2L 364 sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2 365 "Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same 366 LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved by 367 using the procedures defined in [RFC4736] to re-optimize one or more 368 S2L sub-LSP(s) of the P2MP-TE LSP. 370 An ingress node may trigger path re-evaluation requests using the 371 procedures defined in [RFC4736] for a set of S2L sub-LSPs by 372 combining multiple Path messages using an S2L sub-LSP descriptor list 373 [RFC4875]. An S2L sub-LSP descriptor list is created using a series 374 of S2L_SUB_LSP Objects as defined in [RFC4875]. Similarly, a mid- 375 point LSR may send a PathErr message (with Error code 25, sub-code 6, 376 Preferable Path Exists) containing a list of S2L sub-LSPs transiting 377 through the LSR using an S2L sub-LSP descriptor list to notify the 378 ingress node of preferable paths available. 380 As per [RFC4875] (Section 5.2.3, "Transit Fragmentation of Path State 381 Information"), when a Path message is not large enough to fit all S2L 382 sub-LSPs in the descriptor list, an LSR may fragment the message. In 383 this case, the LSR MAY add S2L_SUB_LSP_FRAG Object defined in this 384 document in the S2L sub-LSP descriptor list to be able to rebuild the 385 list from the received fragments that may arrive out of order. 387 The S2L_SUB_LSP_FRAG Object defined in this document is optional. 388 However, a node MUST add the S2L_SUB_LSP_FRAG Object for each 389 fragment in S2L sub-LSP descriptor list when the RSVP message needs 390 to be fragmented. 392 A mid-point LSR SHOULD wait to accumulate all S2L sub-LSPs before 393 attempting to re-evaluate preferable path when a Path message for 394 "Path Re-evaluation Request" is received with S2L_SUB_LSP_FRAG 395 Object. An ingress node SHOULD wait to accumulate all S2L sub-LSPs 396 before attempting to trigger re-optimization when a PathErr message 397 with "Preferable Path Exists" is received with a S2L_SUB_LSP_FRAG 398 Object. 400 The new object S2L_SUB_LSP_FRAG defined in this document has a wider 401 applicability other than the P2MP-TE LSP re-optimization but it is 402 outside the scope of this document. 404 4. Message and Object Definitions 406 4.1. P2MP-TE Tree Re-evaluation Request Flag 408 In order to trigger a tree re-evaluation request, a new flag is 409 defined in Attributes Flags TLV of the LSP_ATTRIBUTES Object 410 [RFC5420] as follows: 412 Bit Number (to be assigned by IANA): P2MP-TE Tree Re-evaluation 413 Request flag 415 The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path 416 message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node. 418 4.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 420 In order to indicate to an ingress node that a preferable P2MP-TE LSP 421 tree exists, the following new sub-code for PathErr code 25 (Notify 422 Error) [RFC3209] is defined: 424 Sub-code (to be assigned by IANA): Preferable P2MP-TE Tree Exists 425 sub-code 427 When a preferable path for P2MP-TE LSP tree exists, the mid-point LSR 428 sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" 429 PathErr notification to the ingress node of the P2MP-TE LSP. 431 4.3. Fragment Identifier For S2L sub-LSP Descriptor 433 An S2L_SUB_LSP Object [RFC4875] identifies a particular S2L sub-LSP 434 belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is 435 created using a series of S2L_SUB_LSP Objects as defined in 436 [RFC4875]. The RSVP message may need to be fragmented due to large 437 number of S2L sub-LSPs added in the descriptor list, and such 438 fragments may be received our of order. To be able to rebuild the 439 fragmented S2L sub-LSP descriptor list correctly, the following new 440 type is defined for the S2L_SUB_LSP Object [RFC4875]. 442 S2L_SUB_LSP_FRAG: Class-Num 50, C-Type TBA by IANA 444 +---------------+---------------+---------------+---------------+ 445 | Len (12 bytes)| Reserved | Class_Num 50 | SUB_LSP_FRAG | 446 +---------------+---------------+---------------+---------------+ 447 | Reserved | Fragment ID | 448 +---------------+---------------+---------------+---------------+ 449 | Fragments Total | Fragment Number | 450 +---------------+---------------+---------------+---------------+ 452 Fragment ID: 16-bit integer in the range of 1 to 65535. This value 453 is incremented for each new RSVP message that needs to be 454 fragmented. 456 Fragments Total: 16-bit integer in the range of 1 to 65535. This 457 value indicates the number of fragments sent for the given RSVP 458 message. 460 Fragment Number: 16-bit integer in the range of 1 to 65535. This 461 value indicates the position of this fragment in the given RSVP 462 message. 464 The S2L_SUB_LSP_FRAG Object is added before adding the 465 S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object in the fragmented 466 message. 468 5. Compatibility 470 The LSP_ATTRIBUTES Object has been defined in [RFC5420] with class 471 numbers in the form 11bbbbbb, which ensures compatibility with 472 non-supporting nodes. Per [RFC2205], nodes not supporting this 473 extension will ignore the new flag defined in this document but 474 forward it without modification. 476 The S2L_SUB_LSP_FRAG Object has been defined with class numbers in 477 the form 11bbbbbb, which ensures compatibility with non-supporting 478 nodes. Per [RFC2205], nodes not supporting new S2L_SUB_LSP_FRAG 479 Object will ignore them but forward it without modification. 481 6. IANA Considerations 483 IANA is requested to administer assignment of new values for 484 namespace defined in this document and summarized in this section. 486 6.1. P2MP-TE Tree Re-evaluation Request Flag 488 IANA maintains a name space for RSVP-TE TE parameters "Resource 489 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" (see 490 http://www.iana.org/assignments/rsvp-te-parameters). From the 491 registries in this name space "Attribute Flags", allocation of new 492 flag is requested (Section 4.1). 494 The following new flag is defined for the Attributes Flags TLV in the 495 LSP_ATTRIBUTES Object [RFC5420]. The numeric value is to be assigned 496 by IANA. 498 o P2MP-TE Tree Re-evaluation Request Flag: 500 +--------+---------------+---------+---------+---------+------------+ 501 | Bit No | Attribute | Carried | Carried | Carried | Reference | 502 | | Flag Name | in Path | in Resv | in RRO | | 503 +--------+---------------+---------+---------+---------+------------+ 504 | TBA by | P2MP-TE Tree | Yes | No | No | This | 505 | IANA | Re-evaluation | | | | document | 506 +--------+---------------+---------+---------+---------+------------+ 508 6.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 510 IANA maintains a name space for RSVP protocol parameters "Resource 511 Reservation Protocol (RSVP) Parameters" (see 512 http://www.iana.org/assignments/rsvp-parameters). From the 513 sub-registry "Sub-Codes - 25 Notify Error" in registry "Error Codes 514 and Globally-Defined Error Value Sub-Codes", allocation of a new 515 error code is requested (Section 4.2). 517 As defined in [RFC3209], the Error Code 25 in the ERROR SPEC Object 518 corresponds to a Notify Error PathErr. This document adds a new 519 sub-code for this PathErr as follows: 521 o Preferable P2MP-TE Tree Exists sub-code: 523 +----------+--------------------+---------+---------+-----------+ 524 | Sub-code | Sub-code | PathErr | PathErr | Reference | 525 | value | Description | Code | Name | | 526 +----------+--------------------+---------+---------+-----------+ 527 | TBA by | Preferable P2MP-TE | 25 | Notify | This | 528 | IANA | Tree Exists | | Error | document | 529 +----------+--------------------+---------+---------+-----------+ 531 6.3. Fragment Identifier For S2L sub-LSP Descriptor 533 IANA maintains a name space for RSVP protocol parameters "Resource 534 Reservation Protocol (RSVP) Parameters" (see 535 http://www.iana.org/assignments/rsvp-parameters). From the 536 sub-registry "Class Types or C-Types 50 S2L_SUB_LSP" in registry 537 "Class Names, Class Numbers, and Class Types", allocation of new 538 C-Types is requested (Section 4.3). 540 As defined in [RFC4875], S2L_SUB_LSP Object is defined with 541 Class-Number 50 to identify a particular S2L sub-LSP belonging to the 542 P2MP-TE LSP. This document adds one new object type for this object 543 as follows: 545 o S2L_SUB_LSP_FRAG Object type: 547 +-----------------+---------------------------+-----------------+ 548 | C-Type value | Description | Reference | 549 +-----------------+---------------------------+-----------------+ 550 | TBA by IANA | S2L_SUB_LSP_FRAG | This document | 551 +-----------------+---------------------------+-----------------+ 553 7. Security Considerations 555 This document defines RSVP-TE signaling extensions to allow an 556 ingress node of a P2MP-TE LSP to request the re-evaluation of the 557 entire LSP tree, and for a mid-point LSR to notify the ingress node 558 of the existence of a preferable tree by sending a PathErr. As per 559 [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning multiple 560 domains, it may be desirable for a mid-point LSR to modify the RSVP 561 PathErr message defined in this document to preserve confidentiality 562 across domains. Furthermore, an ingress node may decide to ignore 563 this PathErr message coming from a mid-point LSR residing in another 564 domain. Similarly, a mid-point LSR may decide to ignore the P2MP-TE 565 tree re-evaluation request originating from another ingress domain. 567 This document also defines fragment identifier for the S2L sub-LSP 568 descriptor list when combining large number of S2L sub-LSPs in an 569 RSVP message and the message needs to be fragmented. The 570 introduction of the fragment identifier, by itself, introduce no 571 additional information to signaling. For a general discussions on 572 MPLS and GMPLS related security issues, see the MPLS/GMPLS security 573 framework [RFC5920]. 575 8. References 577 8.1. Normative References 579 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 580 Requirement Levels", BCP 14, RFC 2119, March 1997. 582 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 583 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 584 Functional Specification", RFC 2205, September 1997. 586 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 587 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 588 Tunnels", RFC 3209, December 2001. 590 [RFC4736] Vasseur, JP., Ikejiri, Y. and Zhang, R, "Reoptimization of 591 Multiprotocol Label Switching (MPLS) Traffic Engineering 592 (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, 593 November 2006. 595 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 596 "Extensions to Resource Reservation Protocol Traffic 597 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 598 Switched Paths (LSPs)", RFC 4875, May 2007. 600 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 601 Ayyangarps, "Encoding of Attributes for MPLS LSP 602 Establishment Using Resource Reservation Protocol Traffic 603 Engineering (RSVP-TE)", RFC 5420, February 2009. 605 8.2. Informative References 607 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation 608 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 609 March 2009. 611 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 612 Networks", RFC 5920, July 2010. 614 Acknowledgments 616 The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis 617 Villamizar, Dimitri Papadimitriou, Nobo Akiya and Vishnu Pavan Beeram 618 for reviewing this document. The authors would also like to thank 619 Ling Zeng for implementing mechanisms defined in this document. 621 Author's Addresses 623 Tarek Saad (editor) 624 Cisco Systems 626 EMail: tsaad@cisco.com 628 Rakesh Gandhi (editor) 629 Cisco Systems 631 EMail: rgandhi@cisco.com 633 Zafar Ali 634 Cisco Systems 636 EMail: zali@cisco.com 638 Robert H. Venator 639 Defense Information Systems Agency 641 EMail: robert.h.venator.civ@mail.mil 643 Yuji Kamite 644 NTT Communications Corporation 646 EMail: y.kamite@ntt.com