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