idnits 2.17.1 draft-ietf-pce-brpc-07.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 792. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 803. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 810. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 816. 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 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 (February 8, 2008) is 5916 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'I-D.ietf-ccamp-inter-domain-rsvp-te' is defined on line 675, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-09 ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-04) exists of draft-ietf-ccamp-isis-interas-te-extension-00 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-ospf-interas-te-extension-02 == Outdated reference: A later version (-11) exists of draft-ietf-pce-manageability-requirements-02 == Outdated reference: A later version (-09) exists of draft-ietf-pce-monitoring-01 == Outdated reference: A later version (-06) exists of draft-ietf-pce-path-key-01 Summary: 3 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: Standards Track R. Zhang 4 Expires: August 11, 2008 BT Infonet 5 N. Bitar 6 Verizon 7 JL. Le Roux 8 France Telecom 9 February 8, 2008 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-07.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 August 11, 2008. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2008). 44 Abstract 46 The ability to compute shortest constrained Traffic Engineering Label 47 Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and 48 Generalized MPLS (GMPLS) networks across multiple domains (where a 49 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 procedure 53 relying on the use of multiple Path Computation Elements (PCEs) in 54 order to compute such inter-domain shortest constrained paths along a 55 determined sequence of domains, using a backward recursive path 56 computation technique while preserving confidentiality across 57 domains, which is sometimes required when domains are managed by 58 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 . . . . . . . . . . . . . . . . . . . . 7 74 5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 9 75 6. VSPT Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 10 77 8. Usage in conjunction with per-domain path computation . . . . 10 78 9. BRPC procedure completion failure . . . . . . . . . . . . . . 10 79 10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11 80 10.1. Diverse end-to-end path computation . . . . . . . . . . . 11 81 10.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 12 82 11. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 12 83 12. Path Computation failure . . . . . . . . . . . . . . . . . . . 12 84 13. Metric normalization . . . . . . . . . . . . . . . . . . . . . 12 85 14. Manageability Considerations . . . . . . . . . . . . . . . . . 13 86 14.1. Control of Function and Policy . . . . . . . . . . . . . . 13 87 14.2. Information and Data Models . . . . . . . . . . . . . . . 13 88 14.3. Liveness Detection and Monitoring . . . . . . . . . . . . 13 89 14.4. Verifying Correct Operation . . . . . . . . . . . . . . . 13 90 14.5. Requirements on Other Protocols and Functional 91 Components . . . . . . . . . . . . . . . . . . . . . . . . 14 92 14.6. Impact on Network Operation . . . . . . . . . . . . . . . 14 93 14.7. Path computation chain monitoring . . . . . . . . . . . . 14 94 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 95 15.1. New flag of the RP object . . . . . . . . . . . . . . . . 14 96 15.2. new Error-Type and Error-Value . . . . . . . . . . . . . . 14 97 15.3. New flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 15 98 16. Security Considerations . . . . . . . . . . . . . . . . . . . 15 99 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 15 100 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 101 18.1. Normative References . . . . . . . . . . . . . . . . . . . 15 102 18.2. Informative References . . . . . . . . . . . . . . . . . . 16 103 Appendix A. Proposed Status and Discussion [To Be Removed 104 Upon Publication] . . . . . . . . . . . . . . . . . . 17 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17 106 Intellectual Property and Copyright Statements . . . . . . . . . . 19 108 1. Terminology 110 ABR: routers used to connect two IGP areas (areas in OSPF or levels 111 in IS-IS). 113 ASBR: routers used to connect together ASes of the same or different 114 Service Provider(s) via one or more Inter-AS links. 116 Boundary Node (BN): a boundary node is either an ABR in the context 117 of inter-area Traffic Engineering or an ASBR in the context of 118 inter-AS Traffic Engineering. 120 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 121 a determined sequence of domains. 123 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 124 a determined sequence of domains. 126 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 128 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 130 LSR: Label Switching Router. 132 LSP: Label Switched Path. 134 PCC: Path Computation Client. Any client application requesting a 135 path computation to be performed by the Path Computation Element. 137 PCE (Path Computation Element): an entity (component, application or 138 network node) that is capable of computing a network path or route 139 based on a network graph and applying computational constraints. 141 PCE(i) is a PCE with the scope of domain(i). 143 TED: Traffic Engineering Database. 145 VSPT: Virtual Shortest Path Tree. 147 The notion of contiguous, stitched and nested TE LSPs is defined in 148 [RFC4726] and will not be repeated here. 150 2. Introduction 152 The requirements for inter-area and inter-AS MPLS Traffic Engineering 153 have been developed by the Traffic Engineering Working Group (TE WG) 154 and have been stated in [RFC4105] and [RFC4216], respectively. 156 The framework for inter-domain MPLS Traffic Engineering has been 157 provided in [RFC4726]. 159 [I-D.ietf-ccamp-inter-domain-pd-path-comp] defines a technique for 160 establishing inter-domain (G)MPLS TE LSP whereby the path is computed 161 during the signalling process on a per-domain basis by the entry 162 boundary node of each domain (each node in charge of computing a 163 section of an inter-domain TE LSP path is always along the path of 164 such TE LSP). Such path computation technique fulfills some of the 165 requirements stated in [RFC4105] and [RFC4216] but not all of them. 166 In particular, it cannot guarantee to find an optimal (shortest) 167 inter-domain constrained path. Furthermore, it cannot be efficiently 168 used to compute a set of inter-domain diversely routed TE LSPs. 170 The PCE architecture is defined in [RFC4655]. The aim of this 171 document is to describe a PCE-based path computation procedure to 172 compute optimal inter-domain constrained (G)MPLS TE LSPs. 174 Qualifying a path as optimal requires some clarification. Indeed, a 175 globally optimal TE LSP placement usually refers to a set of TE LSPs 176 whose placements optimize the network resources with regards to a 177 specified objective function (e.g., a placement that reduces the 178 maximum or average network load while satisfying the TE LSP 179 constraints). In this document, an optimal inter-domain constrained 180 TE LSP is defined as the shortest path satisfying the set of required 181 constraints that would be obtained in the absence of multiple domains 182 (in other words, in a totally flat IGP network between the source and 183 destination of the TE LSP). 185 3. General assumptions 187 In the rest of this document, we make the following set of 188 assumptions common to inter-area and inter-AS MPLS TE: 190 - Each IGP area or Autonomous System (AS) is assumed to be Traffic 191 Engineering enabled (i.e. running OSPF-TE or ISIS-TE and RSVP-TE). 193 - No topology or resource information is distributed between domains 194 (as mandated per [RFC4105] and [RFC4216]), which is critical to 195 preserve IGP/BGP scalability and confidentiality. 197 - While certain constraints like bandwidth can be used across 198 different domains, other TE constraints like resource affinity, 199 color, metric, etc. as listed in [RFC2702] could be translated at 200 domain boundaries. If required, it is assumed that, at the domain 201 boundary nodes, there will exist some sort of local mapping based on 202 policy agreement, in order to translate such constraints across 203 domain boundaries during the inter-PCE communication process. 205 - Each AS can be made of several IGP areas. The path computation 206 procedure described in this document applies to the case of a single 207 AS made of multiple IGP areas, multiple ASes made of a single IGP 208 area or any combination of the above. For the sake of simplicity, 209 each AS will be considered to be made of a single area in this 210 document. The case of an Inter-AS TE LSP spanning multiple ASes 211 where some of those ASes are themselves made of multiple IGP areas 212 can be easily derived from this case by applying the BRPC procedure 213 described in this document, recursively. 215 - The domain path (set of domains traversed to reach the destination 216 domain) is either administratively pre-determined or discovered by 217 some means that are outside of the scope of this document. 219 4. BRPC Procedure 221 The BRPC procedure is a Multiple-PCE path computation technique as 222 described in [RFC4655]. A possible model consists of hosting the PCE 223 function on boundary nodes (e.g., ABR or ASBR) but this is not 224 mandated by the BRPC procedure. 226 The BRPC procedure does not make any assumption with regards to the 227 nature of the inter-domain TE LSP that could be contiguous, nested or 228 stitched. 230 Furthermore, no assumption is made on the actual path computation 231 algorithm in use by a PCE (e.g., it can be any variant of CSPF or an 232 algorithm based on linear-programming to solve multi-constraints 233 optimization problems). 235 4.1. Domain path selection 237 The PCE-based BRPC procedure applies to the computation of an optimal 238 constrained inter-domain TE LSP. The sequence of domains to be 239 traversed can either be determined a priori or during the path 240 computation procedure. The BRPC procedure guarantees to compute the 241 optimal path across a specific sequence of traversed domains (which 242 constitutes an additional constraint). In the case of an arbitrary 243 set of meshed domains, the BRPC procedure can be used to compute the 244 optimal path across each domain set in order to get the optimal 245 constrained path between the source and the destination of the TE 246 LSP. The BRPC procedure can also be used across a subset of all 247 domain sequences, and the best path among these sequences can then be 248 selected. 250 4.2. Mode of Operation 252 Definition of VSPT(i) 254 In each domain i: 256 * There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN- 257 en(k,i) is the kth entry BN of domain(i). 259 * There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where BN- 260 ex(k,i) is the kth exit BN of domain(i). 262 VSPT(i): MP2P (MultiPoint To Point) tree returned by PCE(i) to 263 PCE(i-1): 265 Root (TE LSP destination) 266 / I \ 267 BN-en(1,i) BN-en(2,i) ... BN-en((j), i). 269 Where [X-en(i)] is the number of entry BN in domain i 270 and j<= [X-en(i)] 272 Figure 1 - MP2P Tree 274 Each link of tree VSPT(i) represents the shortest constrained path 275 between BN-en(j,i) (identified by its TE Router-ID) and the TE LSP 276 destination that satisfies the set of required constraints for the TE 277 LSP (bandwidth, affinities, ...). These are path segments to reach 278 the TE LSP destination from BN-en(j,i). 280 Note that PCE(i) only considers the entry BNs that provide 281 connectivity from domain(i-1). That is, the set BN-en(k,i-1) is only 282 made of those BNs that provide connectivity from domain (i-1) to 283 domain(i). Furthermore, some BNs may be excluded according to policy 284 constraints (either due to local policy or policies signaled in the 285 path computation request). 287 Step 1: the PCC needs to first determine the PCE capable of serving 288 its path computation request (this can be done thanks to local 289 configuration or via IGP discovery (see [RFC5088] and [RFC5089])). 290 The path computation request is then relayed until reaching a PCE(n) 291 such that the TE LSP destination resides in the domain(n). At each 292 step of the process, the next PCE can either be statically configured 293 or dynamically discovered via IGP/BGP extensions. If no next PCE can 294 be found or the next hop PCE of choice is unavailable, the procedure 295 stops and a path computation error is returned (see Section 9). If 296 multiple PCEs are discovered, the PCE may select a subset of these 297 PCEs based on some local policies or heuristics. The PCE selection 298 process is outside of the scope of this document. Note also that a 299 sequence of PCEs might be enforced by policy on the PCC and this 300 constraint can be carried in the PCEP path computation request (as 301 defined in [I-D.ietf-pce-monitoring]). 303 Step 2: PCE(n) computes VSPT(n) made of the list of shortest 304 constrained path(s) between every BN-en(j,n) and the TE LSP 305 destination using a suitable path computation algorithm (e.g. CSPF) 306 and returns the computed VSPT(n) to PCE(n-1). 308 Step i: 310 - For i=n-1 to 2: PCE(i) concatenates the topology of domain(i) 311 (using its TED) with the received VSPT(i+1). 313 In the case of Inter-AS TE LSP computation, this requires to also add 314 the inter-AS TE links connecting the domain(i) to the domain(i+1). 316 Then PCE(i) computes VSPT(i) (MP2P (Multi-Point to Point) tree made 317 of the shortest constrained paths between each BN-en(j,i) and the TE 318 LSP destination). 320 End 322 Finally PCE(1) computes the end-to-end shortest constrained path from 323 the source to the destination and returns the corresponding path to 324 the requesting PCC in the form of a PCRep message as defined in 325 [I-D.ietf-pce-pcep]. 327 Each branch of the VSPT tree (path) may be returned in the form of an 328 explicit path (in which case all the hops along the path segment are 329 listed) or a loose path (in which case only the BR is specified) so 330 as to preserve confidentiality along with the respective cost. In 331 the later case, various techniques can be used in order to retrieve 332 the computed explicit paths on a per domain basis during the 333 signaling process thanks to the use of path keys as described in 334 [I-D.ietf-pce-path-key]. 336 BRPC guarantees to find the optimal (shortest) constrained inter- 337 domain TE LSP according to a set of defined domains to be traversed. 338 Note that other variants of the BRPC procedure relying on the same 339 principles are also possible. 341 Note also that in case of ECMP paths, more than one path could be 342 returned to the requesting LSR. 344 5. PCEP Protocol Extensions 346 The BRPC procedure requires the specification of a new flag of the RP 347 object carried within the PCReq message (defined in 348 [I-D.ietf-pce-pcep]) to specify that the shortest paths satisfying 349 the constraints from the destination to the set of entry boundary 350 nodes are requested (such set of paths forms the downstream VSPT as 351 specified in Section 4.2). 353 The following new flag of the RP object is defined: 355 VSPT Flag 356 Bit Number Name Flag 357 7 VSPT 359 When set, the VSPT Flag indicates that the PCC requests the 360 computation of an inter-domain TE LSP using the BRPC procedure 361 defined in this document. 363 Because path segment(s) computed by a downstream PCE in the context 364 of the BRPC procedure MUST be provided along with their respective 365 path cost(s), the C flag of the METRIC object carried within the 366 PCReq message MUST be set. It is the choice of the requester to 367 appropriately set the O bit of the RP object. 369 6. VSPT Encoding 371 The VSPT is returned within a PCRep message. The encoding consists 372 of a non-ordered lists of EROs where each ERO represents a path 373 segment from an ABR to the destination specified in the END-POINT 374 object of the corresponding PCReq message. 376 Example: 378 <---- area 1 ----><---- area 0 -----><------ area 2 ------> 379 ABR1-A-B-+ 380 | | 381 ABR2-----D 382 | | 383 ABR3--C--+ 385 Figure 2 - An Example of VPST Encoding Using a Set of EROs 387 In the simple example shown in figure 2, if we make the assumption 388 that a constrained path exists between each ABR and the destination 389 D, the VSPT computed by a PCE serving area 2 consists of the 390 following non-ordered set of EROs: 392 o ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP 393 address)-D(TE Router ID) 395 o ERO2: ABR2(TE Router ID)-D(TE Router ID) 397 o ERO3: ABR3(TE Router ID)-C(interface IP adress)-D(TE Router ID) 399 The PCERep message, PCRep message, PCEP END-POINT and ERO objects are 400 defined in [I-D.ietf-pce-pcep] 402 7. Inter-AS TE Links 404 In the case of Inter-AS TE LSP path computation, the BRPC procedure 405 requires the knowledge of the traffic engineering attributes of the 406 Inter-AS TE links: the process by which the PCE acquires this 407 information is out of the scope of the BRPC procedure, which is 408 compliant with the PCE architecture defined in [RFC4655]. 410 That said, a straightforward solution consists of allowing the ASBRs 411 to flood the TE information related to the inter-ASBR link(s) 412 although no IGP TE is enabled over those links (there is no IGP 413 adjacency over the inter-ASBR links). This allows the PCE of a 414 domain to get entire TE visibility up to the set of entry ASBRs in 415 the downstream domain (see the IGP extensions defined in 416 [I-D.ietf-ccamp-isis-interas-te-extension] and 417 [I-D.ietf-ccamp-ospf-interas-te-extension]). 419 8. Usage in conjunction with per-domain path computation 421 The BRPC procedure may be used to compute path segments in 422 conjunction with other path computation techniques (such as the per- 423 domain path computation technique defined in 424 [I-D.ietf-ccamp-inter-domain-pd-path-comp]) to compute the end-to-end 425 path. In this case end-to-end path optimality can no longer be 426 guaranteed. 428 9. BRPC procedure completion failure 430 If the BRPC procedure cannot be completed because a PCE along the 431 domain path does not support the procedure, a PCErr message MUST be 432 returned to the upstream PCE with a Error-Type "BRPC procedure 433 completion failure". The PCErr message MUST be relayed to the 434 requesting PCC. 436 PCEP-ERROR objects are used to report a PCEP protocol error and are 437 characterized by an Error-Type which specifies the type of error and 438 an Error-value that provides additional information about the error 439 type. Both the Error-Type and the Error-Value are managed by IANA. 440 A new Error-Type is defined that relates to the BRPC procedure. 442 Error-type Meaning 443 13 BRPC procedure completion failure 444 Error-value 445 1: BRPC procedure not supported by one or more PCEs 446 along the domain path 448 10. Applicability 450 As discussed in Section 3, the requirements for inter-area and 451 inter-AS MPLS Traffic Engineering have been developed by the Traffic 452 Engineering Working Group (TE WG) and have been stated in [RFC4105] 453 and [RFC4216], respectively. Among the set of requirements, both 454 documents indicate the need for some solution providing the ability 455 to compute an optimal (shortest) constrained inter-domain TE LSP and 456 to compute a set of diverse inter-domain TE LSPs. 458 10.1. Diverse end-to-end path computation 460 PCEP (see [I-D.ietf-pce-pcep]) allows a PCC to request the 461 computation of a set of diverse TE LSPs thanks to the SVEC object by 462 setting the flags L, N or S to request link, node or SRLG diversity 463 respectively. Such request MUST be taken into account by each PCE 464 along the path computation chain during the VSPT computation. In the 465 context of the BRPC procedure, a set of diversely routed TE LSP 466 between two LSRs can be computed since the paths segment(s) of the 467 VSPT are simultaneously computed by a given PCE. The BRPC procedure 468 allows for the computation of diverse paths under various objective 469 functions (such as minimizing the sum of the costs of the N diverse 470 paths, etc). 472 By constrast, with a 2-step approach consisting of computing the 473 first path followed by the computation of the second path after 474 having removed the set of network elements traversed by the first 475 path (if that does not violate confidentiality preservation), one 476 cannot guarantee that a solution will be found even if such solution 477 exists. Furthermore, even if a solution is found, it may not be the 478 most optimal one with respect to an objective function such as 479 minimizing the sum of the paths costs, bounding the path delays of 480 both paths and so on. Finally, it must be noted that such a 2-step 481 path computation approach is usually less efficient in term of 482 signalling delays since it requires two serialized TE LSP set up. 484 10.2. Path optimality 486 BRPC guarantees that the optimal (shortest) constrained inter-domain 487 path will always be found subject to policy constraints. When 488 combined with other local path computation techniques (e.g. in the 489 case of stitched/nested TE LSP) and in the case where a domain has 490 more than one BR-en or more than one BR-ex, optimality after some 491 network change within the domain can only be guaranteed by re- 492 executing the BRPC procedure. 494 11. Reoptimization of an inter-domain TE LSP 496 The ability to reoptimize an existing inter-domain TE LSP path has 497 been explicitly listed as a requirement in [RFC4105] and [RFC4216]. 498 In the case of a TE LSP reoptimization request, the reoptimization 499 procedure defined in [I-D.ietf-pce-pcep] applies where the path in 500 use (if available on the head-end) is provided as part of the path 501 computation request in order for the PCEs involved in the 502 reoptimization request to avoid double bandwidth accounting. 504 12. Path Computation failure 506 If a PCE requires to relay a path computation request according to 507 the BRPC procedure defined in this document to a downstream PCE and 508 no such PCE is available, the PCE MUST send a negative path 509 computation reply to the requester using a PCReq message as specified 510 in [I-D.ietf-pce-pcep] that contains a NO-PATH object. In such case, 511 the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in 512 [I-D.ietf-pce-pcep]) with the newly defined bit named "BRPC Path 513 Computation chain unavailable" set. 515 Bit number Name Flag 516 4 BRPC Path computation chain unavailable 518 13. Metric normalization 520 In the case of inter-area TE, the same IGP/TE metric scheme is 521 usually adopted for all the IGP areas (e.g., based on the link-speed, 522 propagation delay or some other combination of link attributes). 523 Hence, the proposed set of mechanisms always computes the shortest 524 path across multiple areas obeying the required set of constraints 525 with respect to a specified objective function. Conversely, in the 526 case of Inter-AS TE, in order for this path computation to be 527 meaningful, a metric normalization between ASes may be required. One 528 solution to avoid IGP metric modification would be for the Service 529 Providers to agree on a TE metric normalization scheme and use the TE 530 metric for TE LSP path computation (in that case, this must be 531 requested in the PCEP Path computation request) thanks to the METRIC 532 object (defined in [I-D.ietf-pce-pcep]). 534 14. Manageability Considerations 536 This section follows the guidance of 537 [I-D.ietf-pce-manageability-requirements]. 539 14.1. Control of Function and Policy 541 The only configurable item is the support of the BRPC procedure on a 542 PCE. The support of the BRPC procedure by the PCE MAY be controlled 543 by a policy module governing the conditions under which a PCE should 544 participate to the BRPC procedure (origin of the requests, number of 545 requests per second, ...). If the BRPC is not supported/allowed on a 546 PCE, it MUST send a PCErr message as specified in Section 9. 548 14.2. Information and Data Models 550 A BRPC MIB module will be specified in a separate document. 552 14.3. Liveness Detection and Monitoring 554 The BRPC procedure is a Multiple-PCE path computation technique and 555 as such a set of PCEs are involved in the path computation chain. If 556 the path computation chain is not operational either because at least 557 one PCE does not support the BRPC procedure or because one of the 558 PCEs that must be involved in the path computation chain is not 559 available, procedures are defined to report such failures in 560 Section 9 and Section 12 respectively. Furthermore, a built-in 561 diagnostic tool to check the availability and performances of a PCE 562 chain is defined in [I-D.ietf-pce-monitoring]. 564 14.4. Verifying Correct Operation 566 Verifying the correct operation of BRPC can be done by looking at the 567 TEDs related to the various domains traversed by a TE LSP at the time 568 the BRPC procedure was invoked and verify that the path computed by 569 the BRPC procedure is the expected optimal inter-domain constrained 570 path (the path that would be obtained in the absence of multiple 571 domains). 573 14.5. Requirements on Other Protocols and Functional Components 575 The BRPC procedure does not put any new requirements on other 576 protocol. That said, since the BRPC procedure relies on the PCEP 577 protocol, there is a dependency between BRPC and PCEP; consequently 578 the BRPC procedure inherently makes use of the management functions 579 developed for PCEP. 581 14.6. Impact on Network Operation 583 The BRPC procedure does not have any significant impact on network 584 operation: indeed, BRPC is a Multiple-PCE path computation scheme as 585 defined in [RFC4655] and does not differ from any other path 586 computation request. 588 14.7. Path computation chain monitoring 590 [I-D.ietf-pce-monitoring] specifies a set of mechanisms that can be 591 used to gather PCE state metrics. Because BRPC is a Multiple-PCE 592 path computation techniques, such mechanism could be advantageously 593 used in the context of the BRPC procedure to check the liveness of 594 the path computation chain, locate a faulty component, monitor the 595 overall performance and so on. 597 15. IANA Considerations 599 15.1. New flag of the RP object 601 A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) is 602 defined in this document. 604 VSPT Flag 605 Bit Number Name Flag Reference 606 7 VSPT This document 608 15.2. new Error-Type and Error-Value 610 A new Error-Type is defined in this document (Error-Type and Error- 611 value to be assigned by IANA). 613 Error-type Meaning Reference 614 13 BRPC procedure completion failure This document 615 Error-value 616 1: BRPC procedure not supported by 617 one a PCE along the domain path 619 15.3. New flag of the NO-PATH-VECTOR TLV 621 A new flag of the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep]) 622 is specified in this document. 624 Bit number Meaning Reference 626 4 BRPC Path computation This document 627 chain unavailable 629 16. Security Considerations 631 The BRPC procedure relies on the use of the PCEP protocol and as such 632 is subjected to the potential attacks listed in section 11 of 633 [I-D.ietf-pce-pcep]. In addition to the security mechanisms 634 described in [I-D.ietf-pce-pcep] with regards to spoofing, snooping, 635 falsification and Denial of Service, an implementation MAY support a 636 policy module governing the conditions under which a PCE should 637 participate to the BRPC procedure. 639 The BRPC procedure does not increase the information exchanged 640 between ASes and preserves topology confidentiality, in compliance 641 with [RFC4105] and [RFC4216]. 643 17. Acknowledgements 645 The authors would like to thank Arthi Ayyangar, Dimitri 646 Papadimitriou, Siva Sivabalan and Meral Shirazipour for their useful 647 comments. A special thank to Adrian Farrel for his useful comments 648 and suggestions. 650 18. References 652 18.1. Normative References 654 [I-D.ietf-pce-pcep] 655 Ayyangar, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, 656 Y., Kumaki, K., Vasseur, J., and J. Roux, "Path 657 Computation Element (PCE) communication Protocol (PCEP)", 658 draft-ietf-pce-pcep-09 (work in progress), November 2007. 660 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 661 Requirement Levels", BCP 14, RFC 2119, March 1997. 663 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 664 Element (PCE)-Based Architecture", RFC 4655, August 2006. 666 18.2. Informative References 668 [I-D.ietf-ccamp-inter-domain-pd-path-comp] 669 Vasseur, J., Ayyangar, A., and R. Zhang, "A Per-domain 670 path computation method for establishing Inter-domain 671 Traffic Engineering (TE) Label Switched Paths (LSPs)", 672 draft-ietf-ccamp-inter-domain-pd-path-comp-06 (work in 673 progress), November 2007. 675 [I-D.ietf-ccamp-inter-domain-rsvp-te] 676 Ayyangar, A., "Inter domain Multiprotocol Label Switching 677 (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - 678 RSVP-TE extensions", 679 draft-ietf-ccamp-inter-domain-rsvp-te-07 (work in 680 progress), September 2007. 682 [I-D.ietf-ccamp-isis-interas-te-extension] 683 Chen, M. and R. Zhang, "ISIS Extensions in Support of 684 Inter-AS Multiprotocol Label Switching (MPLS) and 685 Generalized MPLS (GMPLS) Traffic Engineering", 686 draft-ietf-ccamp-isis-interas-te-extension-00 (work in 687 progress), February 2008. 689 [I-D.ietf-ccamp-ospf-interas-te-extension] 690 Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 691 Support of Inter-AS Multiprotocol Label Switching (MPLS) 692 and Generalized MPLS (GMPLS) Traffic Engineering", 693 draft-ietf-ccamp-ospf-interas-te-extension-02 (work in 694 progress), November 2007. 696 [I-D.ietf-pce-manageability-requirements] 697 Farrel, A., "Inclusion of Manageability Sections in PCE 698 Working Group Drafts", 699 draft-ietf-pce-manageability-requirements-02 (work in 700 progress), August 2007. 702 [I-D.ietf-pce-monitoring] 703 Vasseur, J., Roux, J., and Y. Ikejiri, "A set of 704 monitoring tools for Path Computation Element based 705 Architecture", draft-ietf-pce-monitoring-01 (work in 706 progress), February 2008. 708 [I-D.ietf-pce-path-key] 709 Bradford, R., "Preserving Topology Confidentiality in 710 Inter-Domain Path Computation Using a Key-Based 711 Mechanism", draft-ietf-pce-path-key-01 (work in progress), 712 September 2007. 714 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 715 McManus, "Requirements for Traffic Engineering Over MPLS", 716 RFC 2702, September 1999. 718 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 719 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 721 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 722 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 723 November 2005. 725 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 726 Inter-Domain Multiprotocol Label Switching Traffic 727 Engineering", RFC 4726, November 2006. 729 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 730 "OSPF Protocol Extensions for Path Computation Element 731 (PCE) Discovery", RFC 5088, January 2008. 733 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 734 "IS-IS Protocol Extensions for Path Computation Element 735 (PCE) Discovery", RFC 5089, January 2008. 737 Appendix A. Proposed Status and Discussion [To Be Removed Upon 738 Publication] 740 This Internet-Draft is being submitted for eventual publication as an 741 RFC with a proposed status of Standard. Discussion of this proposal 742 should take place on the following mailing list: pce@ietf.org. 744 Authors' Addresses 746 JP Vasseur (editor) 747 Cisco Systems, Inc 748 1414 Massachusetts Avenue 749 Boxborough, MA 01719 750 USA 752 Email: jpv@cisco.com 754 Raymond Zhang 755 BT Infonet 756 2160 E. Grand Ave. 757 El Segundo, CA 90025 758 USA 760 Email: raymond_zhang@bt.infonet.com 762 Nabil Bitar 763 Verizon 764 40 Sylvan Road 765 Waltham, MA 02145 766 USA 768 Email: nabil.bitar@verizon.com 770 JL Le Roux 771 France Telecom 772 2, Avenue Pierre-Marzin 773 Lannion, 22307 774 FRANCE 776 Email: jeanlouis.leroux@orange-ft.com 778 Full Copyright Statement 780 Copyright (C) The IETF Trust (2008). 782 This document is subject to the rights, licenses and restrictions 783 contained in BCP 78, and except as set forth therein, the authors 784 retain all their rights. 786 This document and the information contained herein are provided on an 787 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 788 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 789 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 790 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 791 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 792 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 794 Intellectual Property 796 The IETF takes no position regarding the validity or scope of any 797 Intellectual Property Rights or other rights that might be claimed to 798 pertain to the implementation or use of the technology described in 799 this document or the extent to which any license under such rights 800 might or might not be available; nor does it represent that it has 801 made any independent effort to identify any such rights. Information 802 on the procedures with respect to rights in RFC documents can be 803 found in BCP 78 and BCP 79. 805 Copies of IPR disclosures made to the IETF Secretariat and any 806 assurances of licenses to be made available, or the result of an 807 attempt made to obtain a general license or permission for the use of 808 such proprietary rights by implementers or users of this 809 specification can be obtained from the IETF on-line IPR repository at 810 http://www.ietf.org/ipr. 812 The IETF invites any interested party to bring to its attention any 813 copyrights, patents or patent applications, or other proprietary 814 rights that may cover technology that may be required to implement 815 this standard. Please address the information to the IETF at 816 ietf-ipr@ietf.org. 818 Acknowledgment 820 Funding for the RFC Editor function is provided by the IETF 821 Administrative Support Activity (IASA).