idnits 2.17.1 draft-ietf-pce-brpc-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 20. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 623. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 634. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 641. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 647. 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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. 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 (January 15, 2007) is 6310 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'I-D.ietf-ccamp-inter-domain-rsvp-te' is defined on line 551, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-05 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-inter-domain-pd-path-comp-03 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-04 Summary: 2 errors (**), 0 flaws (~~), 5 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Networking Working Group JP. Vasseur, Ed. 2 Internet-Draft Cisco Systems, Inc 3 Intended status: Informational R. Zhang 4 Expires: July 19, 2007 BT Infonet 5 N. Bitar 6 Verizon 7 JL. Le Roux 8 France Telecom 9 January 15, 2007 11 A Backward Recursive PCE-based Computation (BRPC) procedure to compute 12 shortest inter-domain Traffic Engineering Label Switched Paths 13 draft-ietf-pce-brpc-03.txt 15 Status of this Memo 17 By submitting this Internet-Draft, each author represents that any 18 applicable patent or other IPR claims of which he or she is aware 19 have been or will be disclosed, and any of which he or she becomes 20 aware will be disclosed, in accordance with Section 6 of BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on July 19, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 The ability to compute constrained shortest Traffic Engineering (TE) 47 Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) 48 and Generalized MPLS (GMPLS) networks across multiple domains (where 49 a domain is referred to as a collection of network elements within a 50 common sphere of address management or path computational 51 responsibility such as IGP areas and Autonomous Systems) has been 52 identified as a key requirement . This document specifies a 53 procedure relying on the use of multiple Path Computation Elements 54 (PCEs) in order to compute such inter-domain shortest constraint 55 paths along a determined sequence of domains, using a backward 56 recursive path computation technique while preserving confidentiality 57 across domains, which is sometimes required when domains are managed 58 by different Service Providers. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [RFC2119]. 66 Table of Contents 68 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 71 4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Domain path selection . . . . . . . . . . . . . . . . . . 6 73 4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 6 74 5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 8 75 6. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Usage in conjunction with per-domain path computation . . . . 9 77 8. BRPC procedure completion failure . . . . . . . . . . . . . . 9 78 9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 79 9.1. Diverse end-to-end path computation . . . . . . . . . . . 10 80 9.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 10 81 10. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 11 82 11. Path Computation failure . . . . . . . . . . . . . . . . . . . 11 83 12. Metric normalization . . . . . . . . . . . . . . . . . . . . . 11 84 13. Manageability Considerations . . . . . . . . . . . . . . . . . 12 85 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 14.1. New flag of the RP object . . . . . . . . . . . . . . . . 12 87 14.2. New flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 12 88 15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 89 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 90 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 13 91 17.1. Normative References . . . . . . . . . . . . . . . . . . . 13 92 17.2. Informative References . . . . . . . . . . . . . . . . . . 13 93 Appendix A. Proposed Status and Discussion [To Be Removed 94 Upon Publication] . . . . . . . . . . . . . . . . . . 14 95 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 96 Intellectual Property and Copyright Statements . . . . . . . . . . 16 98 1. Terminology 100 ABR: routers used to connect two IGP areas (areas in OSPF or levels 101 in IS-IS). 103 ASBR: routers used to connect together ASs of a different or the same 104 Service Provider via one or more Inter-AS links. 106 Boundary Node (BN): a boundary node is either an ABR in the context 107 of inter- area TE or an ASBR in the context of inter-AS TE. 109 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n). 111 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1). 113 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 115 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 117 LSR: Label Switching Router. 119 LSP: Label Switched Path. 121 PCE (Path Computation Element): an entity (component, application or 122 network node) that is capable of computing a network path or route 123 based on a network graph and applying computational constraints. 125 PCE(i) is a PCE with the scope of domain(i). 127 TED: Traffic Engineering Database. 129 VSPT: Virtual Shortest Path Tree. 131 The notion of contiguous, stitched and nested TE LSPs is defined in 132 [I-D.ietf-ccamp-inter-domain-framework] and will not be repeated 133 here. 135 2. Introduction 137 The requirements for inter-area and inter-AS MPLS Traffic Engineering 138 have been developed by the Traffic Engineering Working Group (TE WG) 139 and have been stated in [RFC4105] and [RFC4216], respectively. 141 The framework for inter-domain MPLS Traffic Engineering has been 142 provided in [I-D.ietf-ccamp-inter-domain-framework]. 144 [I-D.ietf-ccamp-inter-domain-pd-path-comp] defines a technique for 145 establishing inter-domain (G)MPLS TE LSP whereby the path is computed 146 during the signalling process on a per-domain basis by the entry 147 boundary node of each domain (each node in charge of computing a 148 section of an inter-domain TE LSP path is always along the path of 149 such TE LSP). Such path computation technique fulfills some of the 150 requirements stated in [RFC4105] and [RFC4216] but not all of them. 151 In particular, it cannot guarantee to find an optimal (shortest) 152 inter-domain constrained path. Furthermore, it cannot be efficiently 153 used to compute a set of inter-domain diversely routed TE LSPs. 155 The aim of this document is to describe a PCE-based TE LSP 156 computation procedure to compute optimal inter-domain constrained 157 (G)MPLS TE LSPs. 159 Qualifying a path as optimal requires some clarification. Indeed, a 160 globally optimal TE LSP placement usually refers to a set of TE LSPs 161 whose placements optimize the network resources with regards to a 162 specified objective function (e.g. a placement that reduces the 163 maximum or average network load while satisfying the TE LSP 164 constraints). In this document, an optimal inter-domain constrained 165 TE LSP is defined as the shortest path satisfying the set of required 166 constraints that would be obtained in the absence of multiple domains 167 (in other words, in a totally flat IGP network between the source and 168 destination of the TE LSP). 170 3. General assumptions 172 In the rest of this document, we make the following set of 173 assumptions common to inter-area and inter-AS MPLS TE: 175 - Each IGP area or AS is assumed to be Traffic Engineering enabled 176 (i.e. running OSPF-TE or ISIS-TE and RSVP-TE). 178 - No topology or resource information is distributed between domains 179 (as mandated per [RFC4105] and [RFC4216]), which is critical to 180 preserve IGP/BGP scalability and confidentiality. 182 - While certain constraints like bandwidth can be used across 183 different domains, other TE constraints like resource affinity, 184 color, metric, etc. as listed in [RFC2702] could be translated at 185 domain boundaries. If required, it is assumed that, at the domain 186 boundary nodes, there will exist some sort of local mapping based on 187 policy agreement, in order to translate such constraints across 188 domain boundaries during the inter-PCE communication process. 190 - The various ASBRs are BGP peers, without any IGP running on the 191 inter-ASBR links. 193 - Each AS can be made of several IGP areas. The path computation 194 procedure described in this document applies to the case of a single 195 AS made of multiple IGP areas, multiples ASs made of a single IGP 196 area or any combination of the above. For the sake of simplicity, 197 each AS will be considered to be comprised of a single area in this 198 document. The case of an Inter-AS TE LSP spanning multiple ASs where 199 some of those ASs are themselves made of multiple IGP areas can be 200 easily derived from this case by applying the BRPC procedure 201 described in this document, recursively. 203 - The domain path (set of domains traversed to reach the destination 204 domain) is either administratively pre-determined or discovered by 205 some means (outside of the scope of this document). 207 4. BRPC Procedure 209 The BRPC procedure is a Multiple-PCE path computation technique as 210 described in [RFC4655]. A possible model consists of hosting the PCE 211 function on boundary nodes (e.g., ABR or ASBR) but this is not 212 mandated by the BRPC procedure. 214 The BRPC procedure does not make any assumptions with regards to the 215 nature of the inter-domain TE LSP that could be contiguous, nested or 216 stitched. 218 Furthermore, no assumption is made on the actual path computation 219 algorithm in use by a PCE (it can be any variant of CSPF, algorithm 220 based on linear-programming to solve multi-constraints optimization 221 problems and so on). 223 4.1. Domain path selection 225 The PCE-based BRPC procedure applies to the computation of an optimal 226 constrained inter-domain TE LSP. The sequence of domains to be 227 traversed can either be determined a priori or during the path 228 computation procedure. The BRPC procedure guarantees to compute the 229 optimal path across a specific set of traversed domains (which 230 constitutes an additional constraint). In the case of an arbitrary 231 set of meshed domains, the BRPC procedure can be used to compute the 232 optimal path across each domain set in order to get to optimal 233 constrained path between the source and the destination of the TE 234 LSP. 236 4.2. Mode of Operation 238 Definition of VSPT(i) 239 In each domain i: 241 * There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN- 242 en(k,i) is the kth entry BN of domain(i). 244 * There is a set of X-ex(i) exit BN noted BN-ex(k,i) where BN-ex(k,i) 245 is the kth exit BN of domain(i). 247 VSPT(i): MP2P (MultiPoint To Point) tree returned by PCE(i) to 248 PCE(i-1): 250 Root (TE LSP destination) 251 / I \ 252 BN-en(1,i) BN-en(2,i) ... BN-en((j), i). 254 Where j<= [X-en(i)] 256 Each link of tree VSPT(i) represents the shortest path between BN- 257 en(j,i) (identified by its TE Router-ID) and the destination that 258 satisfies the set of required constraints for the TE LSP (bandwidth, 259 affinities, ...). These are path segments to reach the destination 260 from BN-en(j,i). 262 Note that PCE(i) only considers the entry BNs that provide 263 connectivity from domain(i-1). That is, the set BN-en(k,i-1) is only 264 made of those BNs that provide connectivity from domain (i-1) to 265 domain(i). Furthermore, some BNs may be excluded according to policy 266 constraints (either due to local policy or policies signaled in the 267 path computation request). 269 Step 1: the PCC needs to first determine the PCE capable of serving 270 its path computation request. The path computation request is then 271 relayed until reaching a PCE(n) such that the TE LSP destination 272 resides in the domain(n). At each step of the process, the next PCE 273 can either be statically configured or dynamically discovered via 274 IGP/BGP extensions. If no next PCE can be found or the next hop PCE 275 of choice is unavailable, the procedure stops and a path computation 276 error is returned (see section Section 8). If multiple PCEs are 277 discovered, the PCE may select a subset of these PCEs based on some 278 local policies or heuristics. Note also that a sequence of PCEs 279 might be enforced by policy on the PCC and this constraint can be 280 either carried in the PCEP path computation request (defined in 281 [I-D.ietf-pce-pcep]. 283 Step 2: PCE(n) computes VSPT(n) made of the list of shortest 284 constrained path(s) between every BN-en(j,n) and the TE LSP 285 destination using a suitable path computation algorithm (e.g. CSPF) 286 and returns the computed VSPT(n) to PCE(n-1). 288 Step i: 290 - For i=n-1 to 2: PCE(i) concatenates the topology of domain (i) 291 (using its TED) with the received VSPT(i+1). In the case of Inter-AS 292 TE LSP computation, this requires to also add the inter-AS TE links 293 connecting the domain (i) to the domain (i+1). Then PCE(i) computes 294 VSPT(i) (P2MP tree made of the shortest constrained paths between 295 each BN-en(j,i) and the TE LSP destination). 297 End 299 Finally PCE(1) computes the end-to-end shortest constrained path from 300 the source to the destination and returns the corresponding path to 301 the requesting PCC. 303 Each branch of the VSPT tree (path) may be returned in the form of an 304 explicit path (in which case all the hops along the path segment are 305 listed) or a loose path (in which case only the BR is specified) so 306 as to preserve confidentiality along with the respective cost. In 307 the later case, various techniques can used in order to retrieve the 308 computed explicit paths on a per domain basis during the signaling 309 process thanks to the use of path keys as described in 310 [I-D.bradford-pce-path-key]. 312 BRPC guarantees to find the optimal (shortest) constrained inter- 313 domain TE LSP according to a set of defined domains to be traversed. 314 Note that other variants of the BRPC procedure relying on the same 315 principles are also possible. 317 Note also that in case of ECMP paths, more than one path could be 318 returned to the requesting LSR. 320 5. PCEP Protocol Extensions 322 The BRPC procedure requires the specification of a new flag of the RP 323 object carried within the PCReq message (defined in 324 [I-D.ietf-pce-pcep]), the aim of which is to specify that the 325 shortest path(s) satisfying the constraints from the destination to 326 the set of entry boundary nodes are requested (such set of path(s) 327 forms the downstream VSPT as specified in Section 4.2). 329 The following new flag of the RP object is defined: VSPT (V) flag: 330 0x60. When set, this indicates that the PCC requests the computation 331 of an inter-domain TE LSP using the BRPC procedure. 333 Because path segment(s) computed by a downstream PCE in the context 334 of the BRPC procedure must be provided along with their respective 335 path cost(s), the C flag of the METRIC object carried within the 336 PCReq message MUST be set. It is the choice of the requester to 337 appropriately set the O bit of the RP object. 339 6. Inter-AS TE Links 341 In the case of Inter-AS TE LSP path computation, the BRPC procedure 342 requires the knowledge of the traffic engineering attributes of the 343 Inter-AS TE links: the process by which the PCE acquires this 344 information is out of the scope of the BRPC procedure (which is 345 compliant with the PCE architecture defined in [RFC4655]). 347 That said, a straitghforward solution consists of allowing the ASBRs 348 to flood the TE information related to the inter-ASBR link(s) 349 although no IGP TE is enabled over those links (there is no IGP 350 adjacency over the inter-ASBR links). This allows the PCE of a 351 domain to get entire TE visibility up to the set of entry ASBRs in 352 the downstream domain. 354 7. Usage in conjunction with per-domain path computation 356 The BRPC procedure may be used to compute path segments and could be 357 used in conjunction with other path computation techniques (such as 358 the per-domain path computation technique defined in 359 [I-D.ietf-ccamp-inter-domain-pd-path-comp]) to compute the end-to-end 360 path. In this case end-to-end path optimality can no longer be 361 guaranteed. 363 8. BRPC procedure completion failure 365 If the BRPC procedure cannot be completed because a PCE along the 366 domain path does not support the procedure, a PCErr message is 367 returned to the upstream PCE with a Error-Type "BRPC procedure 368 completion failure". The PCErr message MUST be relayed to the 369 requesting PCC. 371 PCEP-ERROR objects are used to report a PCEP protocol error and are 372 characterized by an Error-Type which specifies the type of error and 373 an Error-value that provides additional information about the error 374 type. Both the Error-Type and the Error-Value are managed by IANA. 375 A new Error-Type is defined that relates to the BRPC procedure. 377 Error-type Meaning 378 13 BRPC procedure completion failure 379 Error-value 380 1: BRPC procedure not supported by one or more PCEs 381 along the domain path 383 9. Applicability 385 As discussed in section 3, the requirements for inter-area and 386 inter-AS MPLS Traffic Engineering have been developed by the Traffic 387 Engineering Working Group (TE WG) and have been stated in [RFC4105] 388 and [RFC4216], respectively. Among the set of requirements, both 389 documents indicate the need for some solution providing the ability 390 to compute an optimal (shortest) constrained inter-domain TE LSP and 391 to compute a set of diverse inter-domain TE LSPs. 393 9.1. Diverse end-to-end path computation 395 PCEP allows a PCC to request the computation of a set of diverse TE 396 LSPs thanks to the SVEC object by setting the flags L, N or S to 397 request link, node or SRLG diversity respectively. Such request MUST 398 be taken into account by each PCE along the path computation chain 399 during the VSPT computation. In the context of the BRPC procedure, a 400 set of diversely routed TE LSP between two LSRs can be computed since 401 the paths segment(s) of the VSPT are simultaneously computed by a 402 given PCE. The BRPC path procedure allows for the computation of 403 diverse paths under various objective functions (such as minimizing 404 the sum of the costs of the N diverse paths, etc) thus avoiding the 405 well-known "trapping" problem. Indeed, with a 2-step approach 406 consisting of computing the first path followed by the computation of 407 the second path after having removed the set of network elements 408 traversed by the first path (if that does not violate confidentiality 409 preservation), one cannot guarantee that a solution will be found 410 even if such solution exists. Furthermore, even if a solution is 411 found, it may not be the most optimal one with respect to objective 412 function such as minimizing the sum of the paths costs, bounding the 413 path delays of both paths and so on. Finally, it must be noted that 414 such a 2-step path computation approach is usually less efficient in 415 term of signalling delays since it requires two serialized TE LSP set 416 up. 418 9.2. Path optimality 420 BRPC guarantees that the optimal (shortest) constrained inter-domain 421 path will always be found subject to policy constraints. When 422 combined with other local path computation techniques (e.g. in the 423 case of stitched/nested TE LSP) and in the case where a domain has 424 more than one BR-en or more than one BR-ex, optimality after some 425 network change within the domain can only be guaranteed by re- 426 executing the BRPC procedure. 428 10. Reoptimization of an inter-domain TE LSP 430 The ability to reoptimize an existing inter-domain TE LSP path has 431 been explicitly listed as a requirement in [RFC4105] and [RFC4216]. 432 In the case of a TE LSP reoptimization request, regular procedures 433 apply as defined in PCEP where the path in use (if available on the 434 head-end) is provided within the path computation request in order 435 for the PCEs involved in the reoptimization request to avoid double 436 bandwidth accounting. 438 11. Path Computation failure 440 If a PCE requires to relay a path computation request acccording to 441 the BRPC procedure defined in this document to a downstream PCE that 442 no such PCE is available, the PCE MUST send a negative path 443 computation reply to the requester using a PCReq message as specified 444 in [I-D.ietf-pce-pcep]that contains a NO-PATH object. In such case, 445 the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (also defined in 446 [I-D.ietf-pce-pcep]) with the newly defined bit named "BRPC Path 447 Computation chain unvailable" set. 449 0x04: BRPC Path computation chain unavailable 451 12. Metric normalization 453 In the case of inter-area TE, the same IGP/TE metric scheme is 454 usually adopted for all the IGP areas (e.g. based on the link-speed, 455 propagation delay or some other combination of link attributes). 456 Hence, the proposed set of mechanisms always computes the shortest 457 path across multiple areas obeying the required set of constraints 458 with respect to a well-specified objective function. Conversely, in 459 the case of Inter-AS TE, in order for this path computation to be 460 meaningful, a metric normalization between ASs may be required. One 461 solution to avoid IGP metric modification would be for the SPs to 462 agree on a TE metric normalization scheme and use the TE metric for 463 TE LSP path computation (in that case, this must be requested in the 464 PCEP Path computation request) thanks to the COST object. 466 13. Manageability Considerations 468 To be added in a further revision of this document. 470 14. IANA Considerations 472 14.1. New flag of the RP object 474 A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) is 475 defined in this document. 477 Name: VSPT (V) 479 Bit Number: 10 481 Value: 0x60 483 When set, this indicates that the PCC requests the computation of an 484 inter-domain TE LSP using the BRPC procedure. 486 A new Error-Type is defined in this document (Error-Type and Error- 487 value to be assigned by IANA). 489 Error-type Meaning 490 13 BRPC procedure completion failure 491 Error-value 492 1: BRPC procedure not supported by one or PCEs 493 along the domain path 495 14.2. New flag of the NO-PATH-VECTOR TLV 497 A new flag of the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep]) 498 is specified in this document. 500 Defining RFC: draft-ietf-pce-pcep (to be replaced by RFC number when pusblished) 501 Name of bit: BRPC Path computation chain unavailable 502 Bit number (suggested value): 0x04 504 15. Security Considerations 506 The BRPC procedure does not introduce any additional security issues 507 beyond the ones related to inter-PCE communication. 509 16. Acknowledgements 511 The authors would like to thank Arthi Ayyangar, Dimitri Papadimitriou 512 and Siva Sivabalan for their useful comments. A special thank to 513 Adrian Farrel for his useful comments and suggestions. 515 17. References 517 17.1. Normative References 519 [I-D.ietf-pce-pcep] 520 Roux, J. and J. Vasseur, "Path Computation Element (PCE) 521 communication Protocol (PCEP) - Version 1", 522 draft-ietf-pce-pcep-05 (work in progress), January 2007. 524 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 525 Requirement Levels", BCP 14, RFC 2119, March 1997. 527 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 528 Element (PCE)-Based Architecture", RFC 4655, August 2006. 530 17.2. Informative References 532 [I-D.bradford-pce-path-key] 533 Bradford, R., "Preserving Topology Confidentiality in 534 Inter-Domain Path Computation using a key based 535 mechanism", draft-bradford-pce-path-key-02 (work in 536 progress), January 2007. 538 [I-D.ietf-ccamp-inter-domain-framework] 539 Farrel, A., "A Framework for Inter-Domain Multiprotocol 540 Label Switching Traffic Engineering", 541 draft-ietf-ccamp-inter-domain-framework-06 (work in 542 progress), August 2006. 544 [I-D.ietf-ccamp-inter-domain-pd-path-comp] 545 Vasseur, J., "A Per-domain path computation method for 546 establishing Inter-domain Traffic Engineering (TE) Label 547 Switched Paths (LSPs)", 548 draft-ietf-ccamp-inter-domain-pd-path-comp-03 (work in 549 progress), August 2006. 551 [I-D.ietf-ccamp-inter-domain-rsvp-te] 552 Ayyangar, A. and J. Vasseur, "Inter domain MPLS and GMPLS 553 Traffic Engineering - RSVP-TE extensions", 554 draft-ietf-ccamp-inter-domain-rsvp-te-04 (work in 555 progress), January 2007. 557 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 558 McManus, "Requirements for Traffic Engineering Over MPLS", 559 RFC 2702, September 1999. 561 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 562 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 564 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 565 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 566 November 2005. 568 Appendix A. Proposed Status and Discussion [To Be Removed Upon 569 Publication] 571 This Internet-Draft is being submitted for eventual publication as an 572 RFC with a proposed status of Informational. Discussion of this 573 proposal should take place on the following mailing list: 574 pce@ietf.org. 576 Authors' Addresses 578 JP Vasseur (editor) 579 Cisco Systems, Inc 580 1414 Massachusetts Avenue 581 Boxborough, MA 01719 582 USA 584 Email: jpv@cisco.com 586 Raymond Zhang 587 BT Infonet 588 2160 E. Grand Ave. 589 El Segundo, CA 90025 590 USA 592 Email: raymond_zhang@bt.infonet.com 593 Nabil Bitar 594 Verizon 595 40 Sylvan Road 596 Waltham, MA 02145 597 USA 599 Email: nabil.bitar@verizon.com 601 JL Le Roux 602 France Telecom 603 2, Avenue Pierre-Marzin 604 Lannion, 22307 605 FRANCE 607 Email: jeanlouis.leroux@orange-ft.com 609 Full Copyright Statement 611 Copyright (C) The IETF Trust (2007). 613 This document is subject to the rights, licenses and restrictions 614 contained in BCP 78, and except as set forth therein, the authors 615 retain all their rights. 617 This document and the information contained herein are provided on an 618 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 619 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 620 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 621 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 622 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 623 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 625 Intellectual Property 627 The IETF takes no position regarding the validity or scope of any 628 Intellectual Property Rights or other rights that might be claimed to 629 pertain to the implementation or use of the technology described in 630 this document or the extent to which any license under such rights 631 might or might not be available; nor does it represent that it has 632 made any independent effort to identify any such rights. Information 633 on the procedures with respect to rights in RFC documents can be 634 found in BCP 78 and BCP 79. 636 Copies of IPR disclosures made to the IETF Secretariat and any 637 assurances of licenses to be made available, or the result of an 638 attempt made to obtain a general license or permission for the use of 639 such proprietary rights by implementers or users of this 640 specification can be obtained from the IETF on-line IPR repository at 641 http://www.ietf.org/ipr. 643 The IETF invites any interested party to bring to its attention any 644 copyrights, patents or patent applications, or other proprietary 645 rights that may cover technology that may be required to implement 646 this standard. Please address the information to the IETF at 647 ietf-ipr@ietf.org. 649 Acknowledgment 651 Funding for the RFC Editor function is provided by the IETF 652 Administrative Support Activity (IASA).