idnits 2.17.1 draft-ali-ccamp-xro-lsp-subobject-01.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 7 longer pages, the longest (page 1) being 64 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 too long lines in the document, the longest one being 3 characters in excess of 72. ** 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 12, 2012) is 4399 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 606 looks like a reference -- Missing reference section? 'RFC2119' on line 594 looks like a reference -- Missing reference section? 'RFC4208' on line 612 looks like a reference -- Missing reference section? 'RFC3209' on line 597 looks like a reference -- Missing reference section? 'RFC5920' on line 624 looks like a reference -- Missing reference section? 'RFC2205' on line 549 looks like a reference -- Missing reference section? 'RFC3473' on line 601 looks like a reference -- Missing reference section? 'RFC2209' on line 620 looks like a reference Summary: 5 errors (**), 0 flaws (~~), 3 warnings (==), 9 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 11, 2012 Matt Hartley 6 Ori Gerstel 7 Gabriele Maria Galimberti 8 Cisco Systems 9 Ruediger Kunze 10 Deutsche Telekom AG 11 Julien Meuric 12 France Telecom Orange 13 March 12, 2012 15 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) LSP 16 Route Diversity using Exclude Routes 18 draft-ali-ccamp-xro-lsp-subobject-01.txt 20 Status of this Memo 22 This Internet-Draft is submitted in full conformance with the 23 provisions of BCP 78 and BCP 79. 25 Internet-Drafts are working documents of the Internet Engineering 26 Task Force (IETF). Note that other groups may also distribute 27 working documents as Internet-Drafts. The list of current Internet- 28 Drafts is at http://datatracker.ietf.org/drafts/current/. 30 Internet-Drafts are draft documents valid for a maximum of six 31 months and may be updated, replaced, or obsoleted by other documents 32 at any time. It is inappropriate to use Internet-Drafts as 33 reference material or to cite them other than as "work in progress." 35 This Internet-Draft will expire on September 11, 2012. 37 Copyright Notice 39 Copyright (c) 2012 IETF Trust and the persons identified as the 40 document authors. All rights reserved. 42 This document is subject to BCP 78 and the IETF Trust's Legal Provisions 43 Relating to IETF Documents (http://trustee.ietf.org/license-info) 44 in effect on the date of publication of this document. Please 45 review these documents carefully, as they describe your rights and 46 restrictions with respect to this document. 47 Code Components extracted from this 48 document must include Simplified BSD License text as described in 50 Section 4.e of the Trust Legal Provisions and are provided without 51 warranty as described in the Simplified BSD License. 53 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 55 This document may contain material from IETF Documents or IETF 56 Contributions published or made publicly available before November 57 10, 2008. The person(s) controlling the copyright in some of this 58 material may not have granted the IETF Trust the right to allow 59 modifications of such material outside the IETF Standards Process. 60 Without obtaining an adequate license from the person(s) controlling 61 the copyright in such materials, this document may not be modified 62 outside the IETF Standards Process, and derivative works of it may 63 not be created outside the IETF Standards Process, except to format 64 it for publication as an RFC or to translate it into languages other 65 than English. 67 Abstract 69 [RFC4874] specifies methods by which route exclusions may be 70 communicated during RSVP-TE signaling in networks where precise 71 explicit paths are not computed by the LSP ingress node. This 72 document specifies signaling for additional route exclusions based 73 on LSPs currently existing or expected to exist within the network. 75 Conventions used in this document 77 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 78 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 79 document are to be interpreted as described in RFC 2119 [RFC2119]. 81 Table of Contents 83 1. Introduction ...............................................3 84 1.1. Requirements Notation .................................4 85 2. RSVP-TE signaling extensions ...............................5 86 2.1. Terminology ...........................................5 87 2.2. LSP Subobject .........................................5 88 2.3. Processing rules for the LSP subobject ................8 89 2.4. LSP Subobject in Explicit Exclusion Route Subobject ..11 90 2.4.1. Processing Rules for the EXRS with LSP subobject.12 91 4. IANA Considerations .......................................12 92 4.1. New XRO subobject type ...............................12 93 4.2. New EXRS subobject type ..............................12 94 4.3. New RSVP error sub-code ..............................12 95 5. Acknowledgement ...........................................13 96 6. References 97 ................................................13 98 6.1. Normative References .................................13 99 6.2. Informative References ...............................13 100 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 102 1. Introduction 104 Label-Switched Path (LSP) diversity is required to ensure LSPs may 105 be established without sharing resources, thus greatly reducing 106 the probability of simultaneous connection failures. 108 LSP diversity is a well-known requirement from Service Providers. 109 When route computation for LSPs that need to be diverse is 110 performed at ingress node, this requirement can be met by a local 111 decision at that node. However, there are scenarios when route 112 computations are performed by remote nodes, in which case there is 113 a need for relevant diversity requirements to be communicated to 114 those nodes. These include (but are not limited to): 116 . LSPs with loose hops in the Explicit Route Object (ERO), e.g. 117 inter-domain LSPs. 119 . Generalized Multi-Protocol Label Switching (GMPLS) User- 120 Network Interface (UNI) where route computation may be 121 performed by the (sever layer) core node [RFC4208]; 123 The eXclude Route Object (XRO) and Explicit Exclusion Route 124 Subobject (EXRS) specification [RFC4874] introduces a means of 125 specifying nodes and resources to be excluded from routes, using 126 the XRO and/ or EXRS. 128 [RFC4874] facilitates the calculation of diverse routes for LSPs 129 based on known properties of those LSPs including addresses of 130 links and nodes traversed, and Shared Risk Link Groups (SRLGs) of 131 traversed links. This requires that these properties of the LSP(s) 132 from which diversity is required be known to the ingress node 133 which initiates signaling. However, there are circumstances under 134 which this may not be possible or desirable, including (but not 135 limited to): 137 . Exclusion of the route of a LSP which does not originate, 138 terminate or traverse the ingress node signaling the diverse 139 LSP, in which case the addresses and SRLGs of the LSP from 140 which diversity is required are unknown to the ingress node. 142 . Exclusion of the route of a LSP which, while known at the 143 ingress node of the diverse LSP, has incomplete or unavailable 144 route information, e.g. due to confidentiality of the LSP route 145 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 147 attributes. In other words, the scenario in which the reference 148 LSP is hosted by the ingress/ requesting node but the 149 properties required to construct an XRO object are not known to 150 ingress/ requesting node. Inter-domain and GMPLS overlay 151 networks may present such restrictions. 153 . If the route of the reference LSP from which diversity is 154 required (e.g. LSP1) is known to the ingress node, that node 155 can use this information to construct an XRO and send it in the 156 path message during the signaling of a diverse LSP (LSP2). 157 However, if the route of LSP1 changes (e.g. due to re- 158 optimization or failure in the network), the ingress node would 159 need to change path of LSP2 to ensure that it remains diverse 160 from LSP1. It is preferable to have this decision made by the 161 node that calculated the path for LSP2. For example, in the 162 case of GMPLS-UNI, it is better to have such responsibility at 163 the server layer as opposed to at the client layer so that the 164 diversity requirements are transparent to the client layer. 165 Furthermore, in all networking scenarios, if the node 166 performing the route computation/ expansion is aware of the 167 diversity requirements of LSP1 and LSP2, it may consider joint 168 re-optimization of the diverse LSPs. 170 This document addresses such scenarios and defines procedures 171 that may be used to exclude the route taken by a particular LSP, 172 or the route taken by all LSPs belonging to a single tunnel. Note 173 that this diversity requirement is different from the diversity 174 requirements of path protection where both the reference and 175 diverse LSPs belong to the same tunnel. The diversity 176 requirements considered in this document do not require that the 177 LSPs in question belonging to the same tunnel or share an ingress 178 node. 180 The means by which the node calculating or expanding the route of 181 the signaled LSP discovers the route of the LSPs from which the 182 signaled LSP requires diversity is beyond the scope of this 183 document. However, in most cases the LSPs with route diversity 184 requirements may transit the node expanding the route. 186 This document addresses only the exclusion of point-to-point 187 tunnels; point-to-multipoint tunnels will be addressed in a 188 future version. Similarly, at present only IPv4 addresses are 189 considered; support for IPv6 addresses will be added in a future 190 version. 192 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 194 1.1. Requirements Notation 196 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL 197 NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and 198 "OPTIONAL" in this document are to be interpreted as described in 199 [RFC2119]. 201 2. RSVP-TE signaling extensions 203 This section describes the signaling extensions required to 204 address the aforementioned requirements. Specifically, this 205 document defines a new LSP subobject to be signaled in the 206 EXCLUDE_ROUTE object (XRO) and/ or Explicit Exclusion Route 207 Subobject (EXRS) defined in [RFC4874]. Inclusion of the LSP 208 subobject in any other RSVP object is not defined. 210 2.1. Terminology 212 In this document, the following terminology is adapted: 214 LSP1/TUNNEL1: LSP1/TUNNEL1 is the LSP/tunnel from which diversity 215 is required. 217 LSP2/TUNNEL2: The term LSP2/TUNNEL2 is used to refer the LSP 218 being signaled with XRO/ EXRS containing the LSP subobject 219 referencing LSP1/TUNNEL1. 221 CircuitID: The term CircuitID refers to the LSP Forwarding 222 Equivalence Class (FEC) (LSP ID field of the FEC may be ignored 223 depending on the context the CircuitID term is used). 225 CircuitIDx: The term CicuitIDx refers to CircuitID of 226 LSPx/TUNNELx. 228 2.2. LSP Subobject 230 A new IPv4 Point-to-Point (P2P) LSP subobject is defined by this 231 document as follows (IPv6 P2P LSP subobject will be defined in a 232 later version of the document). 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 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 242 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 243 | Must Be Zero | Tunnel ID | 244 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 245 | Extended Tunnel ID | 246 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 247 | IPv4 tunnel sender address | 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 | Must Be Zero | LSP ID | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 L 253 The L-flag is used as for the other XRO subobjects defined 254 in [RFC4874]. 255 0 indicates that the attribute specified MUST be excluded. 256 1 indicates that the attribute specified SHOULD be 257 avoided. 259 Type 260 A new subobject type is introduced; the subobject type is 261 to be defined by IANA (suggested value: 36). 263 Length 265 The length contains the total length of the subobject in 266 bytes, including the type and length fields. The length is 267 always 24. 269 Attribute Flags 271 The Attribute Flags are used to communicate desirable 272 attributes of the LSP being signaled (In the following, the 273 term LSP2 is used to reference the LSP being signaled; 274 please refer to Section 2.1 for definition of LSP2). The 275 following flags are defined. None, all or multiple 276 attribute flags MAY be set within the same subobject. 278 0x01 = LSP ID to be ignored 280 This flag is used to indicate tunnel level exclusion. 281 Specifically, this flag is used to indicate that the 282 lsp-id field of the subobject is to be ignored and the 283 exclusion applies to any LSP matching the rest of the 284 supplied FEC. In other words, if this flag is set, the 286 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 288 processing node MUST calculate a route based on 289 exclusions from the routes of all known LSPs matching 290 the tunnel-id, source, destination and extended tunnel- 291 id specified in the subobject. 293 When this flag is not set, the lsp-id is not ignored and 294 the exclusion applies only to the specified LSP (i.e., 295 LSP level exclusion). In other words, when this flag is 296 not set, route exclusions MUST respect the specified LSP 297 (i.e. the lsp-id, the tunnel-id, source, destination and 298 extended tunnel-id specified needs to be respected 299 during exclusion). 301 0x02 = Destination node exception 303 This flag is used to indicate that the destination node 304 may be shared even when sharing of the said node 305 violates the exclusion flags. When this flag is not set, 306 the exclusion flags SHOULD also be respected for the 307 destination node. 309 0x04 = Processing node exception 311 This flag is used to indicate that the processing node 312 may be shared even when sharing of the said node 313 violates the exclusion flags. When this flag is not set, 314 the exclusion flags SHOULD also be respected for the 315 processing node. 317 0x08 = Penultimate node exception 319 This flag is used to indicate that the penultimate node 320 may be shared even when sharing of the said node 321 violates the exclusion flags. When this flag is not set, 322 the exclusion flags SHOULD also be respected for the 323 penultimate node. 325 Exclusion-Flags 327 The Exclusion-Flags are used to communicate desirable 328 types of exclusion. The following flags are defined. 330 0x01 = SRLG exclusion 332 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 334 This flag is used to indicate that the route of the 335 LSP being signaled is requested to be SRLG diverse 336 from the route of the LSP or tunnel specified by the 337 LSP subobject. 339 0x02 = Node exclusion 341 This flag is used to indicate that the route of the 342 LSP being signaled is requested to be node diverse 343 from the route of the LSP or tunnel specified by the 344 LSP subobject. The node exclusion is subobject to the 345 setting of the "Processing node exception", the 346 "Penultimate node exception" and the "Destination 347 node exception" Attribute Flags. 349 0x04 = Link exclusion 351 This flag is used to indicate that the route of the 352 LSP being signaled is requested to be link diverse 353 from the route of the LSP or tunnel specified by the 354 LSP subobject. 356 The remaining fields are as defined in [RFC3209]. 358 2.3. Processing rules for the LSP subobject 360 XRO processing as described in [RFC4874] is unchanged. 362 If the node is the destination for the LSP being signaled, it 363 SHOULD NOT process a LSP XRO subobject. 365 If the L-flag is not set, the processing node follows the 366 following procedure: 368 - The processing node MUST ensure that any route calculated for 369 the signaled LSP (LSP2) respects the requested exclusion flags 370 with respect to the route traversed by the LSP(s) referenced by 371 the LSP subobject (LSP1/TUNNEL1), including local resources. 373 - If the processing node fails to find a route that meets the 374 requested constraint, the processing node SHOULD return a 375 PathErr with the error code "Routing Problem (24)" and error 376 value "Route blocked by Exclude Route (67)". 378 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 380 - If the route of the LSP or tunnel (LSP1/TUNNEL1) referenced in 381 the LSP subobject is unknown to the processing node, the 382 processing node SHOULD ignore the LSP subobject in the XRO and 383 SHOULD proceed with the signaling request (for LSP2). However, 384 in this case, after sending Resv for LSP2, the processing node 385 SHOULD return a PathErr with the error code "Notify Error (25)" 386 and error value "Route to XRO LSP unknown (value: to be 387 assigned by IANA, suggest value: 13)" for LSP2. 389 - If latter, the route of the LSP or tunnel (LSP1/TUNNEL1) 390 referenced in the LSP subobject becomes known (e.g. when LSP1 391 is signaled) or the TUNNEL1 is re-optimized to a different 392 route, such that the requested exclusion/ diversity constraints 393 are no longer satisfied and a path that can satisfy the 394 requested constraints exists, the node calculating or expanding 395 the path SHOULD send a PathErr message for LSP2 with the error 396 code "Notify Error (25)" and error value "Preferable path 397 exists (6)". An ingress node receiving this error code/value 398 combination MAY try to reoptimize the LSP2 to the new preferred 399 path. 401 - Route computation for the LSP or tunnel (LSP1/ TUNNEL1) 402 referenced in the LSP subobject for new setup or for re- 403 optimization LSP SHOULD be performed to avoid situation where 404 the requested exclusion/ diversity constraints are no longer 405 satisfied and a path that can satisfy the requested constraints 406 does not exist. However, if such situation arises the node that 407 computed or expanded the route for LSP2 SHOULD send a PathErr 408 message for LSP2 with the error code "Routing Problem (24)" and 409 error value "Route blocked by Exclude Route (67)". 411 If the L-flag is set, the processing node follows the following 412 procedure: 414 - The processing node SHOULD respect the requested exclusion 415 flags with respect to the route traversed by the referenced 416 LSP(s) (LSP1/TUNNEL1) as far as possible. 418 - If the processing node fails to find a route that meets the 419 requested constraint, it SHOULD proceeds with a suitable route 420 that best meets the constraint, but after completion of 421 signaling setup, it SHOULD return a PathErr code "Notify Error 422 (25)" and error value "Failed to respect Exclude Route (value: 423 to be assigned by IANA, suggest value: 14)" to the ingress 424 node. 426 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 428 - If the route of the LSP or tunnel (LSP1/TUNNEL1) referenced in 429 the LSP subobject is unknown to the processing node, the 430 processing node SHOULD ignore the LSP subobject in XRO and 431 SHOULD proceed with the signaling request (for LSP2). However, 432 in this case, after sending Resv for LSP2, the processing node 433 SHOULD return a PathErr with the error code "Notify Error" and 434 error value "Route to XRO LSP unknown" for LSP2. 436 - If latter, the route of the LSP or tunnel (LSP1/TUNNEL1) 437 referenced in the LSP subobject becomes known (e.g. when LSP1 438 is signaled) or the TUNNEL1 is re-optimized to a different 439 route, such that the requested exclusion/ diversity constraints 440 are no longer satisfied and a path that can satisfy the 441 requested constraints exists, the node calculating or expanding 442 the path SHOULD send a PathErr message for LSP2 with the error 443 code "Notify Error (25)" and error value "Preferable path 444 exists". An ingress node receiving this error code/value 445 combination MAY try to reoptimize the LSP2 to the new preferred 446 path. 448 - Route computation for the LSP or tunnel (LSP1/ TUNNEL1) 449 referenced in the LSP subobject for new setup or for re- 450 optimization LSP SHOULD be performed to avoid situation where 451 the requested exclusion/ diversity constraints are no longer 452 satisfied and a path that can satisfy the requested constraints 453 does not exist. However, if such situation arises the node that 454 computed or expanded the route for LSP2 SHOULD send a PathErr 455 message for LSP2 with the error code "Notify Error" and error 456 value "Failed to respect Exclude Route". 458 The following rules apply equally to L = 0 and L = 1 case: 460 - XRO object MAY contain multiple LSP subobjects. In this case, 461 the processing node A node receiving a Path message carrying an 462 XRO MAY reject the message if the XRO is too large or 463 complicated for the local implementation or the rules of local 464 policy, as per the roles of XRO defined in [RFC4874]. In this 465 case, the node MUST send a PathErr message with the error 466 code "Routing Error" and error value "XRO Too Complex". An 467 ingress node receiving this error code/value combination MAY 468 reduce the complexity of the XRO or route around the node that 469 rejected the XRO. 471 - An ingress node receiving PathErr with the error code "Notify 472 Error" and error values "Route to XRO LSP unknown" or "Failed 473 to respect Exclude Route" MAY take no action other than simply 474 logging these notifications. 476 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 478 Note that LSP1 may be signaled with an XRO LSP subobject 479 referencing CircuitID2 (LSP2 FEC) and LSP2 may be signaled with 480 an XRO LSP subobject referencing CircuitID1 (LSP1 FEC). The 481 above-mentioned processing rules cover this case. In fact, if 482 "LSP ID to be ignored" attribute flag is set when LSP1 is 483 signaled with an XRO LSP subobject referencing CircuitID2, it is 484 RECOMMENDED that LSP2 is signaled with an XRO LSP subobject 485 referencing CircuitID1. 487 2.4. LSP Subobject in Explicit Exclusion Route Subobject (EXRS) 489 [RFC4874] defines an ERO subobject called Explicit Exclusion 490 Route Subobject (EXRS). An EXRS is used to identify abstract 491 nodes or resources that must not or should not be used on the 492 path between two inclusive abstract nodes or resources in the 493 explicit route. An EXRS contains one or more subobjects of its 494 own, called EXRS subobjects [RFC4874]. 496 An EXRS MAY include an IPv4 Point-to-Point (P2P) LSP subobject. 497 In this case, EXRS would look as follows: 499 0 1 2 3 500 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 501 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 502 |L| Type | Length | Reserved | 503 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 504 |L| Type | Length |Attribute Flags|Exclusion Flags| 505 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 506 | IPv4 tunnel end point address | 507 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 508 | Must Be Zero | Tunnel ID | 509 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 510 | Extended Tunnel ID | 511 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 512 | IPv4 tunnel sender address | 513 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 514 | Must Be Zero | LSP ID | 515 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 517 The meaning of respective fields in EXRS header is as defined in 518 [RFC4874]. Similarly, the meaning of respective fields in IPv4 519 P2P LSP subobject is as defined earlier in this document. This is 520 with the exceptions that: 522 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 524 - Processing node exception applies to the node processing the 525 ERO. 527 - If L bit in the ERO header is not set (ERO.L = 0), the IPv4 528 P2P LSP subobject is processed against the LSPs for which the 529 processing node is ingress, egress or a transit node. 531 - Penultimate node exception applies to the penultimate node of 532 the loose hop. This flag is only processed if EXRS.L bit is 533 set, i.e., in the loose ERO hop case. 535 - Destination node exception applies to the abstract node to 536 which the route is expanded. This flag is only processed if 537 EXRS.L bit is set, i.e., in the loose ERO hop case. 539 2.4.1. Processing Rules for the EXRS with LSP subobject 541 Processing rules for the EXRS object are same as processing rules 542 as described in [RFC4874]. When the EXRS contains one or more LSP 543 subobject(s), processing rule specified in Section 2.3 applies to 544 the node processing the ERO with EXRS subobject. 546 3. Security Considerations 548 This document does not introduce any additional security issues 549 above those identified in [RFC5920], [RFC2205], [RFC3209], and 550 [RFC3473] and [RFC4874]. 552 4. IANA Considerations 554 4.1. New XRO subobject type 556 This document introduces a new subobject for the EXCLUDE_ROUTE 557 object [RFC4874], C-Type 1. 559 Subobject Type 560 Subobject Description 561 -------------- 562 --------------------- 563 To be assigned by IANA (suggest value: 36) IPv4 P2P LSP subobject 565 4.2. New EXRS subobject type 567 IPv4 P2P LSP subobject is also defined as a new EXRS subobject. 569 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 571 4.3. New RSVP error sub-code 573 For Error Code = 25 "Notify Error" (see [RFC3209]) the following 574 sub-code is defined. 576 Sub-code Value 577 -------- ----- 579 Route to XRO LSP unknown To be assigned by IANA. 580 Suggested Value: 13. 582 Failed to respect Exclude Route To be assigned by IANA. 583 Suggested Value: 14. 585 5. Acknowledgement 587 Authors would like to thanks Luyuan Fang and Walid Wakim for 588 their review comments. 590 6. References 592 6.1. Normative References 594 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 595 Requirement Levels", BCP 14, RFC 2119, March 1997. 597 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 598 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 599 LSP Tunnels", RFC 3209, December 2001. 601 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 602 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 603 Engineering (RSVP-TE) Extensions", RFC 3473, January 604 2003. 606 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude 607 Routes - Extension to Resource ReserVation Protocol- 608 Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. 610 6.2. Informative References 612 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 613 "Generalized Multiprotocol Label Switching (GMPLS) 614 User-Network Interface (UNI): Resource ReserVation 615 Protocol-Traffic Engineering (RSVP-TE) Support for the 616 Overlay Model", RFC 4208, October 2005. 618 Internet Draft draft-ali-ccamp-xro-lsp-subobject-01.txt 620 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol 621 (RSVP) -- Version 1 Message Processing Rules", RFC 622 2209, September 1997. 624 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 625 Networks", RFC 5920, July 2010. 627 Authors' Addresses 629 Zafar Ali 630 Cisco Systems. 631 Email: zali@cisco.com 633 George Swallow 634 Cisco Systems 635 swallow@cisco.com 637 Clarence Filsfils 638 Cisco Systems, Inc. 639 cfilsfil@cisco.com 641 Matt Hartley 642 Cisco Systems 643 Email: matt@matthartley.net 645 Ori Gerstel 646 Cisco Systems 647 ogerstel@cisco.com 649 Gabriele Maria Galimberti 650 Cisco Systems 651 ggalimbe@cisco.com 653 Rudiger Kunze 654 Deutsche Telekom AG 655 Ruediger.Kunze@telekom.de 657 Julien Meuric 658 France Telecom Orange 659 Email: julien.meuric@orange.com