idnits 2.17.1 draft-ietf-pce-brpc-05.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 733. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 744. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 751. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 757. 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 are 2 instances of too long lines in the document, the longest one being 8 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 (June 18, 2007) is 6147 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 633, but no explicit reference was found in the text == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-07 ** Downref: Normative reference to an Informational RFC: RFC 4655 == Outdated reference: A later version (-06) exists of draft-ietf-ccamp-inter-domain-pd-path-comp-05 == Outdated reference: A later version (-07) exists of draft-ietf-ccamp-inter-domain-rsvp-te-06 == Outdated reference: A later version (-08) exists of draft-ietf-pce-disco-proto-isis-05 == Outdated reference: A later version (-08) exists of draft-ietf-pce-disco-proto-ospf-05 == Outdated reference: A later version (-11) exists of draft-ietf-pce-manageability-requirements-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: December 20, 2007 BT Infonet 5 N. Bitar 6 Verizon 7 JL. Le Roux 8 France Telecom 9 June 18, 2007 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-05.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 December 20, 2007. 40 Copyright Notice 42 Copyright (C) The IETF Trust (2007). 44 Abstract 46 The ability to compute shortest constrained Traffic Engineering (TE) 47 Label Switched Paths (LSPs) in Multiprotocol Label Switching (MPLS) 48 and Generalized MPLS (GMPLS) networks across multiple domains (where 49 a domain is referred to as a collection of network elements within a 50 common sphere of address management or path computational 51 responsibility such as IGP areas and Autonomous Systems) has been 52 identified as a key requirement . This document specifies a 53 procedure relying on the use of multiple Path Computation Elements 54 (PCEs) in order to compute such inter-domain shortest constrained 55 paths along a determined sequence of domains, using a backward 56 recursive path computation technique while preserving confidentiality 57 across domains, which is sometimes required when domains are managed 58 by different Service Providers. 60 Requirements Language 62 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 63 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 64 document are to be interpreted as described in RFC 2119 [RFC2119]. 66 Table of Contents 68 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 3. General assumptions . . . . . . . . . . . . . . . . . . . . . 5 71 4. BRPC Procedure . . . . . . . . . . . . . . . . . . . . . . . . 6 72 4.1. Domain path selection . . . . . . . . . . . . . . . . . . 6 73 4.2. Mode of Operation . . . . . . . . . . . . . . . . . . . . 7 74 5. PCEP Protocol Extensions . . . . . . . . . . . . . . . . . . . 9 75 6. Inter-AS TE Links . . . . . . . . . . . . . . . . . . . . . . 9 76 7. Usage in conjunction with per-domain path computation . . . . 9 77 8. BRPC procedure completion failure . . . . . . . . . . . . . . 10 78 9. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 10 79 9.1. Diverse end-to-end path computation . . . . . . . . . . . 10 80 9.2. Path optimality . . . . . . . . . . . . . . . . . . . . . 11 81 10. Reoptimization of an inter-domain TE LSP . . . . . . . . . . . 11 82 11. Path Computation failure . . . . . . . . . . . . . . . . . . . 11 83 12. Metric normalization . . . . . . . . . . . . . . . . . . . . . 11 84 13. Manageability Considerations . . . . . . . . . . . . . . . . . 12 85 13.1. Control of Function and Policy . . . . . . . . . . . . . . 12 86 13.2. Information and Data Models . . . . . . . . . . . . . . . 12 87 13.3. Liveness Detection and Monitoring . . . . . . . . . . . . 12 88 13.4. Verifying Correct Operation . . . . . . . . . . . . . . . 12 89 13.5. Requirements on Other Protocols and Functional 90 Components . . . . . . . . . . . . . . . . . . . . . . . . 13 91 13.6. Impact on Network Operation . . . . . . . . . . . . . . . 13 92 13.7. Path computation chain monitoring . . . . . . . . . . . . 13 93 14. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 13 94 14.1. New flag of the RP object . . . . . . . . . . . . . . . . 13 95 14.2. New flag of the NO-PATH-VECTOR TLV . . . . . . . . . . . . 14 96 15. Security Considerations . . . . . . . . . . . . . . . . . . . 14 97 16. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 14 98 17. References . . . . . . . . . . . . . . . . . . . . . . . . . . 14 99 17.1. Normative References . . . . . . . . . . . . . . . . . . . 14 100 17.2. Informative References . . . . . . . . . . . . . . . . . . 15 101 Appendix A. Proposed Status and Discussion [To Be Removed 102 Upon Publication] . . . . . . . . . . . . . . . . . . 16 103 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 104 Intellectual Property and Copyright Statements . . . . . . . . . . 18 106 1. Terminology 108 ABR: routers used to connect two IGP areas (areas in OSPF or levels 109 in IS-IS). 111 ASBR: routers used to connect together ASes of the same or different 112 Service Provider(s) via one or more Inter-AS links. 114 Boundary Node (BN): a boundary node is either an ABR in the context 115 of inter-area Traffic Engineering or an ASBR in the context of 116 inter-AS Traffic Engineering. 118 Entry BN of domain(n): a BN connecting domain(n-1) to domain(n) along 119 a determined sequence of domains. 121 Exit BN of domain(n): a BN connecting domain(n) to domain(n+1) along 122 a determined sequence of domains. 124 Inter-AS TE LSP: A TE LSP that crosses an AS boundary. 126 Inter-area TE LSP: A TE LSP that crosses an IGP area boundary. 128 LSR: Label Switching Router. 130 LSP: Label Switched Path. 132 PCC: Path Computation Client. Any client application requesting a 133 path computation to be performed by the Path Computation Element. 135 PCE (Path Computation Element): an entity (component, application or 136 network node) that is capable of computing a network path or route 137 based on a network graph and applying computational constraints. 139 PCE(i) is a PCE with the scope of domain(i). 141 TED: Traffic Engineering Database. 143 VSPT: Virtual Shortest Path Tree. 145 The notion of contiguous, stitched and nested TE LSPs is defined in 146 [RFC4726] and will not be repeated here. 148 2. Introduction 150 The requirements for inter-area and inter-AS MPLS Traffic Engineering 151 have been developed by the Traffic Engineering Working Group (TE WG) 152 and have been stated in [RFC4105] and [RFC4216], respectively. 154 The framework for inter-domain MPLS Traffic Engineering has been 155 provided in [RFC4726]. 157 [I-D.ietf-ccamp-inter-domain-pd-path-comp] defines a technique for 158 establishing inter-domain (G)MPLS TE LSP whereby the path is computed 159 during the signalling process on a per-domain basis by the entry 160 boundary node of each domain (each node in charge of computing a 161 section of an inter-domain TE LSP path is always along the path of 162 such TE LSP). Such path computation technique fulfills some of the 163 requirements stated in [RFC4105] and [RFC4216] but not all of them. 164 In particular, it cannot guarantee to find an optimal (shortest) 165 inter-domain constrained path. Furthermore, it cannot be efficiently 166 used to compute a set of inter-domain diversely routed TE LSPs. 168 The PCE architecture is defined in [RFC4655]. The aim of this 169 document is to describe a PCE-based TE LSP computation procedure to 170 compute optimal inter-domain constrained (G)MPLS TE LSPs. 172 Qualifying a path as optimal requires some clarification. Indeed, a 173 globally optimal TE LSP placement usually refers to a set of TE LSPs 174 whose placements optimize the network resources with regards to a 175 specified objective function (e.g. a placement that reduces the 176 maximum or average network load while satisfying the TE LSP 177 constraints). In this document, an optimal inter-domain constrained 178 TE LSP is defined as the shortest path satisfying the set of required 179 constraints that would be obtained in the absence of multiple domains 180 (in other words, in a totally flat IGP network between the source and 181 destination of the TE LSP). 183 3. General assumptions 185 In the rest of this document, we make the following set of 186 assumptions common to inter-area and inter-AS MPLS TE: 188 - Each IGP area or AS is assumed to be Traffic Engineering enabled 189 (i.e. running OSPF-TE or ISIS-TE and RSVP-TE). 191 - No topology or resource information is distributed between domains 192 (as mandated per [RFC4105] and [RFC4216]), which is critical to 193 preserve IGP/BGP scalability and confidentiality. 195 - While certain constraints like bandwidth can be used across 196 different domains, other TE constraints like resource affinity, 197 color, metric, etc. as listed in [RFC2702] could be translated at 198 domain boundaries. If required, it is assumed that, at the domain 199 boundary nodes, there will exist some sort of local mapping based on 200 policy agreement, in order to translate such constraints across 201 domain boundaries during the inter-PCE communication process. 203 - Each AS can be made of several IGP areas. The path computation 204 procedure described in this document applies to the case of a single 205 AS made of multiple IGP areas, multiple ASes made of a single IGP 206 area or any combination of the above. For the sake of simplicity, 207 each AS will be considered to be made of a single area in this 208 document. The case of an Inter-AS TE LSP spanning multiple ASes 209 where some of those ASes are themselves made of multiple IGP areas 210 can be easily derived from this case by applying the BRPC procedure 211 described in this document, recursively. 213 - The domain path (set of domains traversed to reach the destination 214 domain) is either administratively pre-determined or discovered by 215 some means that are outside of the scope of this document. 217 4. BRPC Procedure 219 The BRPC procedure is a Multiple-PCE path computation technique as 220 described in [RFC4655]. A possible model consists of hosting the PCE 221 function on boundary nodes (e.g., ABR or ASBR) but this is not 222 mandated by the BRPC procedure. 224 The BRPC procedure does not make any assumptions with regards to the 225 nature of the inter-domain TE LSP that could be contiguous, nested or 226 stitched. 228 Furthermore, no assumption is made on the actual path computation 229 algorithm in use by a PCE (it can be any variant of CSPF, algorithm 230 based on linear-programming to solve multi-constraints optimization 231 problems and so on). 233 4.1. Domain path selection 235 The PCE-based BRPC procedure applies to the computation of an optimal 236 constrained inter-domain TE LSP. The sequence of domains to be 237 traversed can either be determined a priori or during the path 238 computation procedure. The BRPC procedure guarantees to compute the 239 optimal path across a specific sequence of traversed domains (which 240 constitutes an additional constraint). In the case of an arbitrary 241 set of meshed domains, the BRPC procedure can be used to compute the 242 optimal path across each domain set in order to get the optimal 243 constrained path between the source and the destination of the TE 244 LSP. The BRPC procedure can also be used across a subset of all 245 domain sequences, and the best path among these sequences is then 246 selected. 248 4.2. Mode of Operation 250 Definition of VSPT(i) 252 In each domain i: 254 * There is a set of X-en(i) entry BNs noted BN-en(k,i) where BN- 255 en(k,i) is the kth entry BN of domain(i). 257 * There is a set of X-ex(i) exit BNs noted BN-ex(k,i) where BN- 258 ex(k,i) is the kth exit BN of domain(i). 260 VSPT(i): MP2P (MultiPoint To Point) tree returned by PCE(i) to 261 PCE(i-1): 263 Root (TE LSP destination) 264 / I \ 265 BN-en(1,i) BN-en(2,i) ... BN-en((j), i). 267 Where [X-en(i)] is the number of entry BN in domain i 268 and j<= [X-en(i)] 270 Each link of tree VSPT(i) represents the shortest path between BN- 271 en(j,i) (identified by its TE Router-ID) and the destination that 272 satisfies the set of required constraints for the TE LSP (bandwidth, 273 affinities, ...). These are path segments to reach the destination 274 from BN-en(j,i). 276 Note that PCE(i) only considers the entry BNs that provide 277 connectivity from domain(i-1). That is, the set BN-en(k,i-1) is only 278 made of those BNs that provide connectivity from domain (i-1) to 279 domain(i). Furthermore, some BNs may be excluded according to policy 280 constraints (either due to local policy or policies signaled in the 281 path computation request). 283 Step 1: the PCC needs to first determine the PCE capable of serving 284 its path computation request (this can be done thanks to local 285 configuration or via IGP discovery (see 286 [I-D.ietf-pce-disco-proto-ospf] and 287 [I-D.ietf-pce-disco-proto-isis])). The path computation request is 288 then relayed until reaching a PCE(n) such that the TE LSP destination 289 resides in the domain(n). At each step of the process, the next PCE 290 can either be statically configured or dynamically discovered via 291 IGP/BGP extensions. If no next PCE can be found or the next hop PCE 292 of choice is unavailable, the procedure stops and a path computation 293 error is returned (see Section 8). If multiple PCEs are discovered, 294 the PCE may select a subset of these PCEs based on some local 295 policies or heuristics. Note also that a sequence of PCEs might be 296 enforced by policy on the PCC and this constraint can be carried in 297 the PCEP path computation request (as defined in 298 [I-D.vasseur-pce-monitoring]). 300 Step 2: PCE(n) computes VSPT(n) made of the list of shortest 301 constrained path(s) between every BN-en(j,n) and the TE LSP 302 destination using a suitable path computation algorithm (e.g. CSPF) 303 and returns the computed VSPT(n) to PCE(n-1). 305 Step i: 307 - For i=n-1 to 2: PCE(i) concatenates the topology of domain(i) 308 (using its TED) with the received VSPT(i+1). In the case of Inter-AS 309 TE LSP computation, this requires to also add the inter-AS TE links 310 connecting the domain(i) to the domain(i+1). Then PCE(i) computes 311 VSPT(i) (MP2P (Multi-Point to Point) tree made of the shortest 312 constrained paths between each BN-en(j,i) and the TE LSP 313 destination). 315 End 317 Finally PCE(1) computes the end-to-end shortest constrained path from 318 the source to the destination and returns the corresponding path to 319 the requesting PCC in the form of a PCRep message as defined in 320 [I-D.ietf-pce-pcep]. 322 Each branch of the VSPT tree (path) may be returned in the form of an 323 explicit path (in which case all the hops along the path segment are 324 listed) or a loose path (in which case only the BR is specified) so 325 as to preserve confidentiality along with the respective cost. In 326 the later case, various techniques can be used in order to retrieve 327 the computed explicit paths on a per domain basis during the 328 signaling process thanks to the use of path keys as described in 329 [I-D.bradford-pce-path-key]. 331 BRPC guarantees to find the optimal (shortest) constrained inter- 332 domain TE LSP according to a set of defined domains to be traversed. 333 Note that other variants of the BRPC procedure relying on the same 334 principles are also possible. 336 Note also that in case of ECMP paths, more than one path could be 337 returned to the requesting LSR. 339 5. PCEP Protocol Extensions 341 The BRPC procedure requires the specification of a new flag of the RP 342 object carried within the PCReq message (defined in 343 [I-D.ietf-pce-pcep]), the aim of which is to specify that the 344 shortest path(s) satisfying the constraints from the destination to 345 the set of entry boundary nodes are requested (such set of path(s) 346 forms the downstream VSPT as specified in Section 4.2). 348 The following new flag of the RP object is defined: VSPT (V) flag: 349 0x60. When set, this indicates that the PCC requests the computation 350 of an inter-domain TE LSP using the BRPC procedure. 352 Because path segment(s) computed by a downstream PCE in the context 353 of the BRPC procedure must be provided along with their respective 354 path cost(s), the C flag of the METRIC object carried within the 355 PCReq message MUST be set. It is the choice of the requester to 356 appropriately set the O bit of the RP object. 358 6. Inter-AS TE Links 360 In the case of Inter-AS TE LSP path computation, the BRPC procedure 361 requires the knowledge of the traffic engineering attributes of the 362 Inter-AS TE links: the process by which the PCE acquires this 363 information is out of the scope of the BRPC procedure (which is 364 compliant with the PCE architecture defined in [RFC4655]). 366 That said, a straightforward solution consists of allowing the ASBRs 367 to flood the TE information related to the inter-ASBR link(s) 368 although no IGP TE is enabled over those links (there is no IGP 369 adjacency over the inter-ASBR links). This allows the PCE of a 370 domain to get entire TE visibility up to the set of entry ASBRs in 371 the downstream domain. 373 7. Usage in conjunction with per-domain path computation 375 The BRPC procedure may be used to compute path segments in 376 conjunction with other path computation techniques (such as the per- 377 domain path computation technique defined in 378 [I-D.ietf-ccamp-inter-domain-pd-path-comp]) to compute the end-to-end 379 path. In this case end-to-end path optimality can no longer be 380 guaranteed. 382 8. BRPC procedure completion failure 384 If the BRPC procedure cannot be completed because a PCE along the 385 domain path does not support the procedure, a PCErr message MUST be 386 returned to the upstream PCE with a Error-Type "BRPC procedure 387 completion failure". The PCErr message MUST be relayed to the 388 requesting PCC. 390 PCEP-ERROR objects are used to report a PCEP protocol error and are 391 characterized by an Error-Type which specifies the type of error and 392 an Error-value that provides additional information about the error 393 type. Both the Error-Type and the Error-Value are managed by IANA. 394 A new Error-Type is defined that relates to the BRPC procedure. 396 Error-type Meaning 397 13 BRPC procedure completion failure 398 Error-value 399 1: BRPC procedure not supported by one or more PCEs 400 along the domain path 402 9. Applicability 404 As discussed in Section 3, the requirements for inter-area and 405 inter-AS MPLS Traffic Engineering have been developed by the Traffic 406 Engineering Working Group (TE WG) and have been stated in [RFC4105] 407 and [RFC4216], respectively. Among the set of requirements, both 408 documents indicate the need for some solution providing the ability 409 to compute an optimal (shortest) constrained inter-domain TE LSP and 410 to compute a set of diverse inter-domain TE LSPs. 412 9.1. Diverse end-to-end path computation 414 PCEP allows a PCC to request the computation of a set of diverse TE 415 LSPs thanks to the SVEC object by setting the flags L, N or S to 416 request link, node or SRLG diversity respectively. Such request MUST 417 be taken into account by each PCE along the path computation chain 418 during the VSPT computation. In the context of the BRPC procedure, a 419 set of diversely routed TE LSP between two LSRs can be computed since 420 the paths segment(s) of the VSPT are simultaneously computed by a 421 given PCE. The BRPC procedure allows for the computation of diverse 422 paths under various objective functions (such as minimizing the sum 423 of the costs of the N diverse paths, etc) thus avoiding the well- 424 known "trapping" problem. Indeed, with a 2-step approach consisting 425 of computing the first path followed by the computation of the second 426 path after having removed the set of network elements traversed by 427 the first path (if that does not violate confidentiality 428 preservation), one cannot guarantee that a solution will be found 429 even if such solution exists. Furthermore, even if a solution is 430 found, it may not be the most optimal one with respect to an 431 objective function such as minimizing the sum of the paths costs, 432 bounding the path delays of both paths and so on. Finally, it must 433 be noted that such a 2-step path computation approach is usually less 434 efficient in term of signalling delays since it requires two 435 serialized TE LSP set up. 437 9.2. Path optimality 439 BRPC guarantees that the optimal (shortest) constrained inter-domain 440 path will always be found subject to policy constraints. When 441 combined with other local path computation techniques (e.g. in the 442 case of stitched/nested TE LSP) and in the case where a domain has 443 more than one BR-en or more than one BR-ex, optimality after some 444 network change within the domain can only be guaranteed by re- 445 executing the BRPC procedure. 447 10. Reoptimization of an inter-domain TE LSP 449 The ability to reoptimize an existing inter-domain TE LSP path has 450 been explicitly listed as a requirement in [RFC4105] and [RFC4216]. 451 In the case of a TE LSP reoptimization request, the reoptimization 452 procedures defined in [I-D.ietf-pce-pcep] apply where the path in use 453 (if available on the head-end) is provided as part of the path 454 computation request in order for the PCEs involved in the 455 reoptimization request to avoid double bandwidth accounting. 457 11. Path Computation failure 459 If a PCE requires to relay a path computation request according to 460 the BRPC procedure defined in this document to a downstream PCE and 461 no such PCE is available, the PCE MUST send a negative path 462 computation reply to the requester using a PCReq message as specified 463 in [I-D.ietf-pce-pcep] that contains a NO-PATH object. In such case, 464 the NO-PATH object MUST carry a NO-PATH-VECTOR TLV (defined in 465 [I-D.ietf-pce-pcep]) with the newly defined bit named "BRPC Path 466 Computation chain unavailable" set. 468 0x04: BRPC Path computation chain unavailable 470 12. Metric normalization 472 In the case of inter-area TE, the same IGP/TE metric scheme is 473 usually adopted for all the IGP areas (e.g. based on the link-speed, 474 propagation delay or some other combination of link attributes). 475 Hence, the proposed set of mechanisms always computes the shortest 476 path across multiple areas obeying the required set of constraints 477 with respect to a well-specified objective function. Conversely, in 478 the case of Inter-AS TE, in order for this path computation to be 479 meaningful, a metric normalization between ASes may be required. One 480 solution to avoid IGP metric modification would be for the SPs to 481 agree on a TE metric normalization scheme and use the TE metric for 482 TE LSP path computation (in that case, this must be requested in the 483 PCEP Path computation request) thanks to the METRIC object (defined 484 in [I-D.ietf-pce-pcep]). 486 13. Manageability Considerations 488 This section is compliant with 489 [I-D.ietf-pce-manageability-requirements]. 491 13.1. Control of Function and Policy 493 The only configurable item is the support of the BRPC procedure on a 494 PCE. The support of the BRPC procedure by the PCE MAY be controlled 495 by a policy module governing the conditions under which a PCE should 496 participate to the BRPC procedure (origin of the requests, number of 497 requests per second, ...). If the BRPC is not supported/allowed on a 498 PCE, it MUST send a PCErr message as specified in Section 8. 500 13.2. Information and Data Models 502 A BRPC MIB module will be specified in a separate document. 504 13.3. Liveness Detection and Monitoring 506 The BRPC procedure is a Multiple-PCE path computation technique and 507 as such a set of PCEs are involved in the path computation chain. If 508 the path computation chain is not operational either because at least 509 one PCE does not support the BRPC procedure or because one of the 510 PCEs that must be involved in the path computation chain is not 511 available, procedures are defined to report such failures in 512 Section 8 and Section 11 respectively. Furthermore, a built in 513 diagnostic tool to check the availability and performances of a PCE 514 chain is defined in [I-D.vasseur-pce-monitoring]. 516 13.4. Verifying Correct Operation 518 Verifying the correct operation of BRPC can be done by looking at the 519 TEDs related to the various domains traversed by a TE LSP at the time 520 the BRPC procedure was invoked and verify that the path computed by 521 the BRPC procedure is the expected optimal path (the path that would 522 be obtained in the absence of multiple domains). 524 13.5. Requirements on Other Protocols and Functional Components 526 The BRPC procedure does not put any new requirements on other 527 protocol. That said, since the BRPC procedure relies on the PCEP 528 protocol, there is a dependency between BRPC and PCEP; consequently 529 the BRPC procedure inherently makes use of the management functions 530 developed for PCEP. 532 13.6. Impact on Network Operation 534 The BRPC procedure does not have any significant impact on network 535 operation: indeed, BRPC is a Multiple-PCE path computation scheme as 536 defined in [RFC4655] and does not differ from any other path 537 computation request. 539 13.7. Path computation chain monitoring 541 [I-D.vasseur-pce-monitoring] specifies a set of mechanisms that can 542 be used to gather PCE state metrics. Because BRPC is a Multiple-PCE 543 path computation techniques, such mechanism could be advantageously 544 used in the context of the BRPC procedure to check the liveness of 545 the path computation chain, locate a faulty component, monitor the 546 overall performance and so on. 548 14. IANA Considerations 550 14.1. New flag of the RP object 552 A new flag of the RP object (specified in [I-D.ietf-pce-pcep]) is 553 defined in this document. 555 Name: VSPT (V) 557 Bit Number: 10 559 Value: 0x60 561 When set, this indicates that the PCC requests the computation of an 562 inter-domain TE LSP using the BRPC procedure. 564 A new Error-Type is defined in this document (Error-Type and Error- 565 value to be assigned by IANA). 567 Error-type Meaning 568 13 BRPC procedure completion failure 569 Error-value 570 1: BRPC procedure not supported by one or PCEs 571 along the domain path 573 14.2. New flag of the NO-PATH-VECTOR TLV 575 A new flag of the NO-PATH-VECTOR TLV defined in [I-D.ietf-pce-pcep]) 576 is specified in this document. 578 Defining RFC: draft-ietf-pce-pcep (to be replaced by RFC number when pusblished) 579 Name of bit: BRPC Path computation chain unavailable 580 Bit number (suggested value): 0x04 582 15. Security Considerations 584 The BRPC procedure relies on the use of the PCEP protocol and as such 585 is subjected to the potential attacks listed in section 11 of 586 [I-D.ietf-pce-pcep]. In addition to the security mechanisms 587 described in [I-D.ietf-pce-pcep] with regards to spoofing, snooping, 588 falsification and Denial of Service, an implementation MAY support a 589 policy module governing the conditions under which a PCE should 590 participate to the BRPC procedure. 592 The BRPC procedure does not increase the information exchanged 593 between ASes and preserves topology confidentiality, in compliance 594 with [RFC4105] and [RFC4216]. 596 16. Acknowledgements 598 The authors would like to thank Arthi Ayyangar, Dimitri 599 Papadimitriou, Siva Sivabalan and Meral Shirazipour for their useful 600 comments. A special thank to Adrian Farrel for his useful comments 601 and suggestions. 603 17. References 605 17.1. Normative References 607 [I-D.ietf-pce-pcep] 608 Roux, J. and J. Vasseur, "Path Computation Element (PCE) 609 communication Protocol (PCEP)", draft-ietf-pce-pcep-07 610 (work in progress), March 2007. 612 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 613 Requirement Levels", BCP 14, RFC 2119, March 1997. 615 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 616 Element (PCE)-Based Architecture", RFC 4655, August 2006. 618 17.2. Informative References 620 [I-D.bradford-pce-path-key] 621 Bradford, R., "Preserving Topology Confidentiality in 622 Inter-Domain Path Computation using a key based 623 mechanism", draft-bradford-pce-path-key-02 (work in 624 progress), January 2007. 626 [I-D.ietf-ccamp-inter-domain-pd-path-comp] 627 Vasseur, J., "A Per-domain path computation method for 628 establishing Inter-domain Traffic Engineering (TE) Label 629 Switched Paths (LSPs)", 630 draft-ietf-ccamp-inter-domain-pd-path-comp-05 (work in 631 progress), April 2007. 633 [I-D.ietf-ccamp-inter-domain-rsvp-te] 634 Ayyangar, A., "Inter domain Multiprotocol Label Switching 635 (MPLS) and Generalized MPLS (GMPLS) Traffic Engineering - 636 RSVP-TE extensions", 637 draft-ietf-ccamp-inter-domain-rsvp-te-06 (work in 638 progress), April 2007. 640 [I-D.ietf-pce-disco-proto-isis] 641 Roux, J., "IS-IS protocol extensions for Path Computation 642 Element (PCE) Discovery", 643 draft-ietf-pce-disco-proto-isis-05 (work in progress), 644 May 2007. 646 [I-D.ietf-pce-disco-proto-ospf] 647 Roux, J., "OSPF protocol extensions for Path Computation 648 Element (PCE) Discovery", 649 draft-ietf-pce-disco-proto-ospf-05 (work in progress), 650 May 2007. 652 [I-D.ietf-pce-manageability-requirements] 653 Farrel, A., "Inclusion of Manageability Sections in PCE 654 Working Group Drafts", 655 draft-ietf-pce-manageability-requirements-01 (work in 656 progress), March 2007. 658 [I-D.vasseur-pce-monitoring] 659 Vasseur, J., "A set of monitoring tools for Path 660 Computation Element based Architecture", 661 draft-vasseur-pce-monitoring-03 (work in progress), 662 May 2007. 664 [RFC2702] Awduche, D., Malcolm, J., Agogbua, J., O'Dell, M., and J. 665 McManus, "Requirements for Traffic Engineering Over MPLS", 666 RFC 2702, September 1999. 668 [RFC4105] Le Roux, J., Vasseur, J., and J. Boyle, "Requirements for 669 Inter-Area MPLS Traffic Engineering", RFC 4105, June 2005. 671 [RFC4216] Zhang, R. and J. Vasseur, "MPLS Inter-Autonomous System 672 (AS) Traffic Engineering (TE) Requirements", RFC 4216, 673 November 2005. 675 [RFC4726] Farrel, A., Vasseur, J., and A. Ayyangar, "A Framework for 676 Inter-Domain Multiprotocol Label Switching Traffic 677 Engineering", RFC 4726, November 2006. 679 Appendix A. Proposed Status and Discussion [To Be Removed Upon 680 Publication] 682 This Internet-Draft is being submitted for eventual publication as an 683 RFC with a proposed status of Standard. Discussion of this proposal 684 should take place on the following mailing list: pce@ietf.org. 686 Authors' Addresses 688 JP Vasseur (editor) 689 Cisco Systems, Inc 690 1414 Massachusetts Avenue 691 Boxborough, MA 01719 692 USA 694 Email: jpv@cisco.com 696 Raymond Zhang 697 BT Infonet 698 2160 E. Grand Ave. 699 El Segundo, CA 90025 700 USA 702 Email: raymond_zhang@bt.infonet.com 703 Nabil Bitar 704 Verizon 705 40 Sylvan Road 706 Waltham, MA 02145 707 USA 709 Email: nabil.bitar@verizon.com 711 JL Le Roux 712 France Telecom 713 2, Avenue Pierre-Marzin 714 Lannion, 22307 715 FRANCE 717 Email: jeanlouis.leroux@orange-ft.com 719 Full Copyright Statement 721 Copyright (C) The IETF Trust (2007). 723 This document is subject to the rights, licenses and restrictions 724 contained in BCP 78, and except as set forth therein, the authors 725 retain all their rights. 727 This document and the information contained herein are provided on an 728 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 729 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 730 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 731 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 732 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 733 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 735 Intellectual Property 737 The IETF takes no position regarding the validity or scope of any 738 Intellectual Property Rights or other rights that might be claimed to 739 pertain to the implementation or use of the technology described in 740 this document or the extent to which any license under such rights 741 might or might not be available; nor does it represent that it has 742 made any independent effort to identify any such rights. Information 743 on the procedures with respect to rights in RFC documents can be 744 found in BCP 78 and BCP 79. 746 Copies of IPR disclosures made to the IETF Secretariat and any 747 assurances of licenses to be made available, or the result of an 748 attempt made to obtain a general license or permission for the use of 749 such proprietary rights by implementers or users of this 750 specification can be obtained from the IETF on-line IPR repository at 751 http://www.ietf.org/ipr. 753 The IETF invites any interested party to bring to its attention any 754 copyrights, patents or patent applications, or other proprietary 755 rights that may cover technology that may be required to implement 756 this standard. Please address the information to the IETF at 757 ietf-ipr@ietf.org. 759 Acknowledgment 761 Funding for the RFC Editor function is provided by the IETF 762 Administrative Support Activity (IASA).