idnits 2.17.1 draft-ietf-pce-global-concurrent-optimization-03.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 1084. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1095. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1102. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1108. 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 use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- 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 24, 2008) is 5782 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: 'RFC5058' is mentioned on line 186, but not defined == Missing Reference: 'RFC5059' is mentioned on line 186, but not defined == Missing Reference: 'ISIS PCED' is mentioned on line 858, but not defined == Missing Reference: 'OSPF PCED' is mentioned on line 858, but not defined == Unused Reference: 'ISIS-PCED' is defined on line 1009, but no explicit reference was found in the text == Unused Reference: 'OSPF-PCED' is defined on line 1018, but no explicit reference was found in the text == Unused Reference: 'PCE-MLN' is defined on line 1023, 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 (~~), 11 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 26, 2008 France Telecom 6 D. King 7 Aria Networks 8 E. Oki 9 NTT 10 June 24, 2008 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-03.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 26, 2008. 41 Abstract 43 The Path Computation Element (PCE) is a network component, 44 application, or node that is capable of performing path computations 45 at the request of Path Computation Clients (PCCs). The PCE is 46 applied in Multiprotocol Label Switching Traffic Engineering 47 (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to 48 determine the routes of Label Switched Paths (LSPs) through the 49 network. The Path Computation Element Communication Protocol (PCEP) 50 is specified for communications between PCCs and PCEs, and between 51 cooperating PCEs. 53 When computing or re-optimizing the routes of a set of LSPs through a 54 network it may be advantageous to perform bulk path computations in 55 order to avoid blocking problems and to achieve more optimal network- 56 wide solutions. Such bulk optimization is termed Global Concurrent 57 Optimization (GCO). A GCO is able to simultaneously consider the 58 entire topology of the network and the complete set of existing LSPs, 59 and their respective constraints, and look to optimize or re-optimize 60 the entire network to satisfy all constraints for all LSPs. A GCO 61 may also be applied to some subset of the LSPs in a network. The GCO 62 application is primarily a Network Management System (NMS) solution. 64 This document provides application-specific requirements and the PCEP 65 extensions in support of GCO applications. 67 Table of Contents 69 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 71 3. Applicability of Global Concurrent Optimization (GCO) . . . . 7 72 3.1. Application of the PCE Architecture . . . . . . . . . . . 7 73 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8 74 3.2.1. Reconfiguration of the Virtual Network Topology 75 (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8 76 3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8 77 3.3. Greenfield Optimization . . . . . . . . . . . . . . . . . 9 78 3.3.1. Single-layer Traffic Engineering . . . . . . . . . . . 10 79 3.3.2. Multi-layer Traffic Engineering . . . . . . . . . . . 10 80 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 81 5. Protocol extensions for support of global concurrent 82 optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 5.1. Global Objective Function (GOF) Specification . . . . . . 15 84 5.2. Indication of Global Concurrent Optimization Requests . . 16 85 5.3. Request for the order of LSP . . . . . . . . . . . . . . . 16 86 5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17 87 5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 18 88 5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 19 89 5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 20 90 6. Manageability Considerations . . . . . . . . . . . . . . . . . 21 91 6.1. Control of Function and Policy . . . . . . . . . . . . . . 21 92 6.2. Information and Data Models, e.g. MIB module . . . . . . . 21 93 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 94 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 21 95 6.5. Requirements on Other Protocols and Functional 96 Components . . . . . . . . . . . . . . . . . . . . . . . . 22 97 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 22 98 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 99 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 100 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 101 9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 25 102 9.2. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . 25 103 9.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 25 104 9.4. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 26 105 9.4.1. New Error-Values for Existing Error-Types . . . . . . 26 106 9.4.2. New Error-Types and Error-Values . . . . . . . . . . . 26 107 9.5. New No-Path Reasons . . . . . . . . . . . . . . . . . . . 26 108 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 109 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 110 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 111 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 112 Intellectual Property and Copyright Statements . . . . . . . . . . 30 114 1. Introduction 116 [RFC4655] defines the Path Computation Element (PCE) based 117 Architecture and explains how a PCE may compute Label Switched Paths 118 (LSP) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) 119 and Generalized MPLS (GMPLS) networks at the request of Path 120 Computation Clients (PCCs). A PCC is shown to be any network 121 component that makes such a request and may be for instance a Label 122 Switching Router (LSR) or a Network Management System (NMS). The 123 PCE, itself, is shown to be located anywhere within the network, and 124 may be within an LSR, an NMS or Operational Support System (OSS), or 125 may be an independent network server. 127 The PCE Communication Protocol (PCEP) is the communication protocol 128 used between PCC and PCE, and may also be used between cooperating 129 PCEs. [RFC4657] sets out generic protocol requirements for PCEP. 130 Additional application-specific requirements for PCEP are defined in 131 separate documents. 133 This document provides a set of requirements and PCEP extensions in 134 support of concurrent path computation applications. A concurrent 135 path computation is a path computation application where a set of TE 136 paths are computed concurrently in order to efficiently utilize 137 network resources. The computation method involved with a concurrent 138 path computation is referred to as global concurrent optimization in 139 this document. Appropriate computation algorithms to perform this 140 type of optimization are out of the scope of this document. 142 The Global Concurrent Optimization (GCO) application is primarily an 143 NMS or a PCE Server based solution. Owing to complex synchronization 144 issues associated with GCO applications, the management based PCE 145 architecture defined in section 5.5 of [RFC4655] is considered as the 146 most suitable usage to support GCO application. This does not 147 preclude other architectural alternatives to support GCO application, 148 but they are NOT RECOMMENDED. For instance, GCO might be enabled by 149 distributed LSRs through complex synchronization mechanisms. 150 However, this approach might suffer from significant synchronization 151 overhead between the PCE and each of the PCCs. It would likely 152 affect the network stability and hence significantly diminish the 153 benefits of deploying PCEs. 155 As new LSPs are added or removed from the network over time, the 156 global network resources become fragmented and the existing placement 157 of LSPs within network no longer provides optimal use of the 158 available capacity. A global concurrent path computation is able to 159 simultaneously consider the entire topology of the network and the 160 complete set of existing LSPs and their respective constraints, and 161 look to re-optimize the entire network to satisfy all constraints for 162 all LSPs. Alternatively, the application may consider a subset of 163 the LSPs and/or a subset of the network topology. 165 The need for global concurrent path computation may also arise when 166 network operators need to establish a set of TE LSPs in their network 167 planning process. It is also envisioned that network operators might 168 require global concurrent path computation in the event of 169 catastrophic network failures, where a set of TE LSPs need to be 170 optimally rerouted. The nature of this work promote the use of such 171 systems for offline processing. Online application of this work 172 should only be considered with proven empirical validation. 174 As the PCE has the potential to provide solutions in all path 175 computation solutions in a variety of environments and is a candidate 176 for performing path computations in support of GCO. 178 The main focus of this document is to highlight the PCC-PCE 179 communication needs in support of a concurrent path computation 180 applications and to define protocol extensions to meet those needs. 182 The PCC-PCE requirements addressed herein are specific to the context 183 where the PCE is a specialized PCE that is capable of performing 184 computations in support of GCO. Discovery of such capabilities might 185 be desirable and could be achieved through extensions to the PCE 186 discovery mechanisms [RFC4674], [RFC5058], [RFC5059], but that is out 187 of the scope of this document. 189 It is to be noted that BRPC [BRPC] is a multi-PCE path computation 190 technique used to compute a shortest constrained inter-domain path 191 wheres this ID specifies a technique where a set of path computation 192 requests are bundled and send to a PCE with the objective of 193 "optimizing" the set of computed paths. 195 2. Terminology 197 Most of the terminology used in this document is explained in 198 [RFC4655]. A few key terms are repeated here for clarity. 200 PCC: Path Computation Client: Any client application requesting a 201 path computation to be performed by a Path Computation Element. 203 PCE: Path Computation Element: An entity (component, application or 204 network node) that is capable of computing a network path or route 205 based on a network graph and applying computational constraints. 207 TED: Traffic Engineering Database which contains the topology and 208 resource information of the domain. The TED may be fed by IGP 209 extensions or potentially by other means. 211 PCECP: The PCE Communication Protocol: PCECP is the generic abstract 212 idea of a protocol that is used to communicate path computation 213 requests a PCC to a PCE, and to return computed paths from the PCE to 214 the PCC. The PCECP can also be used between cooperating PCEs. 216 PCEP: The PCE communication Protocol: PCEP is the actual protocol 217 that implements the PCECP idea. 219 GCO: Global Concurrent Optimization: A concurrent path computation 220 application where a set of TE paths are computed concurrently in 221 order to efficiently utilize network resources. A GCO path 222 computation is able to simultaneously consider the entire topology of 223 the network and the complete set of existing LSPs, and their 224 respective constraints, and look to optimize or re-optimize the 225 entire network to satisfy all constraints for all LSPs. A GCO path 226 computation can also provide an optimal way to migrate from an 227 existing set of LSPs to a reoptimized set (Morphing Problem). 229 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 230 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 231 document are to be interpreted as described in RFC 2119 [RFC2119]. 232 These terms are also used in the parts of this document that specify 233 requirements for clarity of specification of those requirements. 235 3. Applicability of Global Concurrent Optimization (GCO) 237 This section discusses the PCE architecture to which GCO is applied. 238 It also discusses various application scenarios for which global 239 concurrent path computation may be applied. 241 3.1. Application of the PCE Architecture 243 Figure 1 shows the PCE-based network architecture as defined in 244 [RFC4655] to which GCO application is applied. It must be observed 245 that the PCC is not necessarily an LSR [RFC4655]. The GCO 246 application is primarily an NMS-based solution in which an NMS plays 247 the function of the PCC. Although Figure 1 shows the PCE as remote 248 from the NMS, it might be collocated with the NMS. Note that in the 249 collocated case there is no need for a standard communication 250 protocol, this can rely on internal APIs. 252 ----------- 253 Application | ----- | 254 Request | | TED | | 255 | | ----- | 256 v | | | 257 ------------- Request/ | v | 258 | PCC | Response| ----- | 259 | (NMS/Server)|<--------+> | PCE | | 260 | | | ----- | 261 ------------- ----------- 262 Service | 263 Request | 264 v 265 ---------- Signaling ---------- 266 | Head-End | Protocol | Adjacent | 267 | Node |<---------->| Node | 268 ---------- ---------- 270 Figure 1: PCE-Based Architecture for Global Concurrent Optimization 272 Upon receipt of an application request (e.g., a traffic demand matrix 273 is provided to the NMS by the operator's network planning procedure), 274 the NMS requests a global concurrent path computation from the PCE. 275 The PCE then computes the requested paths concurrently applying some 276 algorithms. When the requested path computation completes, the PCE 277 sends the resulting paths back to the NMS. The NMS then supplies the 278 head-end LSRs with a fully computed explicit path for each TE LSP 279 that needs to be established. 281 3.2. Re-optimization of Existing Networks 283 The need for global concurrent path computation may arise in existing 284 networks. When an existing TE LSP network experiences sub-optimal 285 use of its resources, the need for re-optimization or reconfiguration 286 may arise. The scope of re-optimization and reconfiguration may vary 287 depending on particular situations. The scope of re-optimization may 288 be limited to bandwidth modification to an existing TE LSP. However, 289 it could well be that a set of TE LSPs may need to be re-optimized 290 concurrently. In an extreme case, the TE LSPs may need to be 291 globally re-optimized. 293 In loaded networks, with large size LSPs, a sequential re- 294 optimization may not produce substantial improvements in terms of 295 overall network optimization. The potential for network-wide gains 296 from reoptimization of LSPs sequentially is dependent upon the 297 network usage and size of the LSPs being optimized. However, the key 298 point remains: computing the reoptimized path of one LSP at a time 299 with giving no consideration to the other LSPs in the network could 300 result in sub-optimal use of network resources. This may be far more 301 visible in an optical network with a low ratio of potential LSPs per 302 link, and far less visible in packet networks with micro-flow LSPs. 304 With regards to applicability of GCO in the event of catastrophic 305 failures, there may be a real benefit in computing the paths of the 306 LSPs as a set rather than computing new paths from the head-end LSRs 307 in a distributed manner. It is to be noted, however, that a 308 centralized system will typically suffer from a slower response time 309 than a distributed system. 311 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) 313 Reconfiguration of the VNT [MLN-REQ] is a typical application 314 scenario where global concurrent path computation may be applicable. 315 Triggers for VNT reconfiguration, such as traffic demand changes, 316 network failures, and topological configuration changes, may require 317 a set of existing LSPs to be re-computed. 319 3.2.2. Traffic Migration 321 When migrating from one set of TE LSPs to a reoptimized set of TE 322 LSPs it is important that the traffic be moved without causing 323 disruption. Various techniques exist in MPLS and GMPLS, such as 324 make-before-break [RFC3209], to establish the new LSPs before tearing 325 down the old LSPs. When multiple LSP routes are changed according to 326 the computed results, some of the LSPs may be disrupted due to the 327 resource constraints. In other words, it may prove to be impossible 328 to perform a direct migration from the old LSPs to the new optimal 329 LSPs without disrupting traffic because there are insufficient 330 network resources to support both sets of LSPs when make-before-break 331 is used. However, the PCE may be able to determine an order of LSP 332 rerouting actions so that make-before-break can be performed within 333 the limited resources. 335 It may be the case that the reoptimization is radical. This could 336 mean that it is not possible to apply make-before-break in any order 337 to migrate from the old LSPs to the new LSPs. In this case a 338 migration strategy is required that may necessitate LSPs being 339 rerouted using make-before-break onto temporary paths in order to 340 make space for the full reoptimization. A PCE might indicate the 341 order in which reoptimized LSPs must be established and take over 342 from the old LSPs, and may indicate a series of different temporary 343 paths that must be used. Alternatively, the PCE might perform the 344 global reoptimization as a series of sub-reoptimizations by 345 reoptimizing subsets of the total set of LSPs. 347 The benefit of this multi-step rerouting includes minimization of 348 traffic discruption and optimization gain. However this approach may 349 imply some transient packets desequencing, jitter as well as control 350 plane stress. 352 Note also that during reoptimization, traffic disruption may be 353 allowed for some LSPs carrying low priority services (e.g., Internet 354 traffic) and not allowed for some LSPs carrying mission critical 355 services (e.g., voice traffic). 357 3.3. Greenfield Optimization 359 Greenfield optimization is a special case of GCO application when 360 there is no LSP setup. Once the LSPs are setup, it is not a 361 greenfield. The need for greenfield arises when network planner will 362 want to make use of computation servers to plan the LSPs that will be 363 provisioned in the network. 365 When a new TE network needs to be provisioned from a green-field 366 perspective, a set of TE LSPs need to be created based on traffic 367 demand, network topology, service constraints, and network resources. 368 Under this scenario, concurrent computation ability is highly 369 desirable, or required, to utilize network resources in an optimal 370 manner and avoid blocking risks. 372 3.3.1. Single-layer Traffic Engineering 374 Greenfield optimization can be applied when layer-specific TE LSPs 375 need to be created from a green-field perspective. For example, 376 MPLS-TE network can be established based on layer 3 specific traffic 377 demand, network topology, and network resources. Greenfield 378 optimization for single-layer traffic engineering can be applied to 379 optical transport networks such as SDH/Sonet, Ethernet Transport, 380 WDM, etc. 382 3.3.2. Multi-layer Traffic Engineering 384 Greenfield optimization is not limited to single-layer traffic 385 engineering. It can also be applied to multi-layer traffic 386 engineering. Both the client and the server layers network resources 387 and topology can be considered simultaneously in setting up a set of 388 TE LSPs that traverse the layer boundary. 390 4. PCECP Requirements 392 This section provides the PCECP requirements to support global 393 concurrent path computation applications. The requirements specified 394 here should be regarded as application-specific requirements and are 395 justifiable based on the extensibility clause found in section 6.1.14 396 of [RFC4657]: 398 The PCECP MUST support the requirements specified in the 399 application-specific requirements documents. The PCECP MUST also 400 allow extensions as more PCE applications will be introduced in 401 the future. 403 It is also to be noted that some of the requirements discussed in 404 this section have already been discussed in the PCECP requirement 405 document [RFC4657]. For example, Section 5.1.16 in [RFC4657] 406 provides a list of generic constraints while Section 5.1.17 in 407 [RFC4657] provides a list of generic objective functions that MUST be 408 supported by the PCECP. While using such generic requirements as the 409 baseline, this section provides application-specific requirements in 410 the context of global concurrent path computation and in a more 411 detailed level than the generic requirements. 413 The PCEP SHOULD support the following capabilities either via 414 creation of new objects and/or modification of existing objects where 415 applicable. 417 o An indicator to convey that the request is for a global concurrent 418 path computation. This indicator is necessary to ensure 419 consistency in applying global objectives and global constraints 420 in all path computations. Note: This requirement is covered by 421 "synchronized path computation" in [RFC4655] and [RFC4657]. 422 However, an explicit indicator to request a global concurrent 423 optimization is a new requirement. 425 o A Global Objective Function (GOF) field in which to specify the 426 global objective function. The global objective function is the 427 overarching objective function to which all individual path 428 computation requests are subjected in order to find a globally 429 optimal solution. Note that this requirement is covered by 430 "synchronized objective functions" in section 5.1.7 [RFC4657]. A 431 list of available global objective functions SHOULD include the 432 following objective functions at the minimum and SHOULD be 433 expandable for future addition: 435 * Minimize the sum of all TE LSP costs (min cost) 436 * Evenly allocate the network load to achieve the most uniform 437 link utilization across all links (this can be achieved by the 438 following objective function: minimize max over all links 439 {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i 440 and A(i) is the total bandwidth allocated on link i. 442 o A Global Constraints (GC) field in which to specify the list of 443 global constraints to which all the requested path computations 444 should be subjected. This list SHOULD include the following 445 constraints at the minimum and SHOULD be expandable for future 446 addition: 448 * Maximum link utilization value -- This value indicates the 449 highest possible link utilization percentage set for each link. 450 (Note: to avoid floating point numbers, the values should be 451 integer values.) 453 * Minimum link utilization value -- This value indicates the 454 lowest possible link utilization percentage set for each link. 455 (Note: same as above) 457 * Overbooking Factor -- The overbooking factor allows the 458 reserved bandwidth to be overbooked on each link beyond its 459 physical capacity limit. 461 * Maximum number of hops for all the LSPs -- This is the largest 462 number of hops that any LSP can have. Note that this 463 constraint can also be provided on a per LSP basis (as 464 requested in [RFC4657] and defined in [PCEP]). 466 * Exclusion of links/nodes in all LSP path computation (i.e., all 467 LSPs should not include the specified links/nodes in their 468 paths). Note that this constraint can also be provided on a 469 per LSP basis (as requested in [RFC4657] and defined in 470 [PCEP]). 472 * An indication should be available in a path computation 473 response that further reoptimization may only become available 474 once existing traffic has been moved to the new LSPs. 476 o A Global Concurrent Vector (GCV) field in which to specify all the 477 individual path computation requests that are subject to 478 concurrent path computation and subject to the global objective 479 function and all of the global constraints. Note that this 480 requirement is entirely fulfilled by the SVEC object in the PCEP 481 specification [PCEP]. Since the SVEC object as defined in [PCEP] 482 allows identifying a set of concurrent path requests, the SVEC can 483 be reused to specify all the individual concurrent path requests 484 for a global concurrent optimization. 486 o An indicator field in which to indicate the outcome of the 487 request. When the PCE could not find a feasible solution with the 488 initial request, the reason for failure SHOULD be indicated. This 489 requirement is partially covered by [RFC4657], but not in this 490 level of detail. The following indicators SHOULD be supported at 491 the minimum: 493 * no feasible solution found. Note that this is already covered 494 in [PCEP]. 496 * memory overflow 498 * PCE too busy. Note that this is already covered in [PCEP]. 500 * PCE not capable of concurrent reoptimization 502 * no migration path available 504 * administrative privileges do not allow global reoptimization 506 o In order to minimize disruption associated with bulk path 507 provisioning, the following requirements MUST be supported: 509 * The request message MUST allow requesting the PCE to provide 510 the order in which LSPs should be reoptimized (i.e., the 511 migration path) in order to minimize traffic disruption during 512 the migration. That is the request message MUST allow 513 indicating to the PCE that the set of paths that will be 514 provided in the response message (PCRep) has to be ordered. 516 * In response to the "ordering" request from the PCC, the PCE 517 MUST be able to indicate in the response message (PCRep) the 518 order in which LSPs should be reoptimized so as to minimize 519 traffic disruption. It should indicate for each request the 520 order in which the old LSP should be removed and the order in 521 which the new LSP should be setup. If the removal order is 522 lower than the setup order this means that make-before-break 523 cannot be done for this request. It might also be desirable to 524 have the PCE indicate whether ordering is in fact required or 525 not. 527 * As stated in RFC 4657, the request for a reoptimization MUST 528 support the inclusion of the set of previously computed paths 529 along with their bandwidth. This is to avoid double bandwidth 530 accounting and also this allows running an algorithm that 531 minimizes perturbation and that can compute a migration path 532 (LSP setup/removal orders). This is particularly required for 533 stateless PCEs. 535 * During a migration it may not be possible to do a make-before- 536 break for all existing LSPs. The request message must allow 537 indicating for each request whether make-before-break is 538 required (e.g. Voice traffic) or break-before-make is 539 acceptable (e.g. Internet traffic). The response message must 540 allow indicating LSPs for which make-before-break 541 reoptimization is not possible (this will be deduced from the 542 LSP setup and deletion orders). 544 5. Protocol extensions for support of global concurrent optimization 546 This section provides protocol extensions for support of global 547 concurrent optimization. Protocol extensions discussed in this 548 section are built on [PCEP]. 550 The format of a PCReq message after incorporating new requirements 551 for support of global concurrent optimization is as follows: 553 ::= 554 [] 555 557 The is changed as follows: 559 :: = 560 [] 561 [] 562 [] 563 [] 565 Note that three optional objects are added, following the SVEC 566 object: the OF (Objective Function) object, which is defined in 567 [PCE-OF], the GC (Global Constraints) object, which is defined in 568 this document (section 5.5), as well as the eXclude Route Object 569 (XRO) which is defined in [PCE-XRO]. Details of this change will be 570 discussed in the following sections. 572 Note also that when the XRO is global to a SVEC, and F bit is set, it 573 should be allowed to specify multiple RRO objects in the PCReq 574 message. 576 5.1. Global Objective Function (GOF) Specification 578 The global objective function can be specified in the PCEP Objective 579 Function (OF) object, defined in [PCE-OF]. The OF object includes a 580 16 bit Objective Function identifier. As per discussed in [PCE-OF], 581 objective function identifier code points are managed by IANA. 583 Two global objective functions defined in [PCE-OF] are used in the 584 context of GCO. 586 Function 587 Code Description 589 5 Minimize the load of the Most Loaded Link (MLL) 591 6 Minimize Cumulative Cost of a set of paths (MCC) 593 * Note: This can be achieved by the following objective function: 594 minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link 595 capacity for link i and A(i) is the total bandwidth allocated on link 596 i.) 598 5.2. Indication of Global Concurrent Optimization Requests 600 All the path requests in this application should be indicated so that 601 the global objective function and all of the global constraints are 602 applied to each of the requested path computation. This can be 603 indicated implicitly by placing the GCO related objects (GOF, GC or 604 XRO) after the SVEC object. That is, if any of these objects follows 605 the SVEC object in the PCReq message, all of the requested path 606 computations specified in the SVEC object are subject to GOF, GC or 607 XRO. 609 5.3. Request for the order of LSP 611 In order to minimize disruption associated with bulk path 612 provisioning, the PCC may indicate to the PCE that the response MUST 613 be ordered. That is, the PCE has to include the order in which LSPs 614 MUST be moved so as to minimize traffic disruption. To support such 615 indication a new flag, the D flag, is defined in the RP object as 616 follows: 618 D bit (orDer - 1 bit): when set, in a PCReq message, the requesting 619 PCC requires the PCE to specify in the PCRep message the order in 620 which this particular path request is to be provisioned relative to 621 other requests. 623 To support the determination of whether make-before-break 624 optimization is required, a new flag, the M flag, is defined in the 625 RP object as follows. 627 M bit (Make-before-break - 1 bit): when set, this indicates that a 628 make-before-break reoptimization is required for this request. 630 When M bit is not set, this implies that a break-before-make 631 reoptimization is allowed for this request. Note that M bit can be 632 set only if the R (Reoptimization) flag is set. 634 5.4. The Order Response 636 The PCE MUST specify the order number in response to the Order 637 Request made by the PCC in the PCReq message if so requested by the 638 setting of the D bit in the RP object in the PCReq message. To 639 support such ordering indication a new optional TLV, the Order TLV, 640 is defined in the RP object. 642 The Order TLV is an optional TLV in the RP object, that indicates the 643 order in which the old LSP must be removed and the new LSP must be 644 setup during a reoptimization. It is carried in the PCRep message in 645 response to a reoptimization request. 647 The Order TLV SHOULD be included in the RP object in the PCRep 648 message if the D bit is set in the RP object in the PCReq message. 650 The format of the Order TLV is as follows: 652 0 1 2 3 653 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 654 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 655 | Type | Length | 656 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 657 | Delete Order | 658 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 659 | Setup Order | 660 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 662 Figure 2: The Order TLV in the RP object in the PCRep Message 664 Type: To be defined by IANA (suggested value = 5) 666 Length: Variable 668 Delete Order: 32 bit integer that indicates the order in which the 669 old LSP should be removed 671 Setup Order: 32 bit integer that indicates the order in which the new 672 LSP should be setup 674 The delete order should not be equal to the setup order. If the 675 delete order is higher than the setup order, this means that the 676 reoptimization can be done in a make-before-break manner, else it 677 cannot be done in a make-before-break manner. 679 For a new LSP the delete order is not applicable. The value 0 is 680 designated to specify this case. When the value of the delete order 681 is 0, it implies that the resulting LSP is a new LSP. 683 To illustrate, consider a network with two established requests: R1 684 with path P1 and R2 with path P2. During a reoptimization the PCE 685 may provide the following ordered reply: 687 R1, path P1', remove order 1, setup order 4 688 R2, path P2', remove order 3, setup order 2 690 This indicates that the NMS should do the following sequence of 691 tasks: 693 1: Remove path P1 694 2: Setup path P2' 695 3: Remove path P2 696 4: Setup path P1' 698 That is, R1 is reoptimized in a break-before-make manner and R2 in a 699 make-before-break manner. 701 5.5. GLOBAL CONSTRAINTS (GC) Object 703 The Global Constraints (GC) Object is used in a PCReq message to 704 specify the necessary global constraints that should be applied to 705 all individual path computations for a global concurrent path 706 optimization request. 708 GLOBAL CONSTRAINT Object-Class is to be assigned by IANA (recommended 709 value=24) 711 GLOBAL CONSTRAINT Object-Type is to be assigned by IANA (recommended 712 value=1) 714 The format of the GC object body that includes the global constraints 715 is as follows: 717 0 1 2 3 718 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 719 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 720 | Reserved | 721 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 | MH | MU | mU | OB | 723 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 724 | | 725 // Optional TLV(s) // 726 | | 727 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 729 Figure 3: GC body object format 731 MH (Max Hop: 8 bits): 8 bit integer that indicates the maximum hop 732 count for all the LSPs. 734 MU (Max Utilization Percentage: 8 bits) : 8 bits integer that 735 indicates the upper bound utilization percentage by which all link 736 should be bound. Utilization = (Link Capacity - Allocated Bandwidth 737 on the Link)/ Link Capacity 739 mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that 740 indicates the lower bound utilization percentage by which all link 741 should be bound. 743 OB (Over Booking factor Percentage: 8 bits) : 8 bits integer that 744 indicates the overbooking percentage that allows the reserved 745 bandwidth to be overbooked on each link beyond its physical capacity 746 limit. The value, for example, 10% means that 110 Mbps can be 747 reserved on a 100Mbps link. 749 Reserved bits (24 bits) of the GLOBAL CONSTRAINTS Object SHOULD be 750 transmitted as zero and SHOULD be ignored upon receipt. 752 The exclusion of the list of nodes/links from a global path 753 computation can be done by including the XRO object following the GC 754 object in the new SVEC list definition. 756 5.6. Error Indicator 758 To indicate errors associated with the global concurrent path 759 optimization request, a new Error-Type (14) and subsequent error- 760 values are defined as follows for inclusion in the PCEP-ERROR object: 762 A new Error-Type (15) and subsequent error-values are defined as 763 follows: 765 Error-Type=15 and Error-Value=1: if a PCE receives a global 766 concurrent path optimization request and the PCE is not capable of 767 the request due to insufficient memory, the PCE MUST send a PCErr 768 message with a PCEP ERROR object (Error-Type=15) and an Error-Value 769 (Error-Value=1). The corresponding global concurrent path 770 optimization request MUST be cancelled. 772 Error-Type=15; Error-Value=2: if a PCE receives a global concurrent 773 path optimization request and the PCE is not capable of global 774 concurrent optimization, the PCE MUST send a PCErr message with a 775 PCEP-ERROR Object (Error-Type=15) and an Error-Value (Error-Value=2). 776 The corresponding global concurrent path optimization MUST be 777 cancelled. 779 To indicate an error associated with policy violation, a new error 780 value "global concurrent optimization not allowed" should be added to 781 an existing error code for policy violation (Error-Type=5) as defined 782 in [PCEP]. 784 Error-Type=5; Error-Value=5: if a PCE receives a global concurrent 785 path optimization request which is not compliant with administrative 786 privileges (i.e., the PCE policy does not support global concurrent 787 optimization), the PCE sends a PCErr message with a PCEP-ERROR Object 788 (Error-Type=5) and an Error-Value (Error-Value=5). The corresponding 789 global concurrent path computation MUST be cancelled. 791 5.7. NO-PATH Indicator 793 To communicate the reason(s) for not being able to find global 794 concurrent path computation, the NO-PATH object can be used in the 795 PCRep message. The format of the NO-PATH object body is defined in 796 [PCEP]. The object may contain a NO-PATH-VECTOR TLV to provide 797 additional information about why a path computation has failed. 799 Two new bit flags are defined to be carried in the Flags field in the 800 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 802 Bit 6: When set, the PCE indicates that no migration path was found. 804 Bit 7: When set, the PCE indicates no feasible solution was found 805 that meets all the constraints associated with global concurrent path 806 optimization in the PCRep message. 808 6. Manageability Considerations 810 Manageability of Global Concurrent Path Computation with PCE must 811 address the following considerations: 813 6.1. Control of Function and Policy 815 In addition to the parameters already listed in section 8.1 of 816 [PCEP], a PCEP implementation SHOULD allow configuring the following 817 PCEP session parameters on a PCC: 819 o The ability to send a GCO request. 821 In addition to the parameters already listed in section 8.1 of 822 [PCEP], a PCEP implementation SHOULD allow configuring the following 823 PCEP session parameters on a PCE: 825 o The support for Global Concurrent Optimization. 827 o The maximum number of synchronized path requests per request 828 message. 830 o A set of GCO specific policies (authorized sender, request rate 831 limiter, etc). 833 These parameters may be configured as default parameters for any PCEP 834 session the PCEP speaker participates in, or may apply to a specific 835 session with a given PCEP peer or a specific group of sessions with a 836 specific group of PCEP peers. 838 6.2. Information and Data Models, e.g. MIB module 840 Extensions to the PCEP MIB module defined in [PCEP-MIB] should be 841 defined, so as to cover the GCO information introduced in this 842 document. 844 6.3. Liveness Detection and Monitoring 846 Mechanisms defined in this draft does not imply any new liveness 847 detection and monitoring requirements in addition to those already 848 listed in section 8.3 of [PCEP]. 850 6.4. Verifying Correct Operation 852 Mechanisms defined in this draft does not imply any new verification 853 requirements in addition to those already listed in section 8.4 of 854 [PCEP] 856 6.5. Requirements on Other Protocols and Functional Components 858 The PCE Discovery mechanisms ([ISIS PCED] and [OSPF PCED]) may be 859 used to advertise global concurrent path computation capabilities to 860 PCCs. 862 6.6. Impact on Network Operation 864 Mechanisms defined in this draft does not imply any new network 865 operation requirements in addition to those already listed in section 866 8.6 of [PCEP]. 868 7. Security Considerations 870 When global re-optimization is applied to an active network, it could 871 be extremely disruptive. Although the real security and policy 872 issues apply at the NMS, if the wrong results are returned to the 873 NMS, the wrong actions may be taken in the network. Therefore, it is 874 very important that the operator issuing the commands has sufficient 875 authority and is authenticated, and that the computation request is 876 subject to appropriate policy. 878 The mechanism defined in [PCEP] to secure a PCEP session can be used 879 to secure global concurrent path computation requests/responses. 881 8. Acknowledgements 883 We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning 884 So, Lucy Yong and Fabien Verhaeghe for their useful comments and 885 suggestions. 887 9. IANA Considerations 889 IANA maintains a registry of PCEP parameters. IANA is requested to 890 make allocations from the sub-registries as described in the 891 following sections. 893 9.1. Request Parameter Bit Flags 895 As described in Section 5.3, two new bit lfags are defined for 896 inclusion in the Flags field of the RP object. IANA is requested to 897 make the following allocations from the "Request Parameter Bit Flags" 898 sub-registry. 900 Bit Name Description Reference 902 11 D-bit Report the request order [This.I-D] 903 12 M-bit Make-before-break [This.I-D] 905 9.2. New PCEP TLV 907 As described in Section 5.4, a new PCEP TLV is defined to indicate 908 the setup and delete order of LSPs in a GCO. IANA is requested to 909 make the following allocation from the "PCEP TLV Types" sub-registry. 911 TLV Type Meaning Reference 913 5 Order TLV [This.I-D] 915 9.3. New PCEP Object 917 As descried in Section 5.5, a new PCEP object is defined to carry 918 global constraints. IANA is requested to make the following 919 allocation from the "PCEP Objects" sub-registry. 921 Object Name Reference 922 Class 924 24 GLOBAL-CONSTRAINTS [This.I-D] 925 Object-Type 926 1: Global Constraints [This.I-D] 928 9.4. New PCEP Error Codes 930 As described in Section 5.6, new PCEP error codes are defined for GCO 931 errors. IANA is requested to make allocations from the "PCEP Error 932 Types and Values" sub-registry as set out in the following sections. 934 9.4.1. New Error-Values for Existing Error-Types 936 Error 937 Type Meaning Reference 939 5 Policy violation 940 Error-value=5: [This.I-D] 941 Global concurrent optimization not allowed 943 9.4.2. New Error-Types and Error-Values 945 Error 946 Type Meaning Reference 948 15 Global Concurrent Optimization Error [This.I-D] 949 Error-value=1: 950 Insufficient memory [This.I-D] 951 Error-value=2: 952 Global concurrent optimization not supported 953 [This.I-D] 955 9.5. New No-Path Reasons 957 IANA is requested to make the following allocations from the "No-Path 958 Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV 959 in the PCEP NO-PATH object as described in Section 5.7. 961 Bit 962 Number Name Reference 964 6 No GCO migration path found [This.I-D] 965 7 No GCO solution found [This.I-D] 967 10. References 969 10.1. Normative References 971 [BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based 972 Computation (BRPC) procedure to compute shortest inter- 973 domain Traffic Engineering Label Switched Paths, 974 draft-ietf-pce-brpc-05.txt, work in progress". 976 [PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 977 Function encoding in Path Computation Element 978 communication and discovery protocols, 979 draft-leroux-pce-of, work in progress". 981 [PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation 982 Element Communication Protocol (PCEP) for Route 983 Exclusions, draft-ietf-pce-pcep-xro-00.txt, work in 984 progress". 986 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 987 Element (PCE) communication Protocol (PCEP) - Version 1, 988 draft-ietf-pce-pcep, work in progress". 990 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 991 Requirement Levels", BCP 14, RFC 2119, March 1997. 993 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 994 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 995 Tunnels", RFC 3209, December 2001. 997 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 998 Element (PCE)-Based Architecture, RFC 4655, August 2006". 1000 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 1001 Communication Protocol Generic Requirements, RFC 4657, 1002 September 2006". 1004 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 1005 (PCE) Discovery, RFC 4674, October 2006.". 1007 10.2. Informative References 1009 [ISIS-PCED] 1010 Le Roux, J. and JP. Vasseur, "IS-IS protocol extensions 1011 for Path Computation Element (PCE) Discovery, 1012 draft-ietf-pce-disco-proto-isis, work in progress.". 1014 [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- 1015 region and multi-layer networks (MRN/MLN), 1016 draft-ietf-ccamp-gmpls-mln-reqs, work in progress". 1018 [OSPF-PCED] 1019 Le Roux, J. and JP. Vasseur, "OSPF protocol extensions for 1020 Path Computation Element (PCE) Discovery, 1021 draft-ietf-pce-disco-proto-ospf, work in progress.". 1023 [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- 1024 based inter-layer MPLS and GMPL traffic engineering, 1025 draft-ietf-pce-inter-layer-frwk, work in progress.". 1027 [PCEP-MIB] 1028 Stephen, E. and K. Koushik, "PCE communication 1029 protocol(PCEP) Management Information Base, 1030 draft-kkoushik-pce-pcep-mib, work in progress.". 1032 Authors' Addresses 1034 Young Lee 1035 Huawei 1036 1700 Alma Drive, Suite 100 1037 Plano, TX 75075 1038 US 1040 Phone: +1 972 509 5599 x2240 1041 Fax: +1 469 229 5397 1042 Email: ylee@huawei.com 1044 JL Le Roux 1045 France Telecom 1046 2, Avenue Pierre-Marzin 1047 Lannion 22307 1048 FRANCE 1050 Email: jeanlouis.leroux@orange-ftgroup.com 1052 Daniel King 1053 Aria Networks 1054 44/45 Market Place 1055 Chippenham SN15 3HU 1056 United Kingdom 1058 Phone: +44 7790 775187 1059 Fax: +44 1249 446530 1060 Email: daniel.king@aria-networks.com 1062 Eiji Oki 1063 NTT 1064 Midori 3-9-11 1065 Musashino, Tokyo 180-8585 1066 JAPAN 1068 Email: oki.eiji@lab.ntt.co.jp 1070 Full Copyright Statement 1072 Copyright (C) The IETF Trust (2008). 1074 This document is subject to the rights, licenses and restrictions 1075 contained in BCP 78, and except as set forth therein, the authors 1076 retain all their rights. 1078 This document and the information contained herein are provided on an 1079 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1080 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1081 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1082 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1083 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1084 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1086 Intellectual Property 1088 The IETF takes no position regarding the validity or scope of any 1089 Intellectual Property Rights or other rights that might be claimed to 1090 pertain to the implementation or use of the technology described in 1091 this document or the extent to which any license under such rights 1092 might or might not be available; nor does it represent that it has 1093 made any independent effort to identify any such rights. Information 1094 on the procedures with respect to rights in RFC documents can be 1095 found in BCP 78 and BCP 79. 1097 Copies of IPR disclosures made to the IETF Secretariat and any 1098 assurances of licenses to be made available, or the result of an 1099 attempt made to obtain a general license or permission for the use of 1100 such proprietary rights by implementers or users of this 1101 specification can be obtained from the IETF on-line IPR repository at 1102 http://www.ietf.org/ipr. 1104 The IETF invites any interested party to bring to its attention any 1105 copyrights, patents or patent applications, or other proprietary 1106 rights that may cover technology that may be required to implement 1107 this standard. Please address the information to the IETF at 1108 ietf-ipr@ietf.org.