idnits 2.17.1 draft-lee-pce-global-concurrent-optimization-02.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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1105. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1116. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1123. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1129. 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 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 (March 2007) is 6251 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: 3 errors (**), 0 flaws (~~), 1 warning (==), 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 4 Intended status: Standards Track JL. Le Roux 5 Expires: September 2, 2007 France Telecom 6 D. King 7 Aria Networks 8 E. Oki 9 NTT 10 March 2007 12 Path Computation Element Communication Protocol (PCECP) Requirements and 13 Protocol Extensions In Support of Global Concurrent Optimization 14 draft-lee-pce-global-concurrent-optimization-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on September 2, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 The Path Computation Element (PCE) is a network component, 48 application, or node that is capable of performing path computations 49 at the request of Path Computation Clients (PCCs). The PCE is 50 applied in Multiprotocol Label Switching Traffic Engineering 51 (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to 52 determine the routes of Label Switched Paths (LSPs) through the 53 network. The Path Computation Element Communication Protocol (PCEP) 54 is specified for communications between PCCs and PCEs, and between 55 cooperating PCEs. 57 When computing or re-optimizing the routes of a set of LSPs through a 58 network it may be advantageous to perform bulk path computations in 59 order to avoid blocking problems and to achieve more optimal network- 60 wide solutions. Such bulk optimization is termed Global Concurrent 61 Optimization (GCO). A Global Concurrent Optimization is able to 62 simultaneously consider the entire topology of the network and the 63 complete set of existing LSPs, and their respective constraints, and 64 look to optimize or re-optimize the entire network to satisfy all 65 constraints for all LSPs. 67 This document provides application-specific requirements and the PCEP 68 extensions in support of a global concurrent path computation 69 application. 71 Table of Contents 73 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 74 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 75 3. Applicability of Global Concurrent Path Computation . . . . . 7 76 3.1. Greenfield Optimization . . . . . . . . . . . . . . . . . 7 77 3.1.1. Single-layer Traffic Engineering . . . . . . . . . . . 7 78 3.1.2. Multi-layer Traffic Engineering . . . . . . . . . . . 8 79 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8 80 3.2.1. Reconfiguration of the Virtual Network Topology 81 (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8 82 3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8 83 3.3. Application of the PCE Architecture . . . . . . . . . . . 9 84 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 85 5. Protocol extensions for support of global concurrent 86 optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 87 5.1. Global Objective Function (GOF) Specification . . . . . . 16 88 5.2. Indication of Global Concurrent Optimization Requests . . 16 89 5.3. Request for the order of LSP . . . . . . . . . . . . . . . 17 90 5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17 91 5.5. Global Constraints (GC) Object . . . . . . . . . . . . . . 19 92 5.6. Multi-Session Processing . . . . . . . . . . . . . . . . . 20 93 5.7. Error Indicator . . . . . . . . . . . . . . . . . . . . . 22 94 5.8. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 22 95 6. Manageability Considerations . . . . . . . . . . . . . . . . . 24 96 6.1. Control of Function and Policy . . . . . . . . . . . . . . 24 97 6.2. Information and Data Models, e.g. MIB module . . . . . . . 24 98 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 24 99 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 24 100 6.5. Requirements on Other Protocols and Functional 101 Components . . . . . . . . . . . . . . . . . . . . . . . . 24 102 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 24 103 6.7. Other Considerations . . . . . . . . . . . . . . . . . . . 24 104 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 105 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 106 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 107 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 108 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 109 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 110 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 111 Intellectual Property and Copyright Statements . . . . . . . . . . 30 113 1. Terminology 115 The terminology explained herein complies with [RFC4655]. 117 PCC: Path Computation Client: Any client application requesting a 118 path computation to be performed by a Path Computation Element. 120 PCE: Path Computation Element: An entity (component, application or 121 network node) that is capable of computing a network path or route 122 based on a network graph and applying computational constraints. 124 TED: Traffic Engineering Database which contains the topology and 125 resource information of the domain. The TED may be fed by IGP 126 extensions or potentially by other means. 128 PCECP: The PCE Communication Protocol: PCECP is the generic abstract 129 idea of a protocol that is used to communicate path computation 130 requests from PCCs to a PCE, and to return computed paths from the 131 PCE to the PCCs. The PCECP can also be used between cooperating 132 PCEs. 134 PCEP: The PCE communication Protocol: PCEP is the actual protocol 135 that implements the PCECP idea. 137 GCO: Global Concurrent Optimization: A concurrent path computation 138 application where a set of TE paths are computed concurrently in 139 order to efficiently utilize network resources. A GCO path 140 computation is able to simultaneously consider the entire topology of 141 the network and the complete set of existing LSPs, and their 142 respective constraints, and look to optimize or re-optimize the 143 entire network to satisfy all constraints for all LSPs. A GCO path 144 computation can also provide an optimal way to migrate from an 145 existing set of LSPs to a repotimized set (Morphing Problem). 147 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 148 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 149 document are to be interpreted as described in RFC 2119 [RFC2119]. 150 These terms are also used in the parts of this document that specify 151 requirements for clarity of specification of those requirements. 153 2. Introduction 155 [RFC4655] defines the PCE based Architecture and explains how a PCE 156 may compute the paths of Multiprotocol Label Switching Traffic 157 Engineering (MPLS-TE) and Generalized MPLS (GMPLS) Label Switched 158 Paths (LSPs) at the request of PCCs. A PCC is shown to be any 159 network component that makes such a request and may be for instance a 160 Label Switching Router (LSR) or a Network Management System (NMS). 161 The PCE, itself, is shown to be located anywhere within the network, 162 and may be within an LSR, an NMS or Operational Support System (OSS), 163 or may be an independent network server. 165 The PCECP is the communication protocol used between PCC and PCE, and 166 may also be used between cooperating PCEs. [RFC4657] sets out the 167 common protocol requirements for the PCECP. Additional application- 168 specific requirements for PCECP are deferred to separate documents. 170 This document provides a set of PCECP extension requirements and 171 solutions in support of concurrent path computation applications that 172 may arise during network operations. A concurrent path computation 173 is a path computation application where a set of TE paths are 174 computed concurrently in order to efficiently utilize network 175 resources. The computation method involved with a concurrent path 176 computation is referred to as global concurrent optimization in this 177 document. Appropriate computation algorithms to perform this type of 178 optimization are out of the scope of this document. 180 As new LSPs are added sequentially or removed from the network over 181 time, the global network resources become fragmented and the network 182 no longer provides the optimal use of the available capacity. A 183 global concurrent path computation is able to simultaneously consider 184 the entire topology of the network and the complete set of existing 185 LSPs, and their respective constraints, and look to re-optimize the 186 entire network to satisfy all constraints for all LSPs. 187 Alternatively, the application may consider a subset of the LSPs 188 and/or a subset of the network topology. 190 The need for a global concurrent path computation may also arise when 191 network operators need to establish a set of TE LSPs in their network 192 planning process. It is also envisioned that network operators might 193 require a global concurrent path computation in the event of 194 catastrophic network failures, where a set of TE LSPs need to be 195 optimally rerouted in real-time. 197 As the PCE is envisioned to provide solutions in all path computation 198 matters, it is anticipated that the PCE would provide solutions for 199 global concurrent path computation needs. 201 The main focus of this document is to highlight the PCC-PCE 202 communication needs in support of a concurrent path computation 203 application and to define protocol extensions to meet those needs. 205 The PCC-PCE requirements addressed herein are specific to the context 206 where the PCE is a specialized PCE that is capable of solving global 207 concurrent path computation applications. Discovery of such 208 capabilities might be desirable and could be achieved through 209 extensions to the PCE discovery mechanisms [RFC4674], but that is out 210 of the scope of this document. 212 3. Applicability of Global Concurrent Path Computation 214 This section discusses scenarios for which global concurrent path 215 computation may be applied. It also discusses how these scenarios 216 apply to the PCE architecture. 218 3.1. Greenfield Optimization 220 When a new TE network needs to be provisioned from a green-field 221 perspective, a set of TE LSPs need to be created based on traffic 222 demand, network topology, service constraints, and network resources. 223 Under this scenario, concurrent computation ability is highly 224 desirable, or required, to utilize network resources in an optimal 225 manner and avoid blocking risks. Sequential path computation could 226 potentially result in sub-optimal use of network resources or even 227 blocking issues. 229 3.1.1. Single-layer Traffic Engineering 231 Greenfield optimization can be applied when layer-specific TE LSPs 232 need to be created from a green-field perspective. For example, 233 MPLS-TE network can be established based on layer 3 specific traffic 234 demand, network topology, and network resources. Greenfield 235 optimization for single-layer traffic engineering can be applied to 236 lower layer networks such as SDH/Sonet, Ethernet Transport, WDM, etc. 238 3.1.1.1. Pre-establishment of the Hierarchical-LSP (H-LSP)in the 239 Transport Network 241 When an optical transport layer provides lower-layer traffic 242 engineered LSPs for upper-layer client LSPs via the Hierarchical LSP 243 (H-LSP) mechanism, the operator may desire to pre-establish optical 244 LSPs in the optical transport network [MLN-REQ]. This whole multi- 245 layer network can be managed using PCE [PCE-MLN]. In this scenario, 246 it is anticipated that a set of H-LSPs would be created concurrently 247 in such a way as to efficiently utilize network resources in the 248 lower-layer network. Again, concurrent path computation capability 249 would result in more efficient network resource utilization than 250 sequential path computation. 252 3.1.1.2. VNT Configuration 254 A set of one or more lower-layer LSPs providing information for 255 efficient path handling in upper-layer(s) can be described as a 256 virtual network topology (VNT)[MLN-REQ]. 258 When the VNT [MLN-REQ] is configured for the first time, greenfield 259 concurrent optimization may well be applied to find a set of LSPs 260 more efficiently than sequential path computation. 262 3.1.2. Multi-layer Traffic Engineering 264 Greenfield optimization is not limited to single-layer traffic 265 engineering. It can also be applied to multi-layer traffic 266 engineering. Both the client and the server layers network resources 267 and topology can be considered simultaneously in setting up a set of 268 TE LSPs that traverse the layer boundary. 270 3.2. Re-optimization of Existing Networks 272 The need for global concurrent path computation may also arise in 273 existing networks. When an existing TE LSP network experiences sub- 274 optimal use of its resources, the need for re-optimization or 275 reconfiguration may arise. The scope of re-optimization and 276 reconfiguration may vary depending on particular situations. The 277 scope of re-optimization may be limited to bandwidth modification to 278 an existing TE LSP. However, it could well be that a set of TE LSPs 279 may need to be re-optimized concurrently. In an extreme case, the TE 280 LSPs may need to be globally re-optimized. Note that sequential re- 281 optimization of such TE LSPs is unlikely to produce substantial 282 improvements in overall network optimization except in very sparsely 283 utilized networks. 285 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) 287 Reconfiguration of the VNT [MLN-REQ] is another application scenario 288 where global concurrent path computation may be applicable. Triggers 289 for VNT reconfiguration, such as traffic demand changes, network 290 failures, and topological configuration changes, may require a large 291 set of existing LSPs to be re-computed. Again, concurrent path 292 computation capability would result in more efficient network 293 resource utilization than sequential path computation. 295 3.2.2. Traffic Migration 297 When migrating from one set of TE LSPs to a reoptimized set of TE 298 LSPs it is important that the traffic be moved without causing 299 disruption. Various techniques exist in MPLS and GMPLS, such as 300 make-before-break [RFC3209], to establish the new LSPs before tearing 301 down the old LSPs. When multiple LSP routes are changed according to 302 the computed results, some of the LSPs may be disrupted due to the 303 resource constraints. In other words, it may prove to be impossible 304 to perform a direct migration from the old LSPs to the new optimal 305 LSPs without disrupting traffic because there are insufficient 306 network resources to support both sets of LSPs when make-before-break 307 is used. However, the PCE may be able to determine an order of LSP 308 rerouting actions so that make-before-break can be performed within 309 the limited resources. 311 However, it may be the case that the reoptimization is radical. This 312 could mean that it is not possible to apply make-before-break in any 313 order to migrate from the old LSPs to the new LSPs. In this case a 314 migration strategy is required that may necessitate LSPs being 315 rerouted using make-before-break onto temporary paths in order to 316 make space for the full reoptimization. A PCE might indicate the 317 order in which reoptimized LSPs must be established and take over 318 from the old LSPs, and may indicate a series of different temporary 319 paths that must be used. Alternatively, the PCE might perform the 320 global reoptimization as a series of sub-reoptimizations by 321 reoptimizing subsets of the total set of LSPs. 323 Note also that during reoptimization, traffic disruption may be 324 allowed for some LSPs carrying low priority services (e.g., Internet 325 traffic) and not allowed for some LSPs carrying mission critical 326 services (e.g., voice traffic). 328 3.3. Application of the PCE Architecture 330 Figure 1 shows how the aforementioned functionality applies within 331 the PCE architecture. It must be observed that the PCC is not 332 necessarily an LSR [RFC4655]. Although Figure 1 shows the PCE as 333 remote from the NMS, it might be collocated with the NMS. 335 Upon receipt of an application request (e.g., a traffic demand matrix 336 is provided to the NMS by the operator's network planning procedure), 337 the NMS requests a global concurrent path computation from the PCE. 338 The PCE then computes the requested paths concurrently applying some 339 algorithms. When the requested path computation completes, the PCE 340 sends the resulting paths back to the NMS. The NMS then supplies the 341 head-end LSRs with a fully computed explicit path for each TE LSP 342 that needs to be established. 344 ----------- 345 Application | ----- | 346 Request | | TED | | 347 | | ----- | 348 v | | | 349 ------------- Request/ | v | 350 | | Response| ----- | 351 | NMS |<--------+> | PCE | | 352 | | | ----- | 353 ------------- ----------- 354 Service | 355 Request | 356 v 357 ---------- Signaling ---------- 358 | Head-End | Protocol | Adjacent | 359 | Node |<---------->| Node | 360 ---------- ---------- 362 Figure 1: PCE-Based Architecture for Global Concurrent Optimization 364 4. PCECP Requirements 366 This section provides the PCECP requirements to support global 367 concurrent path computation applications. The requirements specified 368 here should be regarded as application-specific requirements and are 369 justifiable based on the extensibility clause found in section 6.1.14 370 of [RFC4657]: 372 The PCECP MUST support the requirements specified in the 373 application-specific requirements documents. The PCECP MUST also 374 allow extensions as more PCE applications will be introduced in 375 the future. 377 It is also to be noted that some of the requirements discussed in 378 this section have already been discussed in the PCECP requirement 379 document [RFC4657]. For example, Section 5.1.16 in [RFC4657] 380 provides a list of generic constraints while Section 5.1.17 in 381 [RFC4657] provides a list of generic objective functions that MUST be 382 supported by the PCECP. While using such generic requirements as the 383 baseline, this section provides application-specific requirements in 384 the context of global concurrent path computation and in a more 385 detailed level than the generic requirements. 387 The PCEP SHOULD support the following capabilities either via 388 creation of new objects and/or modification of existing objects where 389 applicable. 391 o An indicator to convey that the request is for a global concurrent 392 path computation. This indicator is necessary to ensure 393 consistency in applying global objectives and global constraints 394 in all path computations. Note: This requirement is covered by 395 "synchronized path computation" in [RFC4655] and [RFC4657]. 396 However, an explicit indicator to request a global concurrent 397 optimization is a new requirement. 399 o A Global Objective Function (GOF) field in which to specify the 400 global objective function. The global objective function is the 401 overarching objective function to which all individual path 402 computation requests are subjected in order to find a globally 403 optimal solution. Note that this requirement is covered by 404 "synchronized objective functions" in section 5.1.7 [RFC4657]. A 405 list of available global objective functions SHOULD include the 406 following objective functions at the minimum and SHOULD be 407 expandable for future addition: 409 * Minimize the sum of all TE LSP costs (min cost) 410 * Maximize the residual bandwidth on the most loaded link 412 * Evenly allocate the network load to achieve the most uniform 413 link utilization across all links (this can be achieved by the 414 following objective function: minimize max over all links 415 {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i 416 and A(i) is the total bandwidth allocated on link i. 418 o A Global Constraints (GC) field in which to specify the list of 419 global constraints to which all the requested path computations 420 should be subjected. This list SHOULD include the following 421 constraints at the minimum and SHOULD be expandable for future 422 addition: 424 * Maximum link utilization value -- This value indicates the 425 highest possible link utilization percentage set for each link. 426 (Note: to avoid floating point numbers, the values should be 427 integer values.) 429 * Minimum link utilization value -- This value indicates the 430 lowest possible link utilization percentage set for each link. 431 (Note: same as above) 433 * Overbooking Factor -- The overbooking factor allows the 434 reserved bandwidth to be overbooked on each link beyond its 435 physical capacity limit. 437 * Maximum number of hops for all the LSPs -- This is the largest 438 number of hops that any LSP can have. Note that this 439 constraint can also be provided on a per LSP basis (as 440 requested in [RFC4657] and defined in [PCEP]). 442 * Exclusion of links/nodes in all LSP path computation (i.e., all 443 LSPs should not include the specified links/nodes in their 444 paths). Note that this constraint can also be provided on a 445 per LSP basis (as requested in [RFC4657] and defined in 446 [PCEP]). 448 * An indication should be available in a path computation 449 response that further reoptimization may only become available 450 once existing traffic has been moved to the new LSPs. 452 o A Global Concurrent Vector (GCV) field in which to specify all the 453 individual path computation requests that are subject to 454 concurrent path computation and subject to the global objective 455 function and all of the global constraints. Note that this 456 requirement is partially fulfilled by the SVEC object in the PCEP 457 specification [PCEP]. Since the SVEC object as defined in [PCEP] 458 allows identifying a set of concurrent path requests, the SVEC can 459 be reused to specify all the individual concurrent path requests 460 for a global concurrent optimization. This can be achieved by 461 defining a new flag in the SVEC object to indicate that this is a 462 global concurrent optimization. 464 o An indicator field in which to indicate the outcome of the 465 request. When the PCE could not find a feasible solution with the 466 initial request, the reason for failure SHOULD be indicated. This 467 requirement is partially covered by [RFC4657], but not in this 468 level of detail. The following indicators SHOULD be supported at 469 the minimum: 471 * no feasible solution found. Note that this is already covered 472 in [PCEP]. 474 * memory overflow 476 * PCE too busy. Note that this is already covered in [PCEP]. 478 * PCE not capable of concurrent reoptimization 480 * no migration path available 482 * administrative privileges do not allow global reoptimization 484 o A Multi-Session Indicator field in the case where the original 485 request is sub-divided into multiple sessions. This case may 486 arise when the reason for failure of the original request is due 487 to mathematical infeasibility, or memory overflow. The PCC may 488 follow up with subsequent actions under a local policy. The 489 motivation for multi-session application is to find a partial 490 feasible solution in the absence of the optimal solution. When 491 the PCC decides to scale down the original request into several 492 sessions, the PCC sends the first session path computation request 493 to the PCE. The next session path computation request is held 494 until the results from the first session would be available. Once 495 the results from the first session are available, the PCC then 496 sends the second session path computation request to the PCE. The 497 same procedure is repeated until the last session of the multi- 498 session has been completed. To support this requirement, it is 499 required that the PCE keep in memory the previously computed paths 500 until all paths of the multi-session have been computed. 502 * Multi-Session Indicator 504 * Multi-Session Sequence Number 505 * The Indication of the Final Session 507 o In order to minimize disruption associated with bulk path 508 provisioning, the following requirements MUST be supported: 510 * The request message MUST allow requesting the PCE to provide 511 the order in which LSPs should be reoptimized (i.e., the 512 migration path) in order to minimize traffic disruption during 513 the migration. That is the request message MUST allow 514 indicating to the PCE that the set of paths that will be 515 provided in the response message (PCRep) has to be ordered. 517 * In response to the "ordering" request from the PCC, the PCE 518 MUST be able to indicate in the response message (PCRep) the 519 order in which LSPs should be reoptimized so as to minimize 520 traffic disruption. It should indicate for each request the 521 order in which the old LSP should be removed and the order in 522 which the new LSP should be setup. If the removal order is 523 lower than the setup order this means that make-before-break 524 cannot be done for this request. 526 * As stated in RFC 4657, the request for a reoptimization MUST 527 support the inclusion of the set of previously computed paths 528 along with their bandwidth. This is to avoid double bandwidth 529 accounting and also this allows running an algorithm that 530 minimizes perturbation and that can compute a migration path 531 (LSP setup/removal orders). This is particularly required for 532 stateless PCEs. 534 * During a migration it may not be possible to do a make-before- 535 break for all existing LSPs. The request message must allow 536 indicating for each request whether make-before-break is 537 required (e.g. Voice traffic) or break-before-make is 538 acceptable (e.g. Internet traffic). The response message must 539 allow indicating LSPs for which make-before-break 540 reoptimization is not possible (this will be deduced from the 541 LSP setup and deletion orders). 543 * During a reoptimization it may be required to move a LSP 544 several times so as to avoid traffic disruption. The response 545 message must allow indicating the path sequence for each 546 request. 548 5. Protocol extensions for support of global concurrent optimization 550 This section provides protocol extensions for support of global 551 concurrent optimization. Protocol extensions discussed in this 552 section are built on [PCEP]. 554 The format of a PCReq message is currently as follows per [PCEP]: 556 ::= 557 [] 558 560 where: 561 ::= [] 562 ::= [] 563 ::= 564 [] 565 [] 566 [] 567 [] 568 [] 569 [] 570 [] 572 The format of a PCReq message after incorporating new requirements 573 for support of global concurrent optimization is as follows: 575 ::= 576 [] 577 579 The is changed as follows: 581 :: = 582 [] 583 [] 584 [] 585 [] 587 Note that in the SVEC-list two new optional objects have been 588 defined: the OF (Objective Function) Object and the GC (Global 589 Constraints) Object. Note also that the XRO is also added as an 590 optional Object in the list. Details of this change will be 591 discussed in the following sections. 593 Note that the OF object is defined in [PCE-OF] and the GC object in 594 this document (see section 5.5). 596 5.1. Global Objective Function (GOF) Specification 598 The global objective function can be specified in the PCEP Objective 599 Function (OF) object, defined in [PCE-OF]. The OF object includes a 600 16 bit Objective Function identifier. As per discussed in [PCEP], 601 objective function identifier code points are managed by IANA. 603 Three global objective functions are defined in this document and 604 their identifier should be assigned by IANA (suggested value) 606 Function 607 Code Description 609 1 Minimize the sum of all TE LSP costs (min cost) 611 2 Maximize the residual bandwidth on the most loaded 612 link 614 3 Evenly allocate the network load to achieve the 615 most uniform link utilization across all links* 617 * Note: This can be achieved by the following objective function: 618 minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link 619 capacity for link i and A(i) is the total bandwidth allocated on link 620 i.) 622 5.2. Indication of Global Concurrent Optimization Requests 624 All the path requests in this application should be indicated so that 625 the global objective function and all of the global constraints are 626 applied to each of the requested path computation. In order to 627 support this requirement, the SVEC object should be modified as 628 follows. 630 C flag (1 bit): This is a new flag in the SVEC object. When C flag 631 is set, this indicates that all of the path requests listed in the 632 body of the SVEC object should be computed applying the global 633 constraints and the global objective function. 635 When the C Flag is set in the SVEC Object, the OF and the GC objects 636 should directly follow the SVEC Object. 638 5.3. Request for the order of LSP 640 In order to minimize disruption associated with bulk path 641 provisioning, the PCC MAY indicate to the PCE that the response MUST 642 be ordered. That is, it MUST include the order in which LSPs MUST be 643 moved so as to minimize traffic disruption. Such indication can be 644 included in the RP object which is revised as follows: 646 0 1 2 3 647 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 649 | Reserved | Flags |D|M|F|O|B|R| Pri | 650 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 651 | Request-ID-number | 652 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 653 | | 654 // Optional TLV(s) // 655 | | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 658 Figure 5: RP object body format in the PCReq Message 660 D bit (orDer - 1 bit): when set, in a PCReq message, the requesting 661 PCC requires the PCE to specify in the PCRep message the order in 662 which this particular path request is to be provisioned relative to 663 other requests. 665 M bit (Make-before-break - 1 bit): when set, this indicates that a 666 make-before-break reoptimization is required for this request. 668 When M bit is not set, this implies that a break-before-make 669 reoptimization is allowed for this request. Note that M bit can be 670 set only if the R flag is set. 672 All other fields are unchanged from [PCEP]. 674 5.4. The Order Response 676 The PCE MUST specify the order number in response to the Order 677 Request made by the PCC in the PCReq message if so requested by the 678 setting of the D bit in the RP object in the PCReq message. The 679 format of the RP object body to be included in the PCRep message is 680 modified as follows: 682 0 1 2 3 683 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Reserved | Flags |D|M|F|O|B|R| Pri | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Request-ID-number | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 689 | | 690 // Order TLV (Optional TLV) // 691 | | 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 694 Figure 6: RP object body format in the PCRep Message 696 The Order TLV is an optional TLV in the RP object, that indicates the 697 order in which the old LSP must be removed and the new LSP must be 698 setup during a reoptimization. It is carried in the PCRep message in 699 response to a reoptimization request. 701 The Order TLV SHOULD be included in the RP object in the PCRep 702 message if the D bit is set in the RP object in the PCReq message. 704 The format of the Order TLV is as follows: 706 0 1 2 3 707 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 708 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 709 | Type | Length | 710 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 711 | Delete Order | 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Setup Order | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 716 Type To be defined by IANA (suggested value = ) 717 Length Variable 718 Value Orders in which the old path should be removed 719 and the new path should be setup 721 Figure 7: The Order TLV in the RP object in the PCRep Message 723 Delete Order: 32 bit integer that indicates the order in which the 724 old LSP should be removed 725 Setup Order: 32 bit integer that indicates the order in which the new 726 LSP should be setup 728 The delete order should not be equal to the setup order. If the 729 delete order is higher than the setup order, this means that the 730 reoptimization can be done in a make-before-break manner, else it 731 cannot be done in a make-before-break manner. 733 To illustrate, consider a network with two established requests: R1 734 with path P1 and R2 with path P2. During a reoptimization the PCE 735 may provide the following ordered reply: 737 R1, path P1', remove order 1, setup order 4 738 R2, path P2', remove order 3, setup order 2 740 This indicates that the NMS should do the following sequence of 741 tasks: 743 1: Remove path P1 744 2: Setup path P2' 745 3: Remove path P2 746 4: Setup path P1' 748 That is, R1 is reoptimized in a break-before-make manner and R2 in a 749 make-before-break manner. 751 5.5. Global Constraints (GC) Object 753 The Global Constraints (GC) Object is used in a PCReq message to 754 specify the necessary global constraints that should be applied to 755 all individual path computations for a global concurrent path 756 optimization request. 758 The format of the GC object body that includes the global constraints 759 is as follows: 761 0 1 2 3 762 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 763 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 764 | MU | mU | OB | MH | 765 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 | | 767 // Optional TLV(s) // 768 | | 769 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 Figure 10: GC body object format 772 MU (Max Utilization) (8 bits) : 8 bit integer that indicates the 773 upper bound utilization percentage by which all link should be bound. 774 Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link 775 Capacity 777 mU (minimum Utilization) (8 bits) : 8 bit integer that indicates the 778 lower bound utilization percentage by which all link should be bound. 780 OB (Over Booking factor) (8 bits) : 8 bit integer that indicates the 781 overbooking percentage that allows the reserved bandwidth to be 782 overbooked on each link beyond its physical capacity limit. The 783 value, for example, 10% means that 110 Mbps can be reserved on a 784 100Mbps link. 786 MH (Max Hop) (8 bits): 8 bit integer that indicates the maximum hop 787 count for all the LSPs. 789 GC Object-Class is to be assigned by IANA. 791 GC Object-Type is to be assigned by IANA. 793 The exclusion of the list of nodes/links from a global path 794 computation can be done by including the XRO object following the GC 795 object in the new SVEC list definition. 797 5.6. Multi-Session Processing 799 When the initial global concurrent path computation request fails due 800 to scaling issues or memory overflow as indicated in the PCEP-ERROR 801 object in the PCRep message, multi-session processing may be 802 proceeded in an attempt to find a feasible solution in the absence of 803 an optimal solution. This should be driven by local policy decision. 804 How to divide up the original global concurrent optimization problem 805 into a number of smaller-scale optimization problems is out of the 806 scope of this document. 808 In order to meet these multi-session requirements, a new object, the 809 Multi-Session (MS) object is required. 811 This object should be defined on a per message basis. The message is 812 modified as follows: 814 ::= 815 [] 816 [] 817 819 The format of the MSO object is as follows: 821 0 1 2 3 822 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 823 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 824 |F| Reserved | Multi-Session ID | 825 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 826 | Sequence Number | Reserved | 827 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 829 Figure 12: MSO object body format 831 Multi-Session ID (16 bits): 16 bit integer that identifies the multi- 832 session computation. The Multi-Session ID will allow to map all 833 request messages for the same global computation. 835 Sequence Number (16 bits): 16 bit integer that indicates the sequence 836 number of the current multi-session request. This should be 837 incremented for each new request message during a multi-session 838 request until the final request is performed. 840 F (Final session - 1 bit): When set, the requesting PCC indicates 841 that the PCReq message is the final session of a multi-session 842 request. When it is not set, the PCE SHOULD keep in memory all the 843 computed paths until the final session of a multi-session is 844 completed. This is necessary to correctly account for already 845 computed LSPs. 847 MS Object-Class is to be assigned by IANA. 849 MS Object-Type is to be assigned by IANA. 851 For PCE not able to temporarily maintain previously computed paths, 852 the multi-session capability can be provided by adding in a PCReq the 853 results of all previous path requests for this multi-session. This 854 includes, for each previously handled request, the RP, ERO and 855 Bandwidth objects. 857 In order to distinguish a previously computed request from a new 858 request, a new flag in the RP object is required. 860 A (Already computed request - 1 bit): When set, this indicates that 861 the request has already been computed in a previous session, and its 862 result (as indicated by the ERO and the Bandwidth Object following 863 the RP object) must be taken account in the current session. 865 5.7. Error Indicator 867 To indicate errors associated with the global concurrent path 868 optimization request, a new Error-Type (14) and subsequent error- 869 values are defined as follows for inclusion in the PCEP-ERROR object: 871 A new Error-Type (14) and subsequent error-values are defined as 872 follows: 874 Error-Type=14 and Error-Value=1: if a PCE receives a global 875 concurrent path optimization request and the PCE is not capable of 876 the request due to insufficient memory, the PCE MUST send a PCErr 877 message with a PCEP ERROR object (Error-Type=14) and an Error-Value 878 (Error-Value=1). The corresponding global concurrent path 879 optimization request MUST be cancelled. 881 Error-Type=14; Error-Value=2: if a PCE receives a global concurrent 882 path optimization request and the PCE is not capable of global 883 concurrent optimization, the PCE MUST send a PCErr message with a 884 PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=2). 885 The corresponding global concurrent path optimization MUST be 886 cancelled. 888 To indicate an error associated with policy violation, a new error 889 value "global concurrent optimization not allowed" should be added to 890 an existing error code for policy violation (Error-Type=5) as defined 891 in [PCEP]. 893 Error-Type=5; Error-Value=3: if a PCE receives a global concurrent 894 path optimization request which is not compliant with administrative 895 privileges (i.e., the PCE policy does not support global concurrent 896 optimization), the PCE send a PCErr message with a PCEP-ERROR Object 897 (Error-Type=5) and an Error-Value (Error-Value=3). The corresponding 898 global concurrent path computation MUST be cancelled. 900 5.8. NO-PATH Indicator 902 To communicate the reason(s) for not being able to find global 903 concurrent path computation, the NO-PATH object can be used in the 904 PCRep message. The format of the NO-PATH object body is as follows: 906 0 1 2 3 907 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 908 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 909 |C| Flags | Reserved | 910 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 911 | | 912 // Optional TLV(s) // 913 | | 914 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 916 Figure 13: NO-PATH object format 918 Flags (16 bits). The C flag is defined in [PCEP]. 920 Two new bit flags are defined in the NO-PATH-VECTOR TLV carried in 921 the NO-PATH Object: 923 0x03: when set, the PCE indicates that no migration path was found. 925 0x04: when set, the PCE indicates no feasible solution was found that 926 meets all the constraints associated with global concurrent path 927 optimization in the PCRep message. 929 When either 0x03 or 0x04 flag is set in the NO-PATH-VECTOR TLV 930 carried in the NO-PATH object in the PCRep Message, a subsequent 931 multi-session feature may be triggered if the PCC's local policy 932 allows it. The multi-session feature allows the original global 933 concurrent optimization to be split into a number of multiple 934 sessions so that the PCE would compute a number of smaller-scale 935 optimizations in a sequential manner. The trade-off is that a 936 partial feasible solution may be obtained using this approach which 937 is better than not having any solution at all, although such solution 938 might not be a global optimal solution. How to divide up the 939 original set of global concurrent optimization requests into multiple 940 numbers of smaller-scale optimizations is out of the scope of this 941 document. 943 See Section 5.6 for multi-session processing details. 945 6. Manageability Considerations 947 Manageability of Global Concurrent Path Computation with PCE must 948 address the following considerations: 950 6.1. Control of Function and Policy 952 This sub-section will describe the configurable items that exist for 953 the control of global concurrent optimization functions or policies. 955 6.2. Information and Data Models, e.g. MIB module 957 This sub-section will describe the information and data models 958 necessary for the protocol or the protocol extensions. This 959 includes, but is not necessarily limited to, the MIB modules 960 developed specifically for the protocol functions specified in the 961 document. 963 6.3. Liveness Detection and Monitoring 965 This sub-section will describe liveness detection and monitoring 966 requirements for both the control plane and the data plane. 968 6.4. Verifying Correct Operation 970 This sub-section will describe Operations and Management (OAM) 971 features and functions for verifying the correct operation. 973 6.5. Requirements on Other Protocols and Functional Components 975 This sub-section will describe requirements or refer to the sections 976 that discuss the impact of global concurrent optimization on existing 977 protocols. 979 6.6. Impact on Network Operation 981 This sub-section will discuss the impact on the operation of existing 982 networks. 984 6.7. Other Considerations 986 This sub-section will cover those manageability requirements not 987 specifically in previous sub-sections. 989 7. Security Considerations 991 When global re-optimization is applied to an active network, it could 992 be extremely disruptive. Although the real security and policy 993 issues apply at the NMS, if the wrong results are returned to the 994 NMS, the wrong actions may be taken in the network. Therefore, it is 995 very important that the operator issuing the commands has sufficient 996 authority and is authenticated, and that the computation request is 997 subject to appropriate policy. 999 The mechanisms defined in [PCEP] to secure a PCEP session (MD-5 1000 authentication, etc.) apply here as well. 1002 8. Acknowledgements 1004 We would like to thank Jerry Ash, Adrian Farrel, Ning So and Lucy 1005 Yong for their useful comments and suggestions. 1007 9. IANA Considerations 1009 A future revision of this document will present requests to IANA for 1010 codepoint allocation. 1012 10. References 1014 10.1. Normative References 1016 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1017 Requirement Levels", BCP 14, RFC 2119, March 1997. 1019 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1020 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1021 Tunnels", RFC 3209, December 2001. 1023 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1024 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1026 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 1027 Communication Protocol Generic Requirements", RFC 4657, 1028 September 2006. 1030 10.2. Informative References 1032 [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- 1033 region and multi-layer networks (MRN/MLN), 1034 draft-ietf-ccamp-gmpls-mln-reqs, work in progress". 1036 [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- 1037 based inter-layer MPLS and GMPL traffic engineering, 1038 draft-ietf-pce-inter-layer-frwk, work in progress.". 1040 [PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 1041 Function encoding in Path Computation Element 1042 communication and discovery protocols, 1043 draft-leroux-pce-of, work in progress". 1045 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1046 Element (PCE) communication Protocol (PCEP) - Version 1, 1047 draft-ietf-pce-pcep, work in progress". 1049 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 1050 (PCE) Discovery, draft-ietf-pce-discovery-reqs, work in 1051 progress.". 1053 Authors' Addresses 1055 Young Lee 1056 Huawei 1057 1700 Alma Drive, Suite 100 1058 Plano, TX 75075 1059 US 1061 Phone: +1 972 509 5599 x2240 1062 Fax: +1 469 229 5397 1063 Email: ylee@huawei.com 1065 JL Le Roux 1066 France Telecom 1067 2, Avenue Pierre-Marzin 1068 Lannion 22307 1069 FRANCE 1071 Email: jeanlouis.leroux@orange-ftgroup.com 1073 Daniel King 1074 Aria Networks 1075 44/45 Market Place 1076 Chippenham SN15 3HU 1077 United Kingdom 1079 Phone: +44 7790 775187 1080 Fax: +44 1249 446530 1081 Email: daniel.king@aria-networks.com 1083 Eiji Oki 1084 NTT 1085 Midori 3-9-11 1086 Musashino, Tokyo 180-8585 1087 JAPAN 1089 Email: oki.eiji@lab.ntt.co.jp 1091 Full Copyright Statement 1093 Copyright (C) The IETF Trust (2007). 1095 This document is subject to the rights, licenses and restrictions 1096 contained in BCP 78, and except as set forth therein, the authors 1097 retain all their rights. 1099 This document and the information contained herein are provided on an 1100 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1101 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1102 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1103 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1104 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1105 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1107 Intellectual Property 1109 The IETF takes no position regarding the validity or scope of any 1110 Intellectual Property Rights or other rights that might be claimed to 1111 pertain to the implementation or use of the technology described in 1112 this document or the extent to which any license under such rights 1113 might or might not be available; nor does it represent that it has 1114 made any independent effort to identify any such rights. Information 1115 on the procedures with respect to rights in RFC documents can be 1116 found in BCP 78 and BCP 79. 1118 Copies of IPR disclosures made to the IETF Secretariat and any 1119 assurances of licenses to be made available, or the result of an 1120 attempt made to obtain a general license or permission for the use of 1121 such proprietary rights by implementers or users of this 1122 specification can be obtained from the IETF on-line IPR repository at 1123 http://www.ietf.org/ipr. 1125 The IETF invites any interested party to bring to its attention any 1126 copyrights, patents or patent applications, or other proprietary 1127 rights that may cover technology that may be required to implement 1128 this standard. Please address the information to the IETF at 1129 ietf-ipr@ietf.org. 1131 Acknowledgment 1133 Funding for the RFC Editor function is provided by the IETF 1134 Administrative Support Activity (IASA).