idnits 2.17.1 draft-ietf-teas-p2mp-loose-path-reopt-02.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 9, 2015) is 3326 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) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 1 warning (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 TEAS Working Group Tarek Saad, Ed. 3 Internet-Draft Rakesh Gandhi, Ed. 4 Intended status: Standards Track Zafar Ali 5 Expires: September 10, 2015 Cisco Systems, Inc. 6 Robert H. Venator 7 Defense Information Systems Agency 8 Yuji Kamite 9 NTT Communications Corporation 10 March 9, 2015 12 Extensions to Resource Reservation Protocol For Re-optimization 13 of Loosely Routed Point-to-Multipoint Traffic Engineering LSPs 14 draft-ietf-teas-p2mp-loose-path-reopt-02 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 re- 23 evaluation request and a mechanism for a mid-point LSR to notify an 24 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 RSVP-TE signaling extensions to allow an 28 ingress node of a P2MP-TE LSP to request the re-evaluation of the 29 entire LSP tree containing one or more S2L sub-LSPs whose paths are 30 loose (or abstract) hop expanded, and for a mid-point LSR to notify 31 to the ingress node that a preferable tree exists for the entire 32 P2MP-TE LSP. For re-optimizing a group of S2L sub-LSP(s) in a tree, 33 an S2L sub-LSP descriptor list can be used to signal one or more S2L 34 sub-LSPs in an RSVP message. This document defines markers to 35 indicate beginning and end of an S2L sub-LSP descriptor list when the 36 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) 2015 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 Markers . . . . . . 9 86 4. Message and Object Definitions . . . . . . . . . . . . . . . . 10 87 4.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 10 88 4.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 10 89 4.3. Markers For S2L sub-LSP Descriptor . . . . . . . . . . . . 11 90 5. Compatibility . . . . . . . . . . . . . . . . . . . . . . . . 11 91 6. Security Considerations . . . . . . . . . . . . . . . . . . . 12 92 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 93 7.1. P2MP-TE Tree Re-evaluation Request Flag . . . . . . . . . 12 94 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code . . . . 13 95 7.3. BEGIN and END Markers For S2L sub-LSP Descriptor . . . . . 13 96 8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 14 97 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 9.1. Normative References . . . . . . . . . . . . . . . . . . . 15 99 9.2. Informative References . . . . . . . . . . . . . . . . . . 15 100 Author's Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 102 1. Introduction 104 This document defines Resource Reservation Protocol - Traffic 105 Engineering (RSVP-TE) [RFC2205] [RFC3209] signaling extensions for 106 re-optimizing loosely routed Point-to-Multipoint (P2MP) Traffic 107 Engineered (TE) Label Switched Paths (LSPs) [RFC4875] in an 108 Multi-Protocol Label Switching (MPLS) and/or Generalized MPLS (GMPLS) 109 networks. 111 A P2MP-TE LSP is comprised of one or more source-to-leaf (S2L) 112 sub-LSPs. A loosely routed P2MP-TE S2L sub-LSP is defined as one 113 whose path does not contain the full explicit route identifying each 114 node along the path to the egress node at the time of its signaling 115 by the ingress node. Such an S2L sub-LSP is signaled with no 116 Explicit Route Object (ERO) [RFC3209], or with an ERO that contains 117 at least one loose hop, or with an ERO that contains an abstract node 118 that is not a simple abstract node (that is, an abstract node that 119 identifies more than one node). This is often the case with 120 inter-domain P2MP-TE LSPs where Path Computation Element (PCE) is not 121 used [RFC5440]. 123 As per [RFC4875], an ingress node may re-optimize the entire P2MP-TE 124 LSP by re-signaling all its S2L sub-LSP(s) or may re-optimize 125 individual or group of S2L sub-LSP(s) i.e. individual or group of 126 destination(s). 128 [RFC4736] defines RSVP signaling extensions for re-optimizing loosely 129 routed Point-to-Point (P2P) TE LSP(s) as follows: 131 o A mid-point LSR that expands loose next-hop(s) sends a solicited 132 or unsolicited PathErr with the Notify error code (25 as defined in 133 [RFC3209]) with sub-code 6 to indicate "Preferable Path Exists" to 134 the ingress node. 136 o An ingress node triggers a path re-evaluation request at all 137 mid-point LSR(s) that expands loose next-hop(s) by setting the "Path 138 Re-evaluation Request" flag (0x20) in SESSION_ATTRIBUTES Object in 139 the Path message. 141 o The ingress node upon receiving this PathErr either solicited or 142 unsolicited initiates re-optimization of the LSP with a different 143 LSP-ID. 145 Following Sections discuss the issues that may arise when using 146 existing mechanisms defined in [RFC4736] for re-optimizing loosely 147 routed P2MP-TE LSPs. 149 1.1. Loosely Routed Inter-domain P2MP-TE LSP Tree 151 An example of a loosely routed inter-domain P2MP-TE LSP tree is shown 152 in Figure 1. In this example, the P2MP-TE LSP tree consists of 3 S2L 153 sub-LSPs, to destinations (i.e. leafs) R10, R11 and R12 from the 154 ingress node (i.e. source) R1. Nodes R2 and R5 are branch nodes and 155 nodes ABR3, ABR4, ABR7, ABR8 and ABR9 are area border routers. For 156 the S2L sub-LSP to destination R10, nodes ABR3, ABR7 and R10 are 157 defined as loose hops. For the S2L sub-LSP to destination R11, nodes 158 ABR3, ABR8 and R11 are defined as loose hops. For the S2L sub-LSP to 159 destination R12, nodes ABR4, ABR9 and R12 are defined as loose hops. 161 <--area1--><--area0--><-area2-> 163 ABR7---R10 164 / 165 / 166 ABR3---R5 167 / \ 168 / \ 169 R1---R2 ABR8---R11 170 \ 171 \ 172 ABR4---R6 173 \ 174 \ 175 ABR9---R12 177 Figure 1: An Example of Loosely Routed Inter-domain P2MP-TE LSP Tree 179 1.2. Existing Mechanism For Tree-Based P2MP-TE LSP Re-optimization 181 [RFC4736] does not define signaling extensions specific for 182 re-optimizing entire P2MP-TE LSP tree. Mechanisms defined in 183 [RFC4736] can be used for signaling the re-optimization of individual 184 or group of S2L sub-LSP(s). However, to use [RFC4736] mechanisms for 185 re-optimizing an entire P2MP-TE LSP tree, an ingress node needs to 186 send the path re-evaluation requests on all (typically 100s of) S2L 187 sub-LSPs and the mid-point LSR to notify PathErrs for all S2L 188 sub-LSPs. Such mechanisms may lead to the following issues: 190 o A mid-point LSR that expands loose next-hop(s) may have to 191 accumulate the received path re-evaluation request(s) for all S2L 192 sub-LSPs (e.g. by using a wait timer) and interpret them as a 193 re-optimization request for the whole P2MP-TE LSP tree. Otherwise, a 194 mid-point LSR may prematurely notify "Preferable Path Exists" for one 195 or a sub-set of S2L sub-LSPs. 197 o Similarly, the ingress node may have to heuristically determine 198 when to perform entire P2MP-TE LSP tree re-optimization versus per 199 S2L sub-LSP re-optimization, for example, to delay re-optimization 200 long enough to allow all PathErr(s) to be received. Such procedures 201 may produce undesired results due to timing related issues. 203 o The ingress node that receives (un)solicited PathErr 204 notification(s) for individual S2L sub-LSP(s), may prematurely start 205 re-optimizing the sub-set of S2L sub-LSPs. However, as mentioned in 206 [RFC4875] Section 14.2, such sub-group based re-optimization 207 procedure may result in data duplication that can be avoided if the 208 entire P2MP-TE LSP tree is re-optimized using a different LSP-ID, 209 especially if the ingress node eventually receives PathErr 210 notifications for all S2L sub-LSPs of the P2MP-TE LSP tree. 212 In order to address above mentioned issues and to align re- 213 optimization of P2MP-TE LSP with P2P LSP [RFC4736], there is a need 214 for a mechanism to trigger re-optimization of the LSP tree by re- 215 signaling all S2L sub-LSPs with a different LSP-ID. To meet this 216 requirement, this document defines RSVP-TE signaling extensions for 217 the ingress node to trigger the re-evaluation of the P2MP LSP tree on 218 every hop that has a next-hop defined as a loose or abstract hop for 219 one or more S2L sub-LSP path, and a mid-point LSR to signal to the 220 ingress node that a preferable LSP tree exists (compared to the 221 current path) or that the whole P2MP-TE LSP must be re-optimized 222 (because of maintenance required on the TE LSP path). 224 1.3. Existing Mechanism For Sub-Group-Based P2MP-TE LSP Re-optimization 226 Based on [RFC4875] (Section 14.2 "Sub-Group-Based Re-Optimization"), 227 an ingress node may trigger path re-evaluation requests using the 228 procedures defined in [RFC4736] for a set of S2L sub-LSPs and 229 combining multiple Path messages using S2L sub-LSP descriptor list. 230 Similarly, a mid-point LSR may send a PathErr message (with Error 231 code 25, sub-code 6) containing a list of S2L sub-LSPs transiting 232 through the LSR using an S2L sub-LSP descriptor list to notify the 233 ingress node. This method can be used for re-optimizing a sub-group 234 of S2L sub-LSPs within an LSP tree using the same LSP-ID. This 235 method can alleviate the scale issue associated with sending RSVP 236 messages for individual S2L sub-LSPs. However, this procedure can 237 lead to the following issues when used to re-optimize the LSP tree: 239 o Path message that is intended to carry the path re-evaluation 240 request as defined in [RFC4736] with a full list of S2L sub-LSPs in 241 S2L sub-LSPs descriptor list will be decomposed at branching LSRs, 242 and only a subset of the S2L sub-LSPs that are routed over the same 243 next-hop will be added in the descriptor list of the Path message 244 propagated to downstream mid-point LSRs. Consequently, when a 245 preferable path exists at such mid-point LSRs, the PathErr can only 246 include the sub-set of S2L sub-LSPs traversing the LSR. In this 247 case, at the ingress node there is no way to distinguish which mode 248 of re-optimization to invoke, i.e. sub-group based re-optimization 249 using the same LSP-ID or tree based re-optimization using a different 250 LSP-ID. 252 o An LSR may fragment a large RSVP message (when a combined message 253 may not be large enough to fit all S2L sub-LSPs). In this case, the 254 ingress node may receive multiple PathErrs with sub-sets of S2L 255 sub-LSPs in each (either due to the combined Path message got 256 fragmented or combined PathErr message got fragmented) and would 257 require additional logic to infer to re-optimize the LSP tree (for 258 example, waiting for some time to aggregate all possible PathErr 259 messages before taking an action). 261 In order to address the above mentioned issue due to the RSVP message 262 fragmentation, this document defines markers to indicate beginning 263 and end of an S2L sub-LSP descriptor list when combining large number 264 of S2L sub-LSPs in an RSVP message. 266 2. Conventions Used in This Document 268 2.1. Key Word Definitions 270 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 271 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 272 document are to be interpreted as described in [RFC2119]. 274 The reader is assumed to be familiar with the terminology in 275 [RFC4875] and [RFC4736]. 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 3. Signaling Procedure For Loosely Routed P2MP-TE LSP Re-optimization 311 3.1. Tree-Based Re-optimization 313 To evaluate an entire P2MP-TE LSP tree on mid-point LSRs that expand 314 loose next-hop(s), an ingress node MAY send a Path message with 315 "P2MP-TE Tree Re-evaluation Request" defined in this document. The 316 ingress node SHOULD select one of the S2L sub-LSPs of the P2MP-TE LSP 317 tree transiting a mid-point LSR to trigger the re-evaluation request. 318 The ingress node MAY send a re-evaluation request to each border LSR 319 on the path of the LSP tree. 321 A mid-point LSR that expands loose next-hop(s) for one or more S2L 322 sub-LSP path(s), and that receives a Path message with the "P2MP-TE 323 Tree Re-evaluation Request" bit set: 325 o The mid-point LSR SHOULD check for a preferable P2MP-TE LSP tree 326 by re-evaluating all S2L sub-LSP(s) that are expanded paths of the 327 loose next-hops of the P2MP-TE LSP. 329 o If a preferable P2MP-TE LSP tree is found, the mid-point LSR MAY 330 send an RSVP PathErr to the ingress node with Error code 25 (Notify 331 defined in [RFC3209] and sub-code "Preferable P2MP-TE Tree Exists" 332 defined in this document. The mid-point LSR, in turn, SHOULD NOT 333 propagate the "P2MP-TE Tree Re-evaluation Request" bit in subsequent 334 RSVP Path messages sent downstream for the re-evaluated P2MP-TE LSP. 336 o If no preferable tree for P2MP-TE LSP can be found, the 337 recommended mode is that the mid-point LSR that expands loose next- 338 hop(s) for one or more S2L sub-LSP path(s) SHOULD propagate the 339 request downstream by setting the "P2MP-TE Tree Re-evaluation 340 Request" bit in the LSP_ATTRIBUTES Object of RSVP Path message. 342 A mid-point LSR MAY send an unsolicited PathErr message with 343 "Preferable P2MP-TE Tree Exists" PathErr to the ingress node to 344 notify of a preferred P2MP-TE LSP tree when it determines it exists. 345 In this case, the mid-point LSR that expands loose next-hop(s) for 346 one or more S2L sub-LSP path(s) SHOULD select one of the S2L sub- 347 LSP(s) of the P2MP-TE LSP tree to send this PathErr message to the 348 ingress node. 350 The sending of an RSVP PathErr Notify message "Preferable P2MP-TE 351 Tree Exists" to the ingress node SHALL notify the ingress node of the 352 existence of a preferable P2MP-TE LSP tree and upon receiving this 353 PathErr, the ingress node MAY trigger re-optimization of the LSP 354 using a different LSP-ID. 356 3.2. Sub-Group-Based Re-optimization Using Markers 358 It might be preferable, as per [RFC4875], to re-optimize the entire 359 P2MP-TE LSP by re-signaling all of its S2L sub-LSP(s) (Section 14.1, 360 "Make-before-Break") or to re-optimize individual or group of S2L 361 sub-LSP(s) i.e. individual or group of destination(s) (Section 14.2 362 "Sub-Group-Based Re-Optimization" in [RFC4875]), both using the same 363 LSP-ID. For loosely routed S2L sub-LSPs, this can be achieved by 364 using the procedures defined in [RFC4736] to re-optimize one or more 365 S2L sub-LSP(s) of the P2MP-TE LSP. 367 An ingress node may trigger path re-evaluation requests using the 368 procedures defined in [RFC4736] for a set of S2L sub-LSPs by 369 combining multiple Path messages using an S2L sub-LSP descriptor list 370 [RFC4875]. An S2L sub-LSP descriptor list is created using a series 371 of S2L_SUB_LSP Objects as defined in [RFC4875]. Similarly, a mid- 372 point LSR may send a PathErr message (with Error code 25, sub-code 6, 373 Preferable Path Exists) containing a list of S2L sub-LSPs transiting 374 through the LSR using an S2L sub-LSP descriptor list to notify the 375 ingress node of preferable paths available. 377 As per [RFC4875] (Section 5.2.3, "Transit Fragmentation of Path State 378 Information"), when a Path message is not large enough to fit all S2L 379 sub-LSPs in the descriptor list, an LSR may fragment the message. In 380 this case, the LSR MAY add S2L_SUB_LSP_MARKER_BEGIN and 381 S2L_SUB_LSP_MARKER_END Objects defined in this document at the 382 beginning and at the end of the S2L sub-LSP descriptor list, 383 respectively. 385 Both S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Objects 386 defined in this document are optional. However, a node MUST add the 387 S2L_SUB_LSP_MARKER_END Object if it has added 388 S2L_SUB_LSP_MARKER_BEGIN Object in the S2L sub-LSP descriptor list. 390 A mid-point LSR SHOULD wait to accumulate all S2L sub-LSPs before 391 attempting to re-evaluate preferable path when a Path message for 392 "Path Re-evaluation Request" is received with 393 S2L_SUB_LSP_MARKER_BEGIN Object. An ingress node SHOULD wait to 394 accumulate all S2L sub-LSPs before attempting to trigger 395 re-optimization when a PathErr message with "Preferable Path Exists" 396 is received with S2L_SUB_LSP_MARKER_BEGIN Object. 398 New objects S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END 399 defined in this document have a wider applicability other than the 400 P2MP-TE LSP re-optimization but it is outside the scope of this 401 document. 403 4. Message and Object Definitions 405 4.1. P2MP-TE Tree Re-evaluation Request Flag 407 In order to trigger a tree re-evaluation request, a new flag is 408 defined in Attributes Flags TLV of the LSP_ATTRIBUTES Object 409 [RFC5420] as follows: 411 Bit Number (to be assigned by IANA): P2MP-TE Tree Re-evaluation 412 Request flag 414 The "P2MP-TE Tree Re-evaluation Request" flag is meaningful in a Path 415 message of a P2MP-TE S2L sub-LSP and is inserted by the ingress node. 417 4.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 419 In order to indicate to an ingress node that a preferable P2MP-TE LSP 420 tree exists, the following new sub-code for PathErr code 25 (Notify 421 Error) [RFC3209] is defined: 423 Sub-code (to be assigned by IANA): Preferable P2MP-TE Tree Exists 424 sub-code 426 When a preferable path for P2MP-TE LSP tree exists, the mid-point LSR 427 sends a solicited or unsolicited "Preferable P2MP-TE Tree Exists" 428 PathErr notification to the ingress node of the P2MP-TE LSP. 430 4.3. Markers For S2L sub-LSP Descriptor 432 An S2L_SUB_LSP Object [RFC4875] identifies a particular S2L sub-LSP 433 belonging to the P2MP-TE LSP. An S2L sub-LSP descriptor list is 434 created using a series of S2L_SUB_LSP Objects as defined in 435 [RFC4875]. In order to indicate the beginning and end of the S2L 436 sub-LSP descriptor list when the RSVP message needs to be fragmented 437 due to large number of S2L sub-LSPs, the following new types are 438 defined for the S2L_SUB_LSP Object [RFC4875]. 440 S2L_SUB_LSP_MARKER_BEGIN : 442 Class-Num 50, C-Type TBA by IANA 444 +-----------------+---------------+--------------------------+ 445 | Length (4 bytes)| Class_Num 50 | S2L_SUB_LSP_MARKER_BEGIN | 446 +-----------------+---------------+--------------------------+ 448 S2L_SUB_LSP_MARKER_END : 450 Class-Num 50, C-Type TBA by IANA 452 +-----------------+---------------+--------------------------+ 453 | Length (4 bytes)| Class_Num 50 | S2L_SUB_LSP_MARKER_END | 454 +-----------------+---------------+--------------------------+ 456 The S2L_SUB_LSP_MARKER_BEGIN Object is added before adding the first 457 S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object and the 458 S2L_SUB_LSP_MARKER_END Object is added after adding the last 459 S2L_SUB_LSP_IPv4 or S2L_SUB_LSP_IPv6 Object in the S2L sub-LSP 460 descriptor list. 462 5. Compatibility 464 The LSP_ATTRIBUTES Object has been defined in [RFC5420] with class 465 numbers in the form 11bbbbbb, which ensures compatibility with 466 non-supporting nodes. Per [RFC2205], nodes not supporting this 467 extension will ignore the new flag defined in this document but 468 forward it without modification. 470 The S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Objects have 471 been defined with class numbers in the form 11bbbbbb, which ensures 472 compatibility with non-supporting nodes. Per [RFC2205], nodes not 473 supporting new S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END 474 Objects will ignore them but forward it without modification. 476 6. Security Considerations 478 This document defines RSVP-TE signaling extensions to allow an 479 ingress node of a P2MP-TE LSP to request the re-evaluation of the 480 entire LSP tree, and for a mid-point LSR to notify the ingress node 481 of the existence of a preferable tree by sending a PathErr. As per 482 [RFC4736], in the case of a P2MP-TE LSP S2L sub-LSP spanning multiple 483 domains, it may be desirable for a mid-point LSR to modify the RSVP 484 PathErr message defined in this document to preserve confidentiality 485 across domains. Furthermore, an ingress node may decide to ignore 486 this PathErr message coming from a mid-point LSR residing in another 487 domain. Similarly, a mid-point LSR may decide to ignore the P2MP-TE 488 tree re-evaluation request originating from another ingress domain. 490 This document also defines markers to indicate beginning and end of 491 an S2L sub-LSP descriptor list when combining large number of S2L 492 sub-LSPs in an RSVP message and the message needs to be fragmented. 493 The introduction of these markers, by themselves, introduce no 494 additional information to signaling. For a general discussions on 495 MPLS and GMPLS related security issues, see the MPLS/GMPLS security 496 framework [RFC5920]. 498 7. IANA Considerations 500 IANA is requested to administer assignment of new values for 501 namespace defined in this document and summarized in this section. 503 7.1. P2MP-TE Tree Re-evaluation Request Flag 505 IANA maintains a name space for RSVP-TE TE parameters "Resource 506 Reservation Protocol-Traffic Engineering (RSVP-TE) Parameters" (see 507 http://www.iana.org/assignments/rsvp-te-parameters). From the 508 registries in this name space "Attribute Flags", allocation of new 509 flag is requested (Section 4.1). 511 The following new flag is defined for the Attributes Flags TLV in the 512 LSP_ATTRIBUTES Object [RFC5420]. The numeric value is to be assigned 513 by IANA. 515 o P2MP-TE Tree Re-evaluation Request Flag: 517 +--------+---------------+---------+---------+---------+------------+ 518 | Bit No | Attribute | Carried | Carried | Carried | Reference | 519 | | Flag Name | in Path | in Resv | in RRO | | 520 +--------+---------------+---------+---------+---------+------------+ 521 | TBA by | P2MP-TE Tree | Yes | No | No | This | 522 | IANA | Re-evaluation | | | | document | 523 +--------+---------------+---------+---------+---------+------------+ 525 7.2. Preferable P2MP-TE Tree Exists Path Error Sub-code 527 IANA maintains a name space for RSVP protocol parameters "Resource 528 Reservation Protocol (RSVP) Parameters" (see 529 http://www.iana.org/assignments/rsvp-parameters). From the 530 sub-registry "Sub-Codes - 25 Notify Error" in registry "Error Codes 531 and Globally-Defined Error Value Sub-Codes", allocation of a new 532 error code is requested (Section 4.2). 534 As defined in [RFC3209], the Error Code 25 in the ERROR SPEC Object 535 corresponds to a Notify Error PathErr. This document adds a new 536 sub-code for this PathErr as follows: 538 o Preferable P2MP-TE Tree Exists sub-code: 540 +----------+--------------------+---------+---------+-----------+ 541 | Sub-code | Sub-code | PathErr | PathErr | Reference | 542 | value | Description | Code | Name | | 543 +----------+--------------------+---------+---------+-----------+ 544 | TBA by | Preferable P2MP-TE | 25 | Notify | This | 545 | IANA | Tree Exists | | Error | document | 546 +----------+--------------------+---------+---------+-----------+ 548 7.3. BEGIN and END Markers For S2L sub-LSP Descriptor 550 IANA maintains a name space for RSVP protocol parameters "Resource 551 Reservation Protocol (RSVP) Parameters" (see 552 http://www.iana.org/assignments/rsvp-parameters). From the 553 sub-registry "Class Types or C-Types 50 S2L_SUB_LSP" in registry 554 "Class Names, Class Numbers, and Class Types", allocation of new 555 C-Types is requested (Section 4.3). 557 As defined in [RFC4875], S2L_SUB_LSP Object is defined with 558 Class-Number 50 to identify a particular S2L sub-LSP belonging to the 559 P2MP-TE LSP. This document adds two new object types for this object 560 as follows: 562 o S2L_SUB_LSP_MARKER_BEGIN and S2L_SUB_LSP_MARKER_END Object types: 564 +---------------+---------------------------+-----------------+ 565 | C-Type value | Description | Reference | 566 +---------------+---------------------------+-----------------+ 567 | TBA by IANA | S2L_SUB_LSP_MARKER_BEGIN | This document | 568 +---------------+---------------------------+-----------------+ 569 | TBA by IANA | S2L_SUB_LSP_MARKER_END | This document | 570 +---------------+---------------------------+-----------------+ 572 8. Acknowledgments 574 The authors would like to thank Loa Andersson, Sriganesh Kini, Curtis 575 Villamizar, Dimitri Papadimitriou and Nobo Akiya for reviewing this 576 document. The authors would also like to thank Ling Zeng for 577 implementing mechanisms defined in this document. 579 9. References 581 9.1. Normative References 583 [RFC2205] Braden, R., Ed., Zhang, L., Berson, S., Herzog, S., and S. 584 Jamin, "Resource ReSerVation Protocol (RSVP) -- Version 1 585 Functional Specification", RFC 2205, September 1997. 587 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 588 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 589 Tunnels", RFC 3209, December 2001. 591 [RFC4875] Aggarwal, R., Papadimitriou, D., and S. Yasukawa, 592 "Extensions to Resource Reservation Protocol Traffic 593 Engineering (RSVP-TE) for Point-to-Multipoint TE Label 594 Switched Paths (LSPs)", RFC 4875, May 2007. 596 [RFC5420] Farrel, A., Papadimitriou, D., Vasseur, JP., and A. 597 Ayyangarps, "Encoding of Attributes for MPLS LSP 598 Establishment Using Resource Reservation Protocol Traffic 599 Engineering (RSVP-TE)", RFC 5420, February 2009. 601 9.2. Informative References 603 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 604 Requirement Levels", BCP 14, RFC 2119, March 1997. 606 [RFC4736] Vasseur, JP., Ikejiri, Y. and Zhang, R, "Reoptimization of 607 Multiprotocol Label Switching (MPLS) Traffic Engineering 608 (TE) Loosely Routed Label Switched Path (LSP)", RFC 4736, 609 November 2006. 611 [RFC5440] Vasseur, JP., Ed., and JL. Le Roux, Ed., "Path Computation 612 Element (PCE) Communication Protocol (PCEP)", RFC 5440, 613 March 2009. 615 [RFC5920] Fang, L., "Security Framework for MPLS and GMPLS 616 Networks", RFC 5920, July 2010. 618 Author's Addresses 620 Tarek Saad (editor) 621 Cisco Systems 623 Email: tsaad@cisco.com 625 Rakesh Gandhi (editor) 626 Cisco Systems 628 Email: rgandhi@cisco.com 630 Zafar Ali 631 Cisco Systems 633 Email: zali@cisco.com 635 Robert H. Venator 636 Defense Information Systems Agency 638 Email: robert.h.venator.civ@mail.mil 640 Yuji Kamite 641 NTT Communications Corporation 643 Email: y.kamite@ntt.com