idnits 2.17.1 draft-leroux-pce-pcecp-interarea-reqs-00.txt: -(760): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(761): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding -(873): Line appears to be too long, but this could be caused by non-ascii characters in UTF-8 encoding 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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 866. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 843. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 850. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 856. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? == There are 10 instances of lines with non-ascii characters in the document. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack an Authors' Addresses Section. ** There is 1 instance of lines with control characters in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == Line 651 has weird spacing: '...support the i...' -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (October 2005) is 6768 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PCE-DISCO-REQ' is mentioned on line 551, but not defined == Missing Reference: 'MPLS-FRR' is mentioned on line 659, but not defined == Unused Reference: 'RFC2119' is defined on line 744, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 747, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 750, but no explicit reference was found in the text == Unused Reference: 'PCE-DISC-REQ' is defined on line 764, but no explicit reference was found in the text == Unused Reference: 'ID-RSVP' is defined on line 778, but no explicit reference was found in the text -- Obsolete informational reference (is this intentional?): RFC 3667 (Obsoleted by RFC 3978) -- Obsolete informational reference (is this intentional?): RFC 3979 (ref. 'BCP79') (Obsoleted by RFC 8179) Summary: 7 errors (**), 0 flaws (~~), 10 warnings (==), 9 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 1 Network Working Group J.-L. Le Roux (Editor) 2 Internet Draft France Telecom 4 Category: Informational 5 Expires: April 2006 6 October 2005 8 PCE Communication Protocol (PCECP) specific requirements for Inter-Area 9 (G)MPLS Traffic Engineering 11 draft-leroux-pce-pcecp-interarea-reqs-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that other 22 groups may also distribute working documents as Internet-Drafts. 24 Internet-Drafts are draft documents valid for a maximum of six months 25 and may be updated, replaced, or obsoleted by other documents at any 26 time. It is inappropriate to use Internet- Drafts as reference 27 material or to cite them other than as "work in progress." 29 The list of current Internet-Drafts can be accessed at 30 http://www.ietf.org/ietf/1id-abstracts.txt. 32 The list of Internet-Draft Shadow Directories can be accessed at 33 http://www.ietf.org/shadow.html. 35 Abstract 37 For scalability purposes a network may comprise multiple IGP areas. 38 An inter-area TE-LSP is an LSP that transits through at least two IGP 39 areas. In a multi-area network, topology visibility remains local to 40 a given area, and a head-end LSR cannot compute alone an inter-area 41 shortest constrained path. One key application of the Path 42 Computation Element (PCE) architecture is the computation of inter- 43 area TE-LSP paths. In this context, this document lists a detailed 44 set of PCE Communication Protocol (PCECP) specific requirements for 45 support of inter-area TE-LSP path computation. It complements generic 46 requirements for a PCE Communication Protocol. 48 Conventions used in this document 50 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 51 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 52 document are to be interpreted as described in RFC-2119. 54 Table of Contents 56 1. Contributors................................................3 57 2. Terminology.................................................3 58 3. Introduction................................................4 59 4. Problem Statement...........................................5 60 5. Various approaches for PCE-based inter-area path 61 computation.................................................6 62 5.1. Single PCE Computation......................................6 63 5.2. Multiple PCE path computation with inter-PCE 64 communication...............................................8 65 6. Considerations on PCE location..............................9 66 7. Detailed Requirements on PCECP.............................10 67 7.1. Supported modes for PCE-based inter-area path 68 computation................................................10 69 7.2. Control of area crossing...................................10 70 7.3. Objective functions........................................11 71 7.4. TE metric / IGP metric.....................................11 72 7.5. Recording path attributes..................................11 73 7.6. Strict Explicit path and Loose Path........................12 74 7.7. PCE-list enforcement and recording in Multiple PCE 75 Computation................................................12 76 7.8. Inclusion of Area IDs in request...........................13 77 7.9. Load-Balancing.............................................13 78 7.10. Diverse Path computation...................................13 79 7.11. LSP failure handling.......................................14 80 7.11.1. LSP Rerouting..............................................14 81 7.11.2. Backup path computation....................................14 82 7.12. Inter-Area policies........................................15 83 7.13. Scalability................................................15 84 8. Manageability consideration................................16 85 9. Security Considerations....................................16 86 10. Acknowledgments............................................16 87 11. Informative References.....................................16 88 12. Editor Address:............................................17 89 13. Contributors' Addresses....................................17 90 14. Intellectual Property Statement............................18 92 1. Contributors 94 The following are the authors that contributed to the present 95 document: 97 Jerry Ash (AT&T) 98 Dean Cheng (Cisco) 99 Kenji Kumaki (KDDI) 100 J.L. Le Roux (France Telecom) 101 Eiji Oki (NTT) 102 Nabil Bitar (Verizon) 103 Raymond Zhang (BT Infonet) 105 2. Terminology 107 LSR: Label Switching Router 109 LSP: MPLS Label Switched Path 111 TE-LSP: Traffic Engineering Label Switched Path 113 IGP area: OSPF Area or IS-IS level 115 ABR: IGP Area Border Router, a router that is attached to more 116 than one IGP areas (ABR in OSPF or L1/L2 router in IS-IS) 118 Inter-Area TE LSP: TE LSP that traverses more than one IGP area 120 CSPF: Constraint Shortest Path First 122 SRLG: Shared Risk Link Group 124 PCE: Path Computation Element, an entity that can compute path 125 based on a network graph and applying computational 126 constraints 128 PCC: Path Computation Client, any application that request path 129 computation to be performed by a PCE 131 PCECP: PCE Communication Protocol, a protocol for communication 132 between PCCs and PCEs 134 3. Introduction 136 IGP hierarchy consists of separating an IGP domain into multiple IGP 137 areas, and limiting the topology visibility local to an area. This 138 mechanism significantly improves IGP scalability. 140 [RFC4105] lists a set of motivations and requirements for setting up 141 TE-LSPs across IGP area boundaries. These LSPs are called inter-area 142 TE-LSPs. These requirements include the computation of inter- 143 area shortest constrained paths with key guidelines being to respect 144 the IGP hierarchy concept, and particularly the containment of 145 topology information. The main challenge with inter-area MPLS-TE 146 relies actually on path computation. The head-end LSR cannot compute 147 an end-to-end shortest constrained path, as its topology visibility 148 is limited to one area. Path computation can rely on loose hops with 149 ERO expansion on each ABR, but this faces two issues: (1) it does not 150 guarantee the computation of a shortest path that satisfies the TE- 151 LSP constraints, and (2) it may result in several signalling 152 crankback messages before it successfully sets up the path. 154 The Path Computation Element (PCE) Architecture, defined in [PCE- 155 ARCH] can provide a suitable framework for computing an inter-area 156 shortest path for a TE-LSP. 157 [PCE-ARCH] defines PCEs as entities that can compute paths based on a 158 network graph and applying computational constraints. A PCE function 159 can be located on a LSR or a network server. It defines a Path 160 Computation Client (PCC) as an application requesting a path 161 computation to be performed by a PCE. Typically a PCC can be a head- 162 end LSR, a transit LSR requesting a TE-LSP path computation, or a PCE 163 requesting a path computation of another PCE, in a collaborative 164 mode. 166 One of the key applications of the PCE architecture is inter-domain 167 path computation, where head-end LSRs have a limited topology view 168 beyond its own domain. This includes both inter-area and inter-AS 169 path computation. 170 Inter-area path computation requirements expressed in [RFC4105] may 171 be achieved using the services of one or more PCEs. 172 PCE-based inter-area path computation could rely for instance on a 173 single multi-area PCE that has the TE database of all the areas in 174 the IGP domain and can directly compute an end-to-end shortest 175 constrained path. 176 Alternatively, PCE-based inter-area path computation could rely on 177 the cooperation between PCEs whereby each PCE covers one or more IGP 178 areas and the full set of PCEs covers all areas. 180 The generic requirements for a PCE Communication Protocol (PCECP), 181 allowing a PCC to send path computation requests to a PCE and the PCE 182 to sent path computation response to a PCC are listed in [PCE-COM- 183 REQ]. The use of a PCE-based approach, for inter-area path 184 computation implies specific requirements on a PCE Communication 185 Protocol, in addition to the generic requirements already listed in 186 [PCE-COM-REQ]. 187 This document complements these generic requirements by listing a 188 detailed set of PCECP requirements specific to the PCE-based 189 computation of inter-area TE-LSPs. 191 The problem statement is discussed in section 4. Various PCE-based 192 modes for inter-area path computation are described in section 5. 193 Considerations for PCE location are provided in section 6. Finally 194 detailed requirements are listed in section 7. 196 It is expected that a solution for a PCE Communication Protocol 197 (PCECP) satisfies these requirements. 199 Note that PCE-based inter-area path computation may require a 200 mechanism for an automatic PCE discovery across areas, which is out 201 of the scope of this document. Detailed requirements for such 202 mechanism are discussed in [PCE-DISCO-REQ]. 204 4. Problem Statement 206 In intra-area MPLS-TE, a head-end LSR has complete topology 207 visibility of the area and can compute an end-to-end shortest 208 constrained path. IGP hierarchy allows improving IGP scalability, 209 particularly in large networks with hundreds of nodes and thousands 210 of links, by dividing the IGP domain into areas and limiting the 211 flooding scope of topology information to area boundaries. A router 212 in an area has full topology information for its own area but only 213 reachability to routes in other areas._ Thus, a head-end LSR cannot 214 compute an end-to-end constrained path that traverses more than one 215 IGP area. 217 A solution for computing inter-area TE-LSP path relies on a per 218 domain path computation ([PD-COMP]). It is based on loose hop routing 219 with an ERO expansion on each ABR. This can allow setting up a 220 constrained path, but faces two major limitations: 221 -This does not allow computing an optimal constrained path 222 -This may lead to several signalling crankback messages and 223 hence delay the LSP setup, and invoke routing activities. 225 Note that, here, by optimal constrained path we mean the shortest 226 constrained path across multiple areas, taking into account either 227 the IGP or TE metric [METRIC]. In other words, such a path is the 228 path that would have been computed by making use of some CSPF 229 algorithm in the absence of multiple IGP areas. 231 The PCE architecture is well suited to inter-area path computation, 232 as it allows overcoming the path computation limitations resulting 233 from the limited topology visibility, by introducing path computation 234 entities with more topology visibility, or by allowing cooperation 235 between path computation entities in each area. 237 Several PCE-based path computation approaches can be used to compute 238 inter-area optimal constrained paths, they are discussed in next 239 section. 241 The use of a PCE-based approach, to perform inter-area path 242 computation requires specific functions in a PCECP, in addition to 243 the generic requirements listed in [PCE-COM-REQ]. Detailed 244 requirements are discussed in section 7. 246 5. Various approaches for PCE-based inter-area path computation 248 There are various possible modes for PCE-Based inter-area path 249 computation. 250 The computation of an inter-area optimal path could be done by: 251 - a single PCE, that has enough topology visibility and can 252 alone compute an end-to-end optimal path, 253 - multiple PCEs, that have partial topology 254 visibility and collaborate with each other so as to arrive at 255 an end-to-end optimal path. 257 These two modes are referred as to "Single PCE computation" and 258 "Multiple PCE computation with inter-PCE communication" in [PCE- 259 ARCH]. Note that these two modes may co-exist in a given multi-area 260 network. 262 Note that the per-area path computation mode relying on route 263 expansion performed directly by ABRs on the path (which function has 264 composite PCEs) , or on external PCEs contacted by the ABRs on the 265 path, consists in fact of a simple concatenation of intra area paths. 266 It actually only implies intra-area path computations and does not 267 allow computing inter-area optimal paths. Hence this mode is not 268 discussed in this document. 270 5.1. Single PCE Computation 272 In this mode the inter-area path computation is directly performed by 273 a single PCE that has enough topology information to compute an end- 274 to-end optimal path. 275 No inter-PCE communication is required in this mode. 277 This mode requires that the PCE have at least the TED of all the 278 crossed areas for a given LSP. The actual distribution of PCEs may 279 vary, i.e., a PCE may have TE database base from two, three or more 280 IGP areas. If the head-end and tail-end LSRs are located in two 281 peripheral areas, the PCE must have the TED of the source, backbone, 282 and destination areas. In the particular case where the head- 283 end/tail-End LSR is located in the backbone area and the tail- 284 end/head-end LSR is located in a peripheral area, the PCE only needs 285 the TED of the backbone area and the peripheral area to compute the 286 path. 288 Figure 1 below illustrates an example of single PCE inter-area 289 computation. 291 ------ 292 | PCE0 | 293 / ------ \ 294 / | \ 295 / | \ 296 / | \ 297 / | \ 298 ------------------------------------------ 299 | | | | 300 | ABR2 ABR3 | 301 R1 area1 | area0 | area2 R2 302 | ABR1 ABR4 | 303 | | | | 304 ------------------------------------------ 306 Figure 1: Example of single PCE computation. 308 In this multi area network PCE0 has topology visibility in area1, 309 area0 and area2 and can compute and end-to-end path from area 1 to 310 area 2. To setup an inter-area LSP from R1 in area 1 to R2 in area 2, 311 R1 has to directly contact PCE0. 313 Note that this mode may rely on PCEs that have knowledge of topology 314 in all areas. Such a PCE is called an "all-areas" PCE. 315 Particular attention should be given on the potential limitations of 316 this "all-areas" PCE approach, in terms of scalability. Such all-area 317 PCEs may have to maintain a large topology and this raises 318 scalability issues both in terms of memory to maintain the TED and 319 processing to synchronize TED information. 320 Also such all-area PCEs would potentially serve a large number of 321 PCCs, and hence may face a huge path computation request overload 322 during a network event such as link or node failure (that may impact 323 a large number of TE-LSPs on a large number of head-end LSRs). This 324 may significantly delay the TE-LSP recovery, and thus may diminish 325 the benefits of such an approach. 327 5.2. Multiple PCE path computation with inter-PCE communication 329 In this mode the computation of an optimal inter-area TE-LSP path is 330 distributed across multiple PCEs. 331 There is at least one PCE per area, and those PCEs do not have enough 332 topology visibility to compute and inter-area optimal path. 333 PCEs in each area compute path segments in their respective areas and 334 collaborate together to arrive at an end-to-end inter-area optimal 335 path. Such collaboration is ensured thanks to inter-PCE 336 communication. 337 The actual distribution of PCEs may vary, i.e. a PCE may have TE 338 database from one, two, or more IGP areas, and the important thing is 339 that the collection of topology and TE information maintained by a 340 set of PCEs collectively must cover all the IGP areas where all 341 inter-area LSPs traverse. 343 Figure 2 and 3 below illustrate two examples of multiple PCE inter- 344 area computation 346 ------ ------ ------ 347 | PCE1 |<------>| PCE0 |<---->| PCE2 | 348 ------ ------ ------ 349 | | | 350 | | | 351 -------------------------------------------- 352 | | | | 353 | ABR2 ABR3 | 354 R1 area1 | area0 | area2 R2 355 | ABR1 ABR4 | 356 | | | | 357 -------------------------------------------- 359 Figure 2: Cooperation between single-area PCEs 361 Figure 2 above illustrates a multi-area network with 3 areas. PCE0, 362 PCE1 and PCE2 are PCEs responsible for path computation respectively 363 in area 0, 1 and 2. These PCEs have topology visibility limited to 364 one area and are called single-area PCEs. 365 To setup an inter-area LSP from R1 in area 1 to R2 in area 2, R1 has 366 to contact PCE1. PCE1 then collaborates with PCE0, and PCE0 with PCE2 367 so as to compute an end-to-end shortest constrained path. 369 ------ ------ 370 | PCE1 | <----> | PCE2 | 371 ------ ------ 372 / \ / \ 373 / \ / \ 374 -------------------------------------------- 375 | | | | 376 | ABR2 ABR3 | 377 R1 area1 | area0 | area2 R2 378 | ABR1 ABR4 | 379 | | | | 380 -------------------------------------------- 382 Figure 3: Cooperation between multi-area PCEs 384 Figure 3 above illustrates a multi-area network with 3 areas. PCE1, 385 and PCE2 are PCEs responsible for path computation respectively in 386 area 0+1 and in area 0+2. This means that PCE1 and PCE2 have topology 387 visibility in area0+area1 and area0+area2 respectively. 388 To setup an inter-area LSP from R1 in area 1 to R2 in area 2, R1 has 389 to contact PCE1. PCE1 then collaborates with PCE2, so as to compute 390 an end-to-end shortest constrained path. 392 6. Considerations on PCE location 394 As explained in [PCE-ARCH] a PCE can be a LSR or a network server. 396 But note that in the inter-area context, it may be quite efficient 397 for the ABRs to act as PCEs. Indeed, ABRs have topology information 398 of the backbone area and at least one peripheral area. An inter-area 399 TE-LSP optimal path computation could rely on a single ABR, if the 400 path crosses only two IGP areas, or on collaboration between two ABRs 401 in case the path crosses three IGP areas. 402 For instance, in figure 2 above, ABR1 or ABR2 can play PCE1 role, and 403 similarly ABR3 or ABR4 can play PCE2 role. Note that such ABRs are 404 not necessarily transit LSRs on the computed inter-area TE LSP. 406 With such PCE distribution on ABRs, the PCECP would run directly 407 between LSRs. Note that if N peripheral areas are connected to one 408 backbone area, with at least N ABRs, inter-area path computation 409 would potentially require a full mesh of N^2 PCE-PCE communications 410 between ABRs. This reinforces the requirement for communication 411 protocol overhead minimization, expressed in [PCE-COM-REQ]. 413 7. Detailed Requirements on PCECP 415 This section lists a set of additional requirements for the PCE 416 Communication Protocol that complement requirements listed in [PCE- 417 COM-REQ] and are specific to inter-area (G)MPLS TE path computation. 419 7.1. Supported modes for PCE-based inter-area path computation 421 The PCECP MUST support the two PCE based inter-area path computation 422 modes set forth in section 5. 424 Multiple PCE inter-area path computation requires cooperation between 425 PCEs. Hence the PCECP MUST support cooperation between PCEs so as to 426 arrive at an inter-area optimal path. It MUST allow requests and 427 replies for cooperative inter-area path computation. 429 A simple cooperation may consists in exchanging intra or inter-area 430 path Segments, and combine them to build an end-to-end optimal path. 431 This is a basic cooperation level that allows building an inter-area 432 optimal path in a recursive manner. 433 The path segment combination could be done in the backward 434 direction, in which case an inter-PCE response message includes a set 435 of computed intra or inter-area path segments from a set of 436 downstream ABRs to the destination, along with their respective cost. 437 These path segments have to be completed by upstream PCEs in a 438 recursive manner so as to build an end-to-end optimal path across 439 areas. To support this collaboration mode, a response message MUST 440 allow the inclusion of multiple intra-area or inter-area path 441 segments from a set of downstream ABRs, to the destination, along 442 with their respective cost (see also 8.4). 444 Note that path segment combination in the forward direction is for 445 further Study. 447 7.2. Control of area crossing 449 In addition to the path constraints specified in section 6.1.16 of 450 [PCE-COM-REQ] the request message MUST allow indicating whether area 451 crossing is allowed or not. 452 Indeed, for inter-area TE LSPs whose head-end and tail-end LSRs 453 reside in the same IGP area, there may be intra-area and inter-area 454 feasible paths, and, as set forth in [RFC4105], if the shortest path 455 is an inter-area path, an operator either may want to avoid, as far 456 as possible, crossing area and thus may prefer selecting a sub- 457 optimal intra-area path or, conversely, may prefer to use a shortest 458 path, even if it crosses areas. 460 7.3. Objective functions 462 *Editorial note: This section will be moved to the generic 463 requirement draft [PCE-COM-REQ] as this requirement applies to 464 various PCE applications* 466 As specified in [PCE-COM-REQ] an objective function corresponds to 467 the optimization criteria used for the computation of one path, or 468 the synchronized computation of a set of paths. In case of 469 unsynchronized path computation, this can be, for example, the path 470 cost or the residual bandwidth on the most loaded path link. In case 471 of synchronized path computation, this can be, for example, the 472 global bandwidth consumption or the residual bandwidth on the most 473 loaded network link. 475 For the purpose of inter-area path computation the PCECP MUST support 476 the following "unsynchronized" objective functions: 477 -Minimum cost path (shortest path) 478 -Least loaded path (widest path) 479 -To be completed 481 Also the PCECP SHOULD support the following "synchronized" objective 482 functions: 483 -Minimize aggregate bandwidth consumption on all links 484 -Maximize the residual bandwidth on the most loaded link. 485 -Minimize the cumulative cost of a set of diverse paths. 487 Note that the absence of an objective function in this list does not 488 mean that it must not be supported. As per the extensibility 489 requirement expressed in [PCE-COM-REQ], note that new objective 490 functions can be added to this list without impacting the protocol. 492 7.4. TE metric / IGP metric 494 The shortest path selection may rely either on the TE metric or on 495 the IGP metric (see [METRIC]). Hence the PCECP request message MUST 496 allow indicating the metric type (IGP or TE) to be used for shortest 497 path selection. 499 7.5. Recording path attributes 501 There are at least three aggregate path attributes defined in 502 (G)MPLS-TE: the hop-count, the cumulated TE-metric, and the cumulated 503 IGP-metric. The operator can actually give any semantic to the TE 504 metric and IGP metric. As suggested in [METRIC], if the TE-metric 505 encodes the link cost and the IGP metric the link delay, the 506 cumulated TE-metric indicates the total cost of the LSP and the 507 cumulated IGP metric the end-to-end propagation delay (provided that 508 the LSR transit delay is neglected in a first approximation). 510 A PCC may need to know the aggregate path attributes of an LSR, for 511 instance to select a preferred path among a set of computed paths. 513 In an inter-area context, a PCC may not be able to deduce this 514 information from the supplied path. 515 Therefore the PCECP request message MUST allow indicating the set of 516 aggregate path attributes (hop-count, cumulated TE-metric, cumulated 517 IGP-Metric) that are required in the reply and the PCECP response 518 message MUST support the inclusion of a set of aggregate path 519 attributes. 521 Note that if new TE link attributes are defined in the future to 522 encode specific link parameters, and allowing to define specific 523 aggregate path constraints, such as, e.g. delay, distance or power 524 loss, the PCEPC will have to be extended to support them. 526 Note that in case the computed path includes loose hops the PCE may 527 not be able to give an accurate aggregate path attribute. Hence the 528 response message MUST allow indicating that an aggregate path 529 attribute is unknown. 531 7.6. Strict Explicit path and Loose Path 533 A Strict Explicit Path is defined as a set of strict hops. 534 A Loose Path is defined as a set of strict and loose hops. 535 An inter-area path may be strictly explicit or loose (e.g. a list of 536 ABRs as loose hops) 537 It may be useful to indicate to the PCE if a Strict Explicit path is 538 required or not. 539 Hence the PCECP request message MUST allow indicating if a Strict 540 Explicit Path is required/desired. 542 7.7. PCE-list enforcement and recording in Multiple PCE Computation 544 In case of multiple-PCE path computation, a PCC may want to indicate 545 a preferred list of PCEs to be used. 546 Hence the PCECP request message MUST support the inclusion of a list 547 of preferred PCEs. 548 Note that this requires that a PCC in one area have knowledge of PCEs 549 in other areas. This could rely on configuration or on a PCE 550 discovery mechanism, allowing discovery across area boundaries (see 551 [PCE-DISCO-REQ]). 553 Also it would be useful to know the list of PCEs which effectively 554 participated in the computation. 555 Hence the request message MUST support requesting for PCE recording 556 and the response message MUST support the recording of the set of one 557 or more PCEs that took part into the computation. 558 It may also be useful to know the path segments computed by each PCE. 559 Hence the request message SHOULD allow requesting for the 560 identification of path segment computed by a PCE, and the response 561 message SHOULD allow identifying the path segments computed by each 562 PCE. 564 7.8. Inclusion of Area IDs in request 566 The knowledge of the area in which the source and destination lie 567 would allow selection of appropriate cooperating PCEs. 568 A PCE may not be able to determine the location of the source and 569 destination LSRs. Hence it would be useful that a PCC indicates the 570 source area ID and destination area IDs. 572 For that purpose the request message MUST support the inclusion of 573 source and destination area IDs. 574 Note that this information could be learned on the PCC by 575 configuration. 577 7.9. Load-Balancing 579 *Editorial note: This section will be moved to the generic 580 requirement draft [PCE-COM-REQ] as this requirement applies to 581 various PCE applications* 583 In some cases a single inter-area path may not fit a TE-LSP bandwidth 584 constraint. In this case it may be useful to setup a set of paths 585 whose cumulated residual bandwidth fit the TE-LSP bandwidth request. 586 This is what we call load balancing. 587 So as to avoid ending up with a huge number of paths for a given 588 request, and/or with low bandwidth paths, it is required to control 589 the number of computed paths and the minimum path bandwidth. 591 The request message MUST allow indicating if load-balancing is 592 allowed or not. It MUST also include the number of paths in a load- 593 balancing path group, and the minimum path bandwidth in a load- 594 balancing path group. The response MUST support the inclusion of the 595 set of computed paths of a load-balancing path group, as well as 596 their respective bandwidth. 598 7.10. Diverse Path computation 600 For various reasons including protection and load balancing, the 601 computation of diverse inter-area paths may be required. 602 There are various levels of diversity in an inter-area context: 603 -Per area diversity (intra-area path segments are link, node or 604 SRLG disjoint) 605 -Inter-Area diversity (end-to-end inter-area paths are link, 606 node or SRLG disjoint) 608 Note that two paths may be disjoint in the backbone area but shared 609 in peripheral areas. Also two paths may be node disjoints within 610 areas but may share ABRs. 612 The request message MUST allow requesting the computation of a set of 613 diverse paths between a same couple of nodes or distinct couples of 614 nodes. It MUST allow indicating the required level of intra-area 615 diversity (link, node, SRLG) on a per area basis, as well as the 616 level of inter-area diversity (shared ABRs or ABR disjointness). 618 The response message MUST allow indicating the level of diversity of 619 a set of computed loose paths. 621 Note that specific objective function may be requested for diverse 622 path computation, such as to minimize the cumulated cost of a set of 623 diverse paths (see also 7.3). 625 7.11. LSP failure handling 627 7.11.1. LSP Rerouting 629 *Editorial note: This section will be moved to the generic 630 requirement draft [PCE-COM-REQ] as this requirement applies to 631 various PCE applications* 633 Upon LSP failure, due to link, node or SRLG failure, a head-end LSR 634 may send a request to the PCE so as to reroute the LSP over an 635 alternate path. So as to ease the computation such request should 636 include the previous path and the failed element (if it can be 637 identified). 639 Hence the request message MUST allow indicating if the computation is 640 for an LSP restoration, and MUST support the inclusion of the 641 previously computed path as well as the failed element. 642 Note that the old path is actually useful only if the old LSP is not 643 torn down yet. This is up to the PCC to decide if it includes the old 644 path or not. 646 Note that a network failure may impact a large number of LSPs. A 647 potentially large number of PCCs, are going to simultaneously send a 648 request to the PCE. Some jittering may be used on PCCs so as to delay 649 a request to the PCE, under network failure condition. 651 The PCECP MAY support the inclusion, in a response message to a PCC, 652 of an upper bound of the jitter to be used for further requests to 653 the PCE (e.g. the PCC will wait for a random value between 0 and the 654 upper bound before sending another request). This upper bound would 655 depend on the level of congestion of the PCE. 657 7.11.2. Backup path computation 659 ABRs can be protected using Fast Reroute (FRR) node protection [MPLS- 660 FRR]. This requires setting up inter-area FRR backup LSPs (bypass or 661 detour). 662 The PCECP SHOULD support the computation of inter-area FRR backup 663 LSPs (detour or bypass). Note that the objective function may be to 664 minimize overhaul backup bandwidth consumption, by maximizing 665 bandwidth sharing among backup LSPs protecting independent elements. 667 Detailed requirements for intra and inter-area PCE-based backup path 668 computation are for further study and will be addressed in a separate 669 document. 671 7.12. Inter-Area policies 673 As already defined in Section 8.2 a request message MUST allow 674 indicating whether area crossing is allowed or not. 676 A PCE may want to apply policies based on the initiating PCC. 677 In a multiple-PCE computation the address of the initiating PCC may 678 no longer be part of the request messages sent between PCEs. 679 Hence, the request message MUST support the inclusion of the address 680 of the originator PCC. 682 Note that in some case this is important to contain an inter-area 683 path within a single AS. Hence the request message MUST allow 684 indicating that AS crossing is not authorized. 686 7.13. Scalability 688 As already pointed out in [PCE-COM-REQ] the PCECP MUST scale well, at 689 least as good as linearly, with an increase of any of the following 690 parameters: 691 - number of PCCs communicating with a single PCE 692 - number of PCEs communicated to by a single PCC 693 - number of PCEs communicated to by another PCE 694 - number of request per PCE per second in steady state 695 - number of requests per PCE per second under emergency condition 697 Note that these numbers will depend on the level of PCE distribution 698 and on the PCE approach used (Single PCE computation, Multiple PCEs 699 computation�) 701 For instance in a network that comprises I IGP areas, with P PCCs 702 per area and A ABRs per area boundary then 703 -For single PCE computation with an all-areas PCE Server: 704 -Number of PCCs communicating with a single PCE=I*P 705 -Number of PCEs communicated to by a single PCC=1 706 -Number of PCEs communicated to by another PCE=0 708 -For multiple PCE computation with ABRs acting as PCEs: 709 -Number of PCCs communicating with a single PCE=P 710 -Number of PCE communicated to by a single PCC=I*A 711 -Number of PCEs communicated to by another PCE=I*A 713 Typical values for a large inter-area network can be: I=50, P=100, 714 and A=2. 716 Note also that the memory and CPU consumed to maintain and 717 synchronize the TED on a PCE will directly depend on the number of 718 areas under control of the PCE. This may diminish the benefits of 719 "all area" PCEs, but this is beyond the scope of this document. 721 8. Manageability consideration 723 Manageability of inter-area PCEs must address the following 724 consideration for section 7: 726 - need for a MIB module for control plane and monitoring 727 - need for built-in diagnostic tools 728 - configuration implications for the protocol 730 9. Security Considerations 732 IGP areas are administrated by the same entity. Hence the inter-area 733 application does not imply new trust model, or new security issues 734 beyond those already defined in [PCE-COM-REQ]. 736 10. Acknowledgments 738 We would also like to thank Adrian Farrel, Jean-Philippe Vasseur, 739 Bruno Decraene and Yannick Le Louedec for their useful comments and 740 suggestions. 742 11. Informative References 744 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 745 Requirement Levels", BCP 14, RFC 2119, March 1997. 747 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 748 3667, February 2004. 750 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 751 Technology", RFC 3979, March 2005. 753 [RFC4105] Le Roux J.L., Vasseur J.P., Boyle, J., et al. "Requirements 754 for inter-area MPLS-TE" RFC 4105, June 2005. 756 [PCE-ARCH] A. Farrel, JP. Vasseur and J. Ash, �Path Computation 757 Element (PCE) Architecture�, draft-ietf-pce-architecture (work in 758 progress). 760 [PCE-COM-REQ] J. Ash, J.L Le Roux et al., �PCE Communication Protocol 761 Generic Requirements�, draft-ietf-pce-comm-protocol-gen-reqs (work in 762 progress). 764 [PCE-DISC-REQ] J.L. Le Roux et al., �Requirements for Path 765 Computation Element (PCE) Discovery�, draft-ietf-pce-discovery-reqs 766 (work in progress). 768 [PD-COMP] Vasseur, J.P., Ayyangar, A., Zhang, R., " A Per-domain path 769 computation method for computing Inter-domain Traffic Engineering 770 (TE) Label Switched Path (LSP)", draft-ietf-ccamp-inter-domain-pd- 771 path-comp, work in progress 773 [METRIC] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., 774 and T. Telkamp, "Use of Interior Gateway Protocol(IGP) Metric as a 775 second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 776 2004. 778 [ID-RSVP] Ayyangar, A., Vasseur, J.P., "Inter domain GMPLS Traffic 779 Engineering - RSVP-TE extensions", draft-ietf-ccamp-inter-domain- 780 rsvp-te, work in progress. 782 12. Editor Address: 784 Jean-Louis Le Roux 785 France Telecom 786 2, avenue Pierre-Marzin 787 22307 Lannion Cedex 788 FRANCE 789 Email: jeanlouis.leroux@francetelecom.com 791 13. Contributors' Addresses 793 Jerry Ash 794 AT&T 795 Room MT D5-2A01 796 200 Laurel Avenue 797 Middletown, NJ 07748, USA 798 Phone: +1-(732)-420-4578 799 Email: gash@att.com 801 Nabil Bitar 802 Verizon 803 40 Sylvan Road 804 Waltham, MA 02145 805 Email: nabil.bitar@verizon.com 807 Dean Cheng 808 Cisco Systems Inc. 809 3700 Cisco Way 810 San Jose CA 95134 USA 811 Phone: +1 408 527 0677 812 Email: dcheng@cisco.com 814 Kenji Kumaki 815 KDDI Corporation 816 Garden Air Tower 817 Iidabashi, Chiyoda-ku, 818 Tokyo 102-8460, JAPAN 819 Phone: +81-3-6678-3103 820 Email: ke-kumaki@kddi.com 822 Eiji Oki 823 NTT 824 Midori-cho 3-9-11 825 Musashino-shi, Tokyo 180-8585, JAPAN 826 Email: oki.eiji@lab.ntt.co.jp 828 Raymond Zhang 829 BT INFONET Services Corporation 830 2160 E. Grand Ave. 831 El Segundo, CA 90245 USA 832 Email: Raymond_zhang@bt.infonet.com 834 14. Intellectual Property Statement 836 The IETF takes no position regarding the validity or scope of any 837 Intellectual Property Rights or other rights that might be claimed to 838 pertain to the implementation or use of the technology described in 839 this document or the extent to which any license under such rights 840 might or might not be available; nor does it represent that it has 841 made any independent effort to identify any such rights. Information 842 on the procedures with respect to rights in RFC documents can be 843 found in BCP 78 and BCP 79. 845 Copies of IPR disclosures made to the IETF Secretariat and any 846 assurances of licenses to be made available, or the result of an 847 attempt made to obtain a general license or permission for the use of 848 such proprietary rights by implementers or users of this 849 specification can be obtained from the IETF on-line IPR repository at 850 http://www.ietf.org/ipr. 852 The IETF invites any interested party to bring to its attention any 853 copyrights, patents or patent applications, or other proprietary 854 rights that may cover technology that may be required to implement 855 this standard. Please address the information to the IETF at 856 ietf-ipr@ietf.org. 858 Disclaimer of Validity 860 This document and the information contained herein are provided on an 861 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 862 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 863 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 864 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 865 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 866 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 868 Copyright Statement 869 Copyright (C) The Internet Society (2005). This document is subject 870 to the rights, licenses and restrictions contained in BCP 78, and 871 except as set forth therein, the authors retain all their rights. 873 R��8 E�!���7���JO��f�T��0-draft-leroux-pce-pcecp-multiarea-reqs-00.txt@ 0 �-G���@0�s;G���77.txt7 7-draft-leroux-pce-pcecp-multiarea-reqs-00.txt 875 � 876 ��L