idnits 2.17.1 draft-ietf-ccamp-lsp-diversity-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == 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 : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (July 15, 2013) is 3937 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) No issues found here. Summary: 0 errors (**), 0 flaws (~~), 2 warnings (==), 1 comment (--). 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: January 14, 2014 Matt Hartley 6 Ori Gerstel 7 Gabriele Maria Galimberti 8 Cisco Systems 9 Kenji Kumaki 10 KDDI Corporation 11 Ruediger Kunze 12 Deutsche Telekom AG 13 Julien Meuric 14 France Telecom Orange 15 July 15, 2013 17 Resource ReserVation Protocol-Traffic Engineering (RSVP-TE) Path 18 Diversity using Exclude Routes 20 draft-ietf-ccamp-lsp-diversity-02.txt 22 Status of this Memo 24 This Internet-Draft is submitted in full conformance with the 25 provisions of BCP 78 and BCP 79. 27 Internet-Drafts are working documents of the Internet Engineering 28 Task Force (IETF). Note that other groups may also distribute 29 working documents as Internet-Drafts. The list of current Internet- 30 Drafts is at http://datatracker.ietf.org/drafts/current/. 32 Internet-Drafts are draft documents valid for a maximum of six months 33 and may be updated, replaced, or obsoleted by other documents at any 34 time. It is inappropriate to use Internet-Drafts as reference 35 material or to cite them other than as "work in progress." 37 This Internet-Draft will expire on January 13, 2014. 39 Copyright Notice 41 Copyright (c) 2013 IETF Trust and the persons identified as the 42 document authors. All rights reserved. 44 This document is subject to BCP 78 and the IETF Trust's Legal 45 Provisions Relating to IETF Documents 46 (http://trustee.ietf.org/license-info) in effect on the date of 47 publication of this document. Please review these documents 48 carefully, as they describe your rights and restrictions with respect 49 to this document. Code Components extracted from this document must 50 include Simplified BSD License text as described in Section 4.e of 51 the Trust Legal Provisions and are provided without warranty as 52 described in the Simplified BSD License. 54 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 56 Abstract 58 RFC 4874 specifies methods by which route exclusions may be 59 communicated during RSVP-TE signaling in networks where precise 60 explicit paths are not computed by the LSP source node. This 61 document specifies signaling for additional route exclusions based 62 on Paths currently existing or expected to exist within the network. 64 Conventions used in this document 66 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 67 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 68 document are to be interpreted as described in RFC 2119 [RFC2119]. 70 Table of Contents 72 1. Introduction..................................................2 73 2. RSVP-TE signaling extensions..................................4 74 2.1. Terminology...........................................5 75 2.2. Path XRO Subobjects...................................5 76 2.2.1. IPv4 Point-to-Point Path subobject....................... 5 77 2.2.2. IPv6 Point-to-Point Path subobject....................... 8 78 2.3. Processing rules for the Path XRO subobjects..........9 79 2.4. Path EXRS Subobject..................................12 80 3. Security Considerations......................................13 81 4. IANA Considerations..........................................13 82 4.1. New XRO subobject types..............................13 83 4.2. New EXRS subobject types.............................14 84 4.3. New RSVP error sub-codes.............................14 85 5. Acknowledgements.............................................14 86 6. References...................................................14 87 6.1. Normative References.................................14 88 6.2. Informative References...............................15 90 1. Introduction 92 Path diversity is a well-known requirement from Service Providers. 93 Such diversity is required to ensure Label-Switched Paths (LSPs) 94 may be established without sharing resources, thus greatly 95 reducing the probability of simultaneous connection failures. 97 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 99 When route computation for paths that need to be diverse is 100 performed at the LSP's source node, this requirement can be met by 101 a local decision at that node. However, there are scenarios when 102 route computations are performed by remote nodes, thus there is a 103 need for relevant diversity requirements to be communicated to 104 those nodes. These include (but are not limited to): 106 . LSPs with loose hops in the Explicit Route Object (ERO), e.g. 107 inter-domain LSPs; 109 . Generalized Multi-Protocol Label Switching (GMPLS) User-Network 110 Interface (UNI) where route computation may be performed by the 111 (server layer) core node [RFC4208]. 113 [RFC4874] introduced a means of specifying nodes and resources to 114 be excluded from a route, using the eXclude Route Object (XRO) and 115 Explicit Exclusion Route Subobject (EXRS). 117 [RFC4874] facilitates the calculation of diverse routes for LSPs 118 based on known properties of those paths including addresses of 119 links and nodes traversed, and Shared Risk Link Groups (SRLGs) of 120 traversed links. This requires that these properties of the 121 path(s) from which diversity is required be known to the source 122 node which initiates signaling. However, there are circumstances 123 under which this may not be possible or desirable, including (but 124 not limited to): 126 . Exclusion of a path which does not originate, terminate or 127 traverse the source node signaling the diverse LSP, in which 128 case the addresses and SRLGs of the path from which diversity 129 is required are unknown to the source node. 131 . Exclusion of a path which, while known at the source node of 132 the diverse LSP, has incomplete or unavailable route 133 information, e.g. due to confidentiality of the path 134 attributes. In other words, the scenario in which the reference 135 path is hosted by the source / requesting node but the 136 properties required to construct an XRO object are not known to 137 source / requesting node. Inter-domain and GMPLS overlay 138 networks may present such restrictions. 140 . If the source node knows the route of the reference path from 141 which diversity is required, it can use this information to 142 construct an XRO and send it in the path message during the 143 signaling of a diverse LSP. However, if the route of the 144 excluded path changes (e.g. due to re-optimization or failure 145 in the network), the source node would need to change the 147 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 149 diverse path to ensure that it remains diverse from the 150 excluded path. It is preferable to have this decision made by 151 the node that performed the path-calculation for the diverse 152 path. For example, in the case of GMPLS-UNI, it is better to 153 have such responsibility at the server layer as opposed to at 154 the client layer so that the diversity requirements are 155 transparent to the client layer. Furthermore, in all networking 156 scenarios, if the node performing the route computation/ 157 expansion is aware of the diversity requirements of the two 158 paths, it may consider joint re-optimization of the diverse 159 paths. 161 This document addresses such scenarios and defines procedures 162 that may be used to exclude the route taken by a particular LSP, 163 or the routes taken by all LSPs belonging to a single tunnel. 164 Note that this diversity requirement is different from the 165 diversity requirements of path protection where both the 166 reference and diverse LSPs belong to the same tunnel. The 167 diversity requirements considered in this document do not require 168 that the paths in question belonging to the same tunnel or share 169 the same source or destination node. 171 The means by which the node calculating or expanding the route of 172 the signaled LSP discovers the route of the path(s) from which 173 the signaled LSP requires diversity are beyond the scope of this 174 document. 176 This document addresses only the exclusion of point-to-point 177 paths; point-to-multipoint paths will be addressed in a future 178 version. 180 If mutually diverse routes are desired for two LSPs belonging to 181 different tunnels, it is recommended that they be signaled with 182 XRO LSP subobjects referencing each other. The processing rules 183 specified in this document cover this case. 185 2. RSVP-TE signaling extensions 187 This section describes the signaling extensions required to 188 address the aforementioned requirements. Specifically, this 189 document defines a new LSP subobject to be signaled in the 190 EXCLUDE_ROUTE object (XRO) and/ or Explicit Exclusion Route 191 Subobject (EXRS) defined in [RFC4874]. Inclusion of the LSP 192 subobject in any other RSVP object is not defined. 194 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 196 2.1. Terminology 198 In this document, the following terminology is adopted: 200 Excluded path: the path from which diversity is required. 202 Diverse LSP: the LSP being signaled with XRO/ EXRS containing the 203 path subobject referencing the excluded path(s). 205 Processing node: the node performing a path-calculation involving 206 an exclusion specified in an XRO or EXRS. 208 Destination node: in the context of an XRO, this is the 209 destination of the LSP being signaled. In the context of an EXRS, 210 the destination node is the last explicit node to which the loose 211 hop is expanded. 213 Penultimate node: in the context of an XRO, this is the 214 penultimate hop of the LSP being signaled. In the context of an 215 EXRS, the penultimate node is the penultimate node of the loose 216 hop undergoing expansion. 218 2.2. Path XRO Subobjects 220 New IPv4 and IPv6 Point-to-Point (P2P) Path XRO subobjects are 221 defined by this document as follows. 223 2.2.1. IPv4 Point-to-Point Path subobject 225 0 1 2 3 226 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 227 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 228 |L| Type | Length |Attribute Flags|Exclusion Flags| 229 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 230 | IPv4 tunnel end point address | 231 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 232 | Must Be Zero | Tunnel ID | 233 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 234 | Extended Tunnel ID | 235 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 236 | IPv4 tunnel sender address | 237 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 238 | Must Be Zero | LSP ID | 239 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 241 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 243 L 244 The L-flag is used as for the other XRO subobjects defined 245 in [RFC4874]. 247 0 indicates that the attribute specified MUST be excluded. 249 1 indicates that the attribute specified SHOULD be 250 avoided. 252 Type 254 IPv4 Point-to-Point Path subobject 255 (to be assigned by IANA; suggested value: 36). 257 Length 259 The length contains the total length of the subobject in 260 bytes, including the type and length fields. The length is 261 always 24. 263 Attribute Flags 265 The Attribute Flags are used to communicate desirable 266 attributes of the LSP being signaled. The following flags 267 are defined. None, all or multiple attribute flags MAY be 268 set within the same subobject. 270 0x01 = LSP ID to be ignored 272 This flag is used to indicate tunnel level exclusion. 273 Specifically, this flag is used to indicate that the 274 lsp-id field of the subobject is to be ignored and the 275 exclusion applies to any LSP matching the rest of the 276 supplied FEC. 278 0x02 = Destination node exception 280 This flag is used to indicate that the destination node 281 of the LSP being signaled MAY be shared with the 282 excluded path even when this violates the exclusion 283 flags. 285 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 287 0x04 = Processing node exception 289 This flag is used to indicate that the processing node 290 MAY be shared with the excluded path even when this 291 violates the exclusion flags. 293 0x08 = Penultimate node exception 295 This flag is used to indicate that the penultimate node 296 of the LSP being signaled MAY be shared with the 297 excluded path even when this violates the exclusion 298 flags. 300 Exclusion Flags 302 The Exclusion-Flags are used to communicate desirable 303 types of exclusion. The following flags are defined. 305 0x01 = SRLG exclusion 307 This flag is used to indicate that the route of the 308 LSP being signaled is requested to be SRLG diverse 309 from the excluded path specified by the LSP 310 subobject. 312 0x02 = Node exclusion 314 This flag is used to indicate that the route of the 315 LSP being signaled is requested to be node diverse 316 from the excluded path specified by the LSP 317 subobject. 319 (Note: the meaning of this flag may be modified by 320 the value of the Attribute-flags.) 322 0x04 = Link exclusion 324 This flag is used to indicate that the route of the 325 LSP being signaled is requested to be link diverse 326 from the path specified by the LSP subobject. 328 The remaining fields are as defined in [RFC3209]. 330 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 332 2.2.2. IPv6 Point-to-Point Path subobject 334 0 1 2 3 335 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 336 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 337 |L| Type | Length |Attribute Flags|Exclusion Flags| 338 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 339 | IPv6 tunnel end point address | 340 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 341 | IPv6 tunnel end point address (cont.) | 342 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 | IPv6 tunnel end point address (cont.) | 344 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 345 | IPv6 tunnel end point address (cont.) | 346 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 347 | Must Be Zero | Tunnel ID | 348 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 349 | Extended Tunnel ID | 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 | Extended Tunnel ID (cont.) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | Extended Tunnel ID (cont.) | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 355 | Extended Tunnel ID (cont.) | 356 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 357 | IPv4 tunnel sender address | 358 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 359 | IPv4 tunnel sender address (cont.) | 360 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 361 | IPv4 tunnel sender address (cont.) | 362 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 363 | IPv4 tunnel sender address (cont.) | 364 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 365 | Must Be Zero | LSP ID | 366 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 368 L 369 The L-flag is used as for the other XRO subobjects defined 370 in [RFC4874]. 372 0 indicates that the attribute specified MUST be excluded. 374 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 376 1 indicates that the attribute specified SHOULD be 377 avoided. 379 Type 381 IPv6 Point-to-Point Path subobject 382 (to be assigned by IANA; suggested value: 37). 384 Length 386 The length contains the total length of the subobject in 387 bytes, including the type and length fields. The length is 388 always 48. 390 The Attribute Flags and Exclusion Flags are as defined for the 391 IPv4 Point-to-Point LSP XRO subobject. 393 The remaining fields are as defined in [RFC3209]. 395 2.3. Processing rules for the Path XRO subobjects 397 XRO processing as described in [RFC4874] is unchanged. 399 If the processing node is the destination for the LSP being 400 signaled, it SHOULD NOT process a Path XRO subobject. 402 If the L-flag is not set, the processing node follows the 403 following procedure: 405 - The processing node MUST ensure that any route calculated for 406 the signaled LSP respects the requested exclusion flags with 407 respect to the excluded path referenced by the subobject, 408 including local resources. 410 - If the processing node fails to find a route that meets the 411 requested constraint, the processing node MUST return a PathErr 412 with the error code "Routing Problem" (24) and error sub-code 413 "Route blocked by Exclude Route" (67). 415 - If the excluded path referenced in the LSP subobject is unknown 416 to the processing node, the processing node SHOULD ignore the 417 LSP subobject in the XRO and SHOULD proceed with the signaling 418 request. After sending the Resv for the signaled LSP, the 420 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 422 processing node SHOULD return a PathErr with the error code 423 "Notify Error" (25) and error sub-code "Route of XRO path 424 unknown" (value to be assigned by IANA, suggested value: 13) 425 for the signaled LSP. 427 If the L-flag is set, the processing node follows the following 428 procedure: 430 - The processing node SHOULD respect the requested exclusion 431 flags with respect to the excluded path as far as possible. 433 - If the processing node fails to find a route that meets the 434 requested constraint, it SHOULD proceed with signaling using a 435 suitable route that meets the constraint as far as possible. 436 After sending the Resv for the signaled LSP, it SHOULD return a 437 PathErr message with error code "Notify Error" (25) and error 438 sub-code "Failed to respect Exclude Route" (value: to be 439 assigned by IANA, suggest value: 14) to the source node. 441 - If the excluded path referenced in the LSP subobject is unknown 442 to the processing node, the processing node SHOULD ignore the 443 LSP subobject in the XRO and SHOULD proceed with the signaling 444 request. After sending the Resv for signaled LSP, the 445 processing node SHOULD return a PathErr message with the error 446 code "Notify Error" (25) and error sub-code "Route of XRO path 447 unknown" for the signaled LSP. 449 If, subsequent to the initial signaling of a diverse LSP: 451 - an excluded path referenced in the diverse LSP's XRO subobject 452 becomes known to the processing node (e.g. when the excluded 453 path is signaled), or 455 - A change in the excluded path becomes known to the processing 456 node, 458 the processing node SHOULD re-evaluate the exclusion and 459 diversity constraints requested by the diverse LSP to determine 460 whether they are still satisfied. 462 - If the requested exclusion constraints for the diverse LSP are 463 no longer satisfied and an alternative route for the diverse 464 LSP that can satisfy those constraints exists, the processing 465 node SHOULD send a PathErr message for the diverse LSP with the 466 error code "Notify Error" (25) and error sub-code "Preferable 467 path exists" (6). A source node receiving a PathErr message 469 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 471 with this error code and sub-code combination MAY try to 472 reoptimize the diverse tunnel to the new compliant path. 474 - If the requested exclusion constraints for the diverse LSP are 475 no longer satisfied and no alternative path for the diverse LSP 476 that can satisfy those constraints exists, then: 478 o If the L-flag was not set in the original exclusion, the 479 processing node MUST send a PathErr message for the 480 diverse LSP with the error code "Routing Problem" (24) and 481 error sub-code "Route blocked by Exclude Route" (67). The 482 PSR flag SHOULD NOT be set. 484 o If the L-flag was set in the original exclusion, the 485 processing node SHOULD send a PathErr message for the 486 diverse LSP with the error code error code "Notify Error" 487 (25) and error sub-code "Failed to respect Exclude Route" 488 (value: to be assigned by IANA, suggest value: 14). 490 The following rules apply whether or not the L-flag is set: 492 - An XRO object MAY contain multiple path subobjects. 494 - As specified in [RFC4874], a node receiving a Path message 495 carrying an XRO MAY reject the message if the XRO is too large 496 or complicated for the local implementation or the rules of 497 local policy. In this case, the node MUST send a PathErr 498 message with the error code "Routing Error" (24) and error sub- 499 code "XRO Too Complex" (68). A source node receiving this 500 error code/sub-code combination MAY reduce the complexity of 501 the XRO or route around the node that rejected the XRO. 503 - A source node receiving a PathErr message with the error code 504 "Notify Error" (25) and error sub-codes "Route of XRO path 505 unknown" or "Failed to respect Exclude Route" MAY take no 506 action. 508 - The attribute-flags affect the processing of the XRO subobject 509 as follows: 511 o When the "LSP ID to be ignored" flag is set, the 512 processing node MUST calculate a route based on exclusions 513 from the routes of all known LSPs matching the tunnel-id, 514 source, destination and extended tunnel-id specified in 515 the subobject. When this flag is not set, the lsp-id is 516 not ignored and the exclusion applies only to the 517 specified LSP (i.e., LSP level exclusion). 519 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 521 o When the "destination node exception" flag is not set, the 522 exclusion flags SHOULD also be respected for the 523 destination node. 525 o When the "processing node exception" flag is not set, the 526 exclusion flags SHOULD also be respected for the 527 processing node. 529 o When the "penultimate node exception" flag is not set, the 530 exclusion flags SHOULD also be respected for the 531 penultimate node. 533 2.4. Path EXRS Subobject 535 [RFC4874] defines the EXRS ERO subobject. An EXRS is used to 536 identify abstract nodes or resources that must not or should not 537 be used on the path between two inclusive abstract nodes or 538 resources in the explicit route. An EXRS contains one or more 539 subobjects of its own, called EXRS subobjects [RFC4874]. 541 An EXRS MAY include an IPv4 Point-to-Point (P2P) Path subobject 542 as specified in section 2.2.1. In this case, the EXRS format 543 would be as follows: 545 0 1 2 3 546 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 547 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 548 |L| Type | Length | Reserved | 549 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 550 |L| Type | Length |Attribute Flags|Exclusion Flags| 551 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 552 | IPv4 tunnel end point address | 553 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 554 | Must Be Zero | Tunnel ID | 555 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 556 | Extended Tunnel ID | 557 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 558 | IPv4 tunnel sender address | 559 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 560 | Must Be Zero | LSP ID | 561 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 563 The meaning of respective fields in EXRS header are as defined in 564 [RFC4874]. The meaning of respective fields in IPv4 P2P Path 565 subobject is as defined earlier in this document. 567 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 569 The processing rules for the EXRS object are unchanged from 570 [RFC4874]. When the EXRS contains one or more Path subobject(s), 571 the processing rules specified in Section 2.3 apply to the node 572 processing the ERO with the EXRS subobject. 574 If a loose-hop expansion results in the creation of another 575 loose-hop in the outgoing ERO, the processing node MAY include 576 the EXRS in the newly-created loose hop for further processing by 577 downstream nodes. 579 The processing node exception for the EXRS subobject applies to 580 the node processing the ERO. 582 The destination node exception for the EXRS subobject applies to 583 the explicit node identified by the ERO subobject that identifies 584 the next abstract node. This flag is only processed if the L bit 585 is set in the ERO subobject that identifies the next abstract 586 node. 588 The penultimate node exception for the EXRS subobject applies to 589 the node before the explicit node identified by the ERO subobject 590 that identifies the next abstract node. This flag is only 591 processed if the L bit is set in the ERO subobject that 592 identifies the next abstract node. 594 3. Security Considerations 596 This document does not introduce any additional security issues 597 above those identified in [RFC5920], [RFC2205], [RFC3209], 598 [RFC3473] and [RFC4874]. 600 4. IANA Considerations 602 4.1. New XRO subobject types 604 IANA registry: RSVP PARAMETERS 605 Subsection: Class Names, Class Numbers, and Class Types 607 This document introduces two new subobjects for the EXCLUDE_ROUTE 608 object [RFC4874], C-Type 1. 610 Subobject Type 611 Subobject Description 612 -------------- 613 --------------------- 614 To be assigned by IANA IPv4 P2P Path subobject 615 (suggested value: 36) 617 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 619 To be assigned by IANA IPv6 P2P Path subobject 620 (suggested value: 37) 622 4.2. New EXRS subobject types 624 The IPv4 and IPv6 P2P Path subobjects are also defined as new 625 EXRS subobjects. 627 4.3. New RSVP error sub-codes 629 IANA registry: RSVP PARAMETERS 630 Subsection: Error Codes and Globally-Defined Error Value Sub- 631 Codes 633 For Error Code "Notify Error" (25) (see [RFC3209]) the following 634 sub-codes are defined. 636 Sub-code Value 637 -------- ----- 639 Route of XRO path unknown To be assigned by IANA. 640 Suggested Value: 13. 642 Failed to respect Exclude Route To be assigned by IANA. 643 Suggested Value: 14. 645 5. Acknowledgements 647 The authors would like to thank Luyuan Fang and Walid Wakim for 648 their review comments. 650 6. References 652 6.1. Normative References 654 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 655 Requirement Levels", BCP 14, RFC 2119, March 1997. 657 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, 658 V., and G. Swallow, "RSVP-TE: Extensions to RSVP for 659 LSP Tunnels", RFC 3209, December 2001. 661 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 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 [RFC2205] Braden, R. (Ed.), Zhang, L., Berson, S., Herzog, S. and 681 S. Jamin, "Resource ReserVation Protocol -- Version 1 682 Functional Specification", RFC 2205, 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 701 Internet Draft draft-ietf-ccamp-lsp-diversity-02.txt 703 Matt Hartley 704 Cisco Systems 705 Email: mhartley@cisco.com 707 Ori Gerstel 708 Cisco Systems 709 ogerstel@cisco.com 711 Gabriele Maria Galimberti 712 Cisco Systems 713 ggalimbe@cisco.com 715 Kenji Kumaki 716 KDDI Corporation 717 Email: ke-kumaki@kddi.com 719 Rudiger Kunze 720 Deutsche Telekom AG 721 Ruediger.Kunze@telekom.de 723 Julien Meuric 724 France Telecom Orange 725 Email: julien.meuric@orange.com