idnits 2.17.1 draft-ietf-pce-pcep-xro-03.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 19. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 742. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 716. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 723. ** The document seems to lack an RFC 3979 Section 5, para. 3 IPR Disclosure Invitation -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 4 instances of lines with non-ascii characters in the document. == The page length should not exceed 58 lines per page, but there was 14 longer pages, the longest (page 1) being 60 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 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.) -- The document date (February 2008) is 5905 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) ** Downref: Normative reference to an Informational draft: draft-ietf-ccamp-inter-domain-recovery-analysis (ref. 'INTER-DOMAIN-REC-ANA') Summary: 4 errors (**), 0 flaws (~~), 3 warnings (==), 6 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Oki 3 Internet Draft NTT 4 Category: Standards Track A. Farrel 5 Expires: August 2008 Old Dog Consulting 7 February 2008 9 Extensions to the Path Computation Element Communication Protocol 10 (PCEP) for Route Exclusions 12 draft-ietf-pce-pcep-xro-03.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that 23 other groups may also distribute working documents as Internet- 24 Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six 27 months and may be updated, replaced, or obsoleted by other documents 28 at any time. It is inappropriate to use Internet- Drafts as 29 reference material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 The Path Computation Element (PCE) provides functions of path 40 computation in support of traffic engineering in Multi-Protocol 41 Label Switching (MPLS) and Generalized MPLS (GMPLS) networks. 43 When a Path Computation Client (PCC) requests a PCE for a route, it 44 may be useful for the PCC to specify, as constraints to the path 45 computation, abstract nodes, resources, and Shared Risk Link Groups 46 (SRLGs) that are to be explicitly excluded from the computed route. 47 Such constraints are termed route exclusions. 49 The PCE Communication Protocol (PCEP) is designed as a communication 50 protocol between PCCs and PCEs. This document presents PCEP 51 extensions for route exclusions. 53 Conventions used in this document 55 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 56 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 57 this document are to be interpreted as described in RFC 2119 58 [RFC2119]. 60 Table of Contents 62 1. Introduction...................................................2 63 2. Protocol Procedures and Extensions.............................3 64 2.1. Exclude Route Object (XRO)..................................4 65 2.1.1. Definition................................................4 66 2.1.2. Processing Rules..........................................8 67 2.2. Explicit Route Exclusion....................................9 68 2.2.1. Definition..................................................9 69 2.2.2. Processing Rules...........................................10 70 3. Exclude Route with Confidentiality............................11 71 3.1. Exclude Route Object (XRO) Carrying Path Key...............11 72 3.1.1. Definition.................................................11 73 3.1.2. Processing Rules...........................................11 74 4. IANA Considerations...........................................12 75 4.1. PCEP Objects...............................................12 76 4.2. Explicit Exclusion Route Subobject (EXRS)..................13 77 4.3. Error Object Field Values..................................13 78 5. Manageability Considerations..................................13 79 6. Security Considerations.......................................13 80 7. References....................................................14 81 7.1. Normative Reference........................................14 82 7.2. Informative Reference......................................14 83 8. Acknowledgements..............................................15 84 9. Authors' Addresses............................................15 85 10. Intellectual Property Statement.............................15 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 93 Oki and Farrel Expires August 2008 2 94 Computation Client (PCC) may make requests to a PCE for paths to be 95 computed. 97 When a PCC requests a PCE for a route, it may be useful for the PCC 98 to specify abstract nodes, resources, and Shared Risk Link Groups 99 (SRLGs) that are to be explicitly excluded from the route. 101 For example, disjoint paths for inter-domain LSPs may be computed by 102 cooperation between PCEs, each of which computes segments of the 103 paths across one domain. In order to achieve path computation for a 104 secondary (backup) path, a PCE may act as a PCC to request another 105 PCE for a route that must be node/link/SRLG disjoint from the 106 primary (working) path. Another example is where a network operator 107 wants a path to avoid specified nodes for administrative reasons, 108 perhaps because the specified nodes will be out-of-services in the 109 near future. 111 [RFC4657] specifies generic requirements for a communication 112 protocol between PCCs and PCEs. Generic constraints described in 113 [RFC4657] include route exclusions for links, nodes, and SRLGs. That 114 is, the requirement for support of route exclusions within the PCC- 115 PCE communication protocol is already established. 117 The PCE communication protocol (PCEP) is designed as a communication 118 protocol between PCCs and PCEs and is defined in [PCEP]. This 119 document presents PCEP extensions to satisfy the requirements for 120 route exclusions as described in Sections 5.1.4 and 5.1.16 of 121 [RFC4657]. 123 Note that MPLS-TE and GMPLS signaling extensions for communicating 124 route exclusions between network nodes for specific Label Switched 125 Paths (LSPs) are described in [RFC4874]. Route exclusions may be 126 specified during provisioning requests for specific LSPs by setting 127 the mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in 128 [RFC3812] to false (2). 130 2. Protocol Procedures and Extensions 132 This section describes the procedures adopted by a PCE handling a 133 request for path computation with route exclusions received from a 134 PCC, and defines how those exclusions are encoded. 136 There are two types of route exclusion described in [RFC4874]. 138 1. Exclusion of certain abstract nodes or resources from the whole 139 path. This set of abstract nodes is referred to as the Exclude 140 Route List. 142 2. Exclusion of certain abstract nodes or resources between a 144 Oki and Farrel Expires August 2008 3 145 specific pair of abstract nodes present in an explicit path. Such 146 specific exclusions are referred to as an Explicit Route 147 Exclusion. 149 This document defines protocol extensions to allow a PCC to specify 150 both types of route exclusions to a PCE on a path computation 151 request. 153 A new PCEP object, the Exclude Route Object (XRO), is defined to 154 convey the Exclude Route List. The existing Include Route Object 155 (IRO) in PCEP [PCEP] is modified by introducing a new IRO subobject, 156 the Explicit Exclusion Route Subobject (EXRS), to convey Explicit 157 Route Exclusions. 159 2.1. Exclude Route Object (XRO) 161 2.1.1. Definition 163 The XRO is OPTIONAL and MAY be carried within PCReq and PCRep 164 messages. 166 When present in a PCReq message, the XRO provides a list of network 167 resources that the PCE is requested to exclude from the path that it 168 computes. Flags associated with each list member instruct the PCE as 169 to whether the network resources must be excluded from the computed 170 path, or whether the PCE should make best efforts to exclude the 171 resources from the computed path. 173 The XRO MAY be used on a PCRep message that carries the NO-PATH 174 object (i.e., one that reports a path computation failure) to 175 indicate the set of elements of the original XRO that prevented the 176 PCE from finding a path. 178 The XRO MAY also be used on a PCRep message for a successful path 179 computation when the PCE wishes to provide a set of exclusions to be 180 signaled during LSP setup using the extensions to RSVP-TE [RFC4874]. 182 The XRO Object-Class is to be assigned by IANA (recommended 183 value=17) 185 Oki and Farrel Expires August 2008 4 186 The XRO Object-Type is to be assigned by IANA (recommended value=1) 188 0 1 2 3 189 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 190 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 191 | Reserved | Flags |F| 192 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 193 | | 194 // (Subobjects) // 195 | | 196 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 198 Figure 1: XRO body format 200 Reserved: 16 bits MUST be set to zero on transmission and SHOULD 201 be ignored on receipt. 203 Flags: 16 bits - The following flags are currently defined: 205 F (Fail - 1 bit): when set, the requesting PCC requires the 206 computation of a new path for an existing TE LSP that has failed. 207 If the F bit is set, the path of the existing TE LSP MUST be 208 provided in the PCReq message by means of an RRO object defined in 209 [PCEP]. This allows the path computation to take into account the 210 previous path and reserved resources to avoid double bandwidth 211 booking should the TED have not yet been updated or the 212 corresponding resources not be yet been released. This will 213 usually be used in conjunction with the exclusion from the path 214 computation of the failed resource that caused the LSP to fail. 216 Subobjects. The XRO is up made of one or more subobject(s). An XRO 217 with no subobjects MUST NOT be sent and SHOULD be ignored on receipt. 219 In the following subobject definitions a set of fields have 220 consistent meaning as follows: 222 X 223 The X-bit indicates whether the exclusion is mandatory or 224 desired. 0 indicates that the resource specified MUST be 225 excluded from the path computed by the PCE. 1 indicates that 226 the 227 resource specified SHOULD be excluded from the path computed by 228 the PCE, but MAY be included subject to PCE policy and the 229 absence of a viable path that meets the other constraints and 230 excludes the resource. 232 Type 233 The type of the subobject. The following subobject types are 234 defined. 236 Oki and Farrel Expires August 2008 5 237 Type Subobject 238 -------------+------------------------------- 239 1 IPv4 prefix 240 2 IPv6 prefix 241 3 Unnumbered Interface ID 242 4 Autonomous system number 243 5 SRLG 245 Length 246 The length of the subobject including the Type and Length 247 fields. 249 Prefix Length 250 Where present, this field can be used to indicate a set of 251 addresses matching a prefix. If the subobject indicates a 252 single address, the prefix length MUST be set to the full 253 length of the address. 255 Attribute 256 The Attribute field indicates how the exclusion subobject is to 257 be interpreted. 259 0 Interface 260 The subobject is to be interpreted as an interface or set of 261 interfaces. All interfaces identified by the subobject are 262 to 263 be excluded from the computed path according to the setting 264 of the X-bit. This value is valid only for subobject types 1, 265 2, and 3. 267 1 Node 268 The subobject is to be interpreted as a node or set of nodes. 269 All nodes identified by the subobject are to be excluded 270 from 271 the computed path according to the setting of the X-bit. 272 This 273 value is valid only for subobject types 1, 2, 3, and 4. 275 2 SRLG 276 The subobject identifies an SRLG explicitly or indicates all 277 of the SRLGs associated with the resource or resources 278 identified by the subobject. Resources that share any SRLG 279 with those identified are to be excluded from the computed 280 path according to the setting of the X-bit. This value is 281 valid for all subobjects. 283 Reserved 284 Reserved fields within subobjects MUST be transmitted as zero 286 Oki and Farrel Expires August 2008 6 287 and SHOULD be ignored on receipt. 289 The subobjects are encoded as follows: 291 IPv4 prefix Subobject 293 0 1 2 3 294 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 295 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 296 |X| Type = 1 | Length | IPv4 address (4 bytes) | 297 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 298 | IPv4 address (continued) | Prefix Length | Attribute | 299 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 301 IPv6 prefix Subobject 303 0 1 2 3 304 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 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 306 |X| Type = 2 | Length | IPv6 address (16 bytes) | 307 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 | IPv6 address (continued) | 309 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 310 | IPv6 address (continued) | 311 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 312 | IPv6 address (continued) | 313 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 314 | IPv6 address (continued) | Prefix Length | Attribute | 315 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 Unnumbered Interface ID Subobject 319 0 1 2 3 320 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 321 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 322 |X| Type = 3 | Length | Reserved | Attribute | 323 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 324 | TE Router ID | 325 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 326 | Interface ID | 327 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 329 The TE Router ID and Interface ID fields are as defined in 330 [RFC3477]. 332 Oki and Farrel Expires August 2008 7 333 Autonomous System Number 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 = 4 | Length | Reserved | Attribute | 339 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 340 | Optional AS Number High Octets| 2-Octet AS Number | 341 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 343 If a two-octet AS number is used, the optional AS Number High 344 Octets MUST be set to zero. 346 SRLG Subobject 348 0 1 2 3 349 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 350 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 351 |X| Type = 5 | Length | SRLG Id (4 bytes) | 352 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 353 | SRLG Id (continued) | Reserved | Attribute | 354 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 356 The Attribute SHOULD be set to two (2) and SHOULD be ignored on 357 receipt. 359 2.1.2. Processing Rules 361 A PCC builds an XRO to encode all of the resources that it wishes 362 the PCE to exclude from the path that it is requested to compute. 363 For each exclusion, the PCC clears the X-bit to indicate that the 364 PCE is required to exclude the resources, or sets the X-bit to 365 indicate that the PCC simply desires that the resources are excluded. 366 For each exclusion, the PCC also sets the Attribute field to 367 indicate how the PCE should interpret the contents of the exclusion 368 subobject. 370 When a PCE receives a PCReq message it looks for an XRO to see if 371 exclusions are required. If the PCE finds more than one XRO it MUST 372 use the first one in the message and MUST ignore subsequent 373 instances. 375 If the PCE does not recognize the XRO it MUST return a PCErr message 376 with Error-Type "Unknown Object" as described in [PCEP]. 378 If the PCE is unwilling on unable to process the XRO it MUST return 379 a PCErr message with the Error-Type "Not supported object" and 380 follow the relevant procedures described in [PCEP]. 382 Oki and Farrel Expires August 2008 8 383 If the PCE processes the XRO and attempts to compute a path, it MUST 384 adhere to the requested exclusions as expressed in the XRO. That is, 385 the returned path MUST NOT include any resources encoded with the X- 386 bit clear, and SHOULD NOT include any with the X-bit set unless 387 alternate paths that match the other constraints expressed in the 388 PCReq are unavailable. 390 When a PCE returns a path in a PCRep it MAY also supply an XRO. An 391 XRO in a PCRep message with the NO-PATH object indicates that the 392 set of elements of the original XRO prevented the PCE from finding a 393 path. On the other hand, if an XRO is present in a PCRep message 394 without a NO-PATH object, the PCC SHOULD apply the contents using 395 the same rules as in [RFC4874] and the PCC or a corresponding LSR 396 SHOULD signal an RSVP-TE XRO to indicate the exclusions that 397 downstream LSRs should apply. This may be particularly useful in 398 per-domain path computation scenarios [PD-PATH]. 400 2.2. Explicit Route Exclusion 402 2.2.1. Definition 404 Explicit Route Exclusion defines network elements that must not or 405 should not be used on the path between two abstract nodes or 406 resources explicitly indicated in the Include Route Object (IRO) 407 [PCEP]. This information is encoded by defining a new subobject for 408 the IRO. 410 The new IRO subobject, the Explicit Exclusion Route Subobject (EXRS), 411 has type defined by IANA (see Section 3.). The EXRS contains one or 412 more subobjects in its own right. An EXRS MUST NOT be sent with no 413 subobjects, and if received with no subobjects MUST be ignored. 415 The format of the EXRS is as follows: 417 0 1 2 3 418 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 419 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 420 |L| Type | Length | Reserved | 421 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 422 | | 423 // One or more EXRS subobjects // 424 | | 425 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 427 L 428 MUST be set to zero on transmission and MUST be ignored on 429 receipt. 431 Oki and Farrel Expires August 2008 9 432 Reserved 433 MUST be set to zero on transmission and SHOULD be ignored on 434 receipt. 436 The EXRS subobject may carry any of the subobjects defined for 437 inclusion in the XRO by this document or by future documents. The 438 meanings of the fields of the XRO subobjects are unchanged when the 439 subobjects are included in an EXRS, except that scope of the 440 exclusion is limited to the single hop between the previous and 441 subsequent elements in the IRO. 443 2.2.2. Processing Rules 445 A PCC that supplies a partial explicit route to a PCE in an IRO MAY 446 also specify explicit exclusions by including one or more EXRSes in 447 the IRO. 449 If a PCE parses an IRO in a received PCReq message and encounters an 450 EXRS and does not recognize the subobject it MUST respond with a 451 PCErr message using the Error-Type "Unrecognized IRO subobject" and 452 set the Error-Value to the subobject type code of the EXRS. 454 If a PCE parses an IRO and encounters an EXRS that it recognizes, 455 but detects an EXRS subobject that it does not recognize it MUST act 456 according to the setting of the X-bit in the subobject. If the X-bit 457 is clear, the PCE MUST respond with a PCErr with Error-Type 458 "Unrecognized EXRS subobject" and set the Error-Value to the EXRS 459 subobject type code (see Section 4). If the X-bit is set, the PCE 460 MAY respond with a PCErr as already stated or MAY ignore the EXRS 461 subobject: this choice is a local policy decision. 463 If a PCE parses an IRO and encounters an EXRS subobject that it 464 recognizes, it MUST act according to the requirements expressed in 465 the subobject. That is, if the X-bit is clear, the PCE MUST NOT 466 produce a path that includes any resource identified by the EXRS 467 subobject in the path between the previous abstract node in the IRO 468 and the next abstract node in the IRO. If the X-bit is set, the PCE 469 SHOULD NOT produce a path that includes any resource identified by 470 the EXRS subobject in the path between the previous abstract node in 471 the IRO and the next abstract node in the IRO unless it is not 472 possible to construct a path that avoids that resource while still 473 complying with the other constraints expressed in the PCReq message. 475 A successful path computation reported in a PCRep message MUST 476 include an ERO to specify the path that has been computed as 477 specified in [PCEP]. That ERO MAY contain specific route exclusions 478 using the EXRS as specified in [RFC4874]. 480 Oki and Farrel Expires August 2008 10 481 If the path computation fails and a PCErr is returned with a NO-PATH 482 object, the PCE MAY include an IRO to report the hops that could not 483 be complied with as described in [PCEP], and that IRO MAY include 484 EXRSes. 486 3. Exclude Route with Confidentiality 488 3.1. Exclude Route Object (XRO) Carrying Path Key 490 3.1.1. Definition 492 In PCE-based inter-domain diverse path computation, an XRO may be 493 used to find a backup (secondary) path. A sequential path 494 computation approach may be applied for this purpose, where a 495 working (primary) path route is computed first and a backup path 496 route that must be a node/link/SRLG disjoint route from the working 497 path is then computed [INTER-DOMAIN-REC-ANA]. Backward Recursive 498 Path Computation (BRPC) may be used for inter-domain path 499 computation [BRPC]. 501 In some cases of inter-domain computation (e.g., where domains are 502 administered by different service providers), confidentiality must 503 be kept. For primary path computation, to preserve confidentiality, 504 instead of explicitly expressing the computed route, Path Key 505 Subobjects (PKSs) [PCE-PATH-KEY] are carried in the Explicit Route 506 Object (ERO) in the PCRep Message. 508 Therefore, during inter-domain diverse path computation, it may be 509 necessary to request diversity from a path that is not fully known 510 and where a segment of the path is represented by a PKS. This means 511 that a PKS may be present as a subobject of the XRO on a PCReq 512 message. 514 The format and definition of PKS when it appears as an XRO subobject 515 are as defined in [PCE-PATH-KEY], except for the definition of L bit. 516 The L bit of the PKS subobject in the XRO is defined as follows. 518 L 519 The L bit MUST be ignored. 521 3.1.2. Processing Rules 523 Consider that BRPC is applied for both working and backup path 524 computation in a sequential manner. First, PCC requests PCE for the 525 computation of a working path. After BRPC processing has completed, 526 the PCC receives the results of the working-path computation 528 Oki and Farrel Expires August 2008 11 529 expressed in an ERO in a PCRep message. The ERO may include PKSs if 530 certain segments of the path are to be kept confidential. 532 For backup path computation, when the PCC constructs a PCReq Message, 533 it includes the entire working-path in the XRO so that the computed 534 path is node/link disjoint from the working path. The XRO may also 535 include SRLGs to ensure SRLG diversity from the working path. If the 536 working path ERO includes PKS subobjects, these are also included in 537 the XRO to allow the PCE to ensure diversity. 539 A set of PCEs for backup path computation may be the same as ones 540 for working path computation, or they may be different. 542 - Identical PCEs 544 In the case where the same PCEs are used for both path 545 computations, the processing is as follows. During the process of 546 BRPC for backup path computation, a PCE may encounter a PKS as it 547 processes the XRO when it creates a virtual path tree (VPT) in its 548 own domain. The PCE retrieves the PCE-ID from the PKS, recognizes 549 itself, and converts the PKS into a set of XRO subobjects which it 550 uses for the local calculation to create the VPT. The XRO subobjects 551 created in this way MUST NOT be shared with other PCEs. Other 552 operations are the same as BRPC. 554 - Different PCEs 556 In the case where a set of PCEs for bakup path computation is 557 different from the ones used for working path computation, the 558 processing is as follows. If a PCE encounters a PKS in an XRO when 559 it is creating a virtual path tree in its own domain, the PCE 560 retrieves the PCE-ID from the PKS and sends a PCReq message to the 561 identified PCE to expand the PKS. The PCE computing the VPT treats 562 the path segment in the response as a set of XRO subobjects in 563 performing its path computation. The XRO subobjects determined in 564 this way MUST NOT be shared with other PCEs. 566 4. IANA Considerations 568 4.1. PCEP Objects 570 The "PCEP Parameters" registry contains a subregistry "PCEP Objects". 571 IANA is requested to make the following allocations from this 572 registry. 574 Object Name Object Name 575 Class Type 576 17 XRO 1 Route exclusion 578 Oki and Farrel Expires August 2008 12 580 4.2. Explicit Exclusion Route Subobject (EXRS) 582 The "PCEP Parameters" registry contains a subregistry �IRO 583 subobject�E IANA is requested to make the following allocation from 584 this registry for the Explicit Exclusion Route Subobject (EXRS). 586 Subobject Name 587 Type 33 EXRS 589 4.3. Error Object Field Values. 591 The "PCEP Parameters" registry contains a subregistry "PCEP Errors". 592 IANA is requested to make the following allocations from this 593 registry. 595 Values in this section are recommended and to be confirmed by IANA. 597 Error Meaning and Error-Values 598 Type 600 11 Unrecognized IRO subobject 601 Note that this Error-Type has been omitted from [PCEP] where it is 602 required. It is expected that it will be added to a later version of 603 [PCEP] and removed from this document. 605 12 Unrecognized EXRS subobject 607 5. Manageability Considerations 609 A MIB module for management of the PCEP is specified in a separate 610 document. This MIB module allows examination of individual PCEP 611 messages, in particular requests, responses and errors. 613 The MIB module MUST be extended to include the ability to view the 614 route exclusion extensions defined in this document. 616 Several local policy decisions should be made at the PCE. Firstly, 617 the exact behavior with regard to desired exclusions must be 618 available for examination by an operator and may be configurable. 619 Second, the behavior on receipt of an unrecognized XRO or EXRS 620 subobject with the X-bit set should be configurable and must be 621 available for inspection. The inspection and control of these local 622 policy choices may be part of the PCEP MIB module. 624 6. Security Considerations 626 The new exclude route mechanisms defined in this document allow 627 finer and more specific control of the path computed by a PCE. Such 629 Oki and Farrel Expires August 2008 13 630 control increases the risk if a PCEP message is intercepted, 631 modified, or spoofed. Therefore, the security techniques described 632 in [PCEP] are considered more important. 634 Note, however, that the roue exclusion mechanisms also provide the 635 operator with the ability to route around vulnerable parts of the 636 network and may be used to increase overall network security. 638 7. References 640 7.1. Normative Reference 642 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 643 requirements levels", RFC 2119, March 1997. 645 [PCEP] JP. Vasseur et al, "Path Computation Element (PCE) 646 communication Protocol (PCEP) - Version 1 -" draft-ietf-pce-pcep 647 (work in progress). 649 [INTER-DOMAIN-REC-ANA] T. Takeda et al., "Analysis of Inter-domain 650 Label Switched Path (LSP) Recovery" draft-ietf-ccamp-inter-domain- 651 recovery-analysis (work in progress). 653 [PCE-PATH-KEY] R. Bradford, JP Vasseur, and A. Farrel, �Preserving 654 Topology Confidentiality in Inter-Domain Path Computation using a 655 key based mechanism�E draft-ietf-pce-path-key (work in progress). 657 [BRPC] JP. Vasseur et al, "A Backward Recursive PCE-based 658 Computation (BRPC) procedure to compute shortest inter-domain 659 Traffic Engineering Label Switched Paths", draft-ietf-pce-brpc (work 660 in progress). 662 [PD-PATH] JP. Vasseur et al, " A Per-domain path computation method 663 for establishing Inter-domain Traffic Engineering (TE) Label 664 Switched Paths (LSPs)", draft-ietf-ccamp-inter-domain-pd-path-comp 665 (work in progress). 667 7.2. Informative Reference 669 [RFC3477] K. Kompella and Y. Rekhter, "Signalling Unnumbered Links 670 in Resource ReSerVation Protocol - Traffic Engineering (RSVP-TE)", 671 RFC 3477, January 2003. 673 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 674 "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) 675 Management Information Base (MIB)", RFC 3812, June 2004. 677 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 678 Element (PCE)-Based Architecture", RFC 4655, September 2006. 680 Oki and Farrel Expires August 2008 14 682 [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) 683 Communication Protocol Generic Requirements", RFC 4657, September 684 2006. 686 [RFC4874] Lee et al, "Exclude Routes - Extension to Resource 687 ReserVation Protocol-Traffic Engineering (RSVP-TE)", RFC 4874, April 688 2007. 690 8. Acknowledgements 692 Authors would like to thank Tomonori Takeda for valuable comments on 693 inter-domain path computation. 695 9. Authors' Addresses 697 Eiji Oki 698 NTT 699 3-9-11 Midori-cho, 700 Musashino-shi, Tokyo 180-8585, Japan 701 Email: oki.eiji@lab.ntt.co.jp 703 Adrian Farrel 704 Old Dog Consulting 705 Email: adrian@olddog.co.uk 707 10. Intellectual Property Statement 709 The IETF takes no position regarding the validity or scope of any 710 Intellectual Property Rights or other rights that might be claimed 711 to pertain to the implementation or use of the technology described 712 in this document or the extent to which any license under such 713 rights might or might not be available; nor does it represent that 714 it has made any independent effort to identify any such rights. 715 Information on the procedures with respect to rights in RFC 716 documents can be found in BCP 78 and BCP 79. 718 Copies of IPR disclosures made to the IETF Secretariat and any 719 assurances of licenses to be made available, or the result of an 720 attempt made to obtain a general license or permission for the use 721 of such proprietary rights by implementers or users of this 722 specification can be obtained from the IETF on-line IPR repository 723 at http://www.ietf.org/ipr. 725 The IETF invites any interested party to bring to its attention any 726 copyrights, patents or patent applications, or other proprietary 727 rights that may cover technology that may be required to implement 729 Oki and Farrel Expires August 2008 15 730 this standard. Please address the information to the IETF at ietf- 731 ipr@ietf.org. 733 Disclaimer of Validity 735 This document and the information contained herein are provided on 736 an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 737 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 738 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 739 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 740 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 741 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 742 FOR A PARTICULAR PURPOSE. 744 Copyright Statement 746 Copyright (C) The IETF Trust (2008). 748 This document is subject to the rights, licenses and restrictions 749 contained in BCP 78, and except as set forth therein, the authors 750 retain all their rights. 752 Oki and Farrel Expires August 2008 16