idnits 2.17.1 draft-lee-pce-global-concurrent-optimization-04.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 1054. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1065. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1072. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1078. 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 (May 29, 2007) is 6177 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 909, but not defined == Missing Reference: 'OSPF PCED' is mentioned on line 909, but not defined == Unused Reference: 'ISIS-PCED' is defined on line 979, but no explicit reference was found in the text == Unused Reference: 'OSPF-PCED' is defined on line 988, but no explicit reference was found in the text == Unused Reference: 'PCE-MLN' is defined on line 993, but no explicit reference was found in the text -- 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 (~~), 7 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: November 30, 2007 France Telecom 6 D. King 7 Aria Networks 8 E. Oki 9 NTT 10 May 29, 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-04.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 November 30, 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 3. Applicability of Global Concurrent Optimization (GCO) 227 This section discusses the PCE architecture to which GCO is applied. 228 It also discusses various application scenarios for which global 229 concurrent path computation may be applied. 231 3.1. Application of the PCE Architecture 233 Figure 1 shows the PCE-based network architecture as defined in 234 [RFC4655] to which GCO application is applied. It must be observed 235 that the PCC is not necessarily an LSR [RFC4655]. The GCO 236 application is primarily an NMS-based solution in which an NMS plays 237 the function of the PCC. Although Figure 1 shows the PCE as remote 238 from the NMS, it might be collocated with the NMS. Note that in the 239 collocated case there is no need for a standard communication 240 protocol, this can rely on internal APIs. 242 ----------- 243 Application | ----- | 244 Request | | TED | | 245 | | ----- | 246 v | | | 247 ------------- Request/ | v | 248 | PCC | Response| ----- | 249 | (NMS) |<--------+> | PCE | | 250 | | | ----- | 251 ------------- ----------- 252 Service | 253 Request | 254 v 255 ---------- Signaling ---------- 256 | Head-End | Protocol | Adjacent | 257 | Node |<---------->| Node | 258 ---------- ---------- 260 Figure 1: PCE-Based Architecture for Global Concurrent Optimization 262 Upon receipt of an application request (e.g., a traffic demand matrix 263 is provided to the NMS by the operator's network planning procedure), 264 the NMS requests a global concurrent path computation from the PCE. 265 The PCE then computes the requested paths concurrently applying some 266 algorithms. When the requested path computation completes, the PCE 267 sends the resulting paths back to the NMS. The NMS then supplies the 268 head-end LSRs with a fully computed explicit path for each TE LSP 269 that needs to be established. 271 3.2. Re-optimization of Existing Networks 273 The need for global concurrent path computation may arise in existing 274 networks. When an existing TE LSP network experiences sub-optimal 275 use of its resources, the need for re-optimization or reconfiguration 276 may arise. The scope of re-optimization and reconfiguration may vary 277 depending on particular situations. The scope of re-optimization may 278 be limited to bandwidth modification to an existing TE LSP. However, 279 it could well be that a set of TE LSPs may need to be re-optimized 280 concurrently. In an extreme case, the TE LSPs may need to be 281 globally re-optimized. 283 In loaded networks, with large size LSPs, a sequential re- 284 optimization may not produce substantial improvements in terms of 285 overall network optimization. The potential for network-wide gains 286 from reoptimization of LSPs sequentially is depependent upon the 287 network usage and size of the LSPs being optimized. However, the key 288 point remains: computing the reoptimized path of one LSP at a time 289 with giving no consideration to the other LSPs in the network could 290 result in sub-optimal use of network resources. This may be far more 291 visible in an optical network with a low ratio of potential LSPs per 292 link, and far less visible in packet networks with micro-flow LSPs. 294 With regards to applicability of GCO in the event of catastrophic 295 failures, there may be a real benefit in computing the paths of the 296 LSPs as a set rather than computing new paths from the head-end LSRs 297 in a distributed manner. It is to be noted, however, that a 298 centralized system will typically suffer from a slower response time 299 than a distributed system. 301 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) 303 Reconfiguration of the VNT [MLN-REQ] is a typical application 304 scenario where global concurrent path computation may be applicable. 305 Triggers for VNT reconfiguration, such as traffic demand changes, 306 network failures, and topological configuration changes, may require 307 a set of existing LSPs to be re-computed. 309 3.2.2. Traffic Migration 311 When migrating from one set of TE LSPs to a reoptimized set of TE 312 LSPs it is important that the traffic be moved without causing 313 disruption. Various techniques exist in MPLS and GMPLS, such as 314 make-before-break [RFC3209], to establish the new LSPs before tearing 315 down the old LSPs. When multiple LSP routes are changed according to 316 the computed results, some of the LSPs may be disrupted due to the 317 resource constraints. In other words, it may prove to be impossible 318 to perform a direct migration from the old LSPs to the new optimal 319 LSPs without disrupting traffic because there are insufficient 320 network resources to support both sets of LSPs when make-before-break 321 is used. However, the PCE may be able to determine an order of LSP 322 rerouting actions so that make-before-break can be performed within 323 the limited resources. 325 It may be the case that the reoptimization is radical. This could 326 mean that it is not possible to apply make-before-break in any order 327 to migrate from the old LSPs to the new LSPs. In this case a 328 migration strategy is required that may necessitate LSPs being 329 rerouted using make-before-break onto temporary paths in order to 330 make space for the full reoptimization. A PCE might indicate the 331 order in which reoptimized LSPs must be established and take over 332 from the old LSPs, and may indicate a series of different temporary 333 paths that must be used. Alternatively, the PCE might perform the 334 global reoptimization as a series of sub-reoptimizations by 335 reoptimizing subsets of the total set of LSPs. 337 The benefit of this multi-step rerouting includes minimization of 338 traffic discruption and optimization gain. However this approach may 339 imply some transient packets desequencing, jitter as well as control 340 plane stress. 342 Note also that during reoptimization, traffic disruption may be 343 allowed for some LSPs carrying low priority services (e.g., Internet 344 traffic) and not allowed for some LSPs carrying mission critical 345 services (e.g., voice traffic). 347 3.3. Greenfield Optimization 349 Greenfield optimization is a special case of GCO application when 350 there is no LSP setup. Once the LSPs are setup, it is not a 351 greenfield. The need for greenfield arises when network planner will 352 want to make use of computation servers to plan the LSPs that will be 353 provisioned in the network. 355 When a new TE network needs to be provisioned from a green-field 356 perspective, a set of TE LSPs need to be created based on traffic 357 demand, network topology, service constraints, and network resources. 358 Under this scenario, concurrent computation ability is highly 359 desirable, or required, to utilize network resources in an optimal 360 manner and avoid blocking risks. 362 3.3.1. Single-layer Traffic Engineering 364 Greenfield optimization can be applied when layer-specific TE LSPs 365 need to be created from a green-field perspective. For example, 366 MPLS-TE network can be established based on layer 3 specific traffic 367 demand, network topology, and network resources. Greenfield 368 optimization for single-layer traffic engineering can be applied to 369 optical transport networks such as SDH/Sonet, Ethernet Transport, 370 WDM, etc. 372 3.3.2. Multi-layer Traffic Engineering 374 Greenfield optimization is not limited to single-layer traffic 375 engineering. It can also be applied to multi-layer traffic 376 engineering. Both the client and the server layers network resources 377 and topology can be considered simultaneously in setting up a set of 378 TE LSPs that traverse the layer boundary. 380 4. PCECP Requirements 382 This section provides the PCECP requirements to support global 383 concurrent path computation applications. The requirements specified 384 here should be regarded as application-specific requirements and are 385 justifiable based on the extensibility clause found in section 6.1.14 386 of [RFC4657]: 388 The PCECP MUST support the requirements specified in the 389 application-specific requirements documents. The PCECP MUST also 390 allow extensions as more PCE applications will be introduced in 391 the future. 393 It is also to be noted that some of the requirements discussed in 394 this section have already been discussed in the PCECP requirement 395 document [RFC4657]. For example, Section 5.1.16 in [RFC4657] 396 provides a list of generic constraints while Section 5.1.17 in 397 [RFC4657] provides a list of generic objective functions that MUST be 398 supported by the PCECP. While using such generic requirements as the 399 baseline, this section provides application-specific requirements in 400 the context of global concurrent path computation and in a more 401 detailed level than the generic requirements. 403 The PCEP SHOULD support the following capabilities either via 404 creation of new objects and/or modification of existing objects where 405 applicable. 407 o An indicator to convey that the request is for a global concurrent 408 path computation. This indicator is necessary to ensure 409 consistency in applying global objectives and global constraints 410 in all path computations. Note: This requirement is covered by 411 "synchronized path computation" in [RFC4655] and [RFC4657]. 412 However, an explicit indicator to request a global concurrent 413 optimization is a new requirement. 415 o A Global Objective Function (GOF) field in which to specify the 416 global objective function. The global objective function is the 417 overarching objective function to which all individual path 418 computation requests are subjected in order to find a globally 419 optimal solution. Note that this requirement is covered by 420 "synchronized objective functions" in section 5.1.7 [RFC4657]. A 421 list of available global objective functions SHOULD include the 422 following objective functions at the minimum and SHOULD be 423 expandable for future addition: 425 * Minimize the sum of all TE LSP costs (min cost) 426 * Evenly allocate the network load to achieve the most uniform 427 link utilization across all links (this can be achieved by the 428 following objective function: minimize max over all links 429 {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i 430 and A(i) is the total bandwidth allocated on link i. 432 o A Global Constraints (GC) field in which to specify the list of 433 global constraints to which all the requested path computations 434 should be subjected. This list SHOULD include the following 435 constraints at the minimum and SHOULD be expandable for future 436 addition: 438 * Maximum link utilization value -- This value indicates the 439 highest possible link utilization percentage set for each link. 440 (Note: to avoid floating point numbers, the values should be 441 integer values.) 443 * Minimum link utilization value -- This value indicates the 444 lowest possible link utilization percentage set for each link. 445 (Note: same as above) 447 * Overbooking Factor -- The overbooking factor allows the 448 reserved bandwidth to be overbooked on each link beyond its 449 physical capacity limit. 451 * Maximum number of hops for all the LSPs -- This is the largest 452 number of hops that any LSP can have. Note that this 453 constraint can also be provided on a per LSP basis (as 454 requested in [RFC4657] and defined in [PCEP]). 456 * Exclusion of links/nodes in all LSP path computation (i.e., all 457 LSPs should not include the specified links/nodes in their 458 paths). Note that this constraint can also be provided on a 459 per LSP basis (as requested in [RFC4657] and defined in 460 [PCEP]). 462 * An indication should be available in a path computation 463 response that further reoptimization may only become available 464 once existing traffic has been moved to the new LSPs. 466 o A Global Concurrent Vector (GCV) field in which to specify all the 467 individual path computation requests that are subject to 468 concurrent path computation and subject to the global objective 469 function and all of the global constraints. Note that this 470 requirement is entirely fulfilled by the SVEC object in the PCEP 471 specification [PCEP]. Since the SVEC object as defined in [PCEP] 472 allows identifying a set of concurrent path requests, the SVEC can 473 be reused to specify all the individual concurrent path requests 474 for a global concurrent optimization. 476 o An indicator field in which to indicate the outcome of the 477 request. When the PCE could not find a feasible solution with the 478 initial request, the reason for failure SHOULD be indicated. This 479 requirement is partially covered by [RFC4657], but not in this 480 level of detail. The following indicators SHOULD be supported at 481 the minimum: 483 * no feasible solution found. Note that this is already covered 484 in [PCEP]. 486 * memory overflow 488 * PCE too busy. Note that this is already covered in [PCEP]. 490 * PCE not capable of concurrent reoptimization 492 * no migration path available 494 * administrative privileges do not allow global reoptimization 496 o In order to minimize disruption associated with bulk path 497 provisioning, the following requirements MUST be supported: 499 * The request message MUST allow requesting the PCE to provide 500 the order in which LSPs should be reoptimized (i.e., the 501 migration path) in order to minimize traffic disruption during 502 the migration. That is the request message MUST allow 503 indicating to the PCE that the set of paths that will be 504 provided in the response message (PCRep) has to be ordered. 506 * In response to the "ordering" request from the PCC, the PCE 507 MUST be able to indicate in the response message (PCRep) the 508 order in which LSPs should be reoptimized so as to minimize 509 traffic disruption. It should indicate for each request the 510 order in which the old LSP should be removed and the order in 511 which the new LSP should be setup. If the removal order is 512 lower than the setup order this means that make-before-break 513 cannot be done for this request. It might also be desirable to 514 have the PCE indicate whether ordering is in fact required or 515 not. 517 * As stated in RFC 4657, the request for a reoptimization MUST 518 support the inclusion of the set of previously computed paths 519 along with their bandwidth. This is to avoid double bandwidth 520 accounting and also this allows running an algorithm that 521 minimizes perturbation and that can compute a migration path 522 (LSP setup/removal orders). This is particularly required for 523 stateless PCEs. 525 * During a migration it may not be possible to do a make-before- 526 break for all existing LSPs. The request message must allow 527 indicating for each request whether make-before-break is 528 required (e.g. Voice traffic) or break-before-make is 529 acceptable (e.g. Internet traffic). The response message must 530 allow indicating LSPs for which make-before-break 531 reoptimization is not possible (this will be deduced from the 532 LSP setup and deletion orders). 534 * During a reoptimization it may be required to move a LSP 535 several times so as to avoid traffic disruption. The response 536 message must allow indicating the sequence of successive paths 537 for each request. 539 5. Protocol extensions for support of global concurrent optimization 541 This section provides protocol extensions for support of global 542 concurrent optimization. Protocol extensions discussed in this 543 section are built on [PCEP]. 545 The format of a PCReq message is currently as follows per [PCEP]: 547 ::= 548 [] 549 551 where: 552 ::= [] 553 ::= [] 554 ::= 555 [] 556 [] 557 [] 558 [] 559 [] 560 [] 561 [] 563 The format of a PCReq message after incorporating new requirements 564 for support of global concurrent optimization is as follows: 566 ::= 567 [] 568 570 The is changed as follows: 572 :: = 573 [] 574 [] 575 [] 576 [] 578 Note that three optional objects are added, following the SVEC 579 object: the OF (Objective Function) object, which is defined in 580 [PCE-OF], the GC (Global Constraints) object, which is defined in 581 this document (section 5.5), as well as the eXclude Route Object 582 (XRO) which is defined in [PCE-XRO]. Details of this change will be 583 discussed in the following sections 585 5.1. Global Objective Function (GOF) Specification 587 The global objective function can be specified in the PCEP Objective 588 Function (OF) object, defined in [PCE-OF]. The OF object includes a 589 16 bit Objective Function identifier. As per discussed in [PCE-OF], 590 objective function identifier code points are managed by IANA. 592 Two global objective functions are defined in this document and their 593 identifier should be assigned by IANA (suggested value) 595 Function 596 Code Description 598 1 Minimize the sum of all TE LSP costs (min cost) 600 2 Evenly allocate the network load to achieve the 601 most uniform link utilization across all links* 603 * Note: This can be achieved by the following objective function: 604 minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link 605 capacity for link i and A(i) is the total bandwidth allocated on link 606 i.) 608 5.2. Indication of Global Concurrent Optimization Requests 610 All the path requests in this application should be indicated so that 611 the global objective function and all of the global constraints are 612 applied to each of the requested path computation. In order to 613 support this requirement, a new flag is defined in the SVEC object: 615 C flag (1 bit): This is a new flag in the SVEC object. When C flag 616 is set, this indicates that all of the path requests listed in the 617 body of the SVEC object should be computed applying the global 618 constraints and the global objective function. 620 When the C Flag is set in the SVEC Object, the OF and the GC objects, 621 if included, should directly follow the SVEC Object. 623 5.3. Request for the order of LSP 625 In order to minimize disruption associated with bulk path 626 provisioning, the PCC may indicate to the PCE that the response MUST 627 be ordered. That is, the PCE has to include the order in which LSPs 628 MUST be moved so as to minimize traffic disruption. To support such 629 indication a new flag, the D flag, is defined in the RP object as 630 follows: 632 0 1 2 3 633 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 634 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 635 | Reserved | Flags |D|M|F|O|B|R| Pri | 636 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 637 | Request-ID-number | 638 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 639 | | 640 // Optional TLV(s) // 641 | | 642 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 644 Figure 5: RP object body format in the PCReq Message 646 D bit (orDer - 1 bit): when set, in a PCReq message, the requesting 647 PCC requires the PCE to specify in the PCRep message the order in 648 which this particular path request is to be provisioned relative to 649 other requests. 651 M bit (Make-before-break - 1 bit): when set, this indicates that a 652 make-before-break reoptimization is required for this request. 654 When M bit is not set, this implies that a break-before-make 655 reoptimization is allowed for this request. Note that M bit can be 656 set only if the R (Reoptimization) flag is set. 658 5.4. The Order Response 660 The PCE MUST specify the order number in response to the Order 661 Request made by the PCC in the PCReq message if so requested by the 662 setting of the D bit in the RP object in the PCReq message. To 663 support such ordering indication a new optional TLV is defined in the 664 RP object, the Order TLV, as follows: 666 0 1 2 3 667 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 668 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 669 | Reserved | Flags |D|M|F|O|B|R| Pri | 670 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 671 | Request-ID-number | 672 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 673 | | 674 // Order TLV (Optional TLV) // 675 | | 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 Figure 6: RP object body format in the PCRep Message 680 The Order TLV is an optional TLV in the RP object, that indicates the 681 order in which the old LSP must be removed and the new LSP must be 682 setup during a reoptimization. It is carried in the PCRep message in 683 response to a reoptimization request. 685 The Order TLV SHOULD be included in the RP object in the PCRep 686 message if the D bit is set in the RP object in the PCReq message. 688 The format of the Order TLV is as follows: 690 0 1 2 3 691 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 692 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 693 | Type | Length | | 694 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 695 | Delete Order | 696 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 697 | Setup Order | 698 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 Type To be defined by IANA (suggested value = ) 701 Length Variable 702 Value Orders in which the old path should be removed 703 and the new path should be setup 705 Figure 7: The Order TLV in the RP object in the PCRep Message 707 Delete Order: 32 bit integer that indicates the order in which the 708 old LSP should be removed 709 Setup Order: 32 bit integer that indicates the order in which the new 710 LSP should be setup 712 The delete order should not be equal to the setup order. If the 713 delete order is higher than the setup order, this means that the 714 reoptimization can be done in a make-before-break manner, else it 715 cannot be done in a make-before-break manner. 717 To illustrate, consider a network with two established requests: R1 718 with path P1 and R2 with path P2. During a reoptimization the PCE 719 may provide the following ordered reply: 721 R1, path P1', remove order 1, setup order 4 722 R2, path P2', remove order 3, setup order 2 724 This indicates that the NMS should do the following sequence of 725 tasks: 727 1: Remove path P1 728 2: Setup path P2' 729 3: Remove path P2 730 4: Setup path P1' 732 That is, R1 is reoptimized in a break-before-make manner and R2 in a 733 make-before-break manner. 735 5.5. Global Constraints (GC) Object 737 The Global Constraints (GC) Object is used in a PCReq message to 738 specify the necessary global constraints that should be applied to 739 all individual path computations for a global concurrent path 740 optimization request. 742 The format of the GC object body that includes the global constraints 743 is as follows: 745 0 1 2 3 746 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 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | MU | mU | OB | MH | 749 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 | | 751 // Optional TLV(s) // 752 | | 753 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 754 Figure 10: GC body object format 756 MU (Max Utilization) (8 bits) : 8 bit integer that indicates the 757 upper bound utilization percentage by which all link should be bound. 758 Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link 759 Capacity 761 mU (minimum Utilization) (8 bits) : 8 bit integer that indicates the 762 lower bound utilization percentage by which all link should be bound. 764 OB (Over Booking factor) (8 bits) : 8 bit integer that indicates the 765 overbooking percentage that allows the reserved bandwidth to be 766 overbooked on each link beyond its physical capacity limit. The 767 value, for example, 10% means that 110 Mbps can be reserved on a 768 100Mbps link. 770 MH (Max Hop) (8 bits): 8 bit integer that indicates the maximum hop 771 count for all the LSPs. 773 GC Object-Class is to be assigned by IANA. 775 GC Object-Type is to be assigned by IANA. 777 The exclusion of the list of nodes/links from a global path 778 computation can be done by including the XRO object following the GC 779 object in the new SVEC list definition. 781 5.6. Error Indicator 783 To indicate errors associated with the global concurrent path 784 optimization request, a new Error-Type (14) and subsequent error- 785 values are defined as follows for inclusion in the PCEP-ERROR object: 787 A new Error-Type (14) and subsequent error-values are defined as 788 follows: 790 Error-Type=14 and Error-Value=1: if a PCE receives a global 791 concurrent path optimization request and the PCE is not capable of 792 the request due to insufficient memory, the PCE MUST send a PCErr 793 message with a PCEP ERROR object (Error-Type=14) and an Error-Value 794 (Error-Value=1). The corresponding global concurrent path 795 optimization request MUST be cancelled. 797 Error-Type=14; Error-Value=2: if a PCE receives a global concurrent 798 path optimization request and the PCE is not capable of global 799 concurrent optimization, the PCE MUST send a PCErr message with a 800 PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=2). 801 The corresponding global concurrent path optimization MUST be 802 cancelled. 804 To indicate an error associated with policy violation, a new error 805 value "global concurrent optimization not allowed" should be added to 806 an existing error code for policy violation (Error-Type=5) as defined 807 in [PCEP]. 809 Error-Type=5; Error-Value=3: if a PCE receives a global concurrent 810 path optimization request which is not compliant with administrative 811 privileges (i.e., the PCE policy does not support global concurrent 812 optimization), the PCE sends a PCErr message with a PCEP-ERROR Object 813 (Error-Type=5) and an Error-Value (Error-Value=3). The corresponding 814 global concurrent path computation MUST be cancelled. 816 5.7. NO-PATH Indicator 818 To communicate the reason(s) for not being able to find global 819 concurrent path computation, the NO-PATH object can be used in the 820 PCRep message. The format of the NO-PATH object body is as follows: 822 0 1 2 3 823 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 824 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 825 |C| Flags | Reserved | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 827 | | 828 // Optional TLV(s) // 829 | | 830 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 832 Figure 11: NO-PATH object format 834 Flags (16 bits). The C flag is defined in [PCEP]. 836 Two new bit flags are defined in the NO-PATH-VECTOR TLV carried in 837 the NO-PATH Object: 839 0x08: when set, the PCE indicates that no migration path was found. 841 0x10: when set, the PCE indicates no feasible solution was found that 842 meets all the constraints associated with global concurrent path 843 optimization in the PCRep message. 845 When either 0x08 or 0x10 flag is set in the NO-PATH-VECTOR TLV 846 carried in the NO-PATH object in the PCRep Message, a subsequent 847 multi-session feature may be triggered if the PCC's local policy 848 allows it. The multi-session feature allows the original global 849 concurrent optimization to be split into a number of multiple 850 sessions so that the PCE would compute a number of smaller-scale 851 optimizations in a sequential manner. The trade-off is that a 852 partial feasible solution may be obtained using this approach which 853 is better than not having any solution at all, although such solution 854 might not be a global optimal solution. How to divide up the 855 original set of global concurrent optimization requests into multiple 856 numbers of smaller-scale optimizations is out of the scope of this 857 document. 859 6. Manageability Considerations 861 Manageability of Global Concurrent Path Computation with PCE must 862 address the following considerations: 864 6.1. Control of Function and Policy 866 In addition to the parameters already listed in section 8.1 of 867 [PCEP], a PCEP implementation SHOULD allow configuring the following 868 PCEP session parameters on a PCC: 870 o The ability to send a GCO request. 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 PCE: 876 o The support for Global Concurrent Optimization. 878 o The maximum number of synchronized path requests per request 879 message. 881 o A set of GCO specific policies (authorized sender, request rate 882 limiter, etc). 884 These parameters may be configured as default parameters for any PCEP 885 session the PCEP speaker participates in, or may apply to a specific 886 session with a given PCEP peer or a specific group of sessions with a 887 specific group of PCEP peers. 889 6.2. Information and Data Models, e.g. MIB module 891 Extensions to the PCEP MIB module defined in [PCEP-MIB] should be 892 defined, so as to cover the GCO information introduced in this 893 document. 895 6.3. Liveness Detection and Monitoring 897 Mechanisms defined in this draft does not imply any new liveness 898 detection and monitoring requirements in addition to those already 899 listed in section 8.3 of [PCEP]. 901 6.4. Verifying Correct Operation 903 Mechanisms defined in this draft does not imply any new verification 904 requirements in addition to those already listed in section 8.4 of 905 [PCEP] 907 6.5. Requirements on Other Protocols and Functional Components 909 The PCE Discovery mechanisms ([ISIS PCED] and [OSPF PCED]) may be 910 used to advertise global concurrent path computation capabilities to 911 PCCs. 913 6.6. Impact on Network Operation 915 Mechanisms defined in this draft does not imply any new network 916 operation requirements in addition to those already listed in section 917 8.6 of [PCEP]. 919 7. Security Considerations 921 When global re-optimization is applied to an active network, it could 922 be extremely disruptive. Although the real security and policy 923 issues apply at the NMS, if the wrong results are returned to the 924 NMS, the wrong actions may be taken in the network. Therefore, it is 925 very important that the operator issuing the commands has sufficient 926 authority and is authenticated, and that the computation request is 927 subject to appropriate policy. 929 The mechanism defined in [PCEP] to secure a PCEP session can be used 930 to secure global concurrent path computation requests/responses. 932 8. Acknowledgements 934 We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning So 935 and Lucy Yong for their useful comments and suggestions. 937 9. IANA Considerations 939 A future revision of this document will present requests to IANA for 940 codepoint allocation. 942 10. References 944 10.1. Normative References 946 [PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 947 Function encoding in Path Computation Element 948 communication and discovery protocols, 949 draft-leroux-pce-of, work in progress". 951 [PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation 952 Element Communication Protocol (PCEP) for Route 953 Exclusions, draft-ietf-pce-pcep-xro-00.txt, work in 954 progress". 956 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 957 Element (PCE) communication Protocol (PCEP) - Version 1, 958 draft-ietf-pce-pcep, work in progress". 960 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 961 Requirement Levels", BCP 14, RFC 2119, March 1997. 963 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 964 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 965 Tunnels", RFC 3209, December 2001. 967 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 968 Element (PCE)-Based Architecture, RFC 4655, August 2006". 970 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 971 Communication Protocol Generic Requirements, RFC 4657, 972 September 2006". 974 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 975 (PCE) Discovery, RFC 4674, October 2006.". 977 10.2. Informative References 979 [ISIS-PCED] 980 Le Roux, J. and JP. Vasseur, "IS-IS protocol extensions 981 for Path Computation Element (PCE) Discovery, 982 draft-ietf-pce-disco-proto-isis, work in progress.". 984 [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- 985 region and multi-layer networks (MRN/MLN), 986 draft-ietf-ccamp-gmpls-mln-reqs, work in progress". 988 [OSPF-PCED] 989 Le Roux, J. and JP. Vasseur, "OSPF protocol extensions for 990 Path Computation Element (PCE) Discovery, 991 draft-ietf-pce-disco-proto-ospf, work in progress.". 993 [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- 994 based inter-layer MPLS and GMPL traffic engineering, 995 draft-ietf-pce-inter-layer-frwk, work in progress.". 997 [PCEP-MIB] 998 Stephen, E. and K. Koushik, "PCE communication 999 protocol(PCEP) Management Information Base, 1000 draft-kkoushik-pce-pcep-mib, work in progress.". 1002 Authors' Addresses 1004 Young Lee 1005 Huawei 1006 1700 Alma Drive, Suite 100 1007 Plano, TX 75075 1008 US 1010 Phone: +1 972 509 5599 x2240 1011 Fax: +1 469 229 5397 1012 Email: ylee@huawei.com 1014 JL Le Roux 1015 France Telecom 1016 2, Avenue Pierre-Marzin 1017 Lannion 22307 1018 FRANCE 1020 Email: jeanlouis.leroux@orange-ftgroup.com 1022 Daniel King 1023 Aria Networks 1024 44/45 Market Place 1025 Chippenham SN15 3HU 1026 United Kingdom 1028 Phone: +44 7790 775187 1029 Fax: +44 1249 446530 1030 Email: daniel.king@aria-networks.com 1032 Eiji Oki 1033 NTT 1034 Midori 3-9-11 1035 Musashino, Tokyo 180-8585 1036 JAPAN 1038 Email: oki.eiji@lab.ntt.co.jp 1040 Full Copyright Statement 1042 Copyright (C) The IETF Trust (2007). 1044 This document is subject to the rights, licenses and restrictions 1045 contained in BCP 78, and except as set forth therein, the authors 1046 retain all their rights. 1048 This document and the information contained herein are provided on an 1049 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1050 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1051 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1052 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1053 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1054 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1056 Intellectual Property 1058 The IETF takes no position regarding the validity or scope of any 1059 Intellectual Property Rights or other rights that might be claimed to 1060 pertain to the implementation or use of the technology described in 1061 this document or the extent to which any license under such rights 1062 might or might not be available; nor does it represent that it has 1063 made any independent effort to identify any such rights. Information 1064 on the procedures with respect to rights in RFC documents can be 1065 found in BCP 78 and BCP 79. 1067 Copies of IPR disclosures made to the IETF Secretariat and any 1068 assurances of licenses to be made available, or the result of an 1069 attempt made to obtain a general license or permission for the use of 1070 such proprietary rights by implementers or users of this 1071 specification can be obtained from the IETF on-line IPR repository at 1072 http://www.ietf.org/ipr. 1074 The IETF invites any interested party to bring to its attention any 1075 copyrights, patents or patent applications, or other proprietary 1076 rights that may cover technology that may be required to implement 1077 this standard. Please address the information to the IETF at 1078 ietf-ipr@ietf.org. 1080 Acknowledgment 1082 Funding for the RFC Editor function is provided by the IETF 1083 Administrative Support Activity (IASA).