idnits 2.17.00 (12 Aug 2021) /tmp/idnits14743/draft-ietf-pce-pcecp-interarea-reqs-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 525. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 501. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 514. 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? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an Authors' Addresses Section. 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 (December 2006) is 5629 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 402, but no explicit reference was found in the text == Outdated reference: draft-ietf-pce-policy-enabled-path-comp has been published as RFC 5394 Summary: 3 errors (**), 0 flaws (~~), 3 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group J.-L. Le Roux (Editor) 3 Internet Draft France Telecom 5 Category: Informational 6 Expires: June 2007 7 December 2006 9 PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area 10 Multi Protocol Label Switching (MPLS) and Generalized MPLS (GMPLS) 11 Traffic Engineering 13 draft-ietf-pce-pcecp-interarea-reqs-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 other 24 groups may also distribute working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 For scalability purposes a network may comprise multiple Interior 40 Gateway Protocol (IGP) areas. An inter-area Traffic Engineered-Label 41 Switched Path (TE-LSP) is an LSP that transits through at least two 42 IGP areas. In a multi-area network, topology visibility remains local 43 to a given area, and a head-end Label Switching Router (LSR) cannot 44 compute an inter-area shortest constrained path. One key application 45 of the Path Computation Element (PCE) based architecture is the 46 computation of inter-area TE-LSP paths. The PCE Communication 47 Protocol (PCECP) is used to communicate computation requests from 48 Path Computation Clients (PCC) to PCEs, and to return computed paths 49 in responses. This document lists a detailed set of PCECP specific 50 requirements for support of inter-area TE-LSP path computation. It 51 complements the generic requirements for a PCE Communication 52 Protocol. 54 Conventions used in this document 56 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 57 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 58 document are to be interpreted as described in RFC-2119. 60 Table of Contents 62 1. Terminology.................................................3 63 2. Introduction................................................3 64 3. Motivations for PCE-based Inter-Area Path Computation.......4 65 4. Detailed Inter-Area Specific Requirements on PCECP..........5 66 4.1. Control and Recording of Area Crossing......................5 67 4.2. Area Recording..............................................5 68 4.3. Strict Explicit Path and Loose Path.........................6 69 4.4. PCE-list Enforcement and Recording in Multiple PCE 70 Computation...............................................6 71 4.5. Inclusion of Area IDs in Request............................6 72 4.6. Area Inclusion/Exclusion....................................7 73 4.7. Inter-area Diverse Path computation.........................7 74 4.8. Inter-area Policies.........................................8 75 4.9. Loop Avoidance..............................................8 76 5. Manageability Considerations................................8 77 6. Security Considerations.....................................8 78 7. Acknowledgments.............................................9 79 8. IANA Considerations.........................................9 80 9. References..................................................9 81 9.1. Normative References........................................9 82 9.2. Informative References......................................9 83 10. Editor Address:.............................................9 84 11. Contributors' Addresses....................................10 85 12. Intellectual Property Statement............................11 87 1. Terminology 89 LSR: Label Switching Router. 91 LSP: MPLS Label Switched Path. 93 TE-LSP: Traffic Engineering Label Switched Path. 95 IGP area: OSPF Area or IS-IS level. 97 ABR: IGP Area Border Router, a router that is attached to more 98 than one IGP areas (ABR in OSPF or L1/L2 router in IS-IS). 100 Inter-Area TE LSP: TE LSP that traverses more than one IGP area. 102 CSPF: Constrained Shortest Path First. 104 SRLG: Shared Risk Link Group. 106 PCE: Path Computation Element: an entity (component, application 107 or network node) that is capable of computing a network path or 108 route based on a network graph and applying computational 109 constraints. 111 PCC: Path Computation Client, any application that request path 112 computation to be performed by a PCE. 114 PCECP: PCE Communication Protocol, a protocol for communication 115 between PCCs and PCEs, and between PCEs. 117 ERO: RSVP-TE Explicit Route Object. It encodes the explicit path 118 followed by a TE-LSP. 120 2. Introduction 122 [RFC4105] lists a set of motivations and requirements for setting up 123 TE-LSPs across IGP area boundaries. These LSPs are called inter-area 124 TE-LSPs. These requirements include the computation of inter- 125 area shortest constrained paths with key guideline being to respect 126 the IGP hierarchy concept, and particularly the containment of 127 topology information. The main challenge with inter-area MPLS-TE lies 128 in path computation. Indeed the head-end LSR cannot compute an 129 explicit path across areas, as its topology visibility is limited to 130 its own area. 132 Inter-area path computation is one of the key applications of the PCE 133 based architecture [RFC4655]. The computation of optimal inter-area 134 paths may be achieved using the services of one or more PCEs. 136 Such PCE-based inter-area path computation could rely for instance on 137 a single multi-area PCE that has the TE database of all the areas in 138 the IGP domain and can directly compute an end-to-end constrained 139 shortest path. Alternatively, this could rely on the cooperation 140 between PCEs whereby each PCE covers one or more IGP areas and the 141 full set of PCEs covers all areas. 143 The generic requirements for a PCE Communication Protocol (PCECP), 144 which allows a PCC to send path computation requests to a PCE and the 145 PCE to send path computation responses to a PCC, are set forth in 146 [RFC4657]. The use of a PCE-based approach for inter-area path 147 computation implies specific requirements on a PCE Communication 148 Protocol, in addition to the generic requirements already listed in 149 [RFC4657]. This document complements these generic requirements by 150 listing a detailed set of PCECP requirements specific to inter-area 151 path computation. 153 It is expected that PCECP procedures be defined to satisfy these 154 requirements. 156 Note that PCE-based inter-area path computation may require a 157 mechanism for automatic PCE discovery across areas, which is out of 158 the scope of this document. Detailed requirements for such a 159 mechanism are discussed in [RFC4674]. 161 3. Motivations for PCE-based Inter-Area Path Computation 163 IGP hierarchy enables improved IGP scalability, by dividing the IGP 164 domain into areas and limiting the flooding scope of topology 165 information to within area boundaries. A router in an area has full 166 topology information for its own area but only information about 167 reachability to destinations in other areas._ Thus, a head-end LSR 168 cannot compute an end-to-end path that crosses the boundary of its 169 IGP area(s). 171 A current solution for computing inter-area TE-LSP path relies on a 172 per domain path computation ([PD-COMP]). It is based on loose hop 173 routing with an ERO expansion on each ABR. This allows an LSP to be 174 set up following a constrained path, but faces two major limitations: 175 - This does guarantee the use of an optimal constrained path; 176 - This may lead to several crankback signaling messages and hence 177 delay the LSP setup, and may also invoke possible alternate routing 178 activities. 180 Note that, here, by optimal constrained path we mean the shortest 181 constrained path across multiple areas, taking into account either 182 the IGP or TE metric [METRIC]. In other words, such a path is the 183 path that would have been computed by making use of some CSPF 184 algorithm in the absence of multiple IGP areas. 186 The PCE based architecture [RFC4655] is well suited to inter-area 187 path computation, as it allows the path computation limitations 188 resulting from the limited topology visibility to be overcome by 189 introducing path computation entities with more topology visibility, 190 or by allowing cooperation between path computation entities in each 191 area. 193 There are two main approaches for the computation of an inter-area 194 optimal path: 195 - Single PCE computation: The path is computed by a single PCE that 196 has topology visibility in all areas and can compute an end- 197 to-end optimal constrained path on its own. 198 - Multiple PCE computation with inter-PCE communication: The path 199 computation is distributed on multiple PCEs, which have partial 200 topology visibility. They compute path segments in their domains of 201 visibility and collaborate with each other so as to arrive at an 202 end-to-end optimal constrained path. Such collaboration is ensured 203 thanks to inter-PCE communication. 205 Note that the use of a PCE-based approach, to perform inter-area path 206 computation implies specific functional requirements in a PCECP, in 207 addition to the generic requirements listed in [RFC4657]. These 208 specific requirements are discussed in next section. 210 4. Detailed Inter-Area Specific Requirements on PCECP 212 This section lists a set of additional requirements for the PCECP 213 that complement requirements listed in [RFC4657] and are specific to 214 inter-area (G)MPLS TE path computation. 216 4.1. Control and Recording of Area Crossing 218 In addition to the path constraints specified in [RFC4657], the 219 request message MUST allow indicating whether area crossing is 220 allowed or not. Indeed, when the source and destination reside in the 221 same IGP area, there may be intra-area and inter-area feasible paths. 222 As set forth in [RFC4105], if the shortest path is an inter-area 223 path, an operator either may want to avoid, as far as possible, 224 crossing areas and thus may prefer selecting a sub-optimal intra-area 225 path or, conversely, may prefer to use a shortest path, even if it 226 crosses areas. 228 Also, when the source and destination reside in the same area it may 229 be useful to know whether the returned path is an inter-area path. 230 Hence the response message MUST allow indicating whether the computed 231 path is crossing areas. 233 4.2. Area Recording 235 It may be useful for the PCC to know the set of areas crossed by an 236 inter-area path and the corresponding path segments. Hence the 237 response message MUST allow identifying the crossed areas. Also the 238 response message MUST allow segmenting the returned path and marking 239 each segment so that it is possible to tell which piece of the path 240 lie within which area. 242 4.3. Strict Explicit Path and Loose Path 244 A Strict Explicit Path is defined as a set of strict hops, while a 245 Loose Path is defined as a set of at least one loose hop and zero, 246 one or more strict hops. An inter-area path may be strictly explicit 247 or loose (e.g. a list of ABRs as loose hops). It may be useful to 248 indicate to the PCE if a Strict Explicit path is required or not. 249 Hence the PCECP request message MUST allow indicating whether a 250 Strict Explicit Path is required/desired. 252 4.4. PCE-list Enforcement and Recording in Multiple PCE Computation 254 In case of multiple-PCE inter-area path computation, a PCC may want 255 to indicate a preferred list of PCEs to be used, one per area. 256 In each area the preferred PCE should be tried before another PCE be 257 selected. Note that if there is no preferred PCE indicated for an 258 area, any PCE in that area may be used. 260 Hence the PCECP request message MUST support the inclusion of a list 261 of preferred PCEs per area. Note that this requires that a PCC in one 262 area have knowledge of PCEs in other areas. This could rely on 263 configuration or on a PCE discovery mechanism, allowing discovery 264 across area boundaries (see [RFC4674]). 266 Also it would be useful to know the list of PCEs which effectively 267 participated in the computation. Hence the request message MUST 268 support a request for PCE recording and the response message MUST 269 support the recording of the set of one or more PCEs that took part 270 in the computation. 272 It may also be useful to know the path segments computed by each PCE. 273 Hence the request message SHOULD allow a request for the 274 identification of path segments computed by a PCE, and the response 275 message SHOULD allow identifying the path segments computed by each 276 PCE. 278 4.5. Inclusion of Area IDs in Request 280 The knowledge of the areas in which the source and destination lie 281 would allow a PCE to select an appropriate downstream PCE. This would 282 be useful when the area ID(s) of a PCE (i.e. the area(s) where it has 283 visibility) is/are known, which can be achieved by the PCE Discovery 284 Protocol (see [RFC4674]) or any other mean. 286 A PCE may not have any visibility of the source/destination area and 287 hence may not be able to determine the area of the 288 source/destination. In such a situation it would be useful that a PCC 289 indicates the source and destination area IDs in its request message. 291 For that purpose the request message MUST support the inclusion of 292 the source and destination area IDs. Note that this information could 293 be learned by the PCC through configuration. 295 4.6. Area Inclusion/Exclusion 297 In some situations, it may be useful that the request message 298 indicate one or more area(s) that must be followed by the path to be 299 computed. It may also be useful that the request message indicate one 300 or more area(s) that must be avoided by the path to be computed (e.g. 301 request for a path between LSRs in two stub areas connected to the 302 same ABR(s), which must not cross the backbone area). Hence the 303 request message MUST allow indicating a set of one or more area(s) 304 that must be explicitly included in the path, and a set of one or 305 more area(s) that must be explicitly excluded from the path. 307 4.7. Inter-area Diverse Path computation 309 For various reasons, including protection and load balancing, the 310 computation of diverse inter-area paths may be required. 311 There are various levels of diversity in an inter-area context: 312 -Per-area diversity (intra-area path segments are link, node or 313 SRLG disjoint) 314 -Inter-area diversity (end-to-end inter-area paths are link, 315 node or SRLG disjoint) 317 Note that two paths may be disjoint in the backbone area but non- 318 disjoint in peripheral areas. Also two paths may be node disjoint 319 within areas but may share ABRs, in which case path segments within 320 an area are node disjoint but end-to-end paths are not node-disjoint. 322 The request message MUST allow requesting the computation of a set of 323 inter-area diverse paths between the same node pair or between 324 distinct node pairs. It MUST allow indicating the required level of 325 diversity of a set of inter-area paths (link, node, SRLG diversity), 326 as well as the required level of diversity of a set of intra-area 327 segments of inter-area paths (link, node, SRLG diversity) on a per- 328 area basis. 330 The response message MUST allow indicating the level of diversity of 331 a set of computed inter-area loose paths (link, node, SRLG 332 diversity), globally, and on a per-area basis (link, node, SRLG 333 diversity of intra-area path segments). 335 Note that, in order to ensure SRLG consistency, SRLG identifiers 336 within the IGP domain should be assigned and allocated by the same 337 entity. 339 Note that specific objective functions may be requested for diverse 340 path computation, such as minimizing the cumulated cost of a set of 341 diverse paths as set forth in [RFC4657]. 343 4.8. Inter-area Policies 345 In addition to the policy requirements discussed in [RFC4657], the 346 application of inter-area path computation policies requires some 347 additional information to be carried in the PCECP request messages. 348 The request message MUST allow for the inclusion of the address of 349 the originating PCC. This may be useful in a multiple PCE 350 computation, so as to apply policies not only based on the PCECP peer 351 but also based on the originating PCC. 353 Note that work on supported policy models and the corresponding 354 requirements/implications is being undertaken as a separate work item 355 in the PCE working group ([PCE-POL-FMWK]). 357 4.9. Loop Avoidance 359 In case of multiple-PCE inter-area path computation, there may be 360 risks of PCECP request loops. A mechanism MUST be defined to detect 361 and correct PCECP request message loops. This may rely, for instance, 362 on the recording, in the request message, of the set of traversed 363 PCEs. 365 Also the returned path in a response message MUST be loop free. 367 5. Manageability Considerations 369 The inter-area application implies some new manageability 370 requirements in addition to those already listed in [RFC4657]. The 371 PCECP PCC and PCE MIB modules MUST allow recording the proportion of 372 inter-area requests and the success rate of inter-area requests. The 373 PCEP PCC MIB module MUST also allow recording the performances of a 374 PCE chain (minimum, maximum and average response time), in case of 375 multiple-PCE inter-area path computation. 377 A built in diagnostic tool MUST be defined to monitor the 378 performances of a PCE chain, in case of multiple-PCE inter-area path 379 computation. It MUST allow determining the minimum maximum and 380 average response time globally for the chain, and on a per PCE basis. 382 6. Security Considerations 384 IGP areas are administrated by the same entity. Hence the inter-area 385 application does not imply a new trust model, or new security issues 386 beyond those already defined in [RFC4657]. 388 7. Acknowledgments 390 We would also like to thank Adrian Farrel, Jean-Philippe Vasseur, 391 Bruno Decraene, Yannick Le Louedec, Dimitri Papadimitriou and Lou 392 Berger for their useful comments and suggestions. 394 8. IANA Considerations 396 This document makes no requests for IANA action. 398 9. References 400 9.1. Normative References 402 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 403 Requirement Levels", BCP 14, RFC 2119, March 1997. 405 [RFC4105] Le Roux J.L., Vasseur J.P., Boyle, J., et al. "Requirements 406 for inter-area MPLS-TE" RFC 4105, June 2005. 408 [RFC4655] A. Farrel, JP. Vasseur and J. Ash, "Path Computation 409 Element (PCE) Based Architecture", RFC4655, August 2006. 411 [RFC4657] J. Ash, J.L Le Roux et. al., "PCE Communication Protocol 412 Generic Requirements", RFC4657, September 2006. 414 9.2. Informative References 416 [RFC4674] J.L. Le Roux et. al., "Requirements for Path Computation 417 Element (PCE) Discovery", RFC4674, October 2006. 419 [PD-COMP] Vasseur, J.P., Ayyangar, A., Zhang, R., "A Per-domain path 420 computation method for computing Inter-domain Traffic Engineering 421 (TE) Label Switched Path (LSP)", work in progress. 423 [PCE-POL-FMWK] I. Bryskin, D. Papadimitriou, L. Berger "Policy- 424 Enabled Path Computation Framework", draft-ietf-pce-policy-enabled- 425 path-comp, work in progress. 427 [METRIC] Le Faucheur et al., "Use of Interior Gateway Protocol (IGP) 428 Metric as a second MPLS Traffic Engineering (TE) Metric", RFC3785, 429 May 2004. 431 10. Editor Address: 433 Jean-Louis Le Roux 434 France Telecom 435 2, avenue Pierre-Marzin 436 22307 Lannion Cedex 437 FRANCE 438 Email: jeanlouis.leroux@orange-ftgroup.com 440 11. Contributors' Addresses 442 Jerry Ash 443 AT&T 444 Room MT D5-2A01 445 200 Laurel Avenue 446 Middletown, NJ 07748, USA 447 Phone: +1-(732)-420-4578 448 Email: gash@att.com 450 Nabil Bitar 451 Verizon 452 40 Sylvan Road 453 Waltham, MA 02145 454 Email: nabil.bitar@verizon.com 456 Dean Cheng 457 Cisco Systems Inc. 458 3700 Cisco Way 459 San Jose CA 95134 USA 460 Phone: +1 408 527 0677 461 Email: dcheng@cisco.com 463 Kenji Kumaki 464 KDDI Corporation 465 Garden Air Tower 466 Iidabashi, Chiyoda-ku, 467 Tokyo 102-8460, JAPAN 468 Phone: +81-3-6678-3103 469 Email: ke-kumaki@kddi.com 471 Eiji Oki 472 NTT 473 Midori-cho 3-9-11 474 Musashino-shi, Tokyo 180-8585, JAPAN 475 Email: oki.eiji@lab.ntt.co.jp 477 Raymond Zhang 478 BT 479 2160 E. Grand Ave. 480 El Segundo, CA 90245 481 USA 482 raymond.zhang@bt.com 484 Renhai Zhang 485 Huawei Technologies 486 No. 3 Xinxi Road, Shangdi, 487 Haidian District, 488 Beijing City, 489 P. R. China 490 Email: zhangrenhai@huawei.com 492 12. Intellectual Property Statement 494 The IETF takes no position regarding the validity or scope of any 495 Intellectual Property Rights or other rights that might be claimed to 496 pertain to the implementation or use of the technology described in 497 this document or the extent to which any license under such rights 498 might or might not be available; nor does it represent that it has 499 made any independent effort to identify any such rights. Information 500 on the procedures with respect to rights in RFC documents can be 501 found in BCP 78 and BCP 79. 503 Copies of IPR disclosures made to the IETF Secretariat and any 504 assurances of licenses to be made available, or the result of an 505 attempt made to obtain a general license or permission for the use of 506 such proprietary rights by implementers or users of this 507 specification can be obtained from the IETF on-line IPR repository at 508 http://www.ietf.org/ipr. 510 The IETF invites any interested party to bring to its attention any 511 copyrights, patents or patent applications, or other proprietary 512 rights that may cover technology that may be required to implement 513 this standard. Please address the information to the IETF at 514 ietf-ipr@ietf.org. 516 Disclaimer of Validity 518 This document and the information contained herein are provided 519 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 520 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 521 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 522 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 523 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 524 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 525 FOR A PARTICULAR PURPOSE. 527 Copyright Statement 529 Copyright (C) The IETF Trust (2006). This document is subject to the 530 rights, licenses and restrictions contained in BCP 78, and except as 531 set forth therein, the authors retain all their rights.