idnits 2.17.1 draft-vasseur-pce-brpc-02.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 on line 617. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 628. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 635. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 641. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. 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 is 1 instance of too long lines in the document, the longest one being 5 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (August 29, 2006) is 6447 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 539, but no explicit reference was found in the text == Unused Reference: 'I-D.ietf-pce-disco-proto-igp' is defined on line 545, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-02 == Outdated reference: A later version (-02) exists of draft-bradford-pce-path-key-00 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-inter-domain-framework-05 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-inter-domain-pd-path-comp-02 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-03 Summary: 4 errors (**), 0 flaws (~~), 8 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: March 2, 2007 BT Infonet 5 N. Bitar 6 Verizon 7 JL. Le Roux 8 France Telecom 9 August 29, 2006 11 A Backward Recursive PCE-based Computation (BRPC) procedure to compute 12 shortest inter-domain Traffic Engineering Label Switched Paths 13 draft-vasseur-pce-brpc-02.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 March 2, 2007. 40 Copyright Notice 42 Copyright (C) The Internet Society (2006). 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. History . . . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 4. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 72 5. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 73 5.1. Domain path selection . . . . . . . . . . . . . . . . . . 6 74 5.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 7 75 6. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 9 76 7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 9 77 8. Usage in conjunction with per-domain path computation . . . . 9 78 9. BRPC procedure completion failure . . . . . . . . . . . . . . 10 79 10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 80 10.1. Diverse end-to-end path computation . . . . . . . . . . . 10 81 10.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 11 82 11. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 11 83 12. Metric normalization . . . . . . . . . . . . . . . . . . . . . 11 84 13. Manageability Considerations . . . . . . . . . . . . . . . . . 12 85 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 86 15. Security Considerations . . . . . . . . . . . . . . . . . . . 12 87 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 88 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 89 17.1. Normative References . . . . . . . . . . . . . . . . . . . 12 90 17.2. Informative References . . . . . . . . . . . . . . . . . . 13 91 17.3. Informative References . . . . . . . . . . . . . . . . . . 13 92 Appendix A. Proposed Status and Discussion [To Be Removed 93 Upon Publication] . . . . . . . . . . . . . . . . . . 14 94 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 14 95 Intellectual Property and Copyright Statements . . . . . . . . . . 16 97 1. History 99 The aim of this document is to specify a Backward Recursive PCE-based 100 Computation (BRPC) procedure to compute shortest constrained inter- 101 domain (G)MPLS TE LSP. Such procedure had been initially documented 102 in draft-vasseur-ccamp-inter-domain-path-comp (Scenario 2) and is now 103 moved to a separated document in the light of the progress made by 104 the PCE Working Group. 106 2. Terminology 108 ABR: routers used to connect two IGP areas (areas in OSPF or levels 109 in IS-IS). 111 ASBR: routers used to connect together ASs of a different or the same 112 Service Provider via one or more Inter-AS links. 114 Boundary Node (BN): a boundary node is either an ABR in the context 115 of inter- area TE or an ASBR in the context of inter-AS TE. 117 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n). 119 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1). 121 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 123 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 125 LSR: Label Switching Router. 127 LSP: Label Switched Path. 129 PCE (Path Computation Element): an entity (component, application or 130 network node) that is capable of computing a network path or route 131 based on a network graph and applying computational constraints. 133 PCE(i) is a PCE with the scope of domain(i). 135 TED: Traffic Engineering Database. 137 VSPT: Virtual Shortest Path Tree. 139 The notion of contiguous, stitched and nested TE LSPs is defined in 140 [I-D.ietf-ccamp-inter-domain-framework] and will not be repeated 141 here. 143 3. Introduction 145 The requirements for inter-area and inter-AS MPLS Traffic Engineering 146 have been developed by the Traffic Engineering Working Group (TE WG) 147 and have been stated in [RFC4105] and [RFC4216], respectively. 149 The framework for inter-domain MPLS Traffic Engineering has been 150 provided in [I-D.ietf-ccamp-inter-domain-framework]. 152 [I-D.ietf-ccamp-inter-domain-pd-path-comp] defines a technique for 153 establishing inter-domain (G)MPLS TE LSP whereby the path is computed 154 during the signalling process on a per-domain basis by the entry 155 boundary node of each domain (each node in charge of computing a 156 section of an inter-domain TE LSP path is always along the path of 157 such TE LSP). Such path computation technique fulfills some of the 158 requirements stated in [RFC4105] and [RFC4216] but not all of them. 159 In particular, it cannot guarantee to find an optimal (shortest) 160 inter-domain constrained path. Furthermore, it cannot be efficiently 161 used to compute a set of inter-domain diversely routed TE LSPs. 163 The aim of this document is to describe a PCE-based TE LSP 164 computation procedure to compute optimal inter-domain constrained 165 (G)MPLS TE LSPs. 167 Qualifying a path as optimal requires some clarification. Indeed, a 168 globally optimal TE LSP placement usually refers to a set of TE LSPs 169 whose placements optimize the network resources with regards to a 170 specified objective function (e.g. a placement that reduces the 171 maximum or average network load while satisfying the TE LSP 172 constraints). In this document, an optimal inter-domain constrained 173 TE LSP is defined as the shortest path satisfying the set of required 174 constraints that would be obtained in the absence of multiple domains 175 (in other words, in a totally flat IGP network between the source and 176 destination of the TE LSP). 178 4. General assumptions 180 In the rest of this document, we make the following set of 181 assumptions common to inter-area and inter-AS MPLS TE: 183 - Each IGP area or AS is assumed to be Traffic Engineering enabled 184 (i.e. running OSPF-TE or ISIS-TE and RSVP-TE). 186 - No topology or resource information is distributed between domains 187 (as mandated per [RFC4105] and [RFC4216]), which is critical to 188 preserve IGP/BGP scalability and confidentiality. 190 - While certain constraints like bandwidth can be used across 191 different domains, other TE constraints like resource affinity, 192 color, metric, etc. as listed in [RFC2702] could be translated at 193 domain boundaries. If required, it is assumed that, at the domain 194 boundary nodes, there will exist some sort of local mapping based on 195 policy agreement, in order to translate such constraints across 196 domain boundaries during the inter-PCE communication process. 198 - The various ASBRs are BGP peers, without any IGP running on the 199 inter-ASBR links. 201 - Each AS can be made of several IGP areas. The path computation 202 procedure described in this document applies to the case of a single 203 AS made of multiple IGP areas, multiples ASs made of a single IGP 204 area or any combination of the above. For the sake of simplicity, 205 each AS will be considered to be comprised of a single area in this 206 document. The case of an Inter-AS TE LSP spanning multiple ASs where 207 some of those ASs are themselves made of multiple IGP areas can be 208 easily derived from this case by applying the BRPC procedure 209 described in this document, recursively. 211 - The domain path (set of domains traversed to reach the destination 212 domain) is either administratively pre-determined or discovered by 213 some means (outside of the scope of this document). 215 5. BRPC Procedure 217 The BRPC procedure is a Multiple-PCE path computation technique as 218 described in [I-D.ietf-pce-architecture]. A possible model consists 219 of hosting the PCE function on boundary nodes (e.g., ABR or ASBR) but 220 this is not mandated by the BRPC procedure. 222 The BRPC procedure does not make any assumptions with regards to the 223 nature of the inter-domain TE LSP that could be contiguous, nested or 224 stitched. 226 Furthermore, no assumption is made on the actual path computation 227 algorithm in use by a PCE (it can be any variant of CSPF, algorithm 228 based on linear-programming to solve multi-constraints optimization 229 problems and so on). 231 5.1. Domain path selection 233 The PCE-based BRPC procedure applies to the computation of an optimal 234 constrained inter-domain TE LSP. The sequence of domains to be 235 traversed can either be determined a priori or during the path 236 computation procedure. The BRPC procedure guarantees to compute the 237 optimal path across a specific set of traversed domains (which 238 constitutes an additional constraint). In the case of an arbitrary 239 set of meshed domains, the BRPC procedure can be used to compute the 240 optimal path across each domain set in order to get to optimal 241 constrained path between the source and the destination of the TE 242 LSP. 244 5.2. Mode of Operation 246 Definition of VSPT(i) 248 In each domain i: 250 * There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN- 251 en(k,i) is the kth entry BN of domain(i). 253 * There is a set of X-ex(i) exit BN noted BN-ex(k,i) where BN-ex(k,i) 254 is the kth exit BN of domain(i). 256 VSPT(i): MP2P (MultiPoint To Point) tree returned by PCE(i) to 257 PCE(i-1): 259 Root (TE LSP destination) 260 / I \ 261 BN-en(1,i) BN-en(2,i) ... BN-en((j), i). 263 Where j<= [X-en(i)] 265 Each link of tree VSPT(i) represents the shortest path between BN- 266 en(j,i) (identified by its TE Router-ID) and the destination that 267 satisfies the set of required constraints for the TE LSP (bandwidth, 268 affinities, ...). These are path segments to reach the destination 269 from BN-en(j,i). 271 Note that PCE(i) only considers the entry BNs that provide 272 connectivity from domain(i-1). That is, the set BN-en(k,i-1) is only 273 made of those BNs that provide connectivity from domain (i-1) to 274 domain(i). Furthermore, some BNs may be excluded according to policy 275 constraints (either due to local policy or policies signaled in the 276 path computation request). 278 Step 1: the PCC needs to first determine the PCE capable of serving 279 its path computation request. The path computation request is then 280 relayed until reaching a PCE(n) such that the TE LSP destination 281 resides in the domain(n). At each step of the process, the next PCE 282 can either be statically configured or dynamically discovered via 283 IGP/BGP extensions. If no next PCE can be found or the next hop PCE 284 of choice is unavailable, the procedure stops and a path computation 285 error is returned (see section Section 9). If multiple PCEs are 286 discovered, the PCE may select a subset of these PCEs based on some 287 local policies or heuristics. Note also that a sequence of PCEs 288 might be enforced by policy on the PCC and this constraint can be 289 either carried in the PCEP path computation request (defined in 290 [I-D.ietf-pce-pcep]. 292 Step 2: PCE(n) computes VSPT(n) made of the list of shortest 293 constrained path(s) between every BN-en(j,n) and the TE LSP 294 destination using a suitable path computation algorithm (e.g. CSPF) 295 and returns the computed VSPT(n) to PCE(n-1). 297 Step i: 299 - For i=n-1 to 2: PCE(i) concatenates the topology of domain (i) 300 (using its TED) with the received VSPT(i+1). In the case of Inter-AS 301 TE LSP computation, this requires to also add the inter-AS TE links 302 connecting the domain (i) to the domain (i+1). Then PCE(i) computes 303 VSPT(i) (P2MP tree made of the shortest constrained paths between 304 each BN-en(j,i) and the TE LSP destination). 306 End 308 Finally PCE(1) computes the end-to-end shortest constrained path from 309 the source to the destination and returns the corresponding path to 310 the requesting PCC. 312 Each branch of the VSPT tree (path) may be returned in the form of an 313 explicit path (in which case all the hops along the path segment are 314 listed) or a loose path (in which case only the BR is specified) so 315 as to preserve confidentiality along with the respective cost. In 316 the later case, various techniques can used in order to retrieve the 317 computed explicit paths on a per domain basis during the signaling 318 process thanks to the use of path keys as described in 319 [I-D.bradford-pce-path-key]. 321 BRPC guarantees to find the optimal (shortest) constrained inter- 322 domain TE LSP according to a set of defined domains to be traversed. 323 Note that other variants of the BRPC procedure relying on the same 324 principles are also possible. 326 Note also that in case of ECMP paths, more than one path could be 327 returned to the requesting LSR. 329 6. PCEP Protocol Extensions 331 The BRPC procedure requires the specification of a new flag of the RP 332 object carried within the PCReq message (defined in 333 [I-D.ietf-pce-pcep]), the aim of which is to specify that the 334 shortest path(s) satisfying the constraints from the destination to 335 the set of entry boundary nodes are requested (such set of path(s) 336 forms the downstream VSPT as specified in Section 5.2). 338 The following new flag of the RP object is defined: VSPT (V) flag: 339 0x20. When set, this indicates that the PCC requests the computation 340 of an inter-domain TE LSP using the BRPC procedure. 342 Because path segment(s) computed by a downstream PCE in the context 343 of the BRPC procedure must be provided along with their respective 344 path cost(s), the C flag of the RP object carried within the PCReq 345 message MUST be set. It is the choice of the requester to 346 appropriately set the O bit of the RP object. 348 7. Inter-AS TE Links 350 In the case of Inter-AS TE LSP path computation, the BRPC procedure 351 requires the knowledge of the traffic engineering attributes of the 352 Inter-AS TE links: the process by which the PCE acquires this 353 information is out of the scope of the BRPC procedure (which is 354 compliant with the PCE architecture defined in 355 [I-D.ietf-pce-architecture]). 357 That said, a straitghforward solution consists of allowing the ASBRs 358 to flood the TE information related to the inter-ASBR link(s) 359 although no IGP TE is enabled over those links (there is no IGP 360 adjacency over the inter-ASBR links). This allows the PCE of a 361 domain to get entire TE visibility up to the set of entry ASBRs in 362 the downstream domain. 364 8. Usage in conjunction with per-domain path computation 366 The BRPC procedure may be used to compute path segments and could be 367 used in conjunction with other path computation techniques (such as 368 the per-domain path computation technique defined in 369 [I-D.ietf-ccamp-inter-domain-pd-path-comp]) to compute the end-to-end 370 path. In this case end-to-end path optimality can no longer be 371 guaranteed. 373 9. BRPC procedure completion failure 375 If the BRPC procedure cannot be completed because a PCE along the 376 domain path does not support the procedure, a PCErr message is 377 returned to the upstream PCE with a Error-Type "BRPC procedure 378 completion failure". The PCErr message MUST be relayed to the 379 requesting PCC. 381 PCEP-ERROR objects are used to report a PCEP protocol error and are 382 characterized by an Error-Type which specifies the type of error and 383 an Error-value that provides additional information about the error 384 type. Both the Error-Type and the Error-Value are managed by IANA. 385 A new Error-Type is defined that relates to the BRPC procedure. 387 Error-type Meaning 388 10 BRPC procedure completion failure 389 Error-value 390 1: BRPC procedure not supported by one or more PCEs 391 along the domain path 393 10. Applicability 395 As discussed in section 3, the requirements for inter-area and 396 inter-AS MPLS Traffic Engineering have been developed by the Traffic 397 Engineering Working Group (TE WG) and have been stated in [RFC4105] 398 and [RFC4216], respectively. Among the set of requirements, both 399 documents indicate the need for some solution providing the ability 400 to compute an optimal (shortest) constrained inter-domain TE LSP and 401 to compute a set of diverse inter-domain TE LSPs. 403 10.1. Diverse end-to-end path computation 405 PCEP allows a PCC to request the computation of a set of diverse TE 406 LSPs thanks to the SVEC object by setting the flags L, N or S to 407 request link, node or SRLG diversity respectively. Such request MUST 408 be taken into account by each PCE along the path computation chain 409 during the VSPT computation. In the context of the BRPC procedure, a 410 set of diversely routed TE LSP between two LSRs can be computed since 411 the paths segment(s) of the VSPT are simultaneously computed by a 412 given PCE. The BRPC path procedure allows for the computation of 413 diverse paths under various objective functions (such as minimizing 414 the sum of the costs of the N diverse paths, etc) thus avoiding the 415 well-known "trapping" problem. Indeed, with a 2-step approach 416 consisting of computing the first path followed by the computation of 417 the second path after having removed the set of network elements 418 traversed by the first path (if that does not violate confidentiality 419 preservation), one cannot guarantee that a solution will be found 420 even if such solution exists. Furthermore, even if a solution is 421 found, it may not be the most optimal one with respect to objective 422 function such as minimizing the sum of the paths costs, bounding the 423 path delays of both paths and so on. Finally, it must be noted that 424 such a 2-step path computation approach is usually less efficient in 425 term of signalling delays since it requires two serialized TE LSP set 426 up. 428 10.2. Path optimality 430 BRPC guarantees that the optimal (shortest) constrained inter-domain 431 path will always be found subject to policy constraints. When 432 combined with other local path computation techniques (e.g. in the 433 case of stitched/nested TE LSP) and in the case where a domain has 434 more than one BR-en or more than one BR-ex, optimality after some 435 network change within the domain can only be guaranteed by re- 436 executing the BRPC procedure. 438 11. Reoptimization of an inter-domain TE LSP 440 The ability to reoptimize an existing inter-domain TE LSP path has 441 been explicitly listed as a requirement in [RFC4105] and [RFC4216]. 442 In the case of a TE LSP reoptimization request, regular procedures 443 apply as defined in PCEP where the path in use (if available on the 444 head-end) is provided within the path computation request in order 445 for the PCEs involved in the reoptimization request to avoid double 446 bandwidth accounting. 448 12. Metric normalization 450 In the case of inter-area TE, the same IGP/TE metric scheme is 451 usually adopted for all the IGP areas (e.g. based on the link-speed, 452 propagation delay or some other combination of link attributes). 453 Hence, the proposed set of mechanisms always computes the shortest 454 path across multiple areas obeying the required set of constraints 455 with respect to a well-specified objective function. Conversely, in 456 the case of Inter-AS TE, in order for this path computation to be 457 meaningful, a metric normalization between ASs may be required. One 458 solution to avoid IGP metric modification would be for the SPs to 459 agree on a TE metric normalization scheme and use the TE metric for 460 TE LSP path computation (in that case, this must be requested in the 461 PCEP Path computation request) thanks to the COST object. 463 13. Manageability Considerations 465 To be added in a further revision of this document. 467 14. IANA Considerations 469 A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) is 470 defined in this document. 472 Name: VSPT (V) 474 Value: 0x20. 476 When set, this indicates that the PCC requests the computation of an 477 inter-domain TE LSP using the BRPC procedure. 479 A new Error-Type is defined in this document (Error-Type and Error- 480 value to be assigned by IANA). 482 Error-type Meaning 483 10 BRPC procedure completion failure 484 Error-value 485 1: BRPC procedure not supported by one or PCEs 486 along the domain path 488 15. Security Considerations 490 The BRPC procedure does not introduce any additional security issues 491 beyond the ones related to inter-PCE communication. 493 16. Acknowledgements 495 The authors would like to thank Arthi Ayyangar and Dimitri 496 Papadimitriou for their useful comments. A special thank to Adrian 497 Farrel for his useful comments and suggestions. 499 17. References 501 17.1. Normative References 503 [I-D.ietf-pce-architecture] 504 Farrel, A., "A Path Computation Element (PCE) Based 505 Architecture", draft-ietf-pce-architecture-05 (work in 506 progress), April 2006. 508 [I-D.ietf-pce-pcep] 509 Vasseur, J., "Path Computation Element (PCE) communication 510 Protocol (PCEP) - Version 1", draft-ietf-pce-pcep-02 (work 511 in progress), June 2006. 513 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 514 Requirement Levels", BCP 14, RFC 2119, March 1997. 516 17.2. Informative References 518 17.3. Informative References 520 [I-D.bradford-pce-path-key] 521 Bradford, R., "Preserving Topology Confidentiality in 522 Inter-Domain Path Computation and Signaling", 523 draft-bradford-pce-path-key-00 (work in progress), 524 June 2006. 526 [I-D.ietf-ccamp-inter-domain-framework] 527 Farrel, A., "A Framework for Inter-Domain Multiprotocol 528 Label Switching Traffic Engineering", 529 draft-ietf-ccamp-inter-domain-framework-05 (work in 530 progress), July 2006. 532 [I-D.ietf-ccamp-inter-domain-pd-path-comp] 533 Vasseur, J., "A Per-domain path computation method for 534 establishing Inter-domain Traffic Engineering (TE) Label 535 Switched Paths (LSPs)", 536 draft-ietf-ccamp-inter-domain-pd-path-comp-02 (work in 537 progress), February 2006. 539 [I-D.ietf-ccamp-inter-domain-rsvp-te] 540 Ayyangar, A. and J. Vasseur, "Inter domain GMPLS Traffic 541 Engineering - RSVP-TE extensions", 542 draft-ietf-ccamp-inter-domain-rsvp-te-03 (work in 543 progress), March 2006. 545 [I-D.ietf-pce-disco-proto-igp] 546 Roux, J., "IGP protocol extensions for Path Computation 547 Element (PCE) Discovery", 548 draft-ietf-pce-disco-proto-igp-02 (work in progress), 549 June 2006. 551 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 552 McManus, "Requirements for Traffic Engineering Over MPLS", 553 RFC 2702, September 1999. 555 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 556 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 558 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 559 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 560 November 2005. 562 Appendix A. Proposed Status and Discussion [To Be Removed Upon 563 Publication] 565 This Internet-Draft is being submitted for eventual publication as an 566 RFC with a proposed status of Informational. Discussion of this 567 proposal should take place on the following mailing list: 568 pce@ietf.org. 570 Authors' Addresses 572 JP Vasseur (editor) 573 Cisco Systems, Inc 574 1414 Massachusetts Avenue 575 Boxborough, MA 01719 576 USA 578 Email: jpv@cisco.com 580 Raymond Zhang 581 BT Infonet 582 2160 E. Grand Ave. 583 El Segundo, CA 90025 584 USA 586 Email: raymond_zhang@bt.infonet.com 588 Nabil Bitar 589 Verizon 590 40 Sylvan Road 591 Waltham, MA 02145 592 USA 594 Email: nabil.bitar@verizon.com 595 JL Le Roux 596 France Telecom 597 2, Avenue Pierre-Marzin 598 Lannion, 22307 599 FRANCE 601 Email: jeanlouis.leroux@orange-ft.com 603 Full Copyright Statement 605 Copyright (C) The Internet Society (2006). 607 This document is subject to the rights, licenses and restrictions 608 contained in BCP 78, and except as set forth therein, the authors 609 retain all their rights. 611 This document and the information contained herein are provided on an 612 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 613 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 614 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 615 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 616 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 617 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 619 Intellectual Property 621 The IETF takes no position regarding the validity or scope of any 622 Intellectual Property Rights or other rights that might be claimed to 623 pertain to the implementation or use of the technology described in 624 this document or the extent to which any license under such rights 625 might or might not be available; nor does it represent that it has 626 made any independent effort to identify any such rights. Information 627 on the procedures with respect to rights in RFC documents can be 628 found in BCP 78 and BCP 79. 630 Copies of IPR disclosures made to the IETF Secretariat and any 631 assurances of licenses to be made available, or the result of an 632 attempt made to obtain a general license or permission for the use of 633 such proprietary rights by implementers or users of this 634 specification can be obtained from the IETF on-line IPR repository at 635 http://www.ietf.org/ipr. 637 The IETF invites any interested party to bring to its attention any 638 copyrights, patents or patent applications, or other proprietary 639 rights that may cover technology that may be required to implement 640 this standard. Please address the information to the IETF at 641 ietf-ipr@ietf.org. 643 Acknowledgment 645 Funding for the RFC Editor function is provided by the IETF 646 Administrative Support Activity (IASA).