idnits 2.17.1 draft-ietf-pce-pcecp-interarea-reqs-01.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 19. -- Found old boilerplate from RFC 3978, Section 5.5 on line 470. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 447. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 454. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 460. ** 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 6 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. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (February 2006) is 6645 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Missing Reference: 'PCE-DISCO-REQ' is mentioned on line 259, but not defined == Unused Reference: 'RFC2119' is defined on line 346, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 349, but no explicit reference was found in the text == Unused Reference: 'BCP79' is defined on line 352, but no explicit reference was found in the text == Unused Reference: 'PCE-DISC-REQ' is defined on line 364, but no explicit reference was found in the text == Unused Reference: 'ID-RSVP' is defined on line 376, 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: 6 errors (**), 0 flaws (~~), 8 warnings (==), 9 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: August 2006 7 February 2006 9 PCE Communication Protocol (PCECP) Specific Requirements for Inter-Area 10 (G)MPLS Traffic Engineering 12 draft-ietf-pce-pcecp-interarea-reqs-01.txt 14 Status of this Memo 16 By submitting this Internet-Draft, each author represents that any 17 applicable patent or other IPR claims of which he or she is aware 18 have been or will be disclosed, and any of which he or she becomes 19 aware will be disclosed, in accordance with Section 6 of BCP 79. 21 Internet-Drafts are working documents of the Internet Engineering 22 Task Force (IETF), its areas, and its working groups. Note that other 23 groups may also distribute working documents as Internet-Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet- Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 Abstract 38 For scalability purposes a network may comprise multiple IGP areas. 39 An inter-area TE-LSP is an LSP that transits through at least two IGP 40 areas. In a multi-area network, topology visibility remains local to 41 a given area, and a head-end LSR cannot compute alone an inter-area 42 shortest constrained path. One key application of the Path 43 Computation Element (PCE) based architecture is the computation of 44 inter-area TE-LSP paths. This document lists a detailed set of PCE 45 Communication Protocol (PCECP) specific requirements for support of 46 inter-area TE-LSP path computation. It complements generic 47 requirements for a PCE Communication Protocol. 49 Conventions used in this document 51 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 52 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 53 document are to be interpreted as described in RFC-2119. 55 Table of Contents 57 1. Contributors................................................3 58 2. Terminology.................................................3 59 3. Introduction................................................3 60 4. Motivations for PCE-based Inter-Area Path Computation.......4 61 5. Detailed Inter-Area Specific Requirements on PCECP..........5 62 5.1. Control of area crossing....................................5 63 5.2. Area Recording..............................................6 64 5.3. Strict Explicit Path and Loose Path.........................6 65 5.4. PCE-list Enforcement and Recording in Multiple PCE 66 Computation.................................................6 67 5.5. Inclusion of Area IDs in Request............................6 68 5.6. Inter-area Diverse Path computation.........................7 69 5.7. Inter-Area Policies.........................................7 70 6. Manageability Considerations................................7 71 7. Security Considerations.....................................8 72 8. Acknowledgments.............................................8 73 9. Informative References......................................8 74 10. Editor Address:.............................................9 75 11. Contributors' Addresses.....................................9 76 12. Intellectual Property Statement............................10 78 1. Contributors 80 The following are the authors that contributed to the present 81 document: 83 Jerry Ash (AT&T) 84 Nabil Bitar (Verizon) 85 Dean Cheng (Cisco) 86 Kenji Kumaki (KDDI) 87 J.L. Le Roux (France Telecom) 88 Eiji Oki (NTT) 89 Raymond Zhang (BT Infonet) 90 Renhai Zhang (Huawei) 92 2. Terminology 94 LSR: Label Switching Router. 96 LSP: MPLS Label Switched Path. 98 TE-LSP: Traffic Engineering Label Switched Path. 100 IGP area: OSPF Area or IS-IS level. 102 ABR: IGP Area Border Router, a router that is attached to more 103 than one IGP areas (ABR in OSPF or L1/L2 router in IS-IS). 105 Inter-Area TE LSP: TE LSP that traverses more than one IGP area. 107 CSPF: Constrained Shortest Path First. 109 SRLG: Shared Risk Link Group. 111 PCE: Path Computation Element: an entity (component, application 112 or network node) that is capable of computing a network path or 113 route based on a network graph and applying computational 114 constraints. 116 PCC: Path Computation Client, any application that request path 117 computation to be performed by a PCE. 119 PCECP: PCE Communication Protocol, a protocol for communication 120 between PCCs and PCEs, and between PCEs. 122 3. Introduction 124 [RFC4105] lists a set of motivations and requirements for setting up 125 TE-LSPs across IGP area boundaries. These LSPs are called inter-area 126 TE-LSPs. These requirements include the computation of inter- 127 area shortest constrained paths with key guideline being to respect 128 the IGP hierarchy concept, and particularly the containment of 129 topology information. The main challenge with inter-area MPLS-TE 130 relies actually on path computation. Indeed the head-end LSR cannot 131 compute a constrained path across areas, as its topology visibility 132 is limited to its own area. 134 Inter-area path computation is one of the key applications of the PCE 135 based architecture [PCE-ARCH]. The computation of optimal inter-area 136 paths may be achieved using the services of one or more PCEs. 137 Such PCE-based inter-area path computation could rely for instance on 138 a single multi-area PCE that has the TE database of all the areas in 139 the IGP domain and can directly compute an end-to-end constrained 140 shortest path. Alternatively, this could rely on the cooperation 141 between PCEs whereby each PCE covers one or more IGP areas and the 142 full set of PCEs covers all areas. 144 The generic requirements for a PCE Communication Protocol (PCECP), 145 which allows a PCC to send path computation requests to a PCE and the 146 PCE to sent path computation responses to a PCC, are set forth in 147 [PCE-COM-REQ]. The use of a PCE-based approach for inter-area path 148 computation implies specific requirements on a PCE Communication 149 Protocol, in addition to the generic requirements already listed in 150 [PCE-COM-REQ]. This document complements these generic requirements 151 by listing a detailed set of PCECP requirements specific to inter- 152 area path computation. 154 It is expected that a solution for a PCECP satisfies these 155 requirements. 157 Note that PCE-based inter-area path computation may require a 158 mechanism for an automatic PCE discovery across areas, which is out 159 of the scope of this document. Detailed requirements for such a 160 mechanism are discussed in [PCE-DISCO-REQ]. 162 4. Motivations for PCE-based Inter-Area Path Computation 164 IGP hierarchy allows improving IGP scalability, by dividing the IGP 165 domain into areas and limiting the flooding scope of topology 166 information to area boundaries. A router in an area has full topology 167 information for its own area but only reachability to destinations in 168 other areas._ Thus, a head-end LSR cannot compute an end-to-end 169 constrained path that traverses more than one IGP area. 171 A solution for computing inter-area TE-LSP path currently 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 can allow setting up 174 a constrained path, but faces two major limitations: 175 - This does not allow computing an optimal constrained path 176 - This may lead to several crankback signaling messages and 177 hence delay the LSP setup, and also invoke possible alternate 178 routing 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 [PCE-ARCH] is well suited to inter-area 187 path computation, as it allows overcoming the path computation 188 limitations resulting from the limited topology visibility, 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 alone compute an end- 197 to-end optimal constrained path. 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 areas 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 [PCE-COM-REQ]. These 208 specific requirements are discussed in next section. 210 5. 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 [PCE-COM-REQ] and are specific 214 to inter-area (G)MPLS TE path computation. 216 5.1. Control of area crossing 218 In addition to the path constraints specified in Section 6.1.16 of 219 [PCE-COM-REQ], the request message MUST allow indicating whether area 220 crossing is allowed or not. 221 Indeed, when the source and destination reside in the same IGP area, 222 there may be intra-area and inter-area feasible paths. As set forth 223 in [RFC4105], if the shortest path is an inter-area path, an operator 224 either may want to avoid, as far as possible, crossing areas and thus 225 may prefer selecting a sub-optimal intra-area path or, conversely, 226 may prefer to use a shortest path, even if it crosses areas. 228 Also, when the source and destinations 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 5.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 support the inclusion of the identifiers of the 238 crossed areas and MUST allow identifying the corresponding path 239 segments. 241 5.3. Strict Explicit Path and Loose Path 243 A Strict Explicit Path is defined as a set of strict hops, while a 244 Loose Path is defined as a set of at least one loose hop and zero, 245 one ore more strict hops. An inter-area path may be strictly explicit 246 or loose (e.g. a list of ABRs as loose hops). It may be useful to 247 indicate to the PCE if a Strict Explicit path is required or not. 248 Hence the PCECP request message MUST allow indicating whether a 249 Strict Explicit Path is required/desired. 251 5.4. PCE-list Enforcement and Recording in Multiple PCE Computation 253 In case of multiple-PCE inter-area path computation, a PCC may want 254 to indicate a preferred list of PCEs to be used. Hence the PCECP 255 request message MUST support the inclusion of a list of preferred 256 PCEs. Note that this requires that a PCC in one area have knowledge 257 of PCEs in other areas. This could rely on configuration or on a PCE 258 discovery mechanism, allowing discovery across area boundaries (see 259 [PCE-DISCO-REQ]). 261 Also it would be useful to know the list of PCEs which effectively 262 participated in the computation. Hence the request message MUST 263 support a request for PCE recording and the response message MUST 264 support the recording of the set of one or more PCEs that took part 265 in the computation. 266 It may also be useful to know the path segments computed by each PCE. 267 Hence the request message SHOULD allow a request for the 268 identification of path segments computed by a PCE, and the response 269 message SHOULD allow identifying the path segments computed by each 270 PCE. 272 5.5. Inclusion of Area IDs in Request 274 The knowledge of the areas in which the source and destination lie 275 would allow selection of appropriate cooperating PCEs. A PCE may not 276 be able to determine the location of the source and destination and 277 in such a case it would be useful that a PCC indicates the source and 278 destination area IDs. 279 For that purpose the request message MUST support the inclusion of 280 the source and destination area IDs. Note that this information could 281 be learned by the PCC through configuration. 283 5.6. Inter-area Diverse Path computation 285 For various reasons, including protection and load balancing, the 286 computation of diverse inter-area paths may be required. 287 There are various levels of diversity in an inter-area context: 288 -Per-area diversity (intra-area path segments are link, node or 289 SRLG disjoint) 290 -Inter-area diversity (end-to-end inter-area paths are link, 291 node or SRLG disjoint) 293 Note that two paths may be disjoint in the backbone area but non- 294 disjoint in peripheral areas. Also two paths may be node disjoint 295 within areas but may share ABRs, in which case path segments within 296 an area are node disjoint but end-to-end paths are not node-disjoint. 298 The request message MUST allow requesting the computation of a set of 299 inter-area diverse paths between the same node pair or between 300 distinct node pairs. It MUST allow indicating the required level of 301 intra-area diversity (link, node, SRLG) on a per area basis, as well 302 as the level of inter-area diversity (shared ABRs or ABR 303 disjointness). 305 The response message MUST allow indicating the level of diversity of 306 a set of computed loose paths. 308 Note that specific objective functions may be requested for diverse 309 path computation, such as minimizing the cumulated cost of a set of 310 diverse paths as set forth in [PCE-COM-REQ]. 312 5.7. Inter-Area Policies 314 As already defined in Section 5.1, a request message MUST allow 315 indicating whether area crossing is allowed or not. 317 A PCE may want to apply policies based on the initiating PCC. 318 In a multiple-PCE computation the address of the initiating PCC may 319 no longer be part of the request messages sent between PCEs. 320 Hence, the request message MUST support the inclusion of the address 321 of the originating PCC. 323 Note that in some cases it is important to contain an inter-area 324 path within a single AS. Hence the request message MUST allow 325 indicating that AS crossing is not authorized. 327 6. Manageability Considerations 329 The inter-area application does not imply new manageability 330 requirements beyond those already defined in [PCE-COM-REQ]. 332 7. Security Considerations 334 IGP areas are administrated by the same entity. Hence the inter-area 335 application does not imply a new trust model, or new security issues 336 beyond those already defined in [PCE-COM-REQ]. 338 8. Acknowledgments 340 We would also like to thank Adrian Farrel, Jean-Philippe Vasseur, 341 Bruno Decraene, Yannick Le Louedec and Dimitri Papadimitriou for 342 their useful comments and suggestions. 344 9. Informative References 346 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 347 Requirement Levels", BCP 14, RFC 2119, March 1997. 349 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 350 3667, February 2004. 352 [BCP79] Bradner, S., "Intellectual Property Rights in IETF 353 Technology", RFC 3979, March 2005. 355 [RFC4105] Le Roux J.L., Vasseur J.P., Boyle, J., et al. "Requirements 356 for inter-area MPLS-TE" RFC 4105, June 2005. 358 [PCE-ARCH] A. Farrel, JP. Vasseur and J. Ash, �Path Computation 359 Element (PCE) Based Architecture�, work in progress. 361 [PCE-COM-REQ] J. Ash, J.L Le Roux et. al., �PCE Communication 362 Protocol Generic Requirements�, work in progress. 364 [PCE-DISC-REQ] J.L. Le Roux et. al., �Requirements for Path 365 Computation Element (PCE) Discovery�, work in progress. 367 [PD-COMP] Vasseur, J.P., Ayyangar, A., Zhang, R., "A Per-domain path 368 computation method for computing Inter-domain Traffic Engineering 369 (TE) Label Switched Path (LSP)", work in progress. 371 [METRIC] Le Faucheur, F., Uppili, R., Vedrenne, A., Merckx, P., 372 and T. Telkamp, "Use of Interior Gateway Protocol(IGP) Metric as a 373 second MPLS Traffic Engineering (TE) Metric", BCP 87, RFC 3785, May 374 2004. 376 [ID-RSVP] Ayyangar, A., Vasseur, J.P., "Inter domain GMPLS Traffic 377 Engineering - RSVP-TE extensions", work in progress. 379 10. Editor Address: 381 Jean-Louis Le Roux 382 France Telecom 383 2, avenue Pierre-Marzin 384 22307 Lannion Cedex 385 FRANCE 386 Email: jeanlouis.leroux@francetelecom.com 388 11. Contributors' Addresses 390 Jerry Ash 391 AT&T 392 Room MT D5-2A01 393 200 Laurel Avenue 394 Middletown, NJ 07748, USA 395 Phone: +1-(732)-420-4578 396 Email: gash@att.com 398 Nabil Bitar 399 Verizon 400 40 Sylvan Road 401 Waltham, MA 02145 402 Email: nabil.bitar@verizon.com 404 Dean Cheng 405 Cisco Systems Inc. 406 3700 Cisco Way 407 San Jose CA 95134 USA 408 Phone: +1 408 527 0677 409 Email: dcheng@cisco.com 411 Kenji Kumaki 412 KDDI Corporation 413 Garden Air Tower 414 Iidabashi, Chiyoda-ku, 415 Tokyo 102-8460, JAPAN 416 Phone: +81-3-6678-3103 417 Email: ke-kumaki@kddi.com 419 Eiji Oki 420 NTT 421 Midori-cho 3-9-11 422 Musashino-shi, Tokyo 180-8585, JAPAN 423 Email: oki.eiji@lab.ntt.co.jp 425 Raymond Zhang 426 BT INFONET Services Corporation 427 2160 E. Grand Ave. 428 El Segundo, CA 90245 USA 429 Email: raymond_zhang@bt.infonet.com 430 Renhai Zhang 431 Huawei Technologies 432 No. 3 Xinxi Road, Shangdi, 433 Haidian District, 434 Beijing City, 435 P. R. China 436 Email: zhangrenhai@huawei.com 438 12. Intellectual Property Statement 440 The IETF takes no position regarding the validity or scope of any 441 Intellectual Property Rights or other rights that might be claimed to 442 pertain to the implementation or use of the technology described in 443 this document or the extent to which any license under such rights 444 might or might not be available; nor does it represent that it has 445 made any independent effort to identify any such rights. Information 446 on the procedures with respect to rights in RFC documents can be 447 found in BCP 78 and BCP 79. 449 Copies of IPR disclosures made to the IETF Secretariat and any 450 assurances of licenses to be made available, or the result of an 451 attempt made to obtain a general license or permission for the use of 452 such proprietary rights by implementers or users of this 453 specification can be obtained from the IETF on-line IPR repository at 454 http://www.ietf.org/ipr. 456 The IETF invites any interested party to bring to its attention any 457 copyrights, patents or patent applications, or other proprietary 458 rights that may cover technology that may be required to implement 459 this standard. Please address the information to the IETF at 460 ietf-ipr@ietf.org. 462 Disclaimer of Validity 464 This document and the information contained herein are provided on an 465 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 466 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 467 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 468 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 469 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 470 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 472 Copyright Statement 474 Copyright (C) The Internet Society (2006). This document is subject 475 to the rights, licenses and restrictions contained in BCP 78, and 476 except as set forth therein, the authors retain all their rights.