idnits 2.17.1 draft-lee-pce-global-concurrent-optimization-00.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 508. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 519. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 526. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 532. ** 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: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 Copyright Line does not match the current year == The document seems to lack the recommended RFC 2119 boilerplate, even if it appears to use RFC 2119 keywords. (The document does seem to have the reference to RFC 2119 which the ID-Checklist requires). -- 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 11, 2006) is 6407 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4657 Summary: 5 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Lee 3 Internet-Draft Huawei Technologies (USA) 4 Intended status: Standards Track D. King 5 Expires: April 14, 2007 Aria Networks 6 E. Oki 7 NTT 8 October 11, 2006 10 Path Computation Element Communication Protocol (PCECP) Requirements for 11 Support of Global Concurrent Optimization 12 draft-lee-pce-global-concurrent-optimization-00.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 23 other groups may also distribute working documents as Internet- 24 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 This Internet-Draft will expire on April 14, 2007. 39 Copyright Notice 41 Copyright (C) The Internet Society (2006). 43 Abstract 45 The Path Computation Element (PCE) is a network component, 46 application, or node that is capable of performing path computations 47 at the request of Path Computation Clients (PCCs). The PCE is 48 applied in Multiprotocol Label Switching Traffic Engineering 49 (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to 50 determine the routes of Label Switched Paths (LSPs) through the 51 network. 53 The Path Computation Element Communication Protocol (PCECP) is 54 specified for communications between PCCs and PCEs, and between 55 cooperating PCEs. This document provides application-specific 56 requirements for the PCECP in support of a large-scale concurrent 57 path computation application. 59 Table of Contents 61 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 3. Applicability for Global Concurrent Path Computation . . . . . 6 64 3.1. Greenfield Traffic Engineering . . . . . . . . . . . . . . 6 65 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 6 66 3.2.1. Traffic Migration . . . . . . . . . . . . . . . . . . 6 67 3.3. Multi-layer Traffic Engineering . . . . . . . . . . . . . 7 68 3.4. Reconfiguration of the Virtual Network Topology (VNT) . . 7 69 3.5. The PCE Application Architecture . . . . . . . . . . . . . 7 70 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 9 71 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 72 6. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 13 73 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 14 74 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 15 75 8.1. Normative References . . . . . . . . . . . . . . . . . . . 15 76 8.2. Informative References . . . . . . . . . . . . . . . . . . 15 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16 78 Intellectual Property and Copyright Statements . . . . . . . . . . 17 80 1. Terminology 82 The terminology explained herein complies with [RFC4655]. 84 PCC: Path Computation Client: Any client application requesting a 85 path computation to be performed by a Path Computation Element. 87 PCE: Path Computation Element: An entity (component, application or 88 network node) that is capable of computing a network path or route 89 based on a network graph and applying computational constraints. 91 TED: Traffic Engineering Database which contains the topology and 92 resource information of the domain. The TED may be fed by IGP 93 extensions or potentially by other means. 95 PCECP: The PCE Communications Protocol that is used to communicate 96 path computation requests from PCCs to a PCE, and to return computed 97 paths from the PCE to the PCCs. The PCECP can also be used between 98 cooperating PCEs. 100 Although this is not a protocol specification, the key words "MUST", 101 "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", 102 "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be 103 interpreted as described in RFC 2119 [RFC2119] for clarity of 104 specification of requirements. 106 2. Introduction 108 [RFC4655] defines the PCE Architecture and explains how a PCE may 109 compute the paths of Multiprotocol Label Switching Traffic 110 Engineering (MPLS-TE) and Generalized MPLS (GMPLS) Label Switched 111 Paths (LSPs) at the request of PCCs. A PCC is shown to be any 112 network component that makes such a request and may be a Label 113 Switching Router (LSR) or a Network Management Station (NMS). The 114 PCE, itself, is shown to be located anywhere within the network, and 115 may be within an LSR, an NMS or Operational Support System (OSS), or 116 may be an independent network server. 118 The PCECP is the communications protocol used between PCC and PCE, 119 and may also be used between cooperating PCEs. [RFC4657] sets out 120 the common protocol requirements for the PCECP. Additional 121 application-specific requirements for PCECP are deferred to separate 122 documents. 124 This document provides the PCECP extension requirements in support of 125 a large-scale concurrent path computation application that may arise 126 during network operations. A large-scale concurrent path computation 127 is a path computation application where a large number of TE paths 128 need to be computed concurrently in order to efficiently utilize 129 network resources. The computation method involved with a large- 130 scale concurrent path computation is referred to as global concurrent 131 optimization in this document. Appropriate computation algorithms to 132 perform this type of optimization are out of scope of this document. 134 As new LSPs are added sequentially or removed from the network over 135 time, the global network resources become fragmented and the network 136 no longer provides the optimal use of the available capacity. A 137 large-scale global concurrent path computation would be able to 138 simultaneously consider the entire topology of the network and the 139 complete set of existing LSPs, and their respective constraints, and 140 look to re-optimize the entire network to satisfy all constraints for 141 all LSPs. 143 The need for large-scale concurrent path computation may also arise 144 when network operators need to set up a large number of TE LSPs in 145 their network planning process. All large-scale path computation is 146 typically an off-line computation. This document does not exclude 147 the possibility that network operators might require on-line 148 computation for large-scale concurrent path computation in the event 149 of catastrophic network failures, where large numbers of TE LSPs need 150 to be optimally rerouted in real-time. 152 The off-line computation requirements to support a large number of TE 153 LSPs are quite different from on-line path computation requirements. 155 While on-line path computation is focused on finding a single best 156 path in a timely manner given the prevailing network conditions, a 157 large-scale off-line path computation application involves finding 158 paths for a large number of TE LSPs concurrently to meet a global 159 objective. While off-line computation may not require such stringent 160 time constraints as on-line path computation, the key objective 161 associated with large-scale off-line computation is to efficiently 162 allocate network resources from a global network perspective. While 163 on-line path computation is tactical, off-line large-scale path 164 computation is strategic. 166 As the PCE is envisioned to provide solutions in all path computation 167 matters, it is anticipated that the PCE would provide solutions for 168 large-scale global concurrent path computation needs. 170 Specific algorithms that the PCE may employ are beyond the scope of 171 this document. The main focus of this document is to highlight the 172 PCC-PCE communication needs in support of a large-scale concurrent 173 path computation application. 175 The PCE-PCC requirements addressed herein are specific to the context 176 where the PCE is a specialized PCE that is capable of solving large- 177 scale concurrent path computation applications. Discovery of such 178 capabilities might be desirable and could be achieved through 179 extensions to the PCE discovery mechanisms [PCE-DISCO], but that is 180 out of the scope of this document. 182 3. Applicability for Global Concurrent Path Computation 184 This section discusses scenarios for which global concurrent path 185 computation may be applied. It also discusses how these scenarios 186 apply to the PCE architecture. 188 3.1. Greenfield Traffic Engineering 190 When a new TE network needs to be provisioned from a green-field 191 perspective, large numbers of TE LSPs need to be created based on 192 traffic demand, network topology, service constraints, and network 193 resources. Under this scenario, concurrent computation ability is 194 highly desirable, or required, to utilize network resources in an 195 optimal manner. Sequential path computation could potentially result 196 in sub-optimal use of network resources. 198 3.2. Re-optimization of Existing Networks 200 The need for global concurrent path computation may also arise in 201 existing networks. When an existing TE LSP network experiences sub- 202 optimal use of its resources, the need for re-optimization or 203 reconfiguration may arise. The scope of re-optimization and 204 reconfiguration may vary depending on particular situations. The 205 scope of re-optimization may be limited to bandwidth modification to 206 an existing TE LSP. However, it could well be that a large number of 207 TE LSPs may need to be re-optimized concurrently. In an extreme 208 case, the TE LSPs may need to be globally re-optimized. Note that 209 sequential re-optimization of such TE LSPs is unlikely to produce 210 substantial improvements in overall network optimization except in 211 very sparsely utilized networks. 213 3.2.1. Traffic Migration 215 When migrating from one set of TE LSPs to a reoptimized set of TE 216 LSPs it is important that the traffic be moved without causing 217 disruption. Various techniques exist in MPLS and GMPLS, such as make 218 before break [RFC3209], to establish the new LSPs before tearing down 219 the old LSPs. When multiple LSP routes are changed according to the 220 computed results, some of LSPs may be disrupted due to the resource 221 constraints. Make-before-break action can be considered. PCE may be 222 able to give NMS the orders of LSP rerouting action so that make- 223 before-break can be performed within the limited resources. 225 However, it may be the case that the reoptimization is radical. This 226 could mean that it is not possible to apply make before break in 227 order to migrate from the old LSPs to the new LSPs. In this case a 228 migration strategy is required. A PCE might indicate the order in 229 which reoptimized LSPs must be established and take over from the old 230 LSP, or the PCE might perform the global reoptimization as a series 231 of sub-reoptimizations. 233 3.3. Multi-layer Traffic Engineering 235 When an optical transport layer provides lower-layer traffic 236 engineered LSPs for upper-layer client LSPs via the Hierarchical LSP 237 (H-LSP) mechanism, the operator may desire to pre-establish optical 238 LSPs in the optical transport network [MLN-REQ], this whole 239 multilayer network can be managed using PCE [PCE-MLN]. In this 240 scenario, it is anticipated that a large number of H-LSPs would be 241 created concurrently in such a way as to efficiently utilize network 242 resources in the lower-layer network. Again, concurrent path 243 computation capability would result in more efficient network 244 resource utilization than sequential path computation. 246 3.4. Reconfiguration of the Virtual Network Topology (VNT) 248 A set of one or more of lower-layer LSPs providing information for 249 efficient path handling in upper-layer(s) can be described as a 250 virtual network topology (VNT)[MLN-REQ]. 252 Reconfiguration of the VNT [MLN-REQ] is another application scenario 253 where global concurrent path computation may be applicable. Triggers 254 for VNT reconfiguration, such as traffic demand changes, network 255 failures, and topological configuration changes, may require a large 256 set of existing LSPs to be re-computed. Again, concurrent path 257 computation capability would result in more efficient network 258 resource utilization than sequential path computation. 260 3.5. The PCE Application Architecture 262 Figure 1 shows how the aforementioned functionality applies to the 263 PCE architecture. It must be observed that the PCC is not 264 necessarily an LSR [RFC4655]. Although Figure 1 shows the PCE as 265 remote from the NMS, it might be collocated with the NMS. 267 Upon receipt of an application request (e.g., traffic demand matrix 268 is provided to the NMS by operator's planning procedure), the NMS 269 requests a global concurrent path computation to the PCE. The PCE 270 would then compute the requested paths concurrently applying some 271 algorithm(s). When the requested path computation completes, the PCE 272 would then send the resulting paths back to the NMS. The NMS would 273 supply the the head-end LSR with a fully computed explicit path for 274 each TE LSP that needs to be established. 276 ----------- 277 Application | ----- | 278 Request | | TED | | 279 | | ----- | 280 v | | | 281 ------------- Request/ | v | 282 | | Response| ----- | 283 | NMS |<--------+> | PCE | | 284 | | | ----- | 285 ------------- ----------- 286 Service | 287 Request | 288 v 289 ---------- Signaling ---------- 290 | Head-End | Protocol | Adjacent | 291 | Node |<---------->| Node | 292 ---------- ---------- 294 Figure 1 296 4. PCECP Requirements 298 This section provides the PCECP requirements in support of a large- 299 scale concurrent path computation application. The requirements 300 specified herein should be regarded as application-specific 301 requirements and are justifiable based on the extensibility clause 302 found in section 6.1.14 of [RFC4657]: 304 The PCECP MUST support the requirements specified in the application- 305 specific requirements documents. The PCECP MUST also allow 306 extensions as more PCE applications will be introduced in the future. 308 It is also to be noted that some of the requirements discussed in 309 this section have discussed in the PCECP requirement document 310 [RFC4657]. For example, Section 5.1.16 in [RFC4657] provides a list 311 of generic constraints while Section 5.1.17 in [RFC4657] provides a 312 list of generic objective functions that MUST be supported by the 313 PCECP. While using such generic requirements as the baseline, this 314 section provides application-specific requirements in the context of 315 global concurrent path computation. 317 The PCECP SHOULD support the following capabilities either via 318 creation of new objects and/or modification of existing objects where 319 applicable. 321 o An indicator to convey that the request is a global concurrent 322 path computation. This indicator is necessary to ensure 323 consistency in applying global objectives and global constraints 324 in all path computations. 326 o Global Objective Function (GOF) field in which to specify the 327 global objective function. The global objective function is the 328 overarching objective function to which all individual path 329 computation requests are subjected in order to find a globally 330 optimal solution. A list of available global objective functions 331 SHOULD include the following objective functions at the minimum 332 and SHOULD be expandable for future addition: 334 * Minimize the sum of all TE LSP costs (min cost) 336 * Minimize the most utilized TE LSP (min max utilization) 338 o Global Constraints (GC) field in which to specify the list of 339 global constraints to which all the requested path computations 340 should be subjected. This list SHOULD include the following 341 constraints at the minimum and SHOULD be expandable for future 342 addition: 344 * Maximum link utilization parameter indicators for all links 345 (Note: to avoid floating point number, indicators may be 346 integer values that indicate maximum link utilization to which 347 all links should be subjected. Granularity and other details 348 are subject to further study) 350 * Minimum link utilization parameter indicators for all links 351 (Note: same as above) 353 * Maximum number of hops for all the LSPs 355 * Exclusion of links/nodes in all LSP path computation (i.e., All 356 LSPs should not include the specified links/nodes in the path) 358 * An indication should be available in a path computation 359 response that further reoptimization may only become available 360 once existing traffic has been moved to the new LSPs. 362 * A list of existing or known TE LSPs should be kept intact 363 without any modification, i.e. LSPs that are not subject to 364 reoptimization computation. This capability would be useful in 365 minimizing disruption when a global reconfiguration may need to 366 takes place. 368 o Global Concurrent Vector (GCV) field in which to specify all the 369 individual path computation requests that are subject to 370 concurrent path computation and subject to the global objective 371 function and all of the global constraints. 373 o An indicator field in which to indicate the outcome of the 374 request. When the PCE could not find a feasible solution with the 375 initial request, the reason for infeasibility SHOULD be indicated. 376 The following indicators SHOULD be supported at the minimum: 378 * no feasible solution found 380 * memory overflow 382 * PCE too busy 384 * PCE not capable of concurrent reoptimization 386 * no data migration path available 388 * administrative privileges do not allow global reoptimization 390 o Multi-Session Indicator field in the case where the original 391 request is sub-divided into multiple sessions. This case may 392 arise when the reason for infeasibility of the original request is 393 due to mathematically infeasible, or due to memory overflow, the 394 PCC may follow up with subsequent actions under a local policy. 395 The PCC may decide to scale down the original request into several 396 sessions and make requests to the PCE in several sessions. The 397 reason for this is to find a partial feasible solution in the 398 absence of optimal solution. 400 * Multi-Session Indicator 402 * The list of existing TE LSPs that should be kept without any 403 modification. Note that this may be indicated in the 404 aforementioned Global Constraints (GC) field. During multiple 405 sessions of path computation, the successfully computed paths 406 from the PCE to the PCC in a session should be indicated as the 407 constraint (i.e., as the TE LSPs that should be kept) in the 408 next session computation by the PCE so that the PCE may avoid 409 double booking. If the PCE is stateless PCE, this indication 410 is essential. 412 5. Security Considerations 414 When global re-optimization is applied to an active network, it could 415 be extremely disruptive. Although the real security and policy 416 issues apply at the NMS, if the wrong results are returned to the 417 NMS, the wrong actions may be taken in the network. Therefore, it is 418 very important that the operator issuing the commands has sufficient 419 authority and is authenticated, and that the computation request is 420 subject to appropriate policy. 422 6. Acknowledgements 424 We would like to thank Adrian Farrel, Jerry Ash and Lucy Yong for 425 their useful comments and suggestions. 427 7. IANA Considerations 429 There are no IANA actions requested in this specification. 431 8. References 433 8.1. Normative References 435 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 436 Requirement Levels", BCP 14, RFC 2119, March 1997. 438 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 439 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 440 Tunnels", RFC 3209, December 2001. 442 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 443 Element (PCE)-Based Architecture", RFC 4655, August 2006. 445 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 446 Communication Protocol Generic Requirements", RFC 4657, 447 September 2006. 449 8.2. Informative References 451 [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- 452 region and multi-layer networks (MRN/MLN)", 453 draft-ietf-ccamp-gmpls-mln-reqs, work in progress. 455 [PCE-DISCO] 456 Le Roux, J., "Requirements for Path Computation Element 457 (PCE) Discovery", draft-ietf-pce-discovery-reqs, work in 458 progress. 460 [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- 461 based inter-layer MPLS and GMPL traffic engineering", 462 draft-ietf-pce-inter-layer-frwk, work in progress. 464 Authors' Addresses 466 Young Lee 467 Huawei Technologies (USA) 468 1700 Alma Drive, Suite 100 469 Plano, TX 75075 470 US 472 Phone: +1 972 509 5599 x2240 473 Fax: +1 469 229 5397 474 Email: ylee@huawei.com 476 Daniel King 477 Aria Networks 478 44/45 Market Place 479 Chippenham SN15 3HU 480 United Kingdom 482 Phone: +44 7790 775187 483 Fax: +44 1249 446530 484 Email: daniel.king@aria-networks.com 486 Eiji Oki 487 NTT 488 Midori 3-9-11 489 Musashino, Tokyo 180-8585 490 JAPAN 492 Email: oki.eiji@lab.ntt.co.jp 494 Full Copyright Statement 496 Copyright (C) The Internet Society (2006). 498 This document is subject to the rights, licenses and restrictions 499 contained in BCP 78, and except as set forth therein, the authors 500 retain all their rights. 502 This document and the information contained herein are provided on an 503 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 504 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 505 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 506 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 507 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 508 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 510 Intellectual Property 512 The IETF takes no position regarding the validity or scope of any 513 Intellectual Property Rights or other rights that might be claimed to 514 pertain to the implementation or use of the technology described in 515 this document or the extent to which any license under such rights 516 might or might not be available; nor does it represent that it has 517 made any independent effort to identify any such rights. Information 518 on the procedures with respect to rights in RFC documents can be 519 found in BCP 78 and BCP 79. 521 Copies of IPR disclosures made to the IETF Secretariat and any 522 assurances of licenses to be made available, or the result of an 523 attempt made to obtain a general license or permission for the use of 524 such proprietary rights by implementers or users of this 525 specification can be obtained from the IETF on-line IPR repository at 526 http://www.ietf.org/ipr. 528 The IETF invites any interested party to bring to its attention any 529 copyrights, patents or patent applications, or other proprietary 530 rights that may cover technology that may be required to implement 531 this standard. Please address the information to the IETF at 532 ietf-ipr@ietf.org. 534 Acknowledgment 536 Funding for the RFC Editor function is provided by the IETF 537 Administrative Support Activity (IASA).