idnits 2.17.1 draft-ietf-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 539. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 550. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 557. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 563. 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 == Line 157 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 (April 2007) is 6218 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 283, but not defined Summary: 1 error (**), 0 flaws (~~), 4 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: October 2007 Old Dog Consulting 6 April 2007 8 Extensions to the Path Computation Element Communication Protocol 9 (PCEP) for Route Exclusions 11 draft-ietf-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 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...................................................2 62 2. Protocol Procedures and Extensions.............................3 63 2.1. Exclude Route Object (XRO)..................................4 64 2.2.1. Processing Rules..........................................7 65 2.2. Explicit Route Exclusion....................................8 66 2.2.1. Processing Rules...........................................9 67 3. IANA Considerations...........................................10 68 3.1. PCEP Objects...............................................10 69 3.2. Error Object Field Values..................................10 70 4. Manageability considerations..................................10 71 5. Security Considerations.......................................11 72 6. References....................................................11 73 6.1. Normative Reference........................................11 74 6.2. Informative Reference......................................11 75 7. Authors?EAddresses............................................11 77 1. Introduction 79 The Path Computation Element (PCE) defined in [RFC4655] is an entity 80 that is capable of computing a network path or route based on a 81 network graph, and applying computational constraints. A Path 82 Computation Client (PCC) may make requests to a PCE for paths to be 83 computed. 85 When a PCC requests a PCE for a route, it may be useful for the PCC 86 to specify abstract nodes, resources, and Shared Risk Link Groups 87 (SRLGs) that are to be explicitly excluded from the route. 89 For example, disjoint paths for inter-domain LSPs may be computed by 90 cooperation between PCEs, each of which computes segments of the 91 paths across one domain. In order to achieve path computation for a 92 secondary (backup) path, a PCE may act as a PCC to request another 93 PCE for a route that must be a node/link/SRLG disjoint from the 94 primary (working) path. Another example is where a network operator 95 wants path to avoid specified nodes for administrative reasons 96 perhaps because the specified nodes will be out-of-services in near 97 future. 99 [RFC4657] specifies generic requirements for a communication 100 protocol between PCCs and PCEs. Generic constraints described in 101 [RFC4657] include route exclusions for links, nodes, and SRLGs. That 102 is, the requirement for support of route exclusions within the PCC- 103 PCE communication protocol is already established. 105 The PCE communication protocol (PCEP) is designed as a communication 106 protocol between PCCs and PCEs and is defined in [PCEP]. This 107 document presents PCEP extensions to satisfy the requirements for 108 route exclusions as described in Sections 5.1.4 and 5.1.16 of 109 [RFC4657]. 111 Note that MPLS-TE and GMPLS signaling extensions for communicating 112 route exclusions between network nodes for specific Label Switched 113 Paths (LSPs) are described in [XRO]. Route exclusions may be 114 specified during provisioning requests for specific LSPs using the 115 mplsTunnelHopInclude object of MPLS-TE-STD-MIB defined in [RFC3812]. 117 2. Protocol Procedures and Extensions 119 This section describes the procedures adopted by a PCE handling a 120 request for path computation with route exclusions received from a 121 PCC, and defines how those exclusions are encoded. 123 There are two types of route exclusion described in [XRO]. 125 1. Exclusion of certain abstract nodes or resources on the whole 126 path. This set of abstract nodes is referred to as the Exclude 127 Route List. 129 2. Exclusion of certain abstract nodes or resources between a 130 specific pair of abstract nodes present in an explicit path. Such 131 specific exclusions are referred to as an Explicit Route 132 Exclusion. 134 This document defines protocol extensions to allow a PCC to specify 135 both types of route exclusions to a PCE on a path computation 136 request. 138 A new PCEP object is defined as the Exclude Route Object (XRO) to 139 convey the Exclude Route List. The existing Include Route Object 140 (IRO) in PCEP [PCEP] is modified by introducing a new IRO subobject, 141 the Explicit Exclusion Route Subobject (EXRS), to convey Explicit 142 Route Exclusions. 144 2.1. Exclude Route Object (XRO) 146 The XRO is OPTIONAL and MAY be carried within PCReq and PCRep 147 messages. 149 When present in a PCReq message, the XRO provides a list of network 150 resources that the PCE is requested to exclude from the path that it 151 computes. Flags associated with each list member instruct the PCE as 152 to whether the network resources must be excluded from the computed 153 path or whether the PCE should make best efforts to exclude the 154 resources from the computed path. 156 The XRO MAY be used on PCRep message with the NO-PATH object to 157 indicate the set of elements of the original XRO that prevented the 158 PCE from finding a path. The XRO MAY also be used on a PCRep message 159 for a successful path computation when the PCE wishes to provide a 160 set of exclusions to be signaled during LSP setup. 162 XRO Object-Class is to be assigned by IANA (recommended value=17) 164 XRO Object-Type is to be assigned by IANA (recommended value=1) 166 0 1 2 3 167 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 168 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 169 | | 170 // (Subobjects) // 171 | | 172 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 174 Figure 1: XRO body format 176 Subobjects. The XRO is up made of one or more subobject(s). An XRO 177 with no subobjects MUST not be sent and SHOULD be ignored on receipt. 179 In the following subobject definitions a set of fields have 180 consistent meaning as follows: 182 X 183 The X-bit indicates whether the exclusion is mandatory or 184 desired. 0 indicates that the resource specified MUST be 185 excluded from the path computed by the PCE 1 indicates that the 186 resource specified SHOULD be excluded from the path computed by 187 the PCE, but MAY be included subject to PCE policy and the 188 absence of a viable path that meets the other other constraints 189 and excludes the resource. 191 Type 192 The type of the subobject. The following subobject types are 193 defined. 195 Type Subobject 196 -------------+------------------------------- 197 1 IPv4 prefix 198 2 IPv6 prefix 199 3 Unnumbered Interface ID 200 4 Autonomous system number 201 5 SRLG 203 Length 204 The length of the subobject including the Type and Length 205 fields. 207 Prefix Length 208 Where present, this field can be used to indicate a set of 209 addresses matching a prefix. If the subobject indicates a 210 single address, the prefix length MUST be set to the full 211 length of the address. 213 Attribute 214 The Attribute field indicates how the exclusion subobject is to 215 be interpreted. 217 0 Interface 218 The subobject is to be interpreted as an interface or set of 219 interfaces. All interfaces identified by the subobject are to 220 be excluded from the computed path according to the setting 221 of the X-bit. This value is valid only for subobject types 1, 222 2, and 3. 224 1 Node 225 The subobject is to be interpreted as a node or set of nodes. 226 All nodes identified by the subobject are to be excluded from 227 the computed path according to the setting of the X-bit. This 228 value is valid only for subobject types 1, 2, 3, and 4. 230 2 SRLG 231 The subobject identifies an SRLG explicitly or indicates all 232 of the SRLGs associated with the resource or resources 233 identified by the subobject. Resources that share any SRLG 234 with those identified are to be excluded from the computed 235 path according to the setting of the X-bit. This value is 236 valid for all subobjects. 238 Reserved 239 Reserved fields MUST be transmitted as zero and SHOULD be 240 ignored on receipt. 242 The subobjects are encoded as follows: 244 IPv4 prefix Subobject 246 0 1 2 3 247 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 248 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 249 |X| Type = 1 | Length | IPv4 address (4 bytes) | 250 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 251 | IPv4 address (continued) | Prefix Length | Attribute | 252 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 254 IPv6 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 = 2 | Length | IPv6 address (16 bytes) | 260 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 261 | IPv6 address (continued) | 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 263 | IPv6 address (continued) | 264 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 265 | IPv6 address (continued) | 266 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 267 | IPv6 address (continued) | Prefix Length | Attribute | 268 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 270 Unnumbered Interface ID Subobject 272 0 1 2 3 273 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 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 |X| Type = 3 | Length | Reserved | Attribute | 276 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 277 | TE Router ID | 278 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 279 | Interface ID | 280 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 282 The TE Router ID and Interface ID fields are as defined in 283 [RFC3477]. 285 Autonomous System Number Subobject 287 0 1 2 3 288 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 289 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 290 |X| Type = 4 | Length | Reserved | Attribute | 291 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 292 | Optional AS Number High Octets| 2-Octet AS Number | 293 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 295 If a two-octet AS number is used, the optional AS Number High 296 Octets MUST be set to zero. 298 SRLG Subobject 300 0 1 2 3 301 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 302 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 303 |X| Type = 5 | Length | SRLG Id (4 bytes) | 304 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 305 | SRLG Id (continued) | Reserved | Attribute | 306 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 308 The Attribute SHOULD be set to two (2) and SHOULD be ignored on 309 receipt. 311 2.2.1. Processing Rules 313 A PCC builds an XRO to encode all of the resources that it wishes 314 the PCE to exclude from the path that it is requested to compute. 315 For each exclusion, the PCC clears the X-bit to indicate that the 316 PCE is required to exclude the resources, or sets the X-bit to 317 indicate that the PCC simply desires that the resources are excluded. 318 For each exclusion, the PCC also sets the Attribute field to 319 indicate how the PCE should interpret the contents of the exclusion 320 subobject. 322 When a PCE receives a PCReq message it looks for an XRO to see if 323 exclusions are required. If the PCE finds more than one XRO it MUST 324 use the first one in the message and MUST ignore subsequent 325 instances. 327 If the PCE does not recognize the XRO it MUST return a PCErr message 328 with Error-Type "Unknown Object" as described in [PCEP]. 330 If the PCE is unwilling on unable to process the XRO it MUST return 331 a PCErr message with the Error-Type "Not supported object" and 332 follow the relevant procedures described in [PCEP]. 334 If the PCE processes the XRO and attempts to compute a path, it MUST 335 adhere to the requested exclusions as expressed in the XRO. That is, 336 the returned path MUST NOT include any resources encoded with the X- 337 bit clear, and SHOULD NOT include any with the X-bit set unless 338 alternate paths that match the other constraints expressed in the 339 PCReq are unavailable. 341 When a PCE returns a path in a PCRep it MAY also supply an XRO. In 342 this case, the PCC SHOULD apply the contents using the same rules as 343 in [XRO] and SHOULD signal the an RSVP-TE XRO to indicate the 344 exclusions that downstream LSRs should apply. This may be 345 particularly useful in per-domain path computation scenarios. [Note 346 that this does not match the behavior for an explicit path where an 347 IRO is used to force inclusions and an ERO is used to report a 348 computed path. We could consider using a separate object to report 349 the XRO that should be signaled.] 351 In the event that no suitable path can be computed and the PCE 352 returns a PCRep message containing a NO-PATH object, the PCE MAY 353 also include an XRO that lists one or more subobjects from the 354 original XRO that have contributed to the PCE's inability to select 355 a path. 357 2.2. Explicit Route Exclusion 359 Explicit Route Exclusion defines network elements that must not or 360 should not be used on the path between two abstract nodes or 361 resources explicitly indicated in the Include Route Object (IRO) 362 [PCEP]. This information is encoded by defining a new subobject for 363 the IRO . 365 The new IRO subobject, the Explicit Exclusion Route Subobject (EXRS), 366 has type defined by IANA (see Section 3.). The EXRS contains one or 367 more subobjects in its own right. An EXRS MUST NOT be sent with no 368 subobjects, and if received with no subobjects MUST be ignored. 370 The format of the EXRS is as follows: 372 0 1 2 3 373 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 374 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 375 |L| Type | Length | Reserved | 376 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 377 | | 378 // One or more EXRS subobjects // 379 | | 380 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 381 L 382 MUST be set to zero on transmission and MUST be ignored on 383 receipt. 385 Reserved 386 MUST be set to zero on transmission and MUST be ignored on 387 receipt. 389 The EXRS subobject may carry any of the subobjects defined for 390 inclusion in the XRO by this document or by future documents. The 391 meanings of the fields of the XRO subobjects are unchanged when the 392 subobjects are included in an EXRS, except that scope of the 393 exclusion is limited to the single hop between the previous and 394 subsequent elements in the IRO. 396 2.2.1. Processing Rules 398 A PCC that supplies a partial explicit route to a PCE in an IRO MAY 399 also specify explicit exclusions by including one or more EXRSes in 400 the IRO. 402 If a PCE parses an IRO in a received PCReq message and encounters an 403 EXRS and does not recognize the subobject it MUST respond with a 404 PCErr message using the Error-Type "Unrecognized IRO subobject" and 405 set the Error-Value to the subobject type code of the EXRS (see 406 Section 3). 408 If a PCE parses an IRO and encounters an EXRS that it recognizes, 409 but detects an EXRS subobject that it does not recognize it MUST act 410 according to the setting of the X-bit in the subobject. If the X-bit 411 is clear, the PCE MUST respond with a PCErr with Error-Type 412 "Unrecognized EXRS subobject" and set the Error-Value to the EXRS 413 subobject type code (see Section 3). If the X-bit is set, the PCE 414 MAY respond with a PCErr as already stated or MAY ignore the EXRS 415 subobject: this choice is a local policy decision. 417 If a PCE parses an IRO and encounters an EXRS subobject that it 418 recognizes, it MUST act according to the requirements expressed in 419 the subobject. That is, if the X-bit is clear, the PCE MUST NOT 420 produce a path that includes any resource identified by the EXRS 421 subobject in the path between the previous abstract node in the IRO 422 and the next abstract node in the IRO. If the X-bit is set, the PCE 423 SHOULD NOT produce a path that includes any resource identified by 424 the EXRS subobject in the path between the previous abstract node in 425 the IRO and the next abstract node in the IRO unless it is not 426 possible to construct a path that avoids that resource while still 427 complying with the other constraints expressed in the PCReq message. 429 A successful path computation reported in a PCRep message MUST 430 include an ERO to specify the path that has been computed. That ERO 431 MAY contain specific route exclusions using the EXRS as specified in 432 [XRO]. 434 If the path computation fails and a PCErr is returned with a NO-PATH 435 object, the PCE MAY include an IRO to report the hops that could not 436 be complied with, and that IRO MAY include EXRSes. 438 3. IANA Considerations 440 3.1. PCEP Objects 442 The "PCEP Parameters" registry contains a subregistry "PCEP Objects". 443 IANA is requested to make the following allocations from this 444 registry. 446 Object Name Object Name 447 Class Type 448 17 XRO 1 Route exclusion 450 3.2. Error Object Field Values. 452 The "PCEP Parameters" registry contains a subregistry "PCEP Errors". 453 IANA is requested to make the following allocations from this 454 registry. 456 Values in this section are recommended and to be confirmed by IANA. 458 Error Meaning and Error-Values 459 Type 461 11 Unrecognized IRO subobject 463 Note that this Error-Type has been omitted from [PCEP] where it is 464 required. It is expected that it will be added to a later version of 465 [PCEP] and removed from this document. 467 12 Unrecognized EXRS subobject 469 4. Manageability Considerations 471 A MIB module for management of the PCEP is specified in a separate 472 document. This MIB module allows examination of individual PCEP 473 messages, in particular requests, responses and errors. 475 The MIB module MUST be extended to include the ability to view the 476 route exclusion extensions defined in this document. 478 5. Security Considerations 480 The new exclude route mechanisms defined in this document allow 481 finer and more specific control of the path computed by a PCE. Such 482 control increases the risk if a PCEP message is intercepted, 483 modified, or spoofed. Therefore, the security techniques described 484 in [PCEP] are considered more important. 486 6. References 488 6.1. Normative Reference 490 [RFC2119] Bradner, S., "Key words for use in RFCs to indicate 491 requirements levels", RFC 2119, March 1997. 493 [PCEP] JP. Vasseur et al, "Path Computation Element (PCE) 494 communication Protocol (PCEP) - Version 1" draft-ietf-pce-pcep, 495 (work in progress). 497 6.2. Informative Reference 499 [RFC3812] Srinivasan, C., Viswanathan, A., and T. Nadeau, 500 "Multiprotocol Label Switching (MPLS) Traffic Engineering (TE) 501 Management Information Base (MIB)", RFC 3812, June 2004. 503 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "A Path Computation 504 Element (PCE)-Based Architecture", RFC 4655, September 2006. 506 [RFC4657] J. Ash and J.L. Le Roux, "Path Computation Element (PCE) 507 Communication Protocol Generic Requirements", RFC 4657, September 508 2006. 510 [XRO] Lee et al, "Exclude Routes - Extension to RSVP-TE", draft- 511 ietf-ccamp-rsvp-te-exclude-route, (work in progress). 513 7. Authors' Addresses 515 Eiji Oki 516 NTT 517 3-9-11 Midori-cho, 518 Musashino-shi, Tokyo 180-8585, Japan 519 Email: oki.eiji@lab.ntt.co.jp 521 Adrian Farrel 522 Old Dog Consulting 523 Email: adrian@olddog.co.uk 525 Full Copyright Statement 527 Copyright (C) The IETF Trust (2007). 529 This document is subject to the rights, licenses and restrictions 530 contained in BCP 78, and except as set forth therein, the authors 531 retain all their rights. 533 This document and the information contained herein are provided on an 534 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 535 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 536 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 537 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 538 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 539 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 541 Intellectual Property 543 The IETF takes no position regarding the validity or scope of any 544 Intellectual Property Rights or other rights that might be claimed to 545 pertain to the implementation or use of the technology described in 546 this document or the extent to which any license under such rights 547 might or might not be available; nor does it represent that it has 548 made any independent effort to identify any such rights. Information 549 on the procedures with respect to rights in RFC documents can be 550 found in BCP 78 and BCP 79. 552 Copies of IPR disclosures made to the IETF Secretariat and any 553 assurances of licenses to be made available, or the result of an 554 attempt made to obtain a general license or permission for the use of 555 such proprietary rights by implementers or users of this 556 specification can be obtained from the IETF on-line IPR repository at 557 http://www.ietf.org/ipr. 559 The IETF invites any interested party to bring to its attention any 560 copyrights, patents or patent applications, or other proprietary 561 rights that may cover technology that may be required to implement 562 this standard. Please address the information to the IETF at 563 ietf-ipr@ietf.org.