idnits 2.17.1 draft-oki-pce-pcep-xro-00.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 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 587. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- == There is 1 instance of lines with non-ascii characters in the document. 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 == Line 163 has weird spacing: '...evented the...' == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: Subobjects. The XRO is up made of one or more subobject(s). An XRO with no subobjects MUST not be sent and SHOULD be ignored on receipt. -- 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 (January 2007) is 6309 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFC3477' is mentioned on line 293, but not defined Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group E. Oki 2 Internet Draft NTT 3 Category: Standards Track A. Farrel 4 Expires: June 2007 Old Dog Consulting 6 January 2007 8 Extensions to the Path Computation Element Communication Protocol 9 (PCEP) for Route Exclusions 11 draft-oki-pce-pcep-xro-00.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 26 months and may be updated, replaced, or obsoleted by other documents 27 at any time. It is inappropriate to use Internet-Drafts as 28 reference 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 routes. Such 46 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 Extensions to PCEP for Route Exclusions January 2007 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in 58 this document are to be interpreted as described in RFC 2119 59 [RFC2119]. 61 Table of Contents 63 1. Introduction...................................................2 64 2. Protocol Procedures and Extensions.............................3 65 2.1. Exclude Route Object (XRO)..................................4 66 2.2.1. Processing Rules..........................................7 67 2.2. Explicit Route Exclusion....................................8 68 2.2.1. Processing Rules...........................................9 69 3. IANA Considerations...........................................10 70 3.1. PCEP Objects...............................................10 71 3.2. Error Object Field Values..................................10 72 4. Manageability considerations..................................10 73 5. Security Considerations.......................................11 74 6. References....................................................11 75 6.1. Normative Reference........................................11 76 6.2. Informative Reference......................................11 77 7. Authors�EAddresses............................................11 79 1. Introduction 81 The Path Computation Element (PCE) defined in [RFC4655] is an entity 82 that is capable of computing a network path or route based on a 83 network graph, and applying computational constraints. A Path 84 Computation Client (PCC) may make requests to a PCE for paths to be 85 computed. 87 When a PCC requests a PCE for a route, it may be useful for the PCC 88 to specify abstract nodes, resources, and Shared Risk Link Groups 89 (SRLGs) that are to be explicitly excluded from the route. 91 For example, disjoint paths for inter-domain LSPs may be computed by 92 cooperation between PCEs, each of which computes segments of the 93 paths across one domain. In order to achieve path computation for a 94 secondary (backup) path, a PCE may act as a PCC to request another 95 PCE for a route that must be a node/link/SRLG disjoint from the 96 primary (working) path. Another example is where a network operator 97 wants path to avoid specified nodes for administrative reasons 98 perhaps because the specified nodes will be out-of-services in near 99 future. 101 Extensions to PCEP for Route Exclusions January 2007 103 [RFC4657] specifies generic requirements for a communication 104 protocol between PCCs and PCEs. Generic constraints described in 105 [RFC4657] include route exclusions for links, nodes, and SRLGs. That 106 is, the requirement for support of route exclusions within the PCC- 107 PCE communication protocol is already established. 109 The PCE communication protocol (PCEP) is designed as a communication 110 protocol between PCCs and PCEs and is defined in [PCEP]. This 111 document presents PCEP extensions to satisfy the requirements for 112 route exclusions as described in Sections 5.1.4 and 5.1.16 of 113 [RFC4657]. 115 Note that MPLS-TE and GMPLS signaling extensions for communicating 116 route exclusions between network nodes for specific Label Switched 117 Paths (LSPs) are described in [XRO]. Route exclusions may be 118 specified during provisioning requests for specific LSPs using the 119 mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in [RFC3812]. 121 2. Protocol Procedures and Extensions 123 This section describes the procedures adopted by a PCE handling a 124 request for path computation with route exclusions received from a 125 PCC, and defines how those exclusions are encoded. 127 There are two types of route exclusion described in [XRO]. 129 1. Exclusion of certain abstract nodes or resources on the whole 130 path. This set of abstract nodes is referred to as the Exclude 131 Route List. 133 2. Exclusion of certain abstract nodes or resources between a 134 specific pair of abstract nodes present in an explicit path. Such 135 specific exclusions are referred to as an Explicit Route 136 Exclusion. 138 This document defines protocol extensions to allow a PCC to specify 139 both types of route exclusions to a PCE on a path computation 140 request. 142 A new PCEP object is defined as the Exclude Route Object (XRO) to 143 convey the Exclude Route List. The existing Include Route Object 144 (IRO) in PCEP [PCEP] is modified by introducing a new IRO subobject, 145 the Explicit Exclusion Route Subobject (EXRS), to convey Explicit 146 Route Exclusions. 148 Extensions to PCEP for Route Exclusions January 2007 150 2.1. Exclude Route Object (XRO) 152 The XRO is OPTIONAL and MAY be carried within PCReq and PCRep 153 messages. 155 When present in a PCReq message, the XRO provides a list of network 156 resources that the PCE is requested to exclude from the path that it 157 computes. Flags associated with each list member instruct the PCE as 158 to whether the network resources must be excluded from the computed 159 path or whether the PCE should make best efforts to exclude the 160 resources from the computed path. 162 The XRO MAY be used on PCRep message with the NO-PATH object to 163 indicate the set of elements of the original XRO that prevented the 164 PCE from finding a path. The XRO MAY also be used on a PCRep message 165 for a successful path computation when the PCE wishes to provide a 166 set of exclusions to be signaled during LSP setup. 168 XRO Object-Class is to be assigned by IANA (recommended value=17) 170 XRO Object-Type is to be assigned by IANA (recommended value=1) 172 0 1 2 3 173 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 174 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 175 | | 176 // (Subobjects) // 177 | | 178 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 180 Figure 1: XRO body format 182 Subobjects. The XRO is up made of one or more subobject(s). An XRO 183 with no subobjects MUST not be sent and SHOULD be ignored on receipt. 185 In the following subobject definitions a set of fields have 186 consistent meaning as follows: 188 X 189 The X-bit indicates whether the exclusion is mandatory or 190 desired. 0 indicates that the resource specified MUST be 191 excluded from the path computed by the PCE 1 indicates that the 192 resource specified SHOULD be excluded from the path computed by 193 the PCE, but MAY be included subject to PCE policy and the 194 absence of a viable path that meets the other other constraints 195 and excludes the resource. 197 Extensions to PCEP for Route Exclusions January 2007 199 Type 200 The type of the subobject. The following subobject types are 201 defined. 203 Type Subobject 204 -------------+------------------------------- 205 1 IPv4 prefix 206 2 IPv6 prefix 207 3 Unnumbered Interface ID 208 4 Autonomous system number 209 5 SRLG 211 Length 212 The length of the subobject including the Type and Length 213 fields. 215 Prefix Length 216 Where present, this field can be used to indicate a set of 217 addresses matching a prefix. If the subobject indicates a 218 single address, the prefix length MUST be set to the full 219 length of the address. 221 Attribute 222 The Attribute field indicates how the exclusion subobject is to 223 be interpreted. 225 0 Interface 226 The subobject is to be interpreted as an interface or set of 227 interfaces. All interfaces identified by the subobject are to 228 be excluded from the computed path according to the setting 229 of the X-bit. This value is valid only for subobject types 1, 230 2, and 3. 232 1 Node 233 The subobject is to be interpreted as a node or set of nodes. 234 All nodes identified by the subobject are to be excluded from 235 the computed path according to the setting of the X-bit. This 236 value is valid only for subobject types 1, 2, 3, and 4. 238 2 SRLG 239 The subobject identifies an SRLG explicitly or indicates all 240 of the SRLGs associated with the resource or resources 241 identified by the subobject. Resources that share any SRLG 242 with those identified are to be excluded from the computed 243 path according to the setting of the X-bit. This value is 244 valid for all subobjects. 246 Reserved 247 Reserved fields MUST be transmitted as zero and SHOULD be 248 ignored on receipt. 250 Extensions to PCEP for Route Exclusions January 2007 252 The subobjects are encoded as follows: 254 IPv4 prefix Subobject 256 0 1 2 3 257 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 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 259 |X| Type = 1 | Length | IPv4 address (4 bytes) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | IPv4 address (continued) | Prefix Length | Attribute | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 IPv6 prefix Subobject 266 0 1 2 3 267 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 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 269 |X| Type = 2 | Length | IPv6 address (16 bytes) | 270 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 271 | IPv6 address (continued) | 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | IPv6 address (continued) | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | IPv6 address (continued) | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | IPv6 address (continued) | Prefix Length | Attribute | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 280 Unnumbered Interface ID Subobject 282 0 1 2 3 283 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 284 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 285 |X| Type = 3 | Length | Reserved | Attribute | 286 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 287 | TE Router ID | 288 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 289 | Interface ID | 290 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 The TE Router ID and Interface ID fields are as defined in 293 [RFC3477]. 295 Extensions to PCEP for Route Exclusions January 2007 297 Autonomous System Number Subobject 299 0 1 2 3 300 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 301 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 302 |X| Type = 4 | Length | Reserved | Attribute | 303 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 304 | Optional AS Number High Octets| 2-Octet AS Number | 305 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 307 If a two-octet AS number is used, the optional AS Number High 308 Octets MUST be set to zero. 310 SRLG Subobject 312 0 1 2 3 313 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 314 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 315 |X| Type = 5 | Length | SRLG Id (4 bytes) | 316 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 317 | SRLG Id (continued) | Reserved | Attribute | 318 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 320 The Attribute SHOULD be set to two (2) and SHOULD be ignored on 321 receipt. 323 2.2.1. Processing Rules 325 A PCC builds an XRO to encode all of the resources that it wishes 326 the PCE to exclude from the path that it is requested to compute. 327 For each exclusion, the PCC clears the X-bit to indicate that the 328 PCE is required to exclude the resources, or sets the X-bit to 329 indicate that the PCC simply desires that the resources are excluded. 330 For each exclusion, the PCC also sets the Attribute field to 331 indicate how the PCE should interpret the contents of the exclusion 332 subobject. 334 When a PCE receives a PCReq message it looks for an XRO to see if 335 exclusions are required. If the PCE finds more than one XRO it MUST 336 use the first one in the message and MUST ignore subsequent 337 instances. 339 If the PCE does not recognize the XRO it MUST return a PCErr message 340 with Error-Type "Unknown Object" as described in [PCEP]. 342 If the PCE is unwilling on unable to process the XRO it MUST return 343 a PCErr message with the Error-Type "Not supported object" and 344 follow the relevant procedures described in [PCEP]. 346 Extensions to PCEP for Route Exclusions January 2007 348 If the PCE processes the XRO and attempts to compute a path, it MUST 349 adhere to the requested exclusions as expressed in the XRO. That is, 350 the returned path MUST NOT include any resources encoded with the X- 351 bit clear, and SHOULD NOT include any with the X-bit set unless 352 alternate paths that match the other constraints expressed in the 353 PCReq are unavailable. 355 When a PCE returns a path in a PCRep it MAY also supply an XRO. In 356 this case, the PCC SHOULD apply the contents using the same rules as 357 in [XRO] and SHOULD signal the an RSVP-TE XRO to indicate the 358 exclusions that downstream LSRs should apply. This may be 359 particularly useful in per-domain path computation scenarios. [Note 360 that this does not match the behavior for an explicit path where an 361 IRO is used to force inclusions and an ERO is used to report a 362 computed path. We could consider using a separate object to report 363 the XRO that should be signaled.] 365 In the event that no suitable path can be computed and the PCE 366 returns a PCRep message containing a NO-PATH object, the PCE MAY 367 also include an XRO that lists one or more subobjects from the 368 original XRO that have contributed to the PCE's inability to select 369 a path. 371 2.2. Explicit Route Exclusion 373 Explicit Route Exclusion defines network elements that must not or 374 should not be used on the path between two abstract nodes or 375 resources explicitly indicated in the Include Route Object (IRO) 376 [PCEP]. This information is encoded by defining a new subobject for 377 the IRO . 379 The new IRO subobject, the Explicit Exclusion Route Subobject (EXRS), 380 has type defined by IANA (see Section 3.). The EXRS contains one or 381 more subobjects in its own right. An EXRS MUST NOT be sent with no 382 subobjects, and if received with no subobjects MUST be ignored. 384 The format of the EXRS is as follows: 386 0 1 2 3 387 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 388 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 389 |L| Type | Length | Reserved | 390 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 391 | | 392 // One or more EXRS subobjects // 393 | | 394 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 396 Extensions to PCEP for Route Exclusions January 2007 398 L 399 MUST be set to zero on transmission and MUST be ignored on 400 receipt. 402 Reserved 403 MUST be set to zero on transmission and MUST be ignored on 404 receipt. 406 The EXRS subobject may carry any of the subobjects defined for 407 inclusion in the XRO by this document or by future documents. The 408 meanings of the fields of the XRO subobjects are unchanged when the 409 subobjects are included in an EXRS, except that scope of the 410 exclusion is limited to the single hop between the previous and 411 subsequent elements in the IRO. 413 2.2.1. Processing Rules 415 A PCC that supplies a partial explicit route to a PCE in an IRO MAY 416 also specify explicit exclusions by including one or more EXRSes in 417 the IRO. 419 If a PCE parses an IRO in a received PCReq message and encounters an 420 EXRS and does not recognize the subobject it MUST respond with a 421 PCErr message using the Error-Type "Unrecognized IRO subobject" and 422 set the Error-Value to the subobject type code of the EXRS (see 423 Section 3). 425 If a PCE parses an IRO and encounters an EXRS that it recognizes, 426 but detects an EXRS subobject that it does not recognize it MUST act 427 according to the setting of the X-bit in the subobject. If the X-bit 428 is clear, the PCE MUST respond with a PCErr with Error-Type 429 "Unrecognized EXRS subobject" and set the Error-Value to the EXRS 430 subobject type code (see Section 3). If the X-bit is set, the PCE 431 MAY respond with a PCErr as already stated or MAY ignore the EXRS 432 subobject: this choice is a local policy decision. 434 If a PCE parses an IRO and encounters an EXRS subobject that it 435 recognizes, it MUST act according to the requirements expressed in 436 the subobject. That is, if the X-bit is clear, the PCE MUST NOT 437 produce a path that includes any resource identified by the EXRS 438 subobject in the path between the previous abstract node in the IRO 439 and the next abstract node in the IRO. If the X-bit is set, the PCE 440 SHOULD NOT produce a path that includes any resource identified by 441 the EXRS subobject in the path between the previous abstract node in 442 the IRO and the next abstract node in the IRO unless it is not 443 possible to construct a path that avoids that resource while still 444 complying with the other constraints expressed in the PCReq message. 446 A successful path computation reported in a PCRep message MUST 447 include an ERO to specify the path that has been computed. That ERO 449 Extensions to PCEP for Route Exclusions January 2007 451 MAY contain specific route exclusions using the EXRS as specified in 452 [XRO]. 454 If the path computation fails and a PCErr is returned with a NO-PATH 455 object, the PCE MAY include an IRO to report the hops that could not 456 be complied with, and that IRO MAY include EXRSes. 458 3. IANA Considerations 460 3.1. PCEP Objects 462 The "PCEP Parameters" registry contains a subregistry "PCEP Objects". 463 IANA is requested to make the following allocations from this 464 registry. 466 Object Name Object Name 467 Class Type 468 17 XRO 1 Route exclusion 470 3.2. Error Object Field Values. 472 The "PCEP Parameters" registry contains a subregistry "PCEP Errors". 473 IANA is requested to make the following allocations from this 474 registry. 476 Values in this section are recommended and to be confirmed by IANA. 478 Error Meaning and Error-Values 479 Type 481 11 Unrecognized IRO subobject 483 Note that this Error-Type has been omitted from [PCEP] where it is 484 required. It is expected that it will be added to a later version of 485 [PCEP] and removed from this document. 487 12 Unrecognized EXRS subobject 489 4. Manageability Considerations 491 A MIB module for management of the PCEP is specified in a separate 492 document. This MIB module allows examination of individual PCEP 493 messages, in particular requests, responses and errors. 495 The MIB module MUST be extended to include the ability to view the 496 route exclusion extensions defined in this document. 498 Extensions to PCEP for Route Exclusions January 2007 500 5. Security Considerations 502 The new exclude route mechanisms defined in this document allow 503 finer and more specific control of the path computed by a PCE. Such 504 control increases the risk if a PCEP message is intercepted, 505 modified, or spoofed. Therefore, the security techniques described 506 in [PCEP] are considered more important. 508 6. References 510 6.1. Normative Reference 512 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 513 requirements levels", RFC 2119, March 1997. 515 [PCEP] JP. Vasseur et al, "Path Computation Element (PCE) 516 communication Protocol (PCEP) - Version 1" draft-ietf-pce-pcep, 517 (work in progress). 519 6.2. Informative Reference 521 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 522 "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) 523 Management Information Base (MIB)", RFC 3812, June 2004. 525 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 526 Element (PCE)-Based Architecture", RFC 4655, September 2006. 528 [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) 529 Communication Protocol Generic Requirements", RFC 4657, September 530 2006. 532 [XRO] Lee et al, "Exclude Routes - Extension to RSVP-TE", draft- 533 ietf-ccamp-rsvp-te-exclude-route, (work in progress). 535 7. Authors' Addresses 537 Eiji Oki 538 NTT 539 3-9-11 Midori-cho, 540 Musashino-shi, Tokyo 180-8585, Japan 541 Email: oki.eiji@lab.ntt.co.jp 543 Adrian Farrel 544 Old Dog Consulting 545 Email: adrian@olddog.co.uk 547 Extensions to PCEP for Route Exclusions January 2007 549 Full Copyright Statement 551 Copyright (C) The IETF Trust (2007). 553 This document is subject to the rights, licenses and restrictions 554 contained in BCP 78, and except as set forth therein, the authors 555 retain all their rights. 557 This document and the information contained herein are provided on an 558 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 559 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 560 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 561 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 562 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 563 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 565 Intellectual Property 567 The IETF takes no position regarding the validity or scope of any 568 Intellectual Property Rights or other rights that might be claimed to 569 pertain to the implementation or use of the technology described in 570 this document or the extent to which any license under such rights 571 might or might not be available; nor does it represent that it has 572 made any independent effort to identify any such rights. Information 573 on the procedures with respect to rights in RFC documents can be 574 found in BCP 78 and BCP 79. 576 Copies of IPR disclosures made to the IETF Secretariat and any 577 assurances of licenses to be made available, or the result of an 578 attempt made to obtain a general license or permission for the use of 579 such proprietary rights by implementers or users of this 580 specification can be obtained from the IETF on-line IPR repository at 581 http://www.ietf.org/ipr. 583 The IETF invites any interested party to bring to its attention any 584 copyrights, patents or patent applications, or other proprietary 585 rights that may cover technology that may be required to implement 586 this standard. Please address the information to the IETF at 587 ietf-ipr@ietf.org.