idnits 2.17.1 draft-ietf-pce-pcep-xro-06.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 18. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 764. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 740. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 747. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 753. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- Couldn't find a document date in the document -- date freshness check skipped. 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: 1 error (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Oki 3 Internet Draft T. Takeda 4 Intended Status: Standards Track NTT 5 Created: July 18th, 2008 A. Farrel 6 Expires: January 18th, 2009 Old Dog Consulting 8 Extensions to the Path Computation Element Communication Protocol 9 (PCEP) for Route Exclusions 11 draft-ietf-pce-pcep-xro-06.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 The Path Computation Element (PCE) provides functions of path 39 computation in support of traffic engineering in Multi-Protocol 40 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 42 When a Path Computation Client (PCC) requests a PCE for a route, it 43 may be useful for the PCC to specify, as constraints to the path 44 computation, abstract nodes, resources, and Shared Risk Link Groups 45 (SRLGs) that are to be explicitly excluded from the computed route. 46 Such constraints are termed route exclusions. 48 The PCE Communication Protocol (PCEP) is designed as a communication 49 protocol between PCCs and PCEs. This document presents PCEP 50 extensions for route exclusions. 52 Conventions used in this document 54 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 55 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 56 this document are to be interpreted as described in RFC 2119 57 [RFC2119]. 59 Table of Contents 61 1. Introduction ................................................. 3 62 2. Protocol Procedures and Extensions ........................... 3 63 2.1. Exclude Route Object (XRO) ................................. 4 64 2.1.1. Definition ............................................... 4 65 2.1.2. Processing Rules ......................................... 8 66 2.2. Explicit Route Exclusion ................................... 9 67 2.2.1. Definition ............................................... 9 68 2.2.2. Processing Rules ........................................ 10 69 3. Exclude Route with Confidentiality .......................... 11 70 3.1. Exclude Route Object (XRO) Carrying Path Key .............. 11 71 3.1.1. Definition .............................................. 11 72 3.1.2. Processing Rules ........................................ 11 73 4. IANA Considerations ......................................... 12 74 4.1. PCEP Objects .............................................. 12 75 4.2. New Subobject for the Include Route Object ................ 13 76 4.3. Error Object Field Values ................................. 13 77 4.4. Exclude Route Flags ....................................... 13 78 5. Manageability Considerations ................................ 14 79 6. Security Considerations ..................................... 14 80 7. References .................................................. 14 81 7.1. Normative Reference ....................................... 14 82 7.2. Informative Reference ..................................... 15 83 8. Acknowledgements ............................................ 15 84 9. Authors' Addresses .......................................... 16 85 10. Intellectual Property Statement ............................ 16 87 1. Introduction 89 The Path Computation Element (PCE) defined in [RFC4655] is an entity 90 that is capable of computing a network path or route based on a 91 network graph, and applying computational constraints. A Path 92 Computation Client (PCC) may make requests to a PCE for paths to be 93 computed. 95 When a PCC requests a PCE for a route, it may be useful for the PCC 96 to specify abstract nodes, resources, and Shared Risk Link Groups 97 (SRLGs) that are to be explicitly excluded from the route. 99 For example, disjoint paths for inter-domain LSPs may be computed by 100 cooperation between PCEs, each of which computes segments of the 101 paths across one domain. In order to achieve path computation for a 102 secondary (backup) path, a PCE may act as a PCC to request another 103 PCE for a route that must be node/link/SRLG disjoint from the 104 primary (working) path. Another example is where a network operator 105 wants a path to avoid specified nodes for administrative reasons, 106 perhaps because the specified nodes will be out-of-services in the 107 near future. 109 [RFC4657] specifies generic requirements for a communication 110 protocol between PCCs and PCEs. Generic constraints described in 111 [RFC4657] include route exclusions for links, nodes, and SRLGs. That 112 is, the requirement for support of route exclusions within the PCC- 113 PCE communication protocol is already established. 115 The PCE communication protocol (PCEP) is designed as a communication 116 protocol between PCCs and PCEs and is defined in [PCEP]. This 117 document presents PCEP extensions to satisfy the requirements for 118 route exclusions as described in Sections 5.1.4 and 5.1.16 of 119 [RFC4657]. 121 Note that MPLS-TE and GMPLS signaling extensions for communicating 122 route exclusions between network nodes for specific Label Switched 123 Paths (LSPs) are described in [RFC4874]. Route exclusions may be 124 specified during provisioning requests for specific LSPs by setting 125 the mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in 126 [RFC3812] to false (2). 128 2. Protocol Procedures and Extensions 130 This section describes the procedures adopted by a PCE handling a 131 request for path computation with route exclusions received from a 132 PCC, and defines how those exclusions are encoded. 134 There are two types of route exclusion described in [RFC4874]. 136 1. Exclusion of certain abstract nodes or resources from the whole 137 path. This set of abstract nodes is referred to as the Exclude 138 Route List. 140 2. Exclusion of certain abstract nodes or resources between a 141 specific pair of abstract nodes present in an explicit path. Such 142 specific exclusions are referred to as an Explicit Route 143 Exclusion. 145 This document defines protocol extensions to allow a PCC to specify 146 both types of route exclusions to a PCE on a path computation 147 request. 149 A new PCEP object, the Exclude Route Object (XRO), is defined to 150 convey the Exclude Route List. The existing Include Route Object 151 (IRO) in PCEP [PCEP] is modified by introducing a new IRO subobject, 152 the Explicit Exclusion Route Subobject (EXRS), to convey Explicit 153 Route Exclusions. 155 2.1. Exclude Route Object (XRO) 157 2.1.1. Definition 159 The XRO is OPTIONAL and MAY be carried within PCReq and PCRep 160 messages. 162 When present in a PCReq message, the XRO provides a list of network 163 resources that the PCE is requested to exclude from the path that it 164 computes. Flags associated with each list member instruct the PCE as 165 to whether the network resources must be excluded from the computed 166 path, or whether the PCE should make best efforts to exclude the 167 resources from the computed path. 169 The XRO MAY be used on a PCRep message that carries the NO-PATH 170 object (i.e., one that reports a path computation failure) to 171 indicate the set of elements of the original XRO that prevented the 172 PCE from finding a path. 174 The XRO MAY also be used on a PCRep message for a successful path 175 computation when the PCE wishes to provide a set of exclusions to be 176 signaled during LSP setup using the extensions to RSVP-TE [RFC4874]. 178 The XRO Object-Class is to be assigned by IANA (recommended 179 value=17) 181 The XRO Object-Type is to be assigned by IANA (recommended value=1) 182 0 1 2 3 183 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 184 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 185 | Reserved | Flags |F| 186 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 187 | | 188 // (Subobjects) // 189 | | 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 192 Figure 1: XRO body format 194 Reserved: 16 bits - MUST be set to zero on transmission and SHOULD 195 be ignored on receipt. 197 Flags: 16 bits - The following flags are currently defined: 199 F (Fail - 1 bit): when set, the requesting PCC requires the 200 computation of a new path for an existing TE LSP that has failed. 201 If the F bit is set, the path of the existing TE LSP MUST be 202 provided in the PCReq message by means of an RRO object defined in 203 [PCEP]. This allows the path computation to take into account the 204 previous path and reserved resources to avoid double bandwidth 205 booking should the TED have not yet been updated or the 206 corresponding resources not be yet been released. This will 207 usually be used in conjunction with the exclusion from the path 208 computation of the failed resource that caused the LSP to fail. 210 Subobjects. The XRO is up made of one or more subobject(s). An XRO 211 with no subobjects MUST NOT be sent and SHOULD be ignored on receipt. 213 In the following subobject definitions a set of fields have 214 consistent meaning as follows: 216 X 217 The X-bit indicates whether the exclusion is mandatory or 218 desired. 0 indicates that the resource specified MUST be 219 excluded from the path computed by the PCE. 1 indicates that the 220 resource specified SHOULD be excluded from the path computed by 221 the PCE, but MAY be included subject to PCE policy and the 222 absence of a viable path that meets the other constraints and 223 excludes the resource. 225 Type 226 The type of the subobject. The following subobject types are 227 defined. 229 Type Subobject 230 -------------+------------------------------- 231 1 IPv4 prefix 232 2 IPv6 prefix 233 4 Unnumbered Interface ID 234 32 Autonomous system number 235 34 SRLG 237 Length 238 The length of the subobject including the Type and Length 239 fields. 241 Prefix Length 242 Where present, this field can be used to indicate a set of 243 addresses matching a prefix. If the subobject indicates a 244 single address, the prefix length MUST be set to the full 245 length of the address. 247 Attribute 248 The Attribute field indicates how the exclusion subobject is to 249 be interpreted. 251 0 Interface 252 The subobject is to be interpreted as an interface or set of 253 interfaces. All interfaces identified by the subobject are to 254 be excluded from the computed path according to the setting 255 of the X-bit. This value is valid only for subobject types 1, 256 2, and 3. 258 1 Node 259 The subobject is to be interpreted as a node or set of nodes. 260 All nodes identified by the subobject are to be excluded from 261 the computed path according to the setting of the X-bit. This 262 value is valid only for subobject types 1, 2, 3, and 4. 264 2 SRLG 265 The subobject identifies an SRLG explicitly or indicates all 266 of the SRLGs associated with the resource or resources 267 identified by the subobject. Resources that share any SRLG 268 with those identified are to be excluded from the computed 269 path according to the setting of the X-bit. This value is 270 valid for all subobjects. 272 Reserved 273 Reserved fields within subobjects MUST be transmitted as zero 274 and SHOULD be ignored on receipt. 276 The subobjects are encoded as follows: 278 IPv4 prefix Subobject 280 0 1 2 3 281 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 282 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 283 |X| Type = 1 | Length | IPv4 address (4 bytes) | 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 | IPv4 address (continued) | Prefix Length | Attribute | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 288 IPv6 prefix Subobject 290 0 1 2 3 291 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 292 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 293 |X| Type = 2 | Length | IPv6 address (16 bytes) | 294 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 | IPv6 address (continued) | 296 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 297 | IPv6 address (continued) | 298 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 299 | IPv6 address (continued) | 300 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 | IPv6 address (continued) | Prefix Length | Attribute | 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 Unnumbered Interface ID Subobject 306 0 1 2 3 307 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 308 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 309 |X| Type = 3 | Length | Reserved | Attribute | 310 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 311 | TE Router ID | 312 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 313 | Interface ID | 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 316 The TE Router ID and Interface ID fields are as defined in 317 [RFC3477]. 319 Autonomous System Number Subobject 321 0 1 2 3 322 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 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 |X| Type = 4 | Length | 2-Octet AS Number | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 327 Note that as in other PCEP objects [PCEP] and RSVP-TE objects 328 [RFC3209], no support for 4-octet AS Numbers is provided. It is 329 anticipated that, as 4-octet AS Numbers become more common, both 330 PCEP and RSVP-TE will be updated in a consistent way to add this 331 support. 333 SRLG Subobject 335 0 1 2 3 336 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 337 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 338 |X| Type = 5 | Length | SRLG Id (4 bytes) | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | SRLG Id (continued) | Reserved | Attribute | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 The Attribute SHOULD be set to two (2) and SHOULD be ignored on 344 receipt. 346 2.1.2. Processing Rules 348 A PCC builds an XRO to encode all of the resources that it wishes 349 the PCE to exclude from the path that it is requested to compute. 350 For each exclusion, the PCC clears the X-bit to indicate that the 351 PCE is required to exclude the resources, or sets the X-bit to 352 indicate that the PCC simply desires that the resources are excluded. 353 For each exclusion, the PCC also sets the Attribute field to 354 indicate how the PCE should interpret the contents of the exclusion 355 subobject. 357 When a PCE receives a PCReq message it looks for an XRO to see if 358 exclusions are required. If the PCE finds more than one XRO it MUST 359 use the first one in the message and MUST ignore subsequent 360 instances. 362 If the PCE does not recognize the XRO it MUST return a PCErr message 363 with Error-Type "Unknown Object" as described in [PCEP]. 365 If the PCE is unwilling on unable to process the XRO it MUST return 366 a PCErr message with the Error-Type "Not supported object" and 367 follow the relevant procedures described in [PCEP]. 369 If the PCE processes the XRO and attempts to compute a path, it MUST 370 adhere to the requested exclusions as expressed in the XRO. That is, 371 the returned path MUST NOT include any resources encoded with the X- 372 bit clear, and SHOULD NOT include any with the X-bit set unless 373 alternate paths that match the other constraints expressed in the 374 PCReq are unavailable. 376 When a PCE returns a path in a PCRep it MAY also supply an XRO. An 377 XRO in a PCRep message with the NO-PATH object indicates that the 378 set of elements of the original XRO prevented the PCE from finding a 379 path. On the other hand, if an XRO is present in a PCRep message 380 without a NO-PATH object, the PCC SHOULD apply the contents using 381 the same rules as in [RFC4874] and the PCC or a corresponding LSR 382 SHOULD signal an RSVP-TE XRO to indicate the exclusions that 383 downstream LSRs should apply. This may be particularly useful in 384 per-domain path computation scenarios [RFC5152]. 386 2.2. Explicit Route Exclusion 388 2.2.1. Definition 390 Explicit Route Exclusion defines network elements that must not or 391 should not be used on the path between two abstract nodes or 392 resources explicitly indicated in the Include Route Object (IRO) 393 [PCEP]. This information is encoded by defining a new subobject for 394 the IRO. 396 The new IRO subobject, the Explicit Exclusion Route Subobject (EXRS), 397 has type defined by IANA (see Section 4). The EXRS contains one or 398 more subobjects in its own right. An EXRS MUST NOT be sent with no 399 subobjects, and if received with no subobjects MUST be ignored. 401 The format of the EXRS is as follows: 403 0 1 2 3 404 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 405 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 406 |L| Type | Length | Reserved | 407 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 408 | | 409 // One or more EXRS subobjects // 410 | | 411 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 413 L 414 MUST be set to zero on transmission and MUST be ignored on 415 receipt. 417 Reserved 418 MUST be set to zero on transmission and SHOULD be ignored on 419 receipt. 421 The EXRS subobject may carry any of the subobjects defined for 422 inclusion in the XRO by this document or by future documents. The 423 meanings of the fields of the XRO subobjects are unchanged when the 424 subobjects are included in an EXRS, except that scope of the 425 exclusion is limited to the single hop between the previous and 426 subsequent elements in the IRO. 428 2.2.2. Processing Rules 430 A PCC that supplies a partial explicit route to a PCE in an IRO MAY 431 also specify explicit exclusions by including one or more EXRSs in 432 the IRO. 434 If a PCE parses an IRO in a received PCReq message and encounters an 435 EXRS and does not recognize the subobject it MUST respond with a 436 PCErr message using the Error-Type "Unknown Object" or "Not supported 437 object" and set the Error-Value to "Unrecognized subobject type" or 438 "Unsupported subobject type" as described in [PCEP]. The PCE MAY also 439 include the IRO in the PCErr to indicate in which case, the IRO 440 SHOULD be terminated immediately after the unrecognized EXRS. 442 If a PCE that supports the EXRS in an IRO parses an IRO and 443 encounters an EXRS that contains a subobject that it does not support 444 or recognize it MUST act according to the setting of the X-bit in the 445 subobject. If the X-bit is clear, the PCE MUST respond with a PCErr 446 with Error-Type "Unrecognized EXRS subobject" and set the Error-Value 447 to the EXRS subobject type code (see Section 4). If the X-bit is set, 448 the PCE MAY respond with a PCErr as already stated or MAY ignore the 449 EXRS subobject: this choice is a local policy decision. 451 If a PCE parses an IRO and encounters an EXRS subobject that it 452 recognizes, it MUST act according to the requirements expressed in 453 the subobject. That is, if the X-bit is clear, the PCE MUST NOT 454 produce a path that includes any resource identified by the EXRS 455 subobject in the path between the previous abstract node in the IRO 456 and the next abstract node in the IRO. If the X-bit is set, the PCE 457 SHOULD NOT produce a path that includes any resource identified by 458 the EXRS subobject in the path between the previous abstract node in 459 the IRO and the next abstract node in the IRO unless it is not 460 possible to construct a path that avoids that resource while still 461 complying with the other constraints expressed in the PCReq message. 463 A successful path computation reported in a PCRep message MUST 464 include an ERO to specify the path that has been computed as 465 specified in [PCEP]. That ERO MAY contain specific route exclusions 466 using the EXRS as specified in [RFC4874]. 468 If the path computation fails and a PCErr is returned with a NO-PATH 469 object, the PCE MAY include an IRO to report the hops that could not 470 be complied with as described in [PCEP], and that IRO MAY include 471 EXRSs. 473 3. Exclude Route with Confidentiality 475 3.1. Exclude Route Object (XRO) Carrying Path Key 477 3.1.1. Definition 479 In PCE-based inter-domain diverse path computation, an XRO may be 480 used to find a backup (secondary) path. A sequential path 481 computation approach may be applied for this purpose, where a 482 working (primary) path route is computed first and a backup path 483 route that must be a node/link/SRLG disjoint route from the working 484 path is then computed [INTER-DOMAIN-REC-ANA]. Backward Recursive 485 Path Computation (BRPC) may be used for inter-domain path 486 computation [BRPC]. 488 In some cases of inter-domain computation (e.g., where domains are 489 administered by different service providers), confidentiality must 490 be kept. For primary path computation, to preserve confidentiality, 491 instead of explicitly expressing the computed route, Path Key 492 Subobjects (PKSs) [PCE-PATH-KEY] are carried in the Explicit Route 493 Object (ERO) in the PCRep Message. 495 Therefore, during inter-domain diverse path computation, it may be 496 necessary to request diversity from a path that is not fully known 497 and where a segment of the path is represented by a PKS. This means 498 that a PKS may be present as a subobject of the XRO on a PCReq 499 message. 501 The format and definition of PKS when it appears as an XRO subobject 502 are as defined in [PCE-PATH-KEY], except for the definition of L bit. 503 The L bit of the PKS subobject in the XRO MUST be ignored. 505 3.1.2. Processing Rules 507 Consider that BRPC is applied for both working and backup path 508 computation in a sequential manner. First, PCC requests PCE for the 509 computation of a working path. After BRPC processing has completed, 510 the PCC receives the results of the working-path computation 511 expressed in an ERO in a PCRep message. The ERO may include PKSs if 512 certain segments of the path are to be kept confidential. 514 For backup path computation, when the PCC constructs a PCReq Message, 515 it includes the entire working-path in the XRO so that the computed 516 path is node/link disjoint from the working path. The XRO may also 517 include SRLGs to ensure SRLG diversity from the working path. If the 518 working path ERO includes PKS subobjects, these are also included in 519 the XRO to allow the PCE to ensure diversity. 521 A set of PCEs for backup path computation may be the same as ones 522 for working path computation, or they may be different. 524 - Identical PCEs 526 In the case where the same PCEs are used for both path 527 computations, the processing is as follows. During the process of 528 BRPC for backup path computation, a PCE may encounter a PKS as it 529 processes the XRO when it creates a virtual path tree (VPT) in its 530 own domain. The PCE retrieves the PCE-ID from the PKS, recognizes 531 itself, and converts the PKS into a set of XRO subobjects which it 532 uses for the local calculation to create the VPT. The XRO 533 subobjects created in this way MUST NOT be shared with other PCEs. 534 Other operations are the same as BRPC. 536 - Different PCEs 538 In the case where a set of PCEs for bakup path computation is 539 different from the ones used for working path computation, the 540 processing is as follows. If a PCE encounters a PKS in an XRO when 541 it is creating a virtual path tree in its own domain, the PCE 542 retrieves the PCE-ID from the PKS and sends a PCReq message to the 543 identified PCE to expand the PKS. The PCE computing the VPT treats 544 the path segment in the response as a set of XRO subobjects in 545 performing its path computation. The XRO subobjects determined in 546 this way MUST NOT be shared with other PCEs. 548 4. IANA Considerations 550 4.1. PCEP Objects 552 The "PCEP Parameters" registry contains a subregistry "PCEP Objects". 553 IANA is requested to make the following allocations from this 554 registry. 556 Object Name Reference 557 Class 558 17 XRO [This.ID] 559 Object-Type 560 1: Route exclusion 562 This object should be registered as being allowed to carry the 563 following subobjects: 565 Subobject Type Reference 566 1 IPv4 prefix [RFC3209] 567 2 IPv6 prefix [RFC3209] 568 4 Unnumbered Interface ID [RFC3477] 569 32 Autonomous system number [RFC3209] 570 34 SRLG [RFC4874] 571 64 IPv4 Path Key [PCE-PATH-KEY] 572 65 IPv6 Path Key [PCE-PATH-KEY] 574 4.2. New Subobject for the Include Route Object 576 The "PCEP Parameters" registry contains a subregistry "PCEP Objects" 577 with an entry for the Include Route Object (IRO). 579 IANA is requested to indicate that a further subobject can be carried 580 in the IRO as follows: 582 Subobject Type Reference 584 33 Explicit Exclusion Route subobject (EXRS) [RFC4874] 586 4.3. Error Object Field Values 588 The "PCEP Parameters" registry contains a subregistry "Error Types 589 and Values". IANA is requested to make the following allocations from 590 this subregistry. 592 The value in this section is recommended and to be confirmed by IANA. 594 Error 595 Type Meaning Reference 597 11 Unrecognized EXRS subobject [This.I-D] 599 4.4. Exclude Route Flags 601 IANA is requested to create a subregistry of the "PCEP Parameters" 602 for the bits carried in the Flags field of the Exclude Route Object 603 (XRO). The subregistry should be called "Exclude Route Flags". 605 New bits may be allocated only by an IETF Consensus action. 607 The field contains 16 bits numbered from 1 as the least significant 608 bit. 610 Bit Name Description Reference 612 15 F-bit Fail [This.I-D] 614 5. Manageability Considerations 616 A MIB module for management of the PCEP is being specified in a 617 separate document [PCEP-MIB]. That MIB module allows examination of 618 individual PCEP messages, in particular requests, responses and 619 errors. 621 The MIB module MUST be extended to include the ability to view the 622 route exclusion extensions defined in this document. 624 Several local policy decisions should be made at the PCE. Firstly, 625 the exact behavior with regard to desired exclusions must be 626 available for examination by an operator and may be configurable. 627 Second, the behavior on receipt of an unrecognized XRO or EXRS 628 subobject with the X-bit set should be configurable and must be 629 available for inspection. The inspection and control of these local 630 policy choices may be part of the PCEP MIB module. 632 6. Security Considerations 634 The new exclude route mechanisms defined in this document allow 635 finer and more specific control of the path computed by a PCE. Such 636 control increases the risk if a PCEP message is intercepted, 637 modified, or spoofed because it allows the attacker to exert control 638 over the path that the PCE will compute or to amke the path 639 computation impossible. Therefore, the security techniques described 640 in [PCEP] are considered more important. 642 Note, however, that the roue exclusion mechanisms also provide the 643 operator with the ability to route around vulnerable parts of the 644 network and may be used to increase overall network security. 646 7. References 648 7.1. Normative Reference 650 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 651 requirements levels", RFC 2119, March 1997. 653 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 654 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 655 Tunnels", RFC 3209, December 2001. 657 [RFC5152] JP. Vasseur et al, "A Per-domain path computation method 658 for establishing Inter-domain Traffic Engineering (TE) 659 Label Switched Paths (LSPs)", RFC 5152, February 2008. 661 [PCEP] JP. Vasseur et al, "Path Computation Element (PCE) 662 Communication Protocol (PCEP) - Version 1 -", 663 draft-ietf-pce-pcep, work in progress. 665 [PCE-PATH-KEY] R. Bradford, JP Vasseur, and A. Farrel, "Preserving 666 Topology Confidentiality in Inter-Domain Path Computation 667 using a key based mechanism", draft-ietf-pce-path-key, 668 work in progress. 670 [BRPC] JP. Vasseur et al, "A Backward Recursive PCE-based 671 Computation (BRPC) procedure to compute shortest 672 inter-domain Traffic Engineering Label Switched Paths", 673 draft-ietf-pce-brpc, work in progress. 675 7.2. Informative Reference 677 [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links 678 in Resource ReSerVation Protocol - Traffic Engineering 679 (RSVP-TE)", RFC 3477, January 2003. 681 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 682 "Multiprotocol Label Switching (MPLS) Traffic Engineering 683 (TE) Management Information Base (MIB)", RFC 3812, June 684 2004. 686 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 687 Element (PCE)-Based Architecture", RFC 4655, September 688 2006. 690 [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) 691 Communication Protocol Generic Requirements", RFC 4657, 692 September 2006. 694 [RFC4874] Lee et al, "Exclude Routes - Extension to Resource 695 ReserVation Protocol-Traffic Engineering (RSVP-TE)", 696 RFC 4874, April 2007. 698 [INTER-DOMAIN-REC-ANA] T. Takeda et al., "Analysis of Inter-domain 699 Label Switched Path (LSP) Recovery", 700 draft-ietf-ccamp-inter-domain-recovery-analysis, work in 701 progress. 703 [PCEP-MIB] Koushik, A. S. K., and Stephan, E., "PCE Communication 704 Protocol(PCEP) Management Information Base", draft- 705 kkoushik-pce-pcep-mib, work in progress. 707 8. Acknowledgements 709 Authors would like to thank Fabien Verhaeghe for valuable comments 710 on subobject formats. Thanks to Magnus Westerlund, Dan Romascanu, 711 Tim Polk, and Dave Ward for comments during IESG review. 713 9. Authors' Addresses 715 Eiji Oki 716 NTT 717 3-9-11 Midori-cho, 718 Musashino-shi, Tokyo 180-8585, Japan 719 Email: oki.eiji@lab.ntt.co.jp 721 Tomonori Takeda 722 NTT 723 3-9-11 Midori-cho, 724 Musashino-shi, Tokyo 180-8585, Japan 725 Email: takeda.tomonori@lab.ntt.co.jp 727 Adrian Farrel 728 Old Dog Consulting 729 Email: adrian@olddog.co.uk 731 10. Intellectual Property Statement 733 The IETF takes no position regarding the validity or scope of any 734 Intellectual Property Rights or other rights that might be claimed 735 to pertain to the implementation or use of the technology described 736 in this document or the extent to which any license under such 737 rights might or might not be available; nor does it represent that 738 it has made any independent effort to identify any such rights. 739 Information on the procedures with respect to rights in RFC 740 documents can be found in BCP 78 and BCP 79. 742 Copies of IPR disclosures made to the IETF Secretariat and any 743 assurances of licenses to be made available, or the result of an 744 attempt made to obtain a general license or permission for the use 745 of such proprietary rights by implementers or users of this 746 specification can be obtained from the IETF on-line IPR repository 747 at http://www.ietf.org/ipr. 749 The IETF invites any interested party to bring to its attention any 750 copyrights, patents or patent applications, or other proprietary 751 rights that may cover technology that may be required to implement 752 this standard. Please address the information to the IETF at ietf- 753 ipr@ietf.org. 755 Disclaimer of Validity 757 This document and the information contained herein are provided on 758 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 759 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 760 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 761 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 762 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 763 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 764 FOR A PARTICULAR PURPOSE. 766 Copyright Statement 768 Copyright (C) The IETF Trust (2008). 770 This document is subject to the rights, licenses and restrictions 771 contained in BCP 78, and except as set forth therein, the authors 772 retain all their rights.