idnits 2.17.1 draft-ietf-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 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1076. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1083. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1089. 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 (June 22, 2007) is 6150 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) == Missing Reference: 'ISIS PCED' is mentioned on line 915, but not defined == Missing Reference: 'OSPF PCED' is mentioned on line 915, but not defined == Unused Reference: 'ISIS-PCED' is defined on line 990, but no explicit reference was found in the text == Unused Reference: 'OSPF-PCED' is defined on line 999, but no explicit reference was found in the text == Unused Reference: 'PCE-MLN' is defined on line 1004, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-pce-brpc-05 -- Possible downref: Normative reference to a draft: ref. 'PCE-OF' == Outdated reference: A later version (-06) exists of draft-ietf-pce-pcep-xro-00 ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4657 ** Downref: Normative reference to an Informational RFC: RFC 4674 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 8 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: December 24, 2007 France Telecom 6 D. King 7 Aria Networks 8 E. Oki 9 NTT 10 June 22, 2007 12 Path Computation Element Communication Protocol (PCECP) Requirements and 13 Protocol Extensions In Support of Global Concurrent Optimization 14 draft-ietf-pce-global-concurrent-optimization-00.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 December 24, 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. The Global Concurrent Optimization (GCO) 66 application is primarily an NMS based solution. 68 This document provides application-specific requirements and the PCEP 69 extensions in support of a global concurrent optimization (GCO) 70 application. 72 Table of Contents 74 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 75 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 76 3. Applicability of Global Concurrent Optimization (GCO) . . . . 7 77 3.1. Application of the PCE Architecture . . . . . . . . . . . 7 78 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8 79 3.2.1. Reconfiguration of the Virtual Network Topology 80 (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8 81 3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8 82 3.3. Greenfield Optimization . . . . . . . . . . . . . . . . . 9 83 3.3.1. Single-layer Traffic Engineering . . . . . . . . . . . 10 84 3.3.2. Multi-layer Traffic Engineering . . . . . . . . . . . 10 85 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 86 5. Protocol extensions for support of global concurrent 87 optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 88 5.1. Global Objective Function (GOF) Specification . . . . . . 16 89 5.2. Indication of Global Concurrent Optimization Requests . . 16 90 5.3. Request for the order of LSP . . . . . . . . . . . . . . . 16 91 5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17 92 5.5. Global Constraints (GC) Object . . . . . . . . . . . . . . 19 93 5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 20 94 5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 21 95 6. Manageability Considerations . . . . . . . . . . . . . . . . . 23 96 6.1. Control of Function and Policy . . . . . . . . . . . . . . 23 97 6.2. Information and Data Models, e.g. MIB module . . . . . . . 23 98 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 23 99 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 23 100 6.5. Requirements on Other Protocols and Functional 101 Components . . . . . . . . . . . . . . . . . . . . . . . . 24 102 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 24 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 25 104 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 26 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 27 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 28 107 10.1. Normative References . . . . . . . . . . . . . . . . . . . 28 108 10.2. Informative References . . . . . . . . . . . . . . . . . . 28 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 110 Intellectual Property and Copyright Statements . . . . . . . . . . 31 112 1. Terminology 114 The terminology explained herein complies with [RFC4655]. 116 PCC: Path Computation Client: Any client application requesting a 117 path computation to be performed by a Path Computation Element. 119 PCE: Path Computation Element: An entity (component, application or 120 network node) that is capable of computing a network path or route 121 based on a network graph and applying computational constraints. 123 TED: Traffic Engineering Database which contains the topology and 124 resource information of the domain. The TED may be fed by IGP 125 extensions or potentially by other means. 127 PCECP: The PCE Communication Protocol: PCECP is the generic abstract 128 idea of a protocol that is used to communicate path computation 129 requests a PCC to a PCE, and to return computed paths from the PCE to 130 the PCC. The PCECP can also be used between cooperating PCEs. 132 PCEP: The PCE communication Protocol: PCEP is the actual protocol 133 that implements the PCECP idea. 135 GCO: Global Concurrent Optimization: A concurrent path computation 136 application where a set of TE paths are computed concurrently in 137 order to efficiently utilize network resources. A GCO path 138 computation is able to simultaneously consider the entire topology of 139 the network and the complete set of existing LSPs, and their 140 respective constraints, and look to optimize or re-optimize the 141 entire network to satisfy all constraints for all LSPs. A GCO path 142 computation can also provide an optimal way to migrate from an 143 existing set of LSPs to a reoptimized set (Morphing Problem). 145 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 146 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 147 document are to be interpreted as described in RFC 2119 [RFC2119]. 148 These terms are also used in the parts of this document that specify 149 requirements for clarity of specification of those requirements. 151 2. Introduction 153 [RFC4655] defines the PCE based Architecture and explains how a Path 154 Computation Element (PCE) may compute Label Switched Paths (LSP) in 155 Multiprotocol Label Switching Traffic Engineering (MPLS-TE) and 156 Generalized MPLS (GMPLS) networks at the request of PCCs. A PCC is 157 shown to be any network component that makes such a request and may 158 be for instance a Label Switching Router (LSR) or a Network 159 Management System (NMS). The PCE, itself, is shown to be located 160 anywhere within the network, and may be within an LSR, an NMS or 161 Operational Support System (OSS), or may be an independent network 162 server. 164 The PCECP is the communication protocol used between PCC and PCE, and 165 may also be used between cooperating PCEs. [RFC4657] sets out the 166 common protocol requirements for the PCECP. Additional application- 167 specific requirements for PCECP are deferred to separate documents. 169 This document provides a set of PCECP extension requirements and 170 solutions in support of concurrent path computation applications that 171 may arise during network operations. A concurrent path computation 172 is a path computation application where a set of TE paths are 173 computed concurrently in order to efficiently utilize network 174 resources. The computation method involved with a concurrent path 175 computation is referred to as global concurrent optimization in this 176 document. Appropriate computation algorithms to perform this type of 177 optimization are out of the scope of this document. 179 The Global Concurrent Optimization (GCO) application is primarily an 180 NMS based solution. Due to complex synchronization issues associated 181 with GCO application, the management based PCE architecture defined 182 in section 5.5 of [RFC4655] is considered as the most suitable usage 183 to support GCO application. This does not automatically preclude 184 other architectural alternatives to support GCO application, but they 185 are not recommended. For instance, GCO may be enabled by distributed 186 LSRs through complex synchronization. However, this approach may 187 suffer from significant synchronization overhead between the PCE and 188 each of the PCCs. It would likely affect the network stability and 189 hence significantly diminish the benefits of deploying PCEs. 191 As new LSPs are added sequentially or removed from the network over 192 time, the global network resources become fragmented and the network 193 no longer provides the optimal use of the available capacity. A 194 global concurrent path computation is able to simultaneously consider 195 the entire topology of the network and the complete set of existing 196 LSPs, and their respective constraints, and look to re-optimize the 197 entire network to satisfy all constraints for all LSPs. 198 Alternatively, the application may consider a subset of the LSPs 199 and/or a subset of the network topology. 201 The need for a global concurrent path computation may also arise when 202 network operators need to establish a set of TE LSPs in their network 203 planning process. It is also envisioned that network operators might 204 require a global concurrent path computation in the event of 205 catastrophic network failures, where a set of TE LSPs need to be 206 optimally rerouted. The nature of this work does promote such 207 systems for offline processing. Online application of this work 208 should only be considered with proven empirical validation. 210 As the PCE is envisioned to provide solutions in all path computation 211 matters, it is anticipated that the PCE would provide solutions for 212 global concurrent path computation needs. 214 The main focus of this document is to highlight the PCC-PCE 215 communication needs in support of a concurrent path computation 216 application and to define protocol extensions to meet those needs. 218 The PCC-PCE requirements addressed herein are specific to the context 219 where the PCE is a specialized PCE that is capable of solving global 220 concurrent path computation applications. Discovery of such 221 capabilities might be desirable and could be achieved through 222 extensions to the PCE discovery mechanisms [RFC4674], but that is out 223 of the scope of this document. 225 It is to be noted that BRPC [BRPC] is a multi-PCE path computation 226 technique used to compute a shortest constrained inter-domain path 227 wheres this ID specifies a technique where a set of path computation 228 requests are bundled and send to a PCE with the objective of 229 "optimizing" the set of computed paths. 231 3. Applicability of Global Concurrent Optimization (GCO) 233 This section discusses the PCE architecture to which GCO is applied. 234 It also discusses various application scenarios for which global 235 concurrent path computation may be applied. 237 3.1. Application of the PCE Architecture 239 Figure 1 shows the PCE-based network architecture as defined in 240 [RFC4655] to which GCO application is applied. It must be observed 241 that the PCC is not necessarily an LSR [RFC4655]. The GCO 242 application is primarily an NMS-based solution in which an NMS plays 243 the function of the PCC. Although Figure 1 shows the PCE as remote 244 from the NMS, it might be collocated with the NMS. Note that in the 245 collocated case there is no need for a standard communication 246 protocol, this can rely on internal APIs. 248 ----------- 249 Application | ----- | 250 Request | | TED | | 251 | | ----- | 252 v | | | 253 ------------- Request/ | v | 254 | PCC | Response| ----- | 255 | (NMS) |<--------+> | PCE | | 256 | | | ----- | 257 ------------- ----------- 258 Service | 259 Request | 260 v 261 ---------- Signaling ---------- 262 | Head-End | Protocol | Adjacent | 263 | Node |<---------->| Node | 264 ---------- ---------- 266 Figure 1: PCE-Based Architecture for Global Concurrent Optimization 268 Upon receipt of an application request (e.g., a traffic demand matrix 269 is provided to the NMS by the operator's network planning procedure), 270 the NMS requests a global concurrent path computation from the PCE. 271 The PCE then computes the requested paths concurrently applying some 272 algorithms. When the requested path computation completes, the PCE 273 sends the resulting paths back to the NMS. The NMS then supplies the 274 head-end LSRs with a fully computed explicit path for each TE LSP 275 that needs to be established. 277 3.2. Re-optimization of Existing Networks 279 The need for global concurrent path computation may arise in existing 280 networks. When an existing TE LSP network experiences sub-optimal 281 use of its resources, the need for re-optimization or reconfiguration 282 may arise. The scope of re-optimization and reconfiguration may vary 283 depending on particular situations. The scope of re-optimization may 284 be limited to bandwidth modification to an existing TE LSP. However, 285 it could well be that a set of TE LSPs may need to be re-optimized 286 concurrently. In an extreme case, the TE LSPs may need to be 287 globally re-optimized. 289 In loaded networks, with large size LSPs, a sequential re- 290 optimization may not produce substantial improvements in terms of 291 overall network optimization. The potential for network-wide gains 292 from reoptimization of LSPs sequentially is dependent upon the 293 network usage and size of the LSPs being optimized. However, the key 294 point remains: computing the reoptimized path of one LSP at a time 295 with giving no consideration to the other LSPs in the network could 296 result in sub-optimal use of network resources. This may be far more 297 visible in an optical network with a low ratio of potential LSPs per 298 link, and far less visible in packet networks with micro-flow LSPs. 300 With regards to applicability of GCO in the event of catastrophic 301 failures, there may be a real benefit in computing the paths of the 302 LSPs as a set rather than computing new paths from the head-end LSRs 303 in a distributed manner. It is to be noted, however, that a 304 centralized system will typically suffer from a slower response time 305 than a distributed system. 307 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) 309 Reconfiguration of the VNT [MLN-REQ] is a typical application 310 scenario where global concurrent path computation may be applicable. 311 Triggers for VNT reconfiguration, such as traffic demand changes, 312 network failures, and topological configuration changes, may require 313 a set of existing LSPs to be re-computed. 315 3.2.2. Traffic Migration 317 When migrating from one set of TE LSPs to a reoptimized set of TE 318 LSPs it is important that the traffic be moved without causing 319 disruption. Various techniques exist in MPLS and GMPLS, such as 320 make-before-break [RFC3209], to establish the new LSPs before tearing 321 down the old LSPs. When multiple LSP routes are changed according to 322 the computed results, some of the LSPs may be disrupted due to the 323 resource constraints. In other words, it may prove to be impossible 324 to perform a direct migration from the old LSPs to the new optimal 325 LSPs without disrupting traffic because there are insufficient 326 network resources to support both sets of LSPs when make-before-break 327 is used. However, the PCE may be able to determine an order of LSP 328 rerouting actions so that make-before-break can be performed within 329 the limited resources. 331 It may be the case that the reoptimization is radical. This could 332 mean that it is not possible to apply make-before-break in any order 333 to migrate from the old LSPs to the new LSPs. In this case a 334 migration strategy is required that may necessitate LSPs being 335 rerouted using make-before-break onto temporary paths in order to 336 make space for the full reoptimization. A PCE might indicate the 337 order in which reoptimized LSPs must be established and take over 338 from the old LSPs, and may indicate a series of different temporary 339 paths that must be used. Alternatively, the PCE might perform the 340 global reoptimization as a series of sub-reoptimizations by 341 reoptimizing subsets of the total set of LSPs. 343 The benefit of this multi-step rerouting includes minimization of 344 traffic discruption and optimization gain. However this approach may 345 imply some transient packets desequencing, jitter as well as control 346 plane stress. 348 Note also that during reoptimization, traffic disruption may be 349 allowed for some LSPs carrying low priority services (e.g., Internet 350 traffic) and not allowed for some LSPs carrying mission critical 351 services (e.g., voice traffic). 353 3.3. Greenfield Optimization 355 Greenfield optimization is a special case of GCO application when 356 there is no LSP setup. Once the LSPs are setup, it is not a 357 greenfield. The need for greenfield arises when network planner will 358 want to make use of computation servers to plan the LSPs that will be 359 provisioned in the network. 361 When a new TE network needs to be provisioned from a green-field 362 perspective, a set of TE LSPs need to be created based on traffic 363 demand, network topology, service constraints, and network resources. 364 Under this scenario, concurrent computation ability is highly 365 desirable, or required, to utilize network resources in an optimal 366 manner and avoid blocking risks. 368 3.3.1. Single-layer Traffic Engineering 370 Greenfield optimization can be applied when layer-specific TE LSPs 371 need to be created from a green-field perspective. For example, 372 MPLS-TE network can be established based on layer 3 specific traffic 373 demand, network topology, and network resources. Greenfield 374 optimization for single-layer traffic engineering can be applied to 375 optical transport networks such as SDH/Sonet, Ethernet Transport, 376 WDM, etc. 378 3.3.2. Multi-layer Traffic Engineering 380 Greenfield optimization is not limited to single-layer traffic 381 engineering. It can also be applied to multi-layer traffic 382 engineering. Both the client and the server layers network resources 383 and topology can be considered simultaneously in setting up a set of 384 TE LSPs that traverse the layer boundary. 386 4. PCECP Requirements 388 This section provides the PCECP requirements to support global 389 concurrent path computation applications. The requirements specified 390 here should be regarded as application-specific requirements and are 391 justifiable based on the extensibility clause found in section 6.1.14 392 of [RFC4657]: 394 The PCECP MUST support the requirements specified in the 395 application-specific requirements documents. The PCECP MUST also 396 allow extensions as more PCE applications will be introduced in 397 the future. 399 It is also to be noted that some of the requirements discussed in 400 this section have already been discussed in the PCECP requirement 401 document [RFC4657]. For example, Section 5.1.16 in [RFC4657] 402 provides a list of generic constraints while Section 5.1.17 in 403 [RFC4657] provides a list of generic objective functions that MUST be 404 supported by the PCECP. While using such generic requirements as the 405 baseline, this section provides application-specific requirements in 406 the context of global concurrent path computation and in a more 407 detailed level than the generic requirements. 409 The PCEP SHOULD support the following capabilities either via 410 creation of new objects and/or modification of existing objects where 411 applicable. 413 o An indicator to convey that the request is for a global concurrent 414 path computation. This indicator is necessary to ensure 415 consistency in applying global objectives and global constraints 416 in all path computations. Note: This requirement is covered by 417 "synchronized path computation" in [RFC4655] and [RFC4657]. 418 However, an explicit indicator to request a global concurrent 419 optimization is a new requirement. 421 o A Global Objective Function (GOF) field in which to specify the 422 global objective function. The global objective function is the 423 overarching objective function to which all individual path 424 computation requests are subjected in order to find a globally 425 optimal solution. Note that this requirement is covered by 426 "synchronized objective functions" in section 5.1.7 [RFC4657]. A 427 list of available global objective functions SHOULD include the 428 following objective functions at the minimum and SHOULD be 429 expandable for future addition: 431 * Minimize the sum of all TE LSP costs (min cost) 432 * Evenly allocate the network load to achieve the most uniform 433 link utilization across all links (this can be achieved by the 434 following objective function: minimize max over all links 435 {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i 436 and A(i) is the total bandwidth allocated on link i. 438 o A Global Constraints (GC) field in which to specify the list of 439 global constraints to which all the requested path computations 440 should be subjected. This list SHOULD include the following 441 constraints at the minimum and SHOULD be expandable for future 442 addition: 444 * Maximum link utilization value -- This value indicates the 445 highest possible link utilization percentage set for each link. 446 (Note: to avoid floating point numbers, the values should be 447 integer values.) 449 * Minimum link utilization value -- This value indicates the 450 lowest possible link utilization percentage set for each link. 451 (Note: same as above) 453 * Overbooking Factor -- The overbooking factor allows the 454 reserved bandwidth to be overbooked on each link beyond its 455 physical capacity limit. 457 * Maximum number of hops for all the LSPs -- This is the largest 458 number of hops that any LSP can have. Note that this 459 constraint can also be provided on a per LSP basis (as 460 requested in [RFC4657] and defined in [PCEP]). 462 * Exclusion of links/nodes in all LSP path computation (i.e., all 463 LSPs should not include the specified links/nodes in their 464 paths). Note that this constraint can also be provided on a 465 per LSP basis (as requested in [RFC4657] and defined in 466 [PCEP]). 468 * An indication should be available in a path computation 469 response that further reoptimization may only become available 470 once existing traffic has been moved to the new LSPs. 472 o A Global Concurrent Vector (GCV) field in which to specify all the 473 individual path computation requests that are subject to 474 concurrent path computation and subject to the global objective 475 function and all of the global constraints. Note that this 476 requirement is entirely fulfilled by the SVEC object in the PCEP 477 specification [PCEP]. Since the SVEC object as defined in [PCEP] 478 allows identifying a set of concurrent path requests, the SVEC can 479 be reused to specify all the individual concurrent path requests 480 for a global concurrent optimization. 482 o An indicator field in which to indicate the outcome of the 483 request. When the PCE could not find a feasible solution with the 484 initial request, the reason for failure SHOULD be indicated. This 485 requirement is partially covered by [RFC4657], but not in this 486 level of detail. The following indicators SHOULD be supported at 487 the minimum: 489 * no feasible solution found. Note that this is already covered 490 in [PCEP]. 492 * memory overflow 494 * PCE too busy. Note that this is already covered in [PCEP]. 496 * PCE not capable of concurrent reoptimization 498 * no migration path available 500 * administrative privileges do not allow global reoptimization 502 o In order to minimize disruption associated with bulk path 503 provisioning, the following requirements MUST be supported: 505 * The request message MUST allow requesting the PCE to provide 506 the order in which LSPs should be reoptimized (i.e., the 507 migration path) in order to minimize traffic disruption during 508 the migration. That is the request message MUST allow 509 indicating to the PCE that the set of paths that will be 510 provided in the response message (PCRep) has to be ordered. 512 * In response to the "ordering" request from the PCC, the PCE 513 MUST be able to indicate in the response message (PCRep) the 514 order in which LSPs should be reoptimized so as to minimize 515 traffic disruption. It should indicate for each request the 516 order in which the old LSP should be removed and the order in 517 which the new LSP should be setup. If the removal order is 518 lower than the setup order this means that make-before-break 519 cannot be done for this request. It might also be desirable to 520 have the PCE indicate whether ordering is in fact required or 521 not. 523 * As stated in RFC 4657, the request for a reoptimization MUST 524 support the inclusion of the set of previously computed paths 525 along with their bandwidth. This is to avoid double bandwidth 526 accounting and also this allows running an algorithm that 527 minimizes perturbation and that can compute a migration path 528 (LSP setup/removal orders). This is particularly required for 529 stateless PCEs. 531 * During a migration it may not be possible to do a make-before- 532 break for all existing LSPs. The request message must allow 533 indicating for each request whether make-before-break is 534 required (e.g. Voice traffic) or break-before-make is 535 acceptable (e.g. Internet traffic). The response message must 536 allow indicating LSPs for which make-before-break 537 reoptimization is not possible (this will be deduced from the 538 LSP setup and deletion orders). 540 * During a reoptimization it may be required to move a LSP 541 several times so as to avoid traffic disruption. The response 542 message must allow indicating the sequence of successive paths 543 for each request. 545 5. Protocol extensions for support of global concurrent optimization 547 This section provides protocol extensions for support of global 548 concurrent optimization. Protocol extensions discussed in this 549 section are built on [PCEP]. 551 The format of a PCReq message is currently as follows per [PCEP]: 553 ::= 554 [] 555 557 where: 558 ::= [] 559 ::= [] 560 ::= 561 [] 562 [] 563 [] 564 [] 565 [] 566 [] 567 [] 569 The format of a PCReq message after incorporating new requirements 570 for support of global concurrent optimization is as follows: 572 ::= 573 [] 574 576 The is changed as follows: 578 :: = 579 [] 580 [] 581 [] 582 [] 584 Note that three optional objects are added, following the SVEC 585 object: the OF (Objective Function) object, which is defined in 586 [PCE-OF], the GC (Global Constraints) object, which is defined in 587 this document (section 5.5), as well as the eXclude Route Object 588 (XRO) which is defined in [PCE-XRO]. Details of this change will be 589 discussed in the following sections 591 5.1. Global Objective Function (GOF) Specification 593 The global objective function can be specified in the PCEP Objective 594 Function (OF) object, defined in [PCE-OF]. The OF object includes a 595 16 bit Objective Function identifier. As per discussed in [PCE-OF], 596 objective function identifier code points are managed by IANA. 598 Two global objective functions are defined in this document and their 599 identifier should be assigned by IANA (suggested value) 601 Function 602 Code Description 604 1 Minimize the sum of all TE LSP costs (min cost) 606 2 Evenly allocate the network load to achieve the 607 most uniform link utilization across all links* 609 * Note: This can be achieved by the following objective function: 610 minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link 611 capacity for link i and A(i) is the total bandwidth allocated on link 612 i.) 614 5.2. Indication of Global Concurrent Optimization Requests 616 All the path requests in this application should be indicated so that 617 the global objective function and all of the global constraints are 618 applied to each of the requested path computation. In order to 619 support this requirement, a new flag is defined in the SVEC object: 621 C flag (1 bit): This is a new flag in the SVEC object. When C flag 622 is set, this indicates that all of the path requests listed in the 623 body of the SVEC object should be computed applying the global 624 constraints and the global objective function. 626 When the C Flag is set in the SVEC Object, the OF and the GC objects, 627 if included, should directly follow the SVEC Object. 629 5.3. Request for the order of LSP 631 In order to minimize disruption associated with bulk path 632 provisioning, the PCC may indicate to the PCE that the response MUST 633 be ordered. That is, the PCE has to include the order in which LSPs 634 MUST be moved so as to minimize traffic disruption. To support such 635 indication a new flag, the D flag, is defined in the RP object as 636 follows: 638 0 1 2 3 639 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 640 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 641 | Reserved | Flags |D|M|F|O|B|R| Pri | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 643 | Request-ID-number | 644 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 645 | | 646 // Optional TLV(s) // 647 | | 648 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 650 Figure 5: RP object body format in the PCReq Message 652 D bit (orDer - 1 bit): when set, in a PCReq message, the requesting 653 PCC requires the PCE to specify in the PCRep message the order in 654 which this particular path request is to be provisioned relative to 655 other requests. 657 M bit (Make-before-break - 1 bit): when set, this indicates that a 658 make-before-break reoptimization is required for this request. 660 When M bit is not set, this implies that a break-before-make 661 reoptimization is allowed for this request. Note that M bit can be 662 set only if the R (Reoptimization) flag is set. 664 5.4. The Order Response 666 The PCE MUST specify the order number in response to the Order 667 Request made by the PCC in the PCReq message if so requested by the 668 setting of the D bit in the RP object in the PCReq message. To 669 support such ordering indication a new optional TLV is defined in the 670 RP object, the Order TLV, as follows: 672 0 1 2 3 673 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 674 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 675 | Reserved | Flags |D|M|F|O|B|R| Pri | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Request-ID-number | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | | 680 // Order TLV (Optional TLV) // 681 | | 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 684 Figure 6: RP object body format in the PCRep Message 686 The Order TLV is an optional TLV in the RP object, that indicates the 687 order in which the old LSP must be removed and the new LSP must be 688 setup during a reoptimization. It is carried in the PCRep message in 689 response to a reoptimization request. 691 The Order TLV SHOULD be included in the RP object in the PCRep 692 message if the D bit is set in the RP object in the PCReq message. 694 The format of the Order TLV is as follows: 696 0 1 2 3 697 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 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 699 | Type | Length | | 700 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 701 | Delete Order | 702 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 | Setup Order | 704 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 706 Type To be defined by IANA (suggested value = ) 707 Length Variable 708 Value Orders in which the old path should be removed 709 and the new path should be setup 711 Figure 7: The Order TLV in the RP object in the PCRep Message 713 Delete Order: 32 bit integer that indicates the order in which the 714 old LSP should be removed 715 Setup Order: 32 bit integer that indicates the order in which the new 716 LSP should be setup 718 The delete order should not be equal to the setup order. If the 719 delete order is higher than the setup order, this means that the 720 reoptimization can be done in a make-before-break manner, else it 721 cannot be done in a make-before-break manner. 723 To illustrate, consider a network with two established requests: R1 724 with path P1 and R2 with path P2. During a reoptimization the PCE 725 may provide the following ordered reply: 727 R1, path P1', remove order 1, setup order 4 728 R2, path P2', remove order 3, setup order 2 730 This indicates that the NMS should do the following sequence of 731 tasks: 733 1: Remove path P1 734 2: Setup path P2' 735 3: Remove path P2 736 4: Setup path P1' 738 That is, R1 is reoptimized in a break-before-make manner and R2 in a 739 make-before-break manner. 741 5.5. Global Constraints (GC) Object 743 The Global Constraints (GC) Object is used in a PCReq message to 744 specify the necessary global constraints that should be applied to 745 all individual path computations for a global concurrent path 746 optimization request. 748 The format of the GC object body that includes the global constraints 749 is as follows: 751 0 1 2 3 752 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 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 | MU | mU | OB | MH | 755 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 756 | | 757 // Optional TLV(s) // 758 | | 759 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 760 Figure 10: GC body object format 762 MU (Max Utilization) (8 bits) : 8 bit integer that indicates the 763 upper bound utilization percentage by which all link should be bound. 764 Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link 765 Capacity 767 mU (minimum Utilization) (8 bits) : 8 bit integer that indicates the 768 lower bound utilization percentage by which all link should be bound. 770 OB (Over Booking factor) (8 bits) : 8 bit integer that indicates the 771 overbooking percentage that allows the reserved bandwidth to be 772 overbooked on each link beyond its physical capacity limit. The 773 value, for example, 10% means that 110 Mbps can be reserved on a 774 100Mbps link. 776 MH (Max Hop) (8 bits): 8 bit integer that indicates the maximum hop 777 count for all the LSPs. 779 GC Object-Class is to be assigned by IANA. 781 GC Object-Type is to be assigned by IANA. 783 The exclusion of the list of nodes/links from a global path 784 computation can be done by including the XRO object following the GC 785 object in the new SVEC list definition. 787 5.6. Error Indicator 789 To indicate errors associated with the global concurrent path 790 optimization request, a new Error-Type (14) and subsequent error- 791 values are defined as follows for inclusion in the PCEP-ERROR object: 793 A new Error-Type (14) and subsequent error-values are defined as 794 follows: 796 Error-Type=14 and Error-Value=1: if a PCE receives a global 797 concurrent path optimization request and the PCE is not capable of 798 the request due to insufficient memory, the PCE MUST send a PCErr 799 message with a PCEP ERROR object (Error-Type=14) and an Error-Value 800 (Error-Value=1). The corresponding global concurrent path 801 optimization request MUST be cancelled. 803 Error-Type=14; Error-Value=2: if a PCE receives a global concurrent 804 path optimization request and the PCE is not capable of global 805 concurrent optimization, the PCE MUST send a PCErr message with a 806 PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=2). 807 The corresponding global concurrent path optimization MUST be 808 cancelled. 810 To indicate an error associated with policy violation, a new error 811 value "global concurrent optimization not allowed" should be added to 812 an existing error code for policy violation (Error-Type=5) as defined 813 in [PCEP]. 815 Error-Type=5; Error-Value=3: if a PCE receives a global concurrent 816 path optimization request which is not compliant with administrative 817 privileges (i.e., the PCE policy does not support global concurrent 818 optimization), the PCE sends a PCErr message with a PCEP-ERROR Object 819 (Error-Type=5) and an Error-Value (Error-Value=3). The corresponding 820 global concurrent path computation MUST be cancelled. 822 5.7. NO-PATH Indicator 824 To communicate the reason(s) for not being able to find global 825 concurrent path computation, the NO-PATH object can be used in the 826 PCRep message. The format of the NO-PATH object body is as follows: 828 0 1 2 3 829 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 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 831 |C| Flags | Reserved | 832 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 833 | | 834 // Optional TLV(s) // 835 | | 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 838 Figure 11: NO-PATH object format 840 Flags (16 bits). The C flag is defined in [PCEP]. 842 Two new bit flags are defined in the NO-PATH-VECTOR TLV carried in 843 the NO-PATH Object: 845 0x08: when set, the PCE indicates that no migration path was found. 847 0x10: when set, the PCE indicates no feasible solution was found that 848 meets all the constraints associated with global concurrent path 849 optimization in the PCRep message. 851 When either 0x08 or 0x10 flag is set in the NO-PATH-VECTOR TLV 852 carried in the NO-PATH object in the PCRep Message, a subsequent 853 multi-session feature may be triggered if the PCC's local policy 854 allows it. The multi-session feature allows the original global 855 concurrent optimization to be split into a number of multiple 856 sessions so that the PCE would compute a number of smaller-scale 857 optimizations in a sequential manner. The trade-off is that a 858 partial feasible solution may be obtained using this approach which 859 is better than not having any solution at all, although such solution 860 might not be a global optimal solution. How to divide up the 861 original set of global concurrent optimization requests into multiple 862 numbers of smaller-scale optimizations is out of the scope of this 863 document. 865 6. Manageability Considerations 867 Manageability of Global Concurrent Path Computation with PCE must 868 address the following considerations: 870 6.1. Control of Function and Policy 872 In addition to the parameters already listed in section 8.1 of 873 [PCEP], a PCEP implementation SHOULD allow configuring the following 874 PCEP session parameters on a PCC: 876 o The ability to send a GCO request. 878 In addition to the parameters already listed in section 8.1 of 879 [PCEP], a PCEP implementation SHOULD allow configuring the following 880 PCEP session parameters on a PCE: 882 o The support for Global Concurrent Optimization. 884 o The maximum number of synchronized path requests per request 885 message. 887 o A set of GCO specific policies (authorized sender, request rate 888 limiter, etc). 890 These parameters may be configured as default parameters for any PCEP 891 session the PCEP speaker participates in, or may apply to a specific 892 session with a given PCEP peer or a specific group of sessions with a 893 specific group of PCEP peers. 895 6.2. Information and Data Models, e.g. MIB module 897 Extensions to the PCEP MIB module defined in [PCEP-MIB] should be 898 defined, so as to cover the GCO information introduced in this 899 document. 901 6.3. Liveness Detection and Monitoring 903 Mechanisms defined in this draft does not imply any new liveness 904 detection and monitoring requirements in addition to those already 905 listed in section 8.3 of [PCEP]. 907 6.4. Verifying Correct Operation 909 Mechanisms defined in this draft does not imply any new verification 910 requirements in addition to those already listed in section 8.4 of 911 [PCEP] 913 6.5. Requirements on Other Protocols and Functional Components 915 The PCE Discovery mechanisms ([ISIS PCED] and [OSPF PCED]) may be 916 used to advertise global concurrent path computation capabilities to 917 PCCs. 919 6.6. Impact on Network Operation 921 Mechanisms defined in this draft does not imply any new network 922 operation requirements in addition to those already listed in section 923 8.6 of [PCEP]. 925 7. Security Considerations 927 When global re-optimization is applied to an active network, it could 928 be extremely disruptive. Although the real security and policy 929 issues apply at the NMS, if the wrong results are returned to the 930 NMS, the wrong actions may be taken in the network. Therefore, it is 931 very important that the operator issuing the commands has sufficient 932 authority and is authenticated, and that the computation request is 933 subject to appropriate policy. 935 The mechanism defined in [PCEP] to secure a PCEP session can be used 936 to secure global concurrent path computation requests/responses. 938 8. Acknowledgements 940 We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning So 941 and Lucy Yong for their useful comments and suggestions. 943 9. IANA Considerations 945 A future revision of this document will present requests to IANA for 946 codepoint allocation. 948 10. References 950 10.1. Normative References 952 [BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based 953 Computation (BRPC) procedure to compute shortest inter- 954 domain Traffic Engineering Label Switched Paths, 955 draft-ietf-pce-brpc-05.txt, work in progress". 957 [PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 958 Function encoding in Path Computation Element 959 communication and discovery protocols, 960 draft-leroux-pce-of, work in progress". 962 [PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation 963 Element Communication Protocol (PCEP) for Route 964 Exclusions, draft-ietf-pce-pcep-xro-00.txt, work in 965 progress". 967 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 968 Element (PCE) communication Protocol (PCEP) - Version 1, 969 draft-ietf-pce-pcep, work in progress". 971 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 972 Requirement Levels", BCP 14, RFC 2119, March 1997. 974 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 975 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 976 Tunnels", RFC 3209, December 2001. 978 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 979 Element (PCE)-Based Architecture, RFC 4655, August 2006". 981 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 982 Communication Protocol Generic Requirements, RFC 4657, 983 September 2006". 985 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 986 (PCE) Discovery, RFC 4674, October 2006.". 988 10.2. Informative References 990 [ISIS-PCED] 991 Le Roux, J. and JP. Vasseur, "IS-IS protocol extensions 992 for Path Computation Element (PCE) Discovery, 993 draft-ietf-pce-disco-proto-isis, work in progress.". 995 [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- 996 region and multi-layer networks (MRN/MLN), 997 draft-ietf-ccamp-gmpls-mln-reqs, work in progress". 999 [OSPF-PCED] 1000 Le Roux, J. and JP. Vasseur, "OSPF protocol extensions for 1001 Path Computation Element (PCE) Discovery, 1002 draft-ietf-pce-disco-proto-ospf, work in progress.". 1004 [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- 1005 based inter-layer MPLS and GMPL traffic engineering, 1006 draft-ietf-pce-inter-layer-frwk, work in progress.". 1008 [PCEP-MIB] 1009 Stephen, E. and K. Koushik, "PCE communication 1010 protocol(PCEP) Management Information Base, 1011 draft-kkoushik-pce-pcep-mib, work in progress.". 1013 Authors' Addresses 1015 Young Lee 1016 Huawei 1017 1700 Alma Drive, Suite 100 1018 Plano, TX 75075 1019 US 1021 Phone: +1 972 509 5599 x2240 1022 Fax: +1 469 229 5397 1023 Email: ylee@huawei.com 1025 JL Le Roux 1026 France Telecom 1027 2, Avenue Pierre-Marzin 1028 Lannion 22307 1029 FRANCE 1031 Email: jeanlouis.leroux@orange-ftgroup.com 1033 Daniel King 1034 Aria Networks 1035 44/45 Market Place 1036 Chippenham SN15 3HU 1037 United Kingdom 1039 Phone: +44 7790 775187 1040 Fax: +44 1249 446530 1041 Email: daniel.king@aria-networks.com 1043 Eiji Oki 1044 NTT 1045 Midori 3-9-11 1046 Musashino, Tokyo 180-8585 1047 JAPAN 1049 Email: oki.eiji@lab.ntt.co.jp 1051 Full Copyright Statement 1053 Copyright (C) The IETF Trust (2007). 1055 This document is subject to the rights, licenses and restrictions 1056 contained in BCP 78, and except as set forth therein, the authors 1057 retain all their rights. 1059 This document and the information contained herein are provided on an 1060 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1061 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1062 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1063 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1064 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1065 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1067 Intellectual Property 1069 The IETF takes no position regarding the validity or scope of any 1070 Intellectual Property Rights or other rights that might be claimed to 1071 pertain to the implementation or use of the technology described in 1072 this document or the extent to which any license under such rights 1073 might or might not be available; nor does it represent that it has 1074 made any independent effort to identify any such rights. Information 1075 on the procedures with respect to rights in RFC documents can be 1076 found in BCP 78 and BCP 79. 1078 Copies of IPR disclosures made to the IETF Secretariat and any 1079 assurances of licenses to be made available, or the result of an 1080 attempt made to obtain a general license or permission for the use of 1081 such proprietary rights by implementers or users of this 1082 specification can be obtained from the IETF on-line IPR repository at 1083 http://www.ietf.org/ipr. 1085 The IETF invites any interested party to bring to its attention any 1086 copyrights, patents or patent applications, or other proprietary 1087 rights that may cover technology that may be required to implement 1088 this standard. Please address the information to the IETF at 1089 ietf-ipr@ietf.org. 1091 Acknowledgment 1093 Funding for the RFC Editor function is provided by the IETF 1094 Administrative Support Activity (IASA).