idnits 2.17.1 draft-ali-ccamp-xro-lsp-subobject-00.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: ---------------------------------------------------------------------------- == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 1) being 70 lines Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Introduction section. (A line matching the expected section header was found, but with an unexpected indentation: ' 1. Introduction' ) ** The document seems to lack a Security Considerations section. (A line matching the expected section header was found, but with an unexpected indentation: ' 3. Security Considerations' ) ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) (A line matching the expected section header was found, but with an unexpected indentation: ' 4. IANA Considerations' ) ** There is 1 instance of lines with control characters in the document. ** The abstract seems to contain references ([RFC4874]), which it shouldn't. Please replace those with straight textual mentions of the documents in question. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to contain a disclaimer for pre-RFC5378 work, but was first submitted on or after 10 November 2008. The disclaimer is usually necessary only for documents that revise or obsolete older RFCs, and that take significant amounts of text from those RFCs. If you can contact all authors of the source material and they are willing to grant the BCP78 rights to the IETF Trust, you can and should remove the disclaimer. Otherwise, the disclaimer is needed and you can ignore this comment. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 05, 2012) is 4435 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) -- Missing reference section? 'RFC4874' on line 602 looks like a reference -- Missing reference section? 'RFC2119' on line 590 looks like a reference -- Missing reference section? 'RFC4208' on line 608 looks like a reference -- Missing reference section? 'RFC4894' on line 122 looks like a reference -- Missing reference section? 'RFC3209' on line 593 looks like a reference -- Missing reference section? 'RFC5920' on line 618 looks like a reference -- Missing reference section? 'RFC2205' on line 546 looks like a reference -- Missing reference section? 'RFC3473' on line 597 looks like a reference -- Missing reference section? 'RFC2209' on line 614 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 10 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 CCAMP Working Group Zafar Ali 3 Internet Draft George Swallow 4 Intended status: Standard Track Clarence Filsfils 5 Expires: September 04, 2012 Matt Hartley 6 Ori Gerstel 7 Gabriele Maria Galimberti 8 Cisco Systems 9 March 05, 2012 11 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) LSP 12 Route Diversity using Exclude Routes 14 draft-ali-ccamp-xro-lsp-subobject-00.txt 16 Status of this Memo 18 This Internet-Draft is submitted in full conformance with the 19 provisions of BCP 78 and BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF). Note that other groups may also distribute 23 working documents as Internet-Drafts. The list of current 24 Internet-Drafts is at 25 http://datatracker.ietf.org/drafts/current/. 27 Internet-Drafts are draft documents valid for a maximum of six 28 months and may be updated, replaced, or obsoleted by other 29 documents at any time. It is inappropriate to use Internet- 30 Drafts as reference material or to cite them other than as "work 31 in progress." 33 This Internet-Draft will expire on September 03, 2012. 35 Copyright Notice 37 Copyright (c) 2012 IETF Trust and the persons identified as the 38 document authors. All rights reserved. 40 This document is subject to BCP 78 and the IETF Trust's Legal 41 Provisions Relating to IETF Documents 42 (http://trustee.ietf.org/license-info) 43 in effect on the date of publication of this document. Please 44 review these documents carefully, as they describe your rights and 45 restrictions with respect to this document. Code Components 46 extracted from this document must include Simplified BSD License 47 text as described in Section 4.e of the Trust Legal Provisions 48 and are provided without warranty as described in the Simplified 49 BSD License. 51 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 53 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before 55 November 10, 2008. The person(s) controlling the copyright in 56 some of this material may not have granted the IETF Trust the 57 right to allow modifications of such material outside the IETF 58 Standards Process. Without obtaining an adequate license from the 59 person(s) controlling the copyright in such materials, this 60 document may not be modified outside the IETF Standards Process, 61 and derivative works of it may not be created outside the IETF 62 Standards Process, except to format it for publication as an RFC 63 or to translate it into languages other than English. 65 Abstract 67 [RFC4874] specifies methods by which route exclusions may be 68 communicated during RSVP-TE signaling in networks where precise 69 explicit paths are not computed by the LSP ingress node. This 70 document specifies signaling for additional route exclusions based 71 on LSPs currently existing or expected to exist within the network. 73 Conventions used in this document 75 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 76 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 77 document are to be interpreted as described in RFC 2119 [RFC2119]. 79 Table of Contents 81 1. Introduction ...............................................3 82 1.1. Requirements Notation .................................4 83 2. RSVP-TE signaling extensions ...............................5 84 2.1. Terminology ...........................................5 85 2.2. LSP Subobject .........................................5 86 2.3. Processing rules for the LSP subobject ................8 87 2.4. LSP Subobject in Explicit Exclusion Route Subobject ..11 88 2.4.1. Processing Rules for the EXRS with LSP subobject.12 89 4. IANA Considerations .......................................12 90 4.1. New XRO subobject type ...............................12 91 4.2. New EXRS subobject type ..............................12 92 4.3. New RSVP error sub-code ..............................12 93 5. Acknowledgement ...........................................13 94 6. References 95 ................................................13 96 6.1. Normative References .................................13 97 6.2. Informative References ...............................13 98 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 100 1. Introduction 102 Label-Switched Path (LSP) diversity is required to ensure LSPs may 103 be established without sharing resources, thus greatly reducing 104 the probability of simultaneous connection failures. 106 LSP diversity is a well-known requirement from Service Providers. 107 When route computation for LSPs that need to be diverse is 108 performed at ingress node, this requirement can be met by a local 109 decision at that node. However, there are scenarios when route 110 computations are performed by remote nodes, in which case there is 111 a need for relevant diversity requirements to be communicated to 112 those nodes. These include (but are not limited to): 114 . LSPs with loose hops in the Explicit Route Object (ERO), e.g. 115 inter-domain LSPs. 117 . Generalized Multi-Protocol Label Switching (GMPLS) User- 118 Network Interface (UNI) where route computation may be 119 performed by the UNI-Network (server) node [RFC4208]; 121 The eXclude Route Object (XRO) and Explicit Exclusion Route 122 Subobject (EXRS) specification [RFC4894] introduces a means of 123 specifying nodes and resources to be excluded from routes, using 124 the XRO and/ or EXRS. 126 [RFC4874] facilitates the calculation of diverse routes for LSPs 127 based on known properties of those LSPs including addresses of 128 links and nodes traversed, and Shared Risk Link Groups (SRLGs) of 129 traversed links. This requires that these properties of the LSP(s) 130 from which diversity is required be known to the ingress node 131 which initiates signaling. However, there are circumstances under 132 which this may not be possible or desirable, including (but not 133 limited to): 135 . Exclusion of the route of a LSP which does not originate, 136 terminate or traverse the ingress node signaling the diverse 137 LSP, in which case the addresses and SRLGs of the LSP from 138 which diversity is required are unknown to the ingress node. 140 . Exclusion of the route of a LSP which, while known at the 141 ingress node of the diverse LSP, has incomplete or unavailable 142 route information, e.g. due to confidentiality of the LSP route 143 attributes. In other words, the scenario in which the reference 144 LSP is hosted by the ingress/ requesting node but the 145 properties required to construct an XRO object are not known to 146 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 148 ingress/ requesting node. Inter-domain and GMPLS overlay 149 networks may present such restrictions. 151 . If the route of the reference LSP from which diversity is 152 required (e.g. LSP1) is known to the ingress node, that node 153 can use this information to construct an XRO and send it in the 154 path message during the signaling of a diverse LSP (LSP2). 155 However, if the route of LSP1 changes (e.g. due to re- 156 optimization or failure in the network), the ingress node would 157 need to change path of LSP2 to ensure that it remains diverse 158 from LSP1. It is preferable to have this decision made by the 159 node that calculated the path for LSP2. For example, in the 160 case of GMPLS-UNI, it is better to have such responsibility at 161 the server layer as opposed to at the client layer so that the 162 diversity requirements are transparent to the client layer. 163 Furthermore, in all networking scenarios, if the node 164 performing the route computation/ expansion is aware of the 165 diversity requirements of LSP1 and LSP2, it may consider joint 166 re-optimization of the diverse LSPs. 168 This document addresses such scenarios and defines procedures 169 that may be used to exclude the route taken by a particular LSP, 170 or the route taken by all LSPs belonging to a single tunnel. Note 171 that this diversity requirement is different from the diversity 172 requirements of path protection where both the reference and 173 diverse LSPs belong to the same tunnel. The diversity 174 requirements considered in this document do not require that the 175 LSPs in question belonging to the same tunnel or share an ingress 176 node. 178 The means by which the node calculating or expanding the route of 179 the signaled LSP discovers the route of the LSPs from which the 180 signaled LSP requires diversity is beyond the scope of this 181 document. However, in most cases the LSPs with route diversity 182 requirements may transit the node expanding the route. 184 This document addresses only the exclusion of point-to-point 185 tunnels; point-to-multipoint tunnels will be addressed in a 186 future version. Similarly, at present only IPv4 addresses are 187 considered; support for IPv6 addresses will be added in a future 188 version. 190 1.1. Requirements Notation 192 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 193 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 194 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 196 "OPTIONAL" in this document are to be interpreted as described in 197 [RFC2119]. 199 2. RSVP-TE signaling extensions 201 This section describes the signaling extensions required to 202 address the aforementioned requirements. Specifically, this 203 document defines a new LSP subobject to be signaled in the 204 EXCLUDE_ROUTE object (XRO) and/ or Explicit Exclusion Route 205 Subobject (EXRS) defined in [RFC4874]. Inclusion of the LSP 206 subobject in any other RSVP object is not defined. 208 2.1. Terminology 210 In this document, the following terminology is adapted: 212 LSP1/TUNNEL1: LSP1/TUNNEL1 is the LSP/tunnel from which diversity 213 is required. 215 LSP2/TUNNEL2: The term LSP2/TUNNEL2 is used to refer the LSP 216 being signaled with XRO/ EXRS containing the LSP subobject 217 referencing LSP1/TUNNEL1. 219 CircuitID: The term CircuitID refers to the LSP Forwarding 220 Equivalence Class (FEC) (LSP ID field of the FEC may be ignored 221 depending on the context the CircuitID term is used). 223 CircuitIDx: The term CicuitIDx refers to CircuitID of 224 LSPx/TUNNELx. 226 2.2. LSP Subobject 228 A new IPv4 Point-to-Point (P2P) LSP subobject is defined by this 229 document as follows (IPv6 P2P LSP subobject will be defined in a 230 later version of the document). 232 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 234 0 1 2 3 235 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 236 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 237 |L| Type | Length |Attribute Flags|Exclusion Flags| 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 | IPv4 tunnel end point address | 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | Must Be Zero | Tunnel ID | 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Extended Tunnel ID | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | IPv4 tunnel sender address | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | Must Be Zero | LSP ID | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 L 251 The L-flag is used as for the other XRO subobjects defined 252 in [RFC4874]. 253 0 indicates that the attribute specified MUST be excluded. 254 1 indicates that the attribute specified SHOULD be 255 avoided. 257 Type 258 A new subobject type is introduced; the subobject type is 259 to be defined by IANA (suggested value: 36). 261 Length 263 The length contains the total length of the subobject in 264 bytes, including the type and length fields. The length is 265 always 24. 267 Attribute Flags 269 The Attribute Flags are used to communicate desirable 270 attributes of the LSP being signaled (In the following, the 271 term LSP2 is used to reference the LSP being signaled; 272 please refer to Section 2.1 for definition of LSP2). The 273 following flags are defined. None, all or multiple 274 attribute flags MAY be set within the same subobject. 276 0x01 = LSP ID to be ignored 278 This flag is used to indicate tunnel level exclusion. 279 Specifically, this flag is used to indicate that the 280 lsp-id field of the subobject is to be ignored and the 281 exclusion applies to any LSP matching the rest of the 282 supplied FEC. In other words, if this flag is set, the 283 processing node MUST calculate a route based on 284 exclusions from the routes of all known LSPs matching 285 the tunnel-id, source, destination and extended tunnel- 286 id specified in the subobject. 288 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 290 When this flag is not set, the lsp-id is not ignored and 291 the exclusion applies only to the specified LSP (i.e., 292 LSP level exclusion). In other words, when this flag is 293 not set, route exclusions MUST respect the specified LSP 294 (i.e. the lsp-id, the tunnel-id, source, destination and 295 extended tunnel-id specified needs to be respected 296 during exclusion). 298 0x02 = Destination node exception 300 This flag is used to indicate that the destination node 301 may be shared even when sharing of the said node 302 violates the exclusion flags. When this flag is not set, 303 the exclusion flags SHOULD also be respected for the 304 destination node. 306 0x04 = Processing node exception 308 This flag is used to indicate that the processing node 309 may be shared even when sharing of the said node 310 violates the exclusion flags. When this flag is not set, 311 the exclusion flags SHOULD also be respected for the 312 processing node. 314 0x08 = Penultimate node exception 316 This flag is used to indicate that the penultimate node 317 may be shared even when sharing of the said node 318 violates the exclusion flags. When this flag is not set, 319 the exclusion flags SHOULD also be respected for the 320 penultimate node. 322 Exclusion-Flags 324 The Exclusion-Flags are used to communicate desirable 325 types of exclusion. The following flags are defined. 327 0x01 = SRLG exclusion 329 This flag is used to indicate that the route of the 330 LSP being signaled is requested to be SRLG diverse 331 from the route of the LSP or tunnel specified by the 332 LSP subobject. 334 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 336 0x02 = Node exclusion 338 This flag is used to indicate that the route of the 339 LSP being signaled is requested to be node diverse 340 from the route of the LSP or tunnel specified by the 341 LSP subobject. The node exclusion is subobject to the 342 setting of the "Processing node exception", the 343 "Penultimate node exception" and the "Destination 344 node exception" Attribute Flags. 346 0x04 = Link exclusion 348 This flag is used to indicate that the route of the 349 LSP being signaled is requested to be link diverse 350 from the route of the LSP or tunnel specified by the 351 LSP subobject. 353 The remaining fields are as defined in [RFC3209]. 355 2.3. Processing rules for the LSP subobject 357 XRO processing as described in [RFC4874] is unchanged. 359 If the node is the destination for the LSP being signaled, it 360 SHOULD NOT process a LSP XRO subobject. 362 If the L-flag is not set, the processing node follows the 363 following procedure: 365 - The processing node MUST ensure that any route calculated for 366 the signaled LSP (LSP2) respects the requested exclusion flags 367 with respect to the route traversed by the LSP(s) referenced by 368 the LSP subobject (LSP1/TUNNEL1), including local resources. 370 - If the processing node fails to find a route that meets the 371 requested constraint, the processing node SHOULD return a 372 PathErr with the error code "Routing Problem (24)" and error 373 value "Route blocked by Exclude Route (67)". 375 - If the route of the LSP or tunnel (LSP1/TUNNEL1) referenced in 376 the LSP subobject is unknown to the processing node, the 377 processing node SHOULD ignore the LSP subobject in the XRO and 378 SHOULD proceed with the signaling request (for LSP2). However, 379 in this case, after sending Resv for LSP2, the processing node 380 SHOULD return a PathErr with the error code "Notify Error (25)" 381 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 383 and error value "Route to XRO LSP unknown (value: to be 384 assigned by IANA, suggest value: 13)" for LSP2. 386 - If latter, the route of the LSP or tunnel (LSP1/TUNNEL1) 387 referenced in the LSP subobject becomes known (e.g. when LSP1 388 is signaled) or the TUNNEL1 is re-optimized to a different 389 route, such that the requested exclusion/ diversity constraints 390 are no longer satisfied and a path that can satisfy the 391 requested constraints exists, the node calculating or expanding 392 the path SHOULD send a PathErr message for LSP2 with the error 393 code "Notify Error (25)" and error value "Preferable path 394 exists (6)". An ingress node receiving this error code/value 395 combination MAY try to reoptimize the LSP2 to the new preferred 396 path. 398 - Route computation for the LSP or tunnel (LSP1/ TUNNEL1) 399 referenced in the LSP subobject for new setup or for re- 400 optimization LSP SHOULD be performed to avoid situation where 401 the requested exclusion/ diversity constraints are no longer 402 satisfied and a path that can satisfy the requested constraints 403 does not exist. However, if such situation arises the node that 404 computed or expanded the route for LSP2 SHOULD send a PathErr 405 message for LSP2 with the error code "Routing Problem (24)" and 406 error value "Route blocked by Exclude Route (67)". 408 If the L-flag is set, the processing node follows the following 409 procedure: 411 - The processing node SHOULD respect the requested exclusion 412 flags with respect to the route traversed by the referenced 413 LSP(s) (LSP1/TUNNEL1) as far as possible. 415 - If the processing node fails to find a route that meets the 416 requested constraint, it SHOULD proceeds with a suitable route 417 that best meets the constraint, but after completion of 418 signaling setup, it SHOULD return a PathErr code "Notify Error 419 (25)" and error value "Failed to respect Exclude Route (value: 420 to be assigned by IANA, suggest value: 14)" to the ingress 421 node. 423 - If the route of the LSP or tunnel (LSP1/TUNNEL1) referenced in 424 the LSP subobject is unknown to the processing node, the 425 processing node SHOULD ignore the LSP subobject in XRO and 426 SHOULD proceed with the signaling request (for LSP2). However, 427 in this case, after sending Resv for LSP2, the processing node 428 SHOULD return a PathErr with the error code "Notify Error" and 429 error value "Route to XRO LSP unknown" for LSP2. 431 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 433 - If latter, the route of the LSP or tunnel (LSP1/TUNNEL1) 434 referenced in the LSP subobject becomes known (e.g. when LSP1 435 is signaled) or the TUNNEL1 is re-optimized to a different 436 route, such that the requested exclusion/ diversity constraints 437 are no longer satisfied and a path that can satisfy the 438 requested constraints exists, the node calculating or expanding 439 the path SHOULD send a PathErr message for LSP2 with the error 440 code "Notify Error (25)" and error value "Preferable path 441 exists". An ingress node receiving this error code/value 442 combination MAY try to reoptimize the LSP2 to the new preferred 443 path. 445 - Route computation for the LSP or tunnel (LSP1/ TUNNEL1) 446 referenced in the LSP subobject for new setup or for re- 447 optimization LSP SHOULD be performed to avoid situation where 448 the requested exclusion/ diversity constraints are no longer 449 satisfied and a path that can satisfy the requested constraints 450 does not exist. However, if such situation arises the node that 451 computed or expanded the route for LSP2 SHOULD send a PathErr 452 message for LSP2 with the error code "Notify Error" and error 453 value "Failed to respect Exclude Route". 455 The following rules apply equally to L = 0 and L = 1 case: 457 - XRO object MAY contain multiple LSP subobjects. In this case, 458 the processing node A node receiving a Path message carrying an 459 XRO MAY reject the message if the XRO is too large or 460 complicated for the local implementation or the rules of local 461 policy, as per the roles of XRO defined in [RFC4874]. In this 462 case, the node MUST send a PathErr message with the error 463 code "Routing Error" and error value "XRO Too Complex". An 464 ingress node receiving this error code/value combination MAY 465 reduce the complexity of the XRO or route around the node that 466 rejected the XRO. 468 - An ingress node receiving PathErr with the error code "Notify 469 Error" and error values "Route to XRO LSP unknown" or "Failed 470 to respect Exclude Route" MAY take no action other than simply 471 logging these notifications. 473 Note that LSP1 may be signaled with an XRO LSP subobject 474 referencing CircuitID2 (LSP2 FEC) and LSP2 may be signaled with 475 an XRO LSP subobject referencing CircuitID1 (LSP1 FEC). The 476 above-mentioned processing rules cover this case. In fact, if 477 "LSP ID to be ignored" attribute flag is set when LSP1 is 478 signaled with an XRO LSP subobject referencing CircuitID2, it is 479 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 481 RECOMMENDED that LSP2 is signaled with an XRO LSP subobject 482 referencing CircuitID1. 484 2.4. LSP Subobject in Explicit Exclusion Route Subobject (EXRS) 486 [RFC4874] defines an ERO subobject called Explicit Exclusion 487 Route Subobject (EXRS). An EXRS is used to identify abstract 488 nodes or resources that must not or should not be used on the 489 path between two inclusive abstract nodes or resources in the 490 explicit route. An EXRS contains one or more subobjects of its 491 own, called EXRS subobjects [RFC4874]. 493 An EXRS MAY include an IPv4 Point-to-Point (P2P) LSP subobject. 494 In this case, EXRS would look as follows: 496 0 1 2 3 497 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 498 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 499 |L| Type | Length | Reserved | 500 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 501 |L| Type | Length |Attribute Flags|Exclusion Flags| 502 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 503 | IPv4 tunnel end point address | 504 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 505 | Must Be Zero | Tunnel ID | 506 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 507 | Extended Tunnel ID | 508 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 509 | IPv4 tunnel sender address | 510 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 511 | Must Be Zero | LSP ID | 512 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 The meaning of respective fields in EXRS header is as defined in 515 [RFC4874]. Similarly, the meaning of respective fields in IPv4 516 P2P LSP subobject is as defined earlier in this document. This is 517 with the exceptions that: 519 - Processing node exception applies to the node processing the 520 ERO. 522 - If L bit in the ERO header is not set (ERO.L = 0), the IPv4 523 P2P LSP subobject is processed against the LSPs for which the 524 processing node is ingress, egress or a transit node. 526 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 528 - Penultimate node exception applies to the penultimate node of 529 the loose hop. This flag is only processed if EXRS.L bit is 530 set, i.e., in the loose ERO hop case. 532 - Destination node exception applies to the abstract node to 533 which the route is expanded. This flag is only processed if 534 EXRS.L bit is set, i.e., in the loose ERO hop case. 536 2.4.1. Processing Rules for the EXRS with LSP subobject 538 Processing rules for the EXRS object are same as processing rules 539 as described in [RFC4874]. When the EXRS contains one or more LSP 540 subobject(s), processing rule specified in Section 2.3 applies to 541 the node processing the ERO with EXRS subobject. 543 3. Security Considerations 545 This document does not introduce any additional security issues 546 above those identified in [RFC5920], [RFC2205], [RFC3209], and 547 [RFC3473] and [RFC4874]. 549 4. IANA Considerations 551 4.1. New XRO subobject type 553 This document introduces a new subobject for the EXCLUDE_ROUTE 554 object [RFC4874], C-Type 1. 556 Subobject Type Subobject Description 557 -------------- 558 --------------------- 559 To be assigned by IANA (suggest value: 36) IPv4 P2P LSP subobject 561 4.2. New EXRS subobject type 563 IPv4 P2P LSP subobject is also defined as a new EXRS subobject. 565 4.3. New RSVP error sub-code 567 For Error Code = 25 "Notify Error" (see [RFC3209]) the following 568 sub-code is defined. 570 Sub-code Value 571 -------- ----- 572 Route to XRO LSP unknown To be assigned by IANA. 574 Suggested Value: 13. 576 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 578 Failed to respect Exclude Route To be assigned by IANA. 579 Suggested Value: 14. 581 5. Acknowledgement 583 Authors would like to thank Luyuan Fang and Walid Wakim for 584 their review comments. 586 6. References 588 6.1. Normative References 590 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 591 Requirement Levels", BCP 14, RFC 2119, March 1997. 593 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 594 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 595 LSP Tunnels", RFC 3209, December 2001. 597 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 598 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 599 Engineering (RSVP-TE) Extensions", RFC 3473, January 600 2003. 602 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude 603 Routes - Extension to Resource ReserVation Protocol- 604 Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. 606 6.2. Informative References 608 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 609 "Generalized Multiprotocol Label Switching (GMPLS) 610 User-Network Interface (UNI): Resource ReserVation 611 Protocol-Traffic Engineering (RSVP-TE) Support for the 612 Overlay Model", RFC 4208, October 2005. 614 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol 615 (RSVP) -- Version 1 Message Processing Rules", RFC 616 2209, September 1997. 618 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 619 Networks", RFC 5920, July 2010. 621 Internet Draft draft-ali-ccamp-xro-lsp-subobject-00.txt 623 Authors' Addresses 625 Zafar Ali 626 Cisco Systems. 627 Email: zali@cisco.com 629 George Swallow 630 Cisco Systems 631 swallow@cisco.com 633 Clarence Filsfils 634 Cisco Systems, Inc. 635 cfilsfil@cisco.com 637 Matt Hartley 638 Cisco Systems 639 Email: matt@matthartley.net 641 Ori Gerstel 642 Cisco Systems 643 ogerstel@cisco.com 645 Gabriele Maria Galimberti 646 Cisco Systems 647 ggalimbe@cisco.com