idnits 2.17.1 draft-ietf-pce-brpc-09.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 812. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 823. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 830. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 836. 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 (April 14, 2008) is 5855 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-02 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-ospf-interas-te-extension-05 == 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 16, 2008 BT Infonet 5 N. Bitar 6 Verizon 7 JL. Le Roux 8 France Telecom 9 April 14, 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-09.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 16, 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 . . . . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . 13 81 12. Path Computation Failure . . . . . . . . . . . . . . . . . . . 13 82 13. Metric Normalization . . . . . . . . . . . . . . . . . . . . . 13 83 14. Manageability Considerations . . . . . . . . . . . . . . . . . 14 84 14.1. Control of Function And Policy . . . . . . . . . . . . . . 14 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 . . . . . . . . . . . . . . . . . . . . . . . . 15 90 14.6. Impact on Network Operation . . . . . . . . . . . . . . . 15 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 . . . . . . . . . . . . 16 96 16. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 17. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16 98 18. References . . . . . . . . . . . . . . . . . . . . . . . . . . 16 99 18.1. Normative References . . . . . . . . . . . . . . . . . . . 16 100 18.2. Informative References . . . . . . . . . . . . . . . . . . 17 101 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 18 102 Intellectual Property and Copyright Statements . . . . . . . . . . 20 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 A PCE that can compute the requested path for more than one 350 consecutive domain on the path SHOULD perform this computation for 351 all such domains before passing the PCRep to the previous PCE in the 352 sequence. 354 BRPC guarantees to find the optimal (shortest) constrained inter- 355 domain TE LSP according to a set of defined domains to be traversed. 356 Note that other variants of the BRPC procedure relying on the same 357 principles are also possible. 359 Note also that in case of ECMP paths, more than one path could be 360 returned to the requesting LSR. 362 5. PCEP Protocol Extensions 364 The BRPC procedure requires the specification of a new flag of the RP 365 object carried within the PCReq message (defined in 366 [I-D.ietf-pce-pcep]) to specify that the shortest paths satisfying 367 the constraints from the destination to the set of entry boundary 368 nodes are requested (such set of paths forms the downstream VSPT as 369 specified in Section 4.2). 371 The following new flag of the RP object is defined: 373 VSPT Flag 374 Bit Number Name Flag 375 7 VSPT 377 When set, the VSPT Flag indicates that the PCC requests the 378 computation of an inter-domain TE LSP using the BRPC procedure 379 defined in this document. 381 Because path segments computed by a downstream PCE in the context of 382 the BRPC procedure MUST be provided along with their respective path 383 costs, the C flag of the METRIC object carried within the PCReq 384 message MUST be set. It is the choice of the requester to 385 appropriately set the O bit of the RP object. 387 6. VSPT Encoding 389 The VSPT is returned within a PCRep message. The encoding consists 390 of a non-ordered lists of EROs where each ERO represents a path 391 segment from a BN to the destination specified in the END-POINT 392 object of the corresponding PCReq message. 394 Example: 396 <---- area 1 ----><---- area 0 -----><------ area 2 ------> 397 ABR1-A-B-+ 398 | | 399 ABR2-----D 400 | | 401 ABR3--C--+ 403 Figure 2 - An Example of VPST Encoding Using a Set of EROs 405 In the simple example shown in figure 2, if we make the assumption 406 that a constrained path exists between each ABR and the destination 407 D, the VSPT computed by a PCE serving area 2 consists of the 408 following non-ordered set of EROs: 410 o ERO1: ABR1(TE Router ID)-A(Interface IP address)-B(Interface IP 411 address)-D(TE Router ID) 413 o ERO2: ABR2(TE Router ID)-D(TE Router ID) 415 o ERO3: ABR3(TE Router ID)-C(interface IP adress)-D(TE Router ID) 417 The PCReq message, PCRep message, PCEP END-POINT and ERO objects are 418 defined in [I-D.ietf-pce-pcep] 420 7. Inter-AS TE Links 422 In the case of Inter-AS TE LSP path computation, the BRPC procedure 423 requires the knowledge of the traffic engineering attributes of the 424 Inter-AS TE links: the process by which the PCE acquires this 425 information is out of the scope of the BRPC procedure, which is 426 compliant with the PCE architecture defined in [RFC4655]. 428 That said, a straightforward solution consists of allowing the ASBRs 429 to flood the TE information related to the inter-ASBR links although 430 no IGP TE is enabled over those links (there is no IGP adjacency over 431 the inter-ASBR links). This allows the PCE of a domain to get entire 432 TE visibility up to the set of entry ASBRs in the downstream domain 433 (see the IGP extensions defined in 434 [I-D.ietf-ccamp-isis-interas-te-extension] and 435 [I-D.ietf-ccamp-ospf-interas-te-extension]). 437 8. Usage In Conjunction With Per-domain Path Computation 439 The BRPC procedure may be used to compute path segments in 440 conjunction with other path computation techniques (such as the per- 441 domain path computation technique defined in [RFC5152]) to compute 442 the end-to-end path. In this case end-to-end path optimality can no 443 longer be guaranteed. 445 9. BRPC Procedure Completion Failure 447 If the BRPC procedure cannot be completed because a PCE along the 448 domain does not recognize the procedure (VSPT flag of the RP object), 449 as stated in [I-D.ietf-pce-pcep], the PCE sends a PCErr message to 450 the upstream PCE with an Error-Type=4 (not supported object), Error- 451 value-4 (Unsupported paramater). The PCE may include the parent 452 object (RP object) up to and including (but no further than) the 453 unknown or unsupported parameter. In this case where the unknown or 454 unsupported parameter is a bit flag (VSPT flag), the included RP 455 object should contain the whole bit flag field with all bits after 456 the parameter at issue set to zero. The corresponding path 457 computation request is then cancelled by the PCE without further 458 notification. 460 If the BRPC procedure cannot be completed because a PCE along the 461 domain path recognises but does not support the procedure, it MUST 462 return a PCErr message to the upstream PCE with an Error-Type "BRPC 463 procedure completion failure". 465 The PCErr message MUST be relayed to the requesting PCC. 467 PCEP-ERROR objects are used to report a PCEP protocol error and are 468 characterized by an Error-Type which specifies the type of error and 469 an Error-value that provides additional information about the error 470 type. Both the Error-Type and the Error-Value are managed by IANA. 471 A new Error-Type is defined that relates to the BRPC procedure. 473 Error-type Meaning 474 13 BRPC procedure completion failure 475 Error-value 476 1: BRPC procedure not supported by one or more PCEs 477 along the domain path 479 10. Applicability 481 As discussed in Section 3, the requirements for inter-area and 482 inter-AS MPLS Traffic Engineering have been developed by the Traffic 483 Engineering Working Group (TE WG) and have been stated in [RFC4105] 484 and [RFC4216], respectively. Among the set of requirements, both 485 documents indicate the need for some solution providing the ability 486 to compute an optimal (shortest) constrained inter-domain TE LSP and 487 to compute a set of diverse inter-domain TE LSPs. 489 10.1. Diverse end-to-end path computation 491 PCEP (see [I-D.ietf-pce-pcep]) allows a PCC to request the 492 computation of a set of diverse TE LSPs thanks to the SVEC object by 493 setting the flags L, N or S to request link, node or SRLG diversity 494 respectively. Such requests MUST be taken into account by each PCE 495 along the path computation chain during the VSPT computation. In the 496 context of the BRPC procedure, a set of diversely routed TE LSPs 497 between two LSRs can be computed since the paths segments of the VSPT 498 are simultaneously computed by a given PCE. The BRPC procedure 499 allows for the computation of diverse paths under various objective 500 functions (such as minimizing the sum of the costs of the N diverse 501 paths, etc). 503 By constrast, with a 2-step approach consisting of computing the 504 first path followed by the computation of the second path after 505 having removed the set of network elements traversed by the first 506 path (if that does not violate confidentiality preservation), one 507 cannot guarantee that a solution will be found even if such solution 508 exists. Furthermore, even if a solution is found, it may not be the 509 most optimal one with respect to an objective function such as 510 minimizing the sum of the paths costs, bounding the path delays of 511 both paths and so on. Finally, it must be noted that such a 2-step 512 path computation approach is usually less efficient in term of 513 signalling delays since it requires two serialized TE LSP set up. 515 10.2. Path Optimality 517 BRPC guarantees that the optimal (shortest) constrained inter-domain 518 path will always be found subject to policy constraints. When 519 combined with other local path computation techniques (e.g. in the 520 case of stitched/nested TE LSP) and in the case where a domain has 521 more than one BN-en or more than one BN-ex, optimality after some 522 network change within the domain can only be guaranteed by re- 523 executing the BRPC procedure. 525 11. Reoptimization Of An Inter-domain TE LSP 527 The ability to reoptimize an existing inter-domain TE LSP path has 528 been explicitly listed as a requirement in [RFC4105] and [RFC4216]. 529 In the case of a TE LSP reoptimization request, the reoptimization 530 procedure defined in [I-D.ietf-pce-pcep] applies where the path in 531 use (if available on the head-end) is provided as part of the path 532 computation request in order for the PCEs involved in the 533 reoptimization request to avoid double bandwidth accounting. 535 12. Path Computation Failure 537 If a PCE requires to relay a path computation request according to 538 the BRPC procedure defined in this document to a downstream PCE and 539 no such PCE is available, the PCE MUST send a negative path 540 computation reply to the requester using a PCReq message as specified 541 in [I-D.ietf-pce-pcep] that contains a NO-PATH object. In such case, 542 the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in 543 [I-D.ietf-pce-pcep]) with the newly defined bit named "BRPC Path 544 Computation chain unavailable" set. 546 Bit number Name Flag 547 4 BRPC Path computation chain unavailable 549 13. Metric Normalization 551 In the case of inter-area TE, the same IGP/TE metric scheme is 552 usually adopted for all the IGP areas (e.g., based on the link-speed, 553 propagation delay or some other combination of link attributes). 554 Hence, the proposed set of mechanisms always computes the shortest 555 path across multiple areas obeying the required set of constraints 556 with respect to a specified objective function. Conversely, in the 557 case of Inter-AS TE, in order for this path computation to be 558 meaningful, metric normalization between ASes may be required. One 559 solution to avoid IGP metric modification would be for the Service 560 Providers to agree on a TE metric normalization scheme and use the TE 561 metric for TE LSP path computation (in that case, this must be 562 requested in the PCEP Path computation request) using the METRIC 563 object (defined in [I-D.ietf-pce-pcep]). 565 14. Manageability Considerations 567 This section follows the guidance of 568 [I-D.ietf-pce-manageability-requirements]. 570 14.1. Control of Function And Policy 572 The only configurable item is the support of the BRPC procedure on a 573 PCE. The support of the BRPC procedure by the PCE MAY be controlled 574 by a policy module governing the conditions under which a PCE should 575 participate to the BRPC procedure (origin of the requests, number of 576 requests per second, ...). If the BRPC is not supported/allowed on a 577 PCE, it MUST send a PCErr message as specified in Section 9. 579 14.2. Information And Data Models 581 A BRPC MIB module will be specified in a separate document. 583 14.3. Liveness Detection and Monitoring 585 The BRPC procedure is a Multiple-PCE path computation technique and 586 as such a set of PCEs are involved in the path computation chain. If 587 the path computation chain is not operational either because at least 588 one PCE does not support the BRPC procedure or because one of the 589 PCEs that must be involved in the path computation chain is not 590 available, procedures are defined to report such failures in 591 Section 9 and Section 12 respectively. Furthermore, a built-in 592 diagnostic tool to check the availability and performances of a PCE 593 chain is defined in [I-D.ietf-pce-monitoring]. 595 14.4. Verifying Correct Operation 597 Verifying the correct operation of BRPC can be performed by 598 monitoring a set of parameters. A BRPC implementation SHOULD provide 599 the following parameters: 601 o Number of successful BRPC Procedure completions on a per PCE peer 602 basis, 604 o Number of BRPC procedure completion failures because the VSPT flag 605 was not recognized (on a per PCE peer basis), 607 o Number of BRPC procedure completetion failures because the BRPC 608 procedure was not supported (on a per PCE peer basis), 610 14.5. Requirements on Other Protocols and Functional Components 612 The BRPC procedure does not put any new requirements on other 613 protocol. That said, since the BRPC procedure relies on the PCEP 614 protocol, there is a dependency between BRPC and PCEP; consequently 615 the BRPC procedure inherently makes use of the management functions 616 developed for PCEP. 618 14.6. Impact on Network Operation 620 The BRPC procedure does not have any significant impact on network 621 operation: indeed, BRPC is a Multiple-PCE path computation scheme as 622 defined in [RFC4655] and does not differ from any other path 623 computation request. 625 14.7. Path Computation Chain Monitoring 627 [I-D.ietf-pce-monitoring] specifies a set of mechanisms that can be 628 used to gather PCE state metrics. Because BRPC is a Multiple-PCE 629 path computation techniques, such mechanism could be advantageously 630 used in the context of the BRPC procedure to check the liveness of 631 the path computation chain, locate a faulty component, monitor the 632 overall performance and so on. 634 15. IANA Considerations 636 15.1. New Flag Of The RP Object 638 A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) is 639 defined in this document. 641 VSPT Flag 642 Bit Number Name Flag Reference 643 7 VSPT This document 645 15.2. New Error-Type And Error-Value 647 A new Error-Type is defined in this document (Error-Type and Error- 648 value to be assigned by IANA). 650 Error-type Meaning Reference 651 13 BRPC procedure completion failure This document 652 Error-value 653 1: BRPC procedure not supported by 654 one a PCE along the domain path 656 15.3. New Flag Of The NO-PATH-VECTOR TLV 658 A new flag of the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep]) 659 is specified in this document. 661 Bit number Meaning Reference 663 4 BRPC Path computation This document 664 chain unavailable 666 16. Security Considerations 668 The BRPC procedure relies on the use of the PCEP protocol and as such 669 is subjected to the potential attacks listed in section 11 of 670 [I-D.ietf-pce-pcep]. In addition to the security mechanisms 671 described in [I-D.ietf-pce-pcep] with regards to spoofing, snooping, 672 falsification and Denial of Service, an implementation MAY support a 673 policy module governing the conditions under which a PCE should 674 participate to the BRPC procedure. 676 The BRPC procedure does not increase the information exchanged 677 between ASes and preserves topology confidentiality, in compliance 678 with [RFC4105] and [RFC4216]. 680 17. Acknowledgements 682 The authors would like to thank Arthi Ayyangar, Dimitri 683 Papadimitriou, Siva Sivabalan, Meral Shirazipour and Mach Chen for 684 their useful comments. A special thank to Adrian Farrel for his 685 useful comments and suggestions. 687 18. References 689 18.1. Normative References 691 [I-D.ietf-pce-pcep] 692 Ayyangar, A., Oki, E., Atlas, A., Dolganow, A., Ikejiri, 693 Y., Kumaki, K., Vasseur, J., and J. Roux, "Path 694 Computation Element (PCE) Communication Protocol (PCEP)", 695 draft-ietf-pce-pcep-12 (work in progress), March 2008. 697 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 698 Requirement Levels", BCP 14, RFC 2119, March 1997. 700 18.2. Informative References 702 [I-D.ietf-ccamp-isis-interas-te-extension] 703 Chen, M., Zhang, R., and X. Duan, "ISIS Extensions in 704 Support of Inter-AS Multiprotocol Label Switching (MPLS) 705 and Generalized MPLS (GMPLS) Traffic Engineering", 706 draft-ietf-ccamp-isis-interas-te-extension-02 (work in 707 progress), April 2008. 709 [I-D.ietf-ccamp-ospf-interas-te-extension] 710 Chen, M., Zhang, R., and X. Duan, "OSPF Extensions in 711 Support of Inter-AS Multiprotocol Label Switching (MPLS) 712 and Generalized MPLS (GMPLS) Traffic Engineering", 713 draft-ietf-ccamp-ospf-interas-te-extension-05 (work in 714 progress), April 2008. 716 [I-D.ietf-pce-manageability-requirements] 717 Farrel, A., "Inclusion of Manageability Sections in PCE 718 Working Group Drafts", 719 draft-ietf-pce-manageability-requirements-03 (work in 720 progress), February 2008. 722 [I-D.ietf-pce-monitoring] 723 Vasseur, J., Roux, J., and Y. Ikejiri, "A set of 724 monitoring tools for Path Computation Element based 725 Architecture", draft-ietf-pce-monitoring-01 (work in 726 progress), February 2008. 728 [I-D.ietf-pce-path-key] 729 Bradford, R. and J. Vasseur, "Preserving Topology 730 Confidentiality in Inter-Domain Path Computation Using a 731 Key-Based Mechanism", draft-ietf-pce-path-key-02 (work in 732 progress), February 2008. 734 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 735 McManus, "Requirements for Traffic Engineering Over MPLS", 736 RFC 2702, September 1999. 738 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 739 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 741 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 742 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 743 November 2005. 745 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 746 Element (PCE)-Based Architecture", RFC 4655, August 2006. 748 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 749 Inter-Domain Multiprotocol Label Switching Traffic 750 Engineering", RFC 4726, November 2006. 752 [RFC5088] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 753 "OSPF Protocol Extensions for Path Computation Element 754 (PCE) Discovery", RFC 5088, January 2008. 756 [RFC5089] Le Roux, JL., Vasseur, JP., Ikejiri, Y., and R. Zhang, 757 "IS-IS Protocol Extensions for Path Computation Element 758 (PCE) Discovery", RFC 5089, January 2008. 760 [RFC5152] Vasseur, JP., Ayyangar, A., and R. Zhang, "A Per-Domain 761 Path Computation Method for Establishing Inter-Domain 762 Traffic Engineering (TE) Label Switched Paths (LSPs)", 763 RFC 5152, February 2008. 765 Authors' Addresses 767 JP Vasseur (editor) 768 Cisco Systems, Inc 769 1414 Massachusetts Avenue 770 Boxborough, MA 01719 771 USA 773 Email: jpv@cisco.com 775 Raymond Zhang 776 BT Infonet 777 2160 E. Grand Ave. 778 El Segundo, CA 90025 779 USA 781 Email: raymond_zhang@bt.infonet.com 782 Nabil Bitar 783 Verizon 784 40 Sylvan Road 785 Waltham, MA 02145 786 USA 788 Email: nabil.bitar@verizon.com 790 JL Le Roux 791 France Telecom 792 2, Avenue Pierre-Marzin 793 Lannion, 22307 794 FRANCE 796 Email: jeanlouis.leroux@orange-ft.com 798 Full Copyright Statement 800 Copyright (C) The IETF Trust (2008). 802 This document is subject to the rights, licenses and restrictions 803 contained in BCP 78, and except as set forth therein, the authors 804 retain all their rights. 806 This document and the information contained herein are provided on an 807 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 808 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 809 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 810 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 811 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 812 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 814 Intellectual Property 816 The IETF takes no position regarding the validity or scope of any 817 Intellectual Property Rights or other rights that might be claimed to 818 pertain to the implementation or use of the technology described in 819 this document or the extent to which any license under such rights 820 might or might not be available; nor does it represent that it has 821 made any independent effort to identify any such rights. Information 822 on the procedures with respect to rights in RFC documents can be 823 found in BCP 78 and BCP 79. 825 Copies of IPR disclosures made to the IETF Secretariat and any 826 assurances of licenses to be made available, or the result of an 827 attempt made to obtain a general license or permission for the use of 828 such proprietary rights by implementers or users of this 829 specification can be obtained from the IETF on-line IPR repository at 830 http://www.ietf.org/ipr. 832 The IETF invites any interested party to bring to its attention any 833 copyrights, patents or patent applications, or other proprietary 834 rights that may cover technology that may be required to implement 835 this standard. Please address the information to the IETF at 836 ietf-ipr@ietf.org.