idnits 2.17.1 draft-ietf-pce-brpc-08.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 22. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 808. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 819. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 826. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 832. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- 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 (March 31, 2008) is 5869 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) == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-12 == 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-03 == 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-02 Summary: 1 error (**), 0 flaws (~~), 7 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: October 2, 2008 BT Infonet 5 N. Bitar 6 Verizon 7 JL. Le Roux 8 France Telecom 9 March 31, 2008 11 A Backward Recursive PCE-based Computation (BRPC) Procedure To Compute 12 Shortest Constrained Inter-domain Traffic Engineering Label Switched 13 Paths 15 draft-ietf-pce-brpc-08.txt 17 Status of this Memo 19 By submitting this Internet-Draft, each author represents that any 20 applicable patent or other IPR claims of which he or she is aware 21 have been or will be disclosed, and any of which he or she becomes 22 aware will be disclosed, in accordance with Section 6 of BCP 79. 24 Internet-Drafts are working documents of the Internet Engineering 25 Task Force (IETF), its areas, and its working groups. Note that 26 other groups may also distribute working documents as Internet- 27 Drafts. 29 Internet-Drafts are draft documents valid for a maximum of six months 30 and may be updated, replaced, or obsoleted by other documents at any 31 time. It is inappropriate to use Internet-Drafts as reference 32 material or to cite them other than as "work in progress." 34 The list of current Internet-Drafts can be accessed at 35 http://www.ietf.org/ietf/1id-abstracts.txt. 37 The list of Internet-Draft Shadow Directories can be accessed at 38 http://www.ietf.org/shadow.html. 40 This Internet-Draft will expire on October 2, 2008. 42 Abstract 44 The ability to compute shortest constrained Traffic Engineering Label 45 Switched Paths (TE LSPs) in Multiprotocol Label Switching (MPLS) and 46 Generalized MPLS (GMPLS) networks across multiple domains (where a 47 domain is a collection of network elements within a common sphere of 48 address management or path computational responsibility such as an 49 IGP area or an Autonomous Systems) has been identified as a key 50 requirement. This document specifies a procedure relying on the use 51 of multiple Path Computation Elements (PCEs) to compute such inter- 52 domain shortest constrained paths across a predetermined sequence of 53 domains, using a backward recursive path computation technique. This 54 technique preserves confidentiality across domains, which is 55 sometimes required when domains are managed by different Service 56 Providers. 58 Requirements Language 60 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 61 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 62 document are to be interpreted as described in RFC 2119 [RFC2119]. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. General Assumptions . . . . . . . . . . . . . . . . . . . . . 5 69 4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 70 4.1. Domain Path Selection . . . . . . . . . . . . . . . . . . 7 71 4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 7 72 5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 9 73 6. VSPT Encoding . . . . . . . . . . . . . . . . . . . . . . . . 9 74 7. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 10 75 8. Usage In Conjunction With Per-domain Path Computation . . . . 11 76 9. BRPC Procedure Completion Failure . . . . . . . . . . . . . . 11 77 10. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 11 78 10.1. Diverse end-to-end path computation . . . . . . . . . . . 12 79 10.2. Path Optimality . . . . . . . . . . . . . . . . . . . . . 12 80 11. Reoptimization Of An Inter-domain TE LSP . . . . . . . . . . . 12 81 12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 13 82 13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 13 83 14. Manageability Considerations . . . . . . . . . . . . . . . . . 13 84 14.1. Control of Function And Policy . . . . . . . . . . . . . . 13 85 14.2. Information And Data Models . . . . . . . . . . . . . . . 14 86 14.3. Liveness Detection and Monitoring . . . . . . . . . . . . 14 87 14.4. Verifying Correct Operation . . . . . . . . . . . . . . . 14 88 14.5. Requirements on Other Protocols and Functional 89 Components . . . . . . . . . . . . . . . . . . . . . . . . 14 90 14.6. Impact on Network Operation . . . . . . . . . . . . . . . 14 91 14.7. Path Computation Chain Monitoring . . . . . . . . . . . . 15 92 15. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 15 93 15.1. New Flag Of The RP Object . . . . . . . . . . . . . . . . 15 94 15.2. New Error-Type And Error-Value . . . . . . . . . . . . . . 15 95 15.3. New Flag Of The NO-PATH-VECTOR TLV . . . . . . . . . . . . 15 96 16. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 98 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 18.1. Normative References . . . . . . . . . . . . . . . . . . . 16 100 18.2. Informative References . . . . . . . . . . . . . . . . . . 16 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 102 Intellectual Property and Copyright Statements . . . . . . . . . . 19 104 1. Introduction 106 The requirements for inter-area and inter-AS MPLS Traffic Engineering 107 (TE) have been developed by the Traffic Engineering Working Group (TE 108 WG) and have been stated in [RFC4105] and [RFC4216], respectively. 110 The framework for inter-domain Multiprotocol Label Switching (MPLS) 111 Traffic Engineering (TE) has been provided in [RFC4726]. 113 [RFC5152] defines a technique for establishing an inter-domain 114 Generalized MPLS (GMPLS) TE Label Switched Path (LSP) whereby the 115 path is computed during the signalling process on a per-domain basis 116 by the entry boundary node of each domain (each node responsible for 117 triggering the computation of a section of an inter-domain TE LSP 118 path is always along the path of such TE LSP). This path computation 119 technique fulfills some of the requirements stated in [RFC4105] and 120 [RFC4216] but not all of them. In particular, it cannot guarantee to 121 find an optimal (shortest) inter-domain constrained path. 122 Furthermore, it cannot be efficiently used to compute a set of inter- 123 domain diversely routed TE LSPs. 125 The Path Computation Element (PCE) architecture is defined in 126 [RFC4655]. The aim of this document is to describe a PCE-based path 127 computation procedure to compute optimal inter-domain constrained 128 (G)MPLS TE LSPs. 130 Qualifying a path as optimal requires some clarification. Indeed, a 131 globally optimal TE LSP placement usually refers to a set of TE LSPs 132 whose placements optimize the network resources with regards to a 133 specified objective function (e.g., a placement that reduces the 134 maximum or average network load while satisfying the TE LSP 135 constraints). In this document, an optimal inter-domain constrained 136 TE LSP is defined as the shortest path satisfying the set of required 137 constraints that would be obtained in the absence of multiple domains 138 (in other words, in a totally flat IGP network between the source and 139 destination of the TE LSP). Note that this requires to use 140 consistent metric schemes in each domain (see section Section 13). 142 2. Terminology 144 ABR: Area Border Routers. Routers used to connect two IGP areas 145 (areas in OSPF or levels in IS-IS). 147 ASBR: Autonomous System Border Routers. Routers used to connect 148 together ASes of the same or different Service Providers via one or 149 more Inter-AS links. 151 Boundary Node (BN): a boundary node is either an ABR in the context 152 of inter-area Traffic Engineering or an ASBR in the context of 153 inter-AS Traffic Engineering. 155 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 156 a determined sequence of domains. 158 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 159 a determined sequence of domains. 161 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 163 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 165 LSR: Label Switching Router. 167 LSP: Label Switched Path. 169 PCC: Path Computation Client. Any client application requesting a 170 path computation to be performed by the Path Computation Element. 172 PCE (Path Computation Element): an entity (component, application or 173 network node) that is capable of computing a network path or route 174 based on a network graph and applying computational constraints. 176 PCE(i) is a PCE with the scope of domain(i). 178 TED: Traffic Engineering Database. 180 VSPT: Virtual Shortest Path Tree. 182 The notion of contiguous, stitched and nested TE LSPs is defined in 183 [RFC4726] and will not be repeated here. 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 o Each IGP area or Autonomous System (AS) is assumed to be Traffic 191 Engineering enabled. 193 o 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 o 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 202 on policy agreement, in order to translate such constraints across 203 domain boundaries during the inter-PCE communication process. 205 o Each AS can be made of several IGP areas. The path computation 206 procedure described in this document applies to the case of a 207 single AS made of multiple IGP areas, multiple ASes made of a 208 single IGP area or any combination of the above. For the sake of 209 simplicity, each AS will be considered to be made of a single area 210 in this document. The case of an Inter-AS TE LSP spanning 211 multiple ASes where some of those ASes are themselves made of 212 multiple IGP areas can be easily derived from this case by 213 applying the BRPC procedure described in this document, 214 recursively. 216 o The domain path (set of domains traversed to reach the destination 217 domain) is either administratively pre-determined or discovered by 218 some means that is outside of the scope of this document. 220 4. BRPC Procedure 222 The BRPC procedure is a Multiple-PCE path computation technique as 223 described in [RFC4655]. A possible model consists of hosting the PCE 224 function on boundary nodes (e.g., ABR or ASBR) but this is not 225 mandated by the BRPC procedure. 227 The BRPC procedure relies on communication between cooperating PCEs. 228 In particular, the PCC sends a PCReq to a PCE in its domain. The 229 request is forwarded between PCEs, domain-by-domain until the PCE 230 responsible for the domain containing the LSP destination is reached. 231 The PCE in the destination domain creates a tree of potential paths 232 to the destination (the Virtual Shortest Path Tree - VSPT) and passes 233 this back to the previous PCE in a PCRep. Each PCE in turn adds to 234 the VSPT and passes it back until the PCE in the source domain uses 235 the VSPT to select an end-to-end path that it sends to the PCC. 237 The BRPC procedure does not make any assumption with regards to the 238 nature of the inter-domain TE LSP that could be contiguous, nested or 239 stitched. 241 Furthermore, no assumption is made on the actual path computation 242 algorithm in use by a PCE (e.g., it can be any variant of CSPF or an 243 algorithm based on linear-programming to solve multi-constraint 244 optimization problems). 246 4.1. Domain Path Selection 248 The PCE-based BRPC procedure applies to the computation of an optimal 249 constrained inter-domain TE LSP. The sequence of domains to be 250 traversed is either administratively pre-determined or discovered by 251 some means that is outside of the scope of this document. The PCC 252 MAY indicate the sequence of domains to be traversed using the IRO 253 defined in [I-D.ietf-pce-pcep] so that it is available to all PCEs. 254 Note also that a sequence of PCEs MAY be enforced by policy on the 255 PCC and this constraint can be carried in the PCEP path computation 256 request (as defined in [I-D.ietf-pce-monitoring]). 258 The BRPC procedure guarantees to compute the optimal path across a 259 specific sequence of traversed domains (which constitutes an 260 additional constraint). In the case of an arbitrary set of meshed 261 domains, the BRPC procedure can be used to compute the optimal path 262 across each domain set in order to get the optimal constrained path 263 between the source and the destination of the TE LSP. The BRPC 264 procedure can also be used across a subset of all domain sequences, 265 and the best path among these sequences can then be selected. 267 4.2. Mode of Operation 269 Definition of VSPT(i) 271 In each domain i: 273 o There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN- 274 en(k,i) is the kth entry BN of domain(i). 276 o There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where BN- 277 ex(k,i) is the kth exit BN of domain(i). 279 VSPT(i): MP2P (MultiPoint To Point) tree returned by PCE(i) to 280 PCE(i-1): 282 Root (TE LSP destination) 283 / I \ 284 BN-en(1,i) BN-en(2,i) ... BN-en(j,i). 286 Where [X-en(i)] is the number of entry BNs in domain i 287 and j<= [X-en(i)] 289 Figure 1 - MP2P Tree 291 Each link of tree VSPT(i) represents the shortest constrained path 292 between BN-en(j,i) and the TE LSP destination that satisfies the set 293 of required constraints for the TE LSP (bandwidth, affinities, ...). 294 These are path segments to reach the TE LSP destination from BN- 295 en(j,i). 297 Note that PCE(i) only considers the entry BNs of domain(i). That is 298 only the BNs that provide connectivity from domain(i-1). That is, 299 the set BN-en(k,i) is only made of those BNs that provide 300 connectivity from domain (i-1) to domain(i). Furthermore, some BNs 301 may be excluded according to policy constraints (either due to local 302 policy or policies signaled in the path computation request). 304 Step 1: the PCC needs to first determine the PCE capable of serving 305 its path computation request (this can be done thanks to local 306 configuration or via IGP discovery (see [RFC5088] and [RFC5089])). 307 The path computation request is then relayed until reaching a PCE(n) 308 such that the TE LSP destination resides in the domain(n). At each 309 step of the process, the next PCE can either be statically configured 310 or dynamically discovered via IGP/BGP extensions. If no next PCE can 311 be found or the next hop PCE of choice is unavailable, the procedure 312 stops and a path computation error is returned (see Section 9). If 313 PCE(i-1) discovers multiple PCEs for the adjacent domain(i), PCE(i) 314 may select a subset of these PCEs based on some local policies or 315 heuristics. The PCE selection process is outside of the scope of 316 this document. 318 Step 2: PCE(n) computes VSPT(n) made of the list of shortest 319 constrained paths between every BN-en(j,n) and the TE LSP destination 320 using a suitable path computation algorithm (e.g. CSPF) and returns 321 the computed VSPT(n) to PCE(n-1). 323 Step i: 325 - For i=n-1 to 2: PCE(i) computes VSPT(i), the tree made of the 326 shortest constrained paths between each BN-en(j,i) and the TE LSP 327 destination. It does this by considering its own TED and the 328 information in VSPT(i+1). 330 In the case of Inter-AS TE LSP computation, this requires to also add 331 the inter-AS TE links connecting the domain(i) to the domain(i+1). 333 Step n 335 Finally PCE(1) computes the end-to-end shortest constrained path from 336 the source to the destination and returns the corresponding path to 337 the requesting PCC in the form of a PCRep message as defined in 338 [I-D.ietf-pce-pcep]. 340 Each branch of the VSPT tree (path) may be returned in the form of an 341 explicit path (in which case all the hops along the path segment are 342 listed) or a loose path (in which case only the BN is specified) so 343 as to preserve confidentiality along with the respective cost. In 344 the later case, various techniques can be used in order to retrieve 345 the computed explicit paths on a per domain basis during the 346 signaling process thanks to the use of path keys as described in 347 [I-D.ietf-pce-path-key]. 349 BRPC guarantees to find the optimal (shortest) constrained inter- 350 domain TE LSP according to a set of defined domains to be traversed. 351 Note that other variants of the BRPC procedure relying on the same 352 principles are also possible. 354 Note also that in case of ECMP paths, more than one path could be 355 returned to the requesting LSR. 357 5. PCEP Protocol Extensions 359 The BRPC procedure requires the specification of a new flag of the RP 360 object carried within the PCReq message (defined in 361 [I-D.ietf-pce-pcep]) to specify that the shortest paths satisfying 362 the constraints from the destination to the set of entry boundary 363 nodes are requested (such set of paths forms the downstream VSPT as 364 specified in Section 4.2). 366 The following new flag of the RP object is defined: 368 VSPT Flag 369 Bit Number Name Flag 370 7 VSPT 372 When set, the VSPT Flag indicates that the PCC requests the 373 computation of an inter-domain TE LSP using the BRPC procedure 374 defined in this document. 376 Because path segments computed by a downstream PCE in the context of 377 the BRPC procedure MUST be provided along with their respective path 378 costs, the C flag of the METRIC object carried within the PCReq 379 message MUST be set. It is the choice of the requester to 380 appropriately set the O bit of the RP object. 382 6. VSPT Encoding 384 The VSPT is returned within a PCRep message. The encoding consists 385 of a non-ordered lists of EROs where each ERO represents a path 386 segment from a BN to the destination specified in the END-POINT 387 object of the corresponding PCReq message. 389 Example: 391 <---- area 1 ----><---- area 0 -----><------ area 2 ------> 392 ABR1-A-B-+ 393 | | 394 ABR2-----D 395 | | 396 ABR3--C--+ 398 Figure 2 - An Example of VPST Encoding Using a Set of EROs 400 In the simple example shown in figure 2, if we make the assumption 401 that a constrained path exists between each ABR and the destination 402 D, the VSPT computed by a PCE serving area 2 consists of the 403 following non-ordered set of EROs: 405 o ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP 406 address)-D(TE Router ID) 408 o ERO2: ABR2(TE Router ID)-D(TE Router ID) 410 o ERO3: ABR3(TE Router ID)-C(interface IP adress)-D(TE Router ID) 412 The PCReq message, PCRep message, PCEP END-POINT and ERO objects are 413 defined in [I-D.ietf-pce-pcep] 415 7. Inter-AS TE Links 417 In the case of Inter-AS TE LSP path computation, the BRPC procedure 418 requires the knowledge of the traffic engineering attributes of the 419 Inter-AS TE links: the process by which the PCE acquires this 420 information is out of the scope of the BRPC procedure, which is 421 compliant with the PCE architecture defined in [RFC4655]. 423 That said, a straightforward solution consists of allowing the ASBRs 424 to flood the TE information related to the inter-ASBR links although 425 no IGP TE is enabled over those links (there is no IGP adjacency over 426 the inter-ASBR links). This allows the PCE of a domain to get entire 427 TE visibility up to the set of entry ASBRs in the downstream domain 428 (see the IGP extensions defined in 429 [I-D.ietf-ccamp-isis-interas-te-extension] and 430 [I-D.ietf-ccamp-ospf-interas-te-extension]). 432 8. Usage In Conjunction With Per-domain Path Computation 434 The BRPC procedure may be used to compute path segments in 435 conjunction with other path computation techniques (such as the per- 436 domain path computation technique defined in [RFC5152]) to compute 437 the end-to-end path. In this case end-to-end path optimality can no 438 longer be guaranteed. 440 9. BRPC Procedure Completion Failure 442 If the BRPC procedure cannot be completed because a PCE along the 443 domain does not recognize the procedure (VSPT flag of the RP object), 444 as stated in [I-D.ietf-pce-pcep], the PCE sends a PCErr message to 445 the upstream PCE with an Error-Type=4 (not supported object), Error- 446 value-4 (Unsupported paramater). The PCE may include the parent 447 object (RP object) up to and including (but no further than) the 448 unknown or unsupported parameter. In this case where the unknown or 449 unsupported parameter is a bit flag (VSPT flag), the included RP 450 object should contain the whole bit flag field with all bits after 451 the parameter at issue set to zero. The corresponding path 452 computation request is then cancelled by the PCE without further 453 notification. 455 If the BRPC procedure cannot be completed because a PCE along the 456 domain path recognises but does not support the procedure, it MUST 457 return a PCErr message to the upstream PCE with an Error-Type "BRPC 458 procedure completion failure". 460 The PCErr message MUST be relayed to the requesting PCC. 462 PCEP-ERROR objects are used to report a PCEP protocol error and are 463 characterized by an Error-Type which specifies the type of error and 464 an Error-value that provides additional information about the error 465 type. Both the Error-Type and the Error-Value are managed by IANA. 466 A new Error-Type is defined that relates to the BRPC procedure. 468 Error-type Meaning 469 13 BRPC procedure completion failure 470 Error-value 471 1: BRPC procedure not supported by one or more PCEs 472 along the domain path 474 10. Applicability 476 As discussed in Section 3, the requirements for inter-area and 477 inter-AS MPLS Traffic Engineering have been developed by the Traffic 478 Engineering Working Group (TE WG) and have been stated in [RFC4105] 479 and [RFC4216], respectively. Among the set of requirements, both 480 documents indicate the need for some solution providing the ability 481 to compute an optimal (shortest) constrained inter-domain TE LSP and 482 to compute a set of diverse inter-domain TE LSPs. 484 10.1. Diverse end-to-end path computation 486 PCEP (see [I-D.ietf-pce-pcep]) allows a PCC to request the 487 computation of a set of diverse TE LSPs thanks to the SVEC object by 488 setting the flags L, N or S to request link, node or SRLG diversity 489 respectively. Such requests MUST be taken into account by each PCE 490 along the path computation chain during the VSPT computation. In the 491 context of the BRPC procedure, a set of diversely routed TE LSPs 492 between two LSRs can be computed since the paths segments of the VSPT 493 are simultaneously computed by a given PCE. The BRPC procedure 494 allows for the computation of diverse paths under various objective 495 functions (such as minimizing the sum of the costs of the N diverse 496 paths, etc). 498 By constrast, with a 2-step approach consisting of computing the 499 first path followed by the computation of the second path after 500 having removed the set of network elements traversed by the first 501 path (if that does not violate confidentiality preservation), one 502 cannot guarantee that a solution will be found even if such solution 503 exists. Furthermore, even if a solution is found, it may not be the 504 most optimal one with respect to an objective function such as 505 minimizing the sum of the paths costs, bounding the path delays of 506 both paths and so on. Finally, it must be noted that such a 2-step 507 path computation approach is usually less efficient in term of 508 signalling delays since it requires two serialized TE LSP set up. 510 10.2. Path Optimality 512 BRPC guarantees that the optimal (shortest) constrained inter-domain 513 path will always be found subject to policy constraints. When 514 combined with other local path computation techniques (e.g. in the 515 case of stitched/nested TE LSP) and in the case where a domain has 516 more than one BN-en or more than one BN-ex, optimality after some 517 network change within the domain can only be guaranteed by re- 518 executing the BRPC procedure. 520 11. Reoptimization Of An Inter-domain TE LSP 522 The ability to reoptimize an existing inter-domain TE LSP path has 523 been explicitly listed as a requirement in [RFC4105] and [RFC4216]. 524 In the case of a TE LSP reoptimization request, the reoptimization 525 procedure defined in [I-D.ietf-pce-pcep] applies where the path in 526 use (if available on the head-end) is provided as part of the path 527 computation request in order for the PCEs involved in the 528 reoptimization request to avoid double bandwidth accounting. 530 12. Path Computation Failure 532 If a PCE requires to relay a path computation request according to 533 the BRPC procedure defined in this document to a downstream PCE and 534 no such PCE is available, the PCE MUST send a negative path 535 computation reply to the requester using a PCReq message as specified 536 in [I-D.ietf-pce-pcep] that contains a NO-PATH object. In such case, 537 the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in 538 [I-D.ietf-pce-pcep]) with the newly defined bit named "BRPC Path 539 Computation chain unavailable" set. 541 Bit number Name Flag 542 4 BRPC Path computation chain unavailable 544 13. Metric Normalization 546 In the case of inter-area TE, the same IGP/TE metric scheme is 547 usually adopted for all the IGP areas (e.g., based on the link-speed, 548 propagation delay or some other combination of link attributes). 549 Hence, the proposed set of mechanisms always computes the shortest 550 path across multiple areas obeying the required set of constraints 551 with respect to a specified objective function. Conversely, in the 552 case of Inter-AS TE, in order for this path computation to be 553 meaningful, metric normalization between ASes may be required. One 554 solution to avoid IGP metric modification would be for the Service 555 Providers to agree on a TE metric normalization scheme and use the TE 556 metric for TE LSP path computation (in that case, this must be 557 requested in the PCEP Path computation request) using the METRIC 558 object (defined in [I-D.ietf-pce-pcep]). 560 14. Manageability Considerations 562 This section follows the guidance of 563 [I-D.ietf-pce-manageability-requirements]. 565 14.1. Control of Function And Policy 567 The only configurable item is the support of the BRPC procedure on a 568 PCE. The support of the BRPC procedure by the PCE MAY be controlled 569 by a policy module governing the conditions under which a PCE should 570 participate to the BRPC procedure (origin of the requests, number of 571 requests per second, ...). If the BRPC is not supported/allowed on a 572 PCE, it MUST send a PCErr message as specified in Section 9. 574 14.2. Information And Data Models 576 A BRPC MIB module will be specified in a separate document. 578 14.3. Liveness Detection and Monitoring 580 The BRPC procedure is a Multiple-PCE path computation technique and 581 as such a set of PCEs are involved in the path computation chain. If 582 the path computation chain is not operational either because at least 583 one PCE does not support the BRPC procedure or because one of the 584 PCEs that must be involved in the path computation chain is not 585 available, procedures are defined to report such failures in 586 Section 9 and Section 12 respectively. Furthermore, a built-in 587 diagnostic tool to check the availability and performances of a PCE 588 chain is defined in [I-D.ietf-pce-monitoring]. 590 14.4. Verifying Correct Operation 592 Verifying the correct operation of BRPC can be performed by 593 monitoring a set of parameters. A BRPC implementation SHOULD provide 594 the following parameters: 596 o Number of successful BRPC Procedure completions on a per PCE peer 597 basis, 599 o Number of BRPC procedure completion failures because the VSPT flag 600 was not recognized (on a per PCE peer basis), 602 o Number of BRPC procedure completetion failures because the BRPC 603 procedure was not supported (on a per PCE peer basis), 605 14.5. Requirements on Other Protocols and Functional Components 607 The BRPC procedure does not put any new requirements on other 608 protocol. That said, since the BRPC procedure relies on the PCEP 609 protocol, there is a dependency between BRPC and PCEP; consequently 610 the BRPC procedure inherently makes use of the management functions 611 developed for PCEP. 613 14.6. Impact on Network Operation 615 The BRPC procedure does not have any significant impact on network 616 operation: indeed, BRPC is a Multiple-PCE path computation scheme as 617 defined in [RFC4655] and does not differ from any other path 618 computation request. 620 14.7. Path Computation Chain Monitoring 622 [I-D.ietf-pce-monitoring] specifies a set of mechanisms that can be 623 used to gather PCE state metrics. Because BRPC is a Multiple-PCE 624 path computation techniques, such mechanism could be advantageously 625 used in the context of the BRPC procedure to check the liveness of 626 the path computation chain, locate a faulty component, monitor the 627 overall performance and so on. 629 15. IANA Considerations 631 15.1. New Flag Of The RP Object 633 A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) is 634 defined in this document. 636 VSPT Flag 637 Bit Number Name Flag Reference 638 7 VSPT This document 640 15.2. New Error-Type And Error-Value 642 A new Error-Type is defined in this document (Error-Type and Error- 643 value to be assigned by IANA). 645 Error-type Meaning Reference 646 13 BRPC procedure completion failure This document 647 Error-value 648 1: BRPC procedure not supported by 649 one a PCE along the domain path 651 15.3. New Flag Of The NO-PATH-VECTOR TLV 653 A new flag of the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep]) 654 is specified in this document. 656 Bit number Meaning Reference 658 4 BRPC Path computation This document 659 chain unavailable 661 16. Security Considerations 663 The BRPC procedure relies on the use of the PCEP protocol and as such 664 is subjected to the potential attacks listed in section 11 of 665 [I-D.ietf-pce-pcep]. In addition to the security mechanisms 666 described in [I-D.ietf-pce-pcep] with regards to spoofing, snooping, 667 falsification and Denial of Service, an implementation MAY support a 668 policy module governing the conditions under which a PCE should 669 participate to the BRPC procedure. 671 The BRPC procedure does not increase the information exchanged 672 between ASes and preserves topology confidentiality, in compliance 673 with [RFC4105] and [RFC4216]. 675 17. Acknowledgements 677 The authors would like to thank Arthi Ayyangar, Dimitri 678 Papadimitriou, Siva Sivabalan, Meral Shirazipour and Mach Chen for 679 their useful comments. A special thank to Adrian Farrel for his 680 useful comments and suggestions. 682 18. References 684 18.1. Normative References 686 [I-D.ietf-pce-pcep] 687 Ayyangar, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, 688 Y., Kumaki, K., Vasseur, J., and J. Roux, "Path 689 Computation Element (PCE) Communication Protocol (PCEP)", 690 draft-ietf-pce-pcep-12 (work in progress), March 2008. 692 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 693 Requirement Levels", BCP 14, RFC 2119, March 1997. 695 18.2. Informative References 697 [I-D.ietf-ccamp-isis-interas-te-extension] 698 Chen, M. and R. Zhang, "ISIS Extensions in Support of 699 Inter-AS Multiprotocol Label Switching (MPLS) and 700 Generalized MPLS (GMPLS) Traffic Engineering", 701 draft-ietf-ccamp-isis-interas-te-extension-00 (work in 702 progress), February 2008. 704 [I-D.ietf-ccamp-ospf-interas-te-extension] 705 Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 706 Support of Inter-AS Multiprotocol Label Switching (MPLS) 707 and Generalized MPLS (GMPLS) Traffic Engineering", 708 draft-ietf-ccamp-ospf-interas-te-extension-02 (work in 709 progress), November 2007. 711 [I-D.ietf-pce-manageability-requirements] 712 Farrel, A., "Inclusion of Manageability Sections in PCE 713 Working Group Drafts", 714 draft-ietf-pce-manageability-requirements-03 (work in 715 progress), February 2008. 717 [I-D.ietf-pce-monitoring] 718 Vasseur, J., Roux, J., and Y. Ikejiri, "A set of 719 monitoring tools for Path Computation Element based 720 Architecture", draft-ietf-pce-monitoring-01 (work in 721 progress), February 2008. 723 [I-D.ietf-pce-path-key] 724 Bradford, R. and J. Vasseur, "Preserving Topology 725 Confidentiality in Inter-Domain Path Computation Using a 726 Key-Based Mechanism", draft-ietf-pce-path-key-02 (work in 727 progress), February 2008. 729 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 730 McManus, "Requirements for Traffic Engineering Over MPLS", 731 RFC 2702, September 1999. 733 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 734 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 736 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 737 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 738 November 2005. 740 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 741 Element (PCE)-Based Architecture", RFC 4655, August 2006. 743 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 744 Inter-Domain Multiprotocol Label Switching Traffic 745 Engineering", RFC 4726, November 2006. 747 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 748 "OSPF Protocol Extensions for Path Computation Element 749 (PCE) Discovery", RFC 5088, January 2008. 751 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 752 "IS-IS Protocol Extensions for Path Computation Element 753 (PCE) Discovery", RFC 5089, January 2008. 755 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 756 Path Computation Method for Establishing Inter-Domain 757 Traffic Engineering (TE) Label Switched Paths (LSPs)", 758 RFC 5152, February 2008. 760 Authors' Addresses 762 JP Vasseur (editor) 763 Cisco Systems, Inc 764 1414 Massachusetts Avenue 765 Boxborough, MA 01719 766 USA 768 Email: jpv@cisco.com 770 Raymond Zhang 771 BT Infonet 772 2160 E. Grand Ave. 773 El Segundo, CA 90025 774 USA 776 Email: raymond_zhang@bt.infonet.com 778 Nabil Bitar 779 Verizon 780 40 Sylvan Road 781 Waltham, MA 02145 782 USA 784 Email: nabil.bitar@verizon.com 786 JL Le Roux 787 France Telecom 788 2, Avenue Pierre-Marzin 789 Lannion, 22307 790 FRANCE 792 Email: jeanlouis.leroux@orange-ft.com 794 Full Copyright Statement 796 Copyright (C) The IETF Trust (2008). 798 This document is subject to the rights, licenses and restrictions 799 contained in BCP 78, and except as set forth therein, the authors 800 retain all their rights. 802 This document and the information contained herein are provided on an 803 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 804 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 805 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 806 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 807 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 808 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 810 Intellectual Property 812 The IETF takes no position regarding the validity or scope of any 813 Intellectual Property Rights or other rights that might be claimed to 814 pertain to the implementation or use of the technology described in 815 this document or the extent to which any license under such rights 816 might or might not be available; nor does it represent that it has 817 made any independent effort to identify any such rights. Information 818 on the procedures with respect to rights in RFC documents can be 819 found in BCP 78 and BCP 79. 821 Copies of IPR disclosures made to the IETF Secretariat and any 822 assurances of licenses to be made available, or the result of an 823 attempt made to obtain a general license or permission for the use of 824 such proprietary rights by implementers or users of this 825 specification can be obtained from the IETF on-line IPR repository at 826 http://www.ietf.org/ipr. 828 The IETF invites any interested party to bring to its attention any 829 copyrights, patents or patent applications, or other proprietary 830 rights that may cover technology that may be required to implement 831 this standard. Please address the information to the IETF at 832 ietf-ipr@ietf.org.