idnits 2.17.1 draft-ietf-ccamp-lsp-diversity-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: ---------------------------------------------------------------------------- == It seems as if not all pages are separated by form feeds - found 11 form feeds but 17 pages 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 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 (February 18, 2013) is 4078 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: 'RFC2205' is mentioned on line 603, but not defined == Unused Reference: 'RFC2209' is defined on line 680, but no explicit reference was found in the text Summary: 0 errors (**), 0 flaws (~~), 5 warnings (==), 1 comment (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 CCAMP Working Group Zafar Ali 2 Internet Draft George Swallow 3 Intended status: Standard Track Clarence Filsfils 4 Expires: August 17, 2013 Matt Hartley 5 Ori Gerstel 6 Gabriele Maria Galimberti 7 Cisco Systems 8 Kenji Kumaki 9 KDDI Corporation 10 Ruediger Kunze 11 Deutsche Telekom AG 12 Julien Meuric 13 France Telecom Orange 14 February 18, 2013 16 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path 17 Diversity using Exclude Routes 19 draft-ietf-ccamp-lsp-diversity-01.txt 21 Status of this Memo 23 This Internet-Draft is submitted in full conformance with the 24 provisions of BCP 78 and BCP 79. 26 Internet-Drafts are working documents of the Internet Engineering 27 Task Force (IETF). Note that other groups may also distribute 28 working documents as Internet-Drafts. The list of current Internet- 29 Drafts is at http://datatracker.ietf.org/drafts/current/. 31 Internet-Drafts are draft documents valid for a maximum of six 32 months and may be updated, replaced, or obsoleted by other documents 33 at any time. It is inappropriate to use Internet-Drafts as 34 reference material or to cite them other than as "work in progress." 36 This Internet-Draft will expire on August 17, 2013. 38 Copyright Notice 40 Copyright (c) 2012 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents 45 (http://trustee.ietf.org/license-info) in effect on the date of 46 publication of this document. Please review these documents 47 carefully, as they describe your rights and restrictions with 48 respect to this document. Code Components extracted from this 49 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 This document may contain material from IETF Documents or IETF 54 Contributions published or made publicly available before November 55 10, 2008. The person(s) controlling the copyright in some of this 56 material may not have granted the IETF Trust the right to allow 57 modifications of such material outside the IETF Standards Process. 58 Without obtaining an adequate license from the person(s) controlling 59 the copyright in such materials, this document may not be modified 60 outside the IETF Standards Process, and derivative works of it may 61 not be created outside the IETF Standards Process, except to format 62 it for publication as an RFC or to translate it into languages other 63 than English. 65 Abstract 67 RFC 4874 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 source node. This 70 document specifies signaling for additional route exclusions based 71 on Paths 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 2. RSVP-TE signaling extensions ..................................5 83 2.1. Terminology .................................................5 84 2.2. Path XRO Subobjects .........................................5 85 2.2.1. IPv4 Point-to-Point Path subobject ....................... 5 86 2.2.2. IPv6 Point-to-Point Path subobject ....................... 9 87 2.3. Processing rules for the Path XRO subobjects ..............10 88 2.4. Path EXRS Subobject ........................................13 89 2.4.1. Processing Rules for the EXRS with Path subobject ....... 14 90 3. Security Considerations .....................................14 91 4. IANA Considerations .........................................14 92 4.1. New XRO subobject types ....................................14 93 4.2. New EXRS subobject types ...................................15 94 4.3. New RSVP error sub-codes....................................15 96 Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt 98 5. Acknowledgements .............................................15 99 6. References ...................................................15 100 6.1. Normative References .................................15 101 6.2. Informative References ...............................16 103 1. Introduction 105 Path diversity is a well-known requirement from Service Providers. 106 Such diversity is required to ensure Label-Switched Path (LSPs) 107 may be established without sharing resources, thus greatly 108 reducing the probability of simultaneous connection failures. 110 When route computation for paths that need to be diverse is 111 performed at the LSP's source node, this requirement can be met by 112 a local decision at that node. However, there are scenarios when 113 route computations are performed by remote nodes, there is a need 114 for relevant diversity requirements to be communicated to those 115 nodes. These include (but are not limited to): 117 . LSPs with loose hops in the Explicit Route Object (ERO), e.g. 118 inter-domain LSPs. 120 . Generalized Multi-Protocol Label Switching (GMPLS) User- 121 Network Interface (UNI) where route computation may be 122 performed by the (server layer) core node [RFC4208]; 124 [RFC4874] introduced a means of specifying nodes and resources to 125 be excluded from a route, using the eXclude Route Object (XRO) and 126 Explicit Exclusion Route Subobject (EXRS). 128 [RFC4874] facilitates the calculation of diverse routes for LSPs 129 based on known properties of those paths 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 132 path(s) from which diversity is required be known to the source 133 node which initiates signaling. However, there are circumstances 134 under which this may not be possible or desirable, including (but 135 not limited to): 137 . Exclusion of a path which does not originate, terminate or 138 traverse the source node signaling the diverse LSP, in which 139 case the addresses and SRLGs of the path from which diversity 140 is required are unknown to the source node. 142 . Exclusion of a path which, while known at the source node of 143 the diverse LSP, has incomplete or unavailable route 144 information, e.g. due to confidentiality of the path 146 Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt 148 attributes. In other words, the scenario in which the reference 149 path is hosted by the source / requesting node but the 150 properties required to construct an XRO object are not known to 151 source / requesting node. Inter-domain and GMPLS overlay 152 networks may present such restrictions. 154 . If the source node knows the route of the reference path from 155 which diversity is required, it can use this information to 156 construct an XRO and send it in the path message during the 157 signaling of a diverse LSP. However, if the route of the 158 excluded path changes (e.g. due to re-optimization or failure 159 in the network), the source node would need to change the 160 diverse path to ensure that it remains diverse from the 161 excluded path. It is preferable to have this decision made by 162 the node that performed the path-calculation for the diverse 163 path. For example, in the case of GMPLS-UNI, it is better to 164 have such responsibility at the server layer as opposed to at 165 the client layer so that the diversity requirements are 166 transparent to the client layer. Furthermore, in all networking 167 scenarios, if the node performing the route computation/ 168 expansion is aware of the diversity requirements of the two 169 paths, it may consider joint re-optimization of the diverse 170 paths. 172 This document addresses such scenarios and defines procedures 173 that may be used to exclude the route taken by a particular LSP, 174 or the routes taken by all LSPs belonging to a single tunnel. 175 Note that this diversity requirement is different from the 176 diversity requirements of path protection where both the 177 reference and diverse LSPs belong to the same tunnel. The 178 diversity requirements considered in this document do not require 179 that the paths in question belonging to the same tunnel or share 180 the same source or destination node. 182 The means by which the node calculating or expanding the route of 183 the signaled LSP discovers the route of the path(s) from which 184 the signaled LSP requires diversity are beyond the scope of this 185 document. 187 This document addresses only the exclusion of point-to-point 188 paths; point-to-multipoint paths will be addressed in a future 189 version. 191 If mutually diverse routes are desired for two LSPs belonging to 192 different tunnels, it is recommended that they be signaled with 193 XRO LSP subobjects referencing each other. The processing rules 194 specified in this document cover this case. 196 Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt 198 2. RSVP-TE signaling extensions 200 This section describes the signaling extensions required to 201 address the aforementioned requirements. Specifically, this 202 document defines a new LSP subobject to be signaled in the 203 EXCLUDE_ROUTE object (XRO) and/ or Explicit Exclusion Route 204 Subobject (EXRS) defined in [RFC4874]. Inclusion of the LSP 205 subobject in any other RSVP object is not defined. 207 2.1. Terminology 209 In this document, the following terminology is adopted: 211 Excluded path: the path from which diversity is required. 213 Diverse LSP: the LSP being signaled with XRO/ EXRS containing the 214 path subobject referencing the excluded path(s). 216 Processing node: the node performing a path-calculation involving 217 an exclusion specified in an XRO or EXRS. 219 Destination node: in the context of an XRO, this is the 220 destination of the LSP being signaled. In the context of an EXRS, 221 the destination node is the last explicit node to which the loose 222 hop is expanded. 224 Penultimate node: in the context of an XRO, this is the 225 penultimate hop of the LSP being signaled. In the context of an 226 EXRS, the penultimate node is the penultimate node of the loose 227 hop undergoing expansion. 229 2.2. Path XRO Subobjects 231 New IPv4 and IPv6 Point-to-Point (P2P) Path XRO subobjects are 232 defined by this document as follows. 234 2.2.1. IPv4 Point-to-Point Path subobject 236 0 1 2 3 237 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 238 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 239 |L| Type | Length |Attribute Flags|Exclusion Flags| 240 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 | IPv4 tunnel end point address | 243 Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt 245 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 246 | Must Be Zero | Tunnel ID | 247 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 248 | Extended Tunnel ID | 249 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 250 | IPv4 tunnel sender address | 251 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 252 | Must Be Zero | LSP ID | 253 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 255 L 256 The L-flag is used as for the other XRO subobjects defined 257 in [RFC4874]. 259 0 indicates that the attribute specified MUST be excluded. 261 1 indicates that the attribute specified SHOULD be 262 avoided. 264 Type 266 IPv4 Point-to-Point Path subobject 267 (to be assigned by IANA; suggested value: 36). 269 Length 271 The length contains the total length of the subobject in 272 bytes, including the type and length fields. The length is 273 always 24. 275 Attribute Flags 277 The Attribute Flags are used to communicate desirable 278 attributes of the LSP being signaled. The following flags 279 are defined. None, all or multiple attribute flags MAY be 280 set within the same subobject. 282 0x01 = LSP ID to be ignored 284 This flag is used to indicate tunnel level exclusion. 285 Specifically, this flag is used to indicate that the 286 lsp-id field of the subobject is to be ignored and the 288 Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt 290 exclusion applies to any LSP matching the rest of the 291 supplied FEC. 293 0x02 = Destination node exception 295 This flag is used to indicate that the destination node 296 of the LSP being signaled MAY be shared with the 297 excluded path even when this violates the exclusion 298 flags. 300 0x04 = Processing node exception 302 This flag is used to indicate that the processing node 303 MAY be shared with the excluded path even when this 304 violates the exclusion flags. 306 0x08 = Penultimate node exception 308 This flag is used to indicate that the penultimate node 309 of the LSP being signaled MAY be shared with the 310 excluded path even when this violates the exclusion 311 flags. 313 Exclusion Flags 315 The Exclusion-Flags are used to communicate desirable 316 types of exclusion. The following flags are defined. 318 0x01 = SRLG exclusion 320 This flag is used to indicate that the route of the 321 LSP being signaled is requested to be SRLG diverse 322 from the excluded path specified by the LSP 323 subobject. 325 0x02 = Node exclusion 327 This flag is used to indicate that the route of the 328 LSP being signaled is requested to be node diverse 329 from the excluded path specified by the LSP 330 subobject. 332 (Note: the meaning of this flag may be modified by 333 the value of the Attribute-flags.) 335 Internet Draft draft-ietf-ccamp-lsp-diversity-01.txt 337 0x04 = Link exclusion 339 This flag is used to indicate that the route of the 340 LSP being signaled is requested to be link diverse 341 from the path specified by the LSP subobject. 343 The remaining fields are as defined in [RFC3209]. 345 2.2.2. IPv6 Point-to-Point Path subobject 347 0 1 2 3 348 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 349 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 350 |L| Type | Length |Attribute Flags|Exclusion Flags| 351 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 352 | IPv6 tunnel end point address | 353 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 354 | IPv6 tunnel end point address (cont.) | 355 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 | IPv6 tunnel end point address (cont.) | 357 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 358 | IPv6 tunnel end point address (cont.) | 359 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 360 | Must Be Zero | Tunnel ID | 361 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 362 | Extended Tunnel ID | 363 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 364 | Extended Tunnel ID (cont.) | 365 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 366 | Extended Tunnel ID (cont.) | 367 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 | Extended Tunnel ID (cont.) | 369 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 370 | IPv4 tunnel sender address | 371 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 372 | IPv4 tunnel sender address (cont.) | 373 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 374 | IPv4 tunnel sender address (cont.) | 375 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 376 | IPv4 tunnel sender address (cont.) | 377 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 378 | Must Be Zero | LSP ID | 379 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 L 382 The L-flag is used as for the other XRO subobjects defined 383 in [RFC4874]. 385 0 indicates that the attribute specified MUST be excluded. 387 1 indicates that the attribute specified SHOULD be 388 avoided. 390 Type 392 IPv6 Point-to-Point Path subobject 393 (to be assigned by IANA; suggested value: 37). 395 Length 397 The length contains the total length of the subobject in 398 bytes, including the type and length fields. The length is 399 always 48. 401 The Attribute Flags and Exclusion Flags are as defined for the 402 IPv4 Point-to-Point LSP XRO subobject. 404 The remaining fields are as defined in [RFC3209]. 406 2.3. Processing rules for the Path XRO subobjects 408 XRO processing as described in [RFC4874] is unchanged. 410 If the processing node is the destination for the LSP being 411 signaled, it SHOULD NOT process a Path XRO subobject. 413 If the L-flag is not set, the processing node follows the 414 following procedure: 416 - The processing node MUST ensure that any route calculated for 417 the signaled LSP respects the requested exclusion flags with 418 respect to the excluded path referenced by the subobject, 419 including local resources. 421 - If the processing node fails to find a route that meets the 422 requested constraint, the processing node MUST return a PathErr 423 with the error code "Routing Problem" (24) and error sub-code 424 "Route blocked by Exclude Route" (67). 426 - If the excluded path referenced in the LSP subobject is 427 unknown to the processing node, the processing node SHOULD 428 ignore the LSP subobject in the XRO and SHOULD proceed with the 429 signaling request. After sending the Resv for the signaled LSP, 430 the processing node SHOULD return a PathErr with the error code 431 "Notify Error" (25) and error sub-code "Route of XRO path 432 unknown" (value to be assigned by IANA, suggested value: 13) 433 for the signaled LSP. 435 If the L-flag is set, the processing node follows the following 436 procedure: 438 - The processing node SHOULD respect the requested exclusion 439 flags with respect to the excluded path as far as possible. 441 - If the processing node fails to find a route that meets the 442 requested constraint, it SHOULD proceed with signaling using a 443 suitable route that meets the constraint as far as possible. 444 After sending the Resv for the signaled LSP, it SHOULD return a 445 PathErr message with error code "Notify Error" (25) and error 446 sub-code "Failed to respect Exclude Route" (value: to be 447 assigned by IANA, suggest value: 14) to the source node. 449 - If the excluded path referenced in the LSP subobject is 450 unknown to the processing node, the processing node SHOULD 451 ignore the LSP subobject in the XRO and SHOULD proceed with the 452 signaling request. After sending the Resv for signaled LSP, the 453 processing node SHOULD return a PathErr message with the error 454 code "Notify Error" (25) and error sub-code "Route of XRO path 455 unknown" for the signaled LSP. 457 If, subsequent to the initial signaling of a diverse LSP: 459 - an excluded path referenced in the diverse LSP's XRO 460 subobject becomes known to the processing node (e.g. when the 461 excluded path is signaled), or 463 - A change in the excluded path becomes known to the processing 464 node, 466 the processing node SHOULD re-evaluate the exclusion and 467 diversity constraints requested by the diverse LSP to determine 468 whether they are still satisfied. 470 - If the requested exclusion constraints for the diverse LSP 471 are no longer satisfied and an alternative route for the 472 diverse LSP that can satisfy those constraints exists, the 473 processing node SHOULD send a PathErr message for the diverse 474 LSP with the error code "Notify Error" (25) and error sub-code 475 "Preferable path exists" (6). A source node receiving a PathErr 476 message with this error code and sub-code combination MAY try 477 to reoptimize the diverse tunnel to the new compliant path. 479 - If the requested exclusion constraints for the diverse LSP 480 are no longer satisfied and no alternative path for the diverse 481 LSP that can satisfy those constraints exists, then: 483 o If the L-flag was not set in the original exclusion, the 484 processing node MUST send a PathErr message for the 485 diverse LSP with the error code "Routing Problem" (24) and 486 error sub-code "Route blocked by Exclude Route" (67). The 487 PSR flag SHOULD NOT be set. 489 o If the L-flag was set in the original exclusion, the 490 processing node SHOULD send a PathErr message for the 491 diverse LSP with the error code error code "Notify Error" 492 (25) and error sub-code "Failed to respect Exclude Route" 493 (value: to be assigned by IANA, suggest value: 14). 495 The following rules apply whether or not the L-flag is set: 497 - An XRO object MAY contain multiple path subobjects. 499 - As specified in [RFC4874], a node receiving a Path message 500 carrying an XRO MAY reject the message if the XRO is too large 501 or complicated for the local implementation or the rules of 502 local policy. In this case, the node MUST send a PathErr 503 message with the error code "Routing Error" (24) and error sub- 504 code "XRO Too Complex" (68). A source node receiving this 505 error code/sub-code combination MAY reduce the complexity of 506 the XRO or route around the node that rejected the XRO. 508 - A source node receiving a PathErr message with the error code 509 "Notify Error" (25) and error sub-codes "Route of XRO path 510 unknown" or "Failed to respect Exclude Route" MAY take no 511 action. 513 - The attribute-flags affect the processing of the XRO subobject 514 as follows: 516 o When the "LSP ID to be ignored" flag is set, the 517 processing node MUST calculate a route based on exclusions 518 from the routes of all known LSPs matching the tunnel-id, 519 source, destination and extended tunnel-id specified in 520 the subobject. When this flag is not set, the lsp-id is 521 not ignored and the exclusion applies only to the 522 specified LSP (i.e., LSP level exclusion). 524 o When the "destination node exception" flag is not set, the 525 exclusion flags SHOULD also be respected for the 526 destination node. 528 o When the "processing node exception" flag is not set, the 529 exclusion flags SHOULD also be respected for the 530 processing node. 532 o When the "penultimate node exception" flag is not set, the 533 exclusion flags SHOULD also be respected for the 534 penultimate node. 536 2.4. Path EXRS Subobject 538 [RFC4874] defines the EXRS ERO subobject. An EXRS is used to 539 identify abstract nodes or resources that must not or should not 540 be used on the path between two inclusive abstract nodes or 541 resources in the explicit route. An EXRS contains one or more 542 subobjects of its own, called EXRS subobjects [RFC4874]. 544 An EXRS MAY include an IPv4 Point-to-Point (P2P) Path subobject 545 as specified in section 2.2.1. In this case, the EXRS format 546 would be as follows: 548 0 1 2 3 549 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 550 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 551 |L| Type | Length | Reserved | 552 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 553 |L| Type | Length |Attribute Flags|Exclusion Flags| 554 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 555 | IPv4 tunnel end point address | 556 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 557 | Must Be Zero | Tunnel ID | 558 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 559 | Extended Tunnel ID | 560 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 561 | IPv4 tunnel sender address | 562 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 | Must Be Zero | LSP ID | 564 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 566 The meaning of respective fields in EXRS header is as defined in 567 [RFC4874]. The meaning of respective fields in IPv4 P2P Path 568 subobject is as defined earlier in this document. This is with 569 the exceptions that: 571 - The processing node exception applies to the node processing 572 the ERO. 574 - If the L bit in the ERO header is not set (ERO.L = 0), the 575 IPv4 P2P Path subobject is processed against the path(s) for 576 which the processing node is a source, destination or transit 577 node. 579 - The penultimate node exception applies to the penultimate node 580 of the loose hop. This flag is only processed if the ERO.L bit 581 is set, i.e. in the loose ERO hop case. 583 - The destination node exception applies to the last explicit 584 node to which the loose hop is expanded. This flag is only 585 processed if ERO.L bit is set, i.e., in the loose ERO hop case. 587 2.4.1. Processing Rules for the EXRS with Path subobject 589 The processing rules for the EXRS object are unchanged from 590 [RFC4874]. When the EXRS contains one or more Path subobject(s), 591 the processing rules specified in Section 2.3 apply to the node 592 processing the ERO with the EXRS subobject. 594 The EXRS scope is limited to the loose hop in which the EXRS 595 appears. If loose-hop expansion results in the creation of 596 another loose-hop in the outgoing ERO, the processing node MAY 597 include the EXRS in the newly-created loose hop for further 598 processing by downstream nodes. 600 3. Security Considerations 602 This document does not introduce any additional security issues 603 above those identified in [RFC5920], [RFC2205], [RFC3209], 604 [RFC3473] and [RFC4874]. 606 4. IANA Considerations 608 4.1. New XRO subobject types 610 IANA registry: RSVP PARAMETERS 611 Subsection: Class Names, Class Numbers, and Class Types 612 This document introduces two new subobjects for the EXCLUDE_ROUTE 613 object [RFC4874], C-Type 1. 615 Subobject Type 616 Subobject Description 617 -------------- 618 --------------------- 619 To be assigned by IANA IPv4 P2P Path subobject 620 (suggested value: 36) 621 To be assigned by IANA IPv6 P2P Path subobject 622 (suggested value: 37) 624 4.2. New EXRS subobject types 626 The IPv4 and IPv6 P2P Path subobjects are also defined as new 627 EXRS subobjects. 629 4.3. New RSVP error sub-codes 631 IANA registry: RSVP PARAMETERS 632 Subsection: Error Codes and Globally-Defined Error Value Sub- 633 Codes 635 For Error Code "Notify Error" (25) (see [RFC3209]) the following 636 sub-codes are defined. 638 Sub-code Value 639 -------- ----- 641 Route of XRO path unknown To be assigned by IANA. 642 Suggested Value: 13. 644 Failed to respect Exclude Route To be assigned by IANA. 645 Suggested Value: 14. 647 5. Acknowledgements 649 The authors would like to thank Luyuan Fang and Walid Wakim for 650 their review comments. 652 6. References 654 6.1. Normative References 656 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 657 Requirement Levels", BCP 14, RFC 2119, March 1997. 659 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 660 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 661 LSP Tunnels", RFC 3209, December 2001. 663 [RFC3473] Berger, L., "Generalized Multi-Protocol Label Switching 664 (GMPLS) Signaling Resource ReserVation Protocol-Traffic 665 Engineering (RSVP-TE) Extensions", RFC 3473, January 666 2003. 668 [RFC4874] Lee, CY., Farrel, A., and S. De Cnodder, "Exclude 669 Routes - Extension to Resource ReserVation Protocol- 670 Traffic Engineering (RSVP-TE)", RFC 4874, April 2007. 672 6.2. Informative References 674 [RFC4208] Swallow, G., Drake, J., Ishimatsu, H., and Y. Rekhter, 675 "Generalized Multiprotocol Label Switching (GMPLS) 676 User-Network Interface (UNI): Resource ReserVation 677 Protocol-Traffic Engineering (RSVP-TE) Support for the 678 Overlay Model", RFC 4208, October 2005. 680 [RFC2209] Braden, R. and L. Zhang, "Resource ReSerVation Protocol 681 (RSVP) -- Version 1 Message Processing Rules", RFC 682 2209, September 1997. 684 [RFC5920] Fang, L., Ed., "Security Framework for MPLS and GMPLS 685 Networks", RFC 5920, July 2010. 687 Authors' Addresses 689 Zafar Ali 690 Cisco Systems. 691 Email: zali@cisco.com 693 George Swallow 694 Cisco Systems 695 swallow@cisco.com 697 Clarence Filsfils 698 Cisco Systems, Inc. 699 cfilsfil@cisco.com 700 Matt Hartley 701 Cisco Systems 702 Email: mhartley@cisco.com 704 Ori Gerstel 705 Cisco Systems 706 ogerstel@cisco.com 708 Gabriele Maria Galimberti 709 Cisco Systems 710 ggalimbe@cisco.com 712 Kenji Kumaki 713 KDDI Corporation 714 Email: ke-kumaki@kddi.com 716 Rudiger Kunze 717 Deutsche Telekom AG 718 Ruediger.Kunze@telekom.de 720 Julien Meuric 721 France Telecom Orange 722 Email: julien.meuric@orange.com