idnits 2.17.1 draft-ietf-pce-global-concurrent-optimization-01.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 1057. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1068. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1075. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1081. 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 (November 2, 2007) is 6019 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 907, but not defined == Missing Reference: 'OSPF PCED' is mentioned on line 907, but not defined == Unused Reference: 'ISIS-PCED' is defined on line 982, but no explicit reference was found in the text == Unused Reference: 'OSPF-PCED' is defined on line 991, but no explicit reference was found in the text == Unused Reference: 'PCE-MLN' is defined on line 996, but no explicit reference was found in the text == Outdated reference: A later version (-09) exists of draft-ietf-pce-brpc-05 -- Possible downref: Normative reference to a draft: ref. 'PCE-OF' == Outdated reference: A later version (-06) exists of draft-ietf-pce-pcep-xro-00 ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4657 ** Downref: Normative reference to an Informational RFC: RFC 4674 Summary: 4 errors (**), 0 flaws (~~), 8 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Lee 3 Internet-Draft Huawei 4 Intended status: Standards Track JL. Le Roux 5 Expires: May 5, 2008 France Telecom 6 D. King 7 Aria Networks 8 E. Oki 9 NTT 10 November 2, 2007 12 Path Computation Element Communication Protocol (PCECP) Requirements and 13 Protocol Extensions In Support of Global Concurrent Optimization 14 draft-ietf-pce-global-concurrent-optimization-01.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 May 5, 2008. 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 or a PCE Server based solution. Due to complex synchronization 181 issues associated with GCO application, the management based PCE 182 architecture defined in section 5.5 of [RFC4655] is considered as the 183 most suitable usage to support GCO application. This does not 184 automatically preclude other architectural alternatives to support 185 GCO application, but they are not recommended. For instance, GCO may 186 be enabled by distributed LSRs through complex synchronization. 187 However, this approach may suffer from significant synchronization 188 overhead between the PCE and each of the PCCs. It would likely 189 affect the network stability and hence significantly diminish the 190 benefits of deploying PCEs. 192 As new LSPs are added sequentially or removed from the network over 193 time, the global network resources become fragmented and the network 194 no longer provides the optimal use of the available capacity. A 195 global concurrent path computation is able to simultaneously consider 196 the entire topology of the network and the complete set of existing 197 LSPs, and their respective constraints, and look to re-optimize the 198 entire network to satisfy all constraints for all LSPs. 200 Alternatively, the application may consider a subset of the LSPs 201 and/or a subset of the network topology. 203 The need for a global concurrent path computation may also arise when 204 network operators need to establish a set of TE LSPs in their network 205 planning process. It is also envisioned that network operators might 206 require a global concurrent path computation in the event of 207 catastrophic network failures, where a set of TE LSPs need to be 208 optimally rerouted. The nature of this work does promote such 209 systems for offline processing. Online application of this work 210 should only be considered with proven empirical validation. 212 As the PCE is envisioned to provide solutions in all path computation 213 matters, it is anticipated that the PCE would provide solutions for 214 global concurrent path computation needs. 216 The main focus of this document is to highlight the PCC-PCE 217 communication needs in support of a concurrent path computation 218 application and to define protocol extensions to meet those needs. 220 The PCC-PCE requirements addressed herein are specific to the context 221 where the PCE is a specialized PCE that is capable of solving global 222 concurrent path computation applications. Discovery of such 223 capabilities might be desirable and could be achieved through 224 extensions to the PCE discovery mechanisms [RFC4674], but that is out 225 of the scope of this document. 227 It is to be noted that BRPC [BRPC] is a multi-PCE path computation 228 technique used to compute a shortest constrained inter-domain path 229 wheres this ID specifies a technique where a set of path computation 230 requests are bundled and send to a PCE with the objective of 231 "optimizing" the set of computed paths. 233 3. Applicability of Global Concurrent Optimization (GCO) 235 This section discusses the PCE architecture to which GCO is applied. 236 It also discusses various application scenarios for which global 237 concurrent path computation may be applied. 239 3.1. Application of the PCE Architecture 241 Figure 1 shows the PCE-based network architecture as defined in 242 [RFC4655] to which GCO application is applied. It must be observed 243 that the PCC is not necessarily an LSR [RFC4655]. The GCO 244 application is primarily an NMS-based solution in which an NMS plays 245 the function of the PCC. Although Figure 1 shows the PCE as remote 246 from the NMS, it might be collocated with the NMS. Note that in the 247 collocated case there is no need for a standard communication 248 protocol, this can rely on internal APIs. 250 ----------- 251 Application | ----- | 252 Request | | TED | | 253 | | ----- | 254 v | | | 255 ------------- Request/ | v | 256 | PCC | Response| ----- | 257 | (NMS/Server)|<--------+> | PCE | | 258 | | | ----- | 259 ------------- ----------- 260 Service | 261 Request | 262 v 263 ---------- Signaling ---------- 264 | Head-End | Protocol | Adjacent | 265 | Node |<---------->| Node | 266 ---------- ---------- 268 Figure 1: PCE-Based Architecture for Global Concurrent Optimization 270 Upon receipt of an application request (e.g., a traffic demand matrix 271 is provided to the NMS by the operator's network planning procedure), 272 the NMS requests a global concurrent path computation from the PCE. 273 The PCE then computes the requested paths concurrently applying some 274 algorithms. When the requested path computation completes, the PCE 275 sends the resulting paths back to the NMS. The NMS then supplies the 276 head-end LSRs with a fully computed explicit path for each TE LSP 277 that needs to be established. 279 3.2. Re-optimization of Existing Networks 281 The need for global concurrent path computation may arise in existing 282 networks. When an existing TE LSP network experiences sub-optimal 283 use of its resources, the need for re-optimization or reconfiguration 284 may arise. The scope of re-optimization and reconfiguration may vary 285 depending on particular situations. The scope of re-optimization may 286 be limited to bandwidth modification to an existing TE LSP. However, 287 it could well be that a set of TE LSPs may need to be re-optimized 288 concurrently. In an extreme case, the TE LSPs may need to be 289 globally re-optimized. 291 In loaded networks, with large size LSPs, a sequential re- 292 optimization may not produce substantial improvements in terms of 293 overall network optimization. The potential for network-wide gains 294 from reoptimization of LSPs sequentially is dependent upon the 295 network usage and size of the LSPs being optimized. However, the key 296 point remains: computing the reoptimized path of one LSP at a time 297 with giving no consideration to the other LSPs in the network could 298 result in sub-optimal use of network resources. This may be far more 299 visible in an optical network with a low ratio of potential LSPs per 300 link, and far less visible in packet networks with micro-flow LSPs. 302 With regards to applicability of GCO in the event of catastrophic 303 failures, there may be a real benefit in computing the paths of the 304 LSPs as a set rather than computing new paths from the head-end LSRs 305 in a distributed manner. It is to be noted, however, that a 306 centralized system will typically suffer from a slower response time 307 than a distributed system. 309 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) 311 Reconfiguration of the VNT [MLN-REQ] is a typical application 312 scenario where global concurrent path computation may be applicable. 313 Triggers for VNT reconfiguration, such as traffic demand changes, 314 network failures, and topological configuration changes, may require 315 a set of existing LSPs to be re-computed. 317 3.2.2. Traffic Migration 319 When migrating from one set of TE LSPs to a reoptimized set of TE 320 LSPs it is important that the traffic be moved without causing 321 disruption. Various techniques exist in MPLS and GMPLS, such as 322 make-before-break [RFC3209], to establish the new LSPs before tearing 323 down the old LSPs. When multiple LSP routes are changed according to 324 the computed results, some of the LSPs may be disrupted due to the 325 resource constraints. In other words, it may prove to be impossible 326 to perform a direct migration from the old LSPs to the new optimal 327 LSPs without disrupting traffic because there are insufficient 328 network resources to support both sets of LSPs when make-before-break 329 is used. However, the PCE may be able to determine an order of LSP 330 rerouting actions so that make-before-break can be performed within 331 the limited resources. 333 It may be the case that the reoptimization is radical. This could 334 mean that it is not possible to apply make-before-break in any order 335 to migrate from the old LSPs to the new LSPs. In this case a 336 migration strategy is required that may necessitate LSPs being 337 rerouted using make-before-break onto temporary paths in order to 338 make space for the full reoptimization. A PCE might indicate the 339 order in which reoptimized LSPs must be established and take over 340 from the old LSPs, and may indicate a series of different temporary 341 paths that must be used. Alternatively, the PCE might perform the 342 global reoptimization as a series of sub-reoptimizations by 343 reoptimizing subsets of the total set of LSPs. 345 The benefit of this multi-step rerouting includes minimization of 346 traffic discruption and optimization gain. However this approach may 347 imply some transient packets desequencing, jitter as well as control 348 plane stress. 350 Note also that during reoptimization, traffic disruption may be 351 allowed for some LSPs carrying low priority services (e.g., Internet 352 traffic) and not allowed for some LSPs carrying mission critical 353 services (e.g., voice traffic). 355 3.3. Greenfield Optimization 357 Greenfield optimization is a special case of GCO application when 358 there is no LSP setup. Once the LSPs are setup, it is not a 359 greenfield. The need for greenfield arises when network planner will 360 want to make use of computation servers to plan the LSPs that will be 361 provisioned in the network. 363 When a new TE network needs to be provisioned from a green-field 364 perspective, a set of TE LSPs need to be created based on traffic 365 demand, network topology, service constraints, and network resources. 366 Under this scenario, concurrent computation ability is highly 367 desirable, or required, to utilize network resources in an optimal 368 manner and avoid blocking risks. 370 3.3.1. Single-layer Traffic Engineering 372 Greenfield optimization can be applied when layer-specific TE LSPs 373 need to be created from a green-field perspective. For example, 374 MPLS-TE network can be established based on layer 3 specific traffic 375 demand, network topology, and network resources. Greenfield 376 optimization for single-layer traffic engineering can be applied to 377 optical transport networks such as SDH/Sonet, Ethernet Transport, 378 WDM, etc. 380 3.3.2. Multi-layer Traffic Engineering 382 Greenfield optimization is not limited to single-layer traffic 383 engineering. It can also be applied to multi-layer traffic 384 engineering. Both the client and the server layers network resources 385 and topology can be considered simultaneously in setting up a set of 386 TE LSPs that traverse the layer boundary. 388 4. PCECP Requirements 390 This section provides the PCECP requirements to support global 391 concurrent path computation applications. The requirements specified 392 here should be regarded as application-specific requirements and are 393 justifiable based on the extensibility clause found in section 6.1.14 394 of [RFC4657]: 396 The PCECP MUST support the requirements specified in the 397 application-specific requirements documents. The PCECP MUST also 398 allow extensions as more PCE applications will be introduced in 399 the future. 401 It is also to be noted that some of the requirements discussed in 402 this section have already been discussed in the PCECP requirement 403 document [RFC4657]. For example, Section 5.1.16 in [RFC4657] 404 provides a list of generic constraints while Section 5.1.17 in 405 [RFC4657] provides a list of generic objective functions that MUST be 406 supported by the PCECP. While using such generic requirements as the 407 baseline, this section provides application-specific requirements in 408 the context of global concurrent path computation and in a more 409 detailed level than the generic requirements. 411 The PCEP SHOULD support the following capabilities either via 412 creation of new objects and/or modification of existing objects where 413 applicable. 415 o An indicator to convey that the request is for a global concurrent 416 path computation. This indicator is necessary to ensure 417 consistency in applying global objectives and global constraints 418 in all path computations. Note: This requirement is covered by 419 "synchronized path computation" in [RFC4655] and [RFC4657]. 420 However, an explicit indicator to request a global concurrent 421 optimization is a new requirement. 423 o A Global Objective Function (GOF) field in which to specify the 424 global objective function. The global objective function is the 425 overarching objective function to which all individual path 426 computation requests are subjected in order to find a globally 427 optimal solution. Note that this requirement is covered by 428 "synchronized objective functions" in section 5.1.7 [RFC4657]. A 429 list of available global objective functions SHOULD include the 430 following objective functions at the minimum and SHOULD be 431 expandable for future addition: 433 * Minimize the sum of all TE LSP costs (min cost) 434 * Evenly allocate the network load to achieve the most uniform 435 link utilization across all links (this can be achieved by the 436 following objective function: minimize max over all links 437 {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i 438 and A(i) is the total bandwidth allocated on link i. 440 o A Global Constraints (GC) field in which to specify the list of 441 global constraints to which all the requested path computations 442 should be subjected. This list SHOULD include the following 443 constraints at the minimum and SHOULD be expandable for future 444 addition: 446 * Maximum link utilization value -- This value indicates the 447 highest possible link utilization percentage set for each link. 448 (Note: to avoid floating point numbers, the values should be 449 integer values.) 451 * Minimum link utilization value -- This value indicates the 452 lowest possible link utilization percentage set for each link. 453 (Note: same as above) 455 * Overbooking Factor -- The overbooking factor allows the 456 reserved bandwidth to be overbooked on each link beyond its 457 physical capacity limit. 459 * Maximum number of hops for all the LSPs -- This is the largest 460 number of hops that any LSP can have. Note that this 461 constraint can also be provided on a per LSP basis (as 462 requested in [RFC4657] and defined in [PCEP]). 464 * Exclusion of links/nodes in all LSP path computation (i.e., all 465 LSPs should not include the specified links/nodes in their 466 paths). Note that this constraint can also be provided on a 467 per LSP basis (as requested in [RFC4657] and defined in 468 [PCEP]). 470 * An indication should be available in a path computation 471 response that further reoptimization may only become available 472 once existing traffic has been moved to the new LSPs. 474 o A Global Concurrent Vector (GCV) field in which to specify all the 475 individual path computation requests that are subject to 476 concurrent path computation and subject to the global objective 477 function and all of the global constraints. Note that this 478 requirement is entirely fulfilled by the SVEC object in the PCEP 479 specification [PCEP]. Since the SVEC object as defined in [PCEP] 480 allows identifying a set of concurrent path requests, the SVEC can 481 be reused to specify all the individual concurrent path requests 482 for a global concurrent optimization. 484 o An indicator field in which to indicate the outcome of the 485 request. When the PCE could not find a feasible solution with the 486 initial request, the reason for failure SHOULD be indicated. This 487 requirement is partially covered by [RFC4657], but not in this 488 level of detail. The following indicators SHOULD be supported at 489 the minimum: 491 * no feasible solution found. Note that this is already covered 492 in [PCEP]. 494 * memory overflow 496 * PCE too busy. Note that this is already covered in [PCEP]. 498 * PCE not capable of concurrent reoptimization 500 * no migration path available 502 * administrative privileges do not allow global reoptimization 504 o In order to minimize disruption associated with bulk path 505 provisioning, the following requirements MUST be supported: 507 * The request message MUST allow requesting the PCE to provide 508 the order in which LSPs should be reoptimized (i.e., the 509 migration path) in order to minimize traffic disruption during 510 the migration. That is the request message MUST allow 511 indicating to the PCE that the set of paths that will be 512 provided in the response message (PCRep) has to be ordered. 514 * In response to the "ordering" request from the PCC, the PCE 515 MUST be able to indicate in the response message (PCRep) the 516 order in which LSPs should be reoptimized so as to minimize 517 traffic disruption. It should indicate for each request the 518 order in which the old LSP should be removed and the order in 519 which the new LSP should be setup. If the removal order is 520 lower than the setup order this means that make-before-break 521 cannot be done for this request. It might also be desirable to 522 have the PCE indicate whether ordering is in fact required or 523 not. 525 * As stated in RFC 4657, the request for a reoptimization MUST 526 support the inclusion of the set of previously computed paths 527 along with their bandwidth. This is to avoid double bandwidth 528 accounting and also this allows running an algorithm that 529 minimizes perturbation and that can compute a migration path 530 (LSP setup/removal orders). This is particularly required for 531 stateless PCEs. 533 * During a migration it may not be possible to do a make-before- 534 break for all existing LSPs. The request message must allow 535 indicating for each request whether make-before-break is 536 required (e.g. Voice traffic) or break-before-make is 537 acceptable (e.g. Internet traffic). The response message must 538 allow indicating LSPs for which make-before-break 539 reoptimization is not possible (this will be deduced from the 540 LSP setup and deletion orders). 542 5. Protocol extensions for support of global concurrent optimization 544 This section provides protocol extensions for support of global 545 concurrent optimization. Protocol extensions discussed in this 546 section are built on [PCEP]. 548 The format of a PCReq message is currently as follows per [PCEP]: 550 ::= 551 [] 552 554 where: 555 ::= [] 556 ::= [] 557 ::= 558 [] 559 [] 560 [] 561 [] 562 [] 563 [] 564 [] 566 The format of a PCReq message after incorporating new requirements 567 for support of global concurrent optimization is as follows: 569 ::= 570 [] 571 573 The is changed as follows: 575 :: = 576 [] 577 [] 578 [] 579 [] 581 Note that three optional objects are added, following the SVEC 582 object: the OF (Objective Function) object, which is defined in 583 [PCE-OF], the GC (Global Constraints) object, which is defined in 584 this document (section 5.5), as well as the eXclude Route Object 585 (XRO) which is defined in [PCE-XRO]. Details of this change will be 586 discussed in the following sections 588 5.1. Global Objective Function (GOF) Specification 590 The global objective function can be specified in the PCEP Objective 591 Function (OF) object, defined in [PCE-OF]. The OF object includes a 592 16 bit Objective Function identifier. As per discussed in [PCE-OF], 593 objective function identifier code points are managed by IANA. 595 Two global objective functions are defined in this document and their 596 identifier should be assigned by IANA (suggested value) 598 Function 599 Code Description 601 1 Minimize the sum of all TE LSP costs (min cost) 603 2 Evenly allocate the network load to achieve the 604 most uniform link utilization across all links* 606 * Note: This can be achieved by the following objective function: 607 minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link 608 capacity for link i and A(i) is the total bandwidth allocated on link 609 i.) 611 5.2. Indication of Global Concurrent Optimization Requests 613 All the path requests in this application should be indicated so that 614 the global objective function and all of the global constraints are 615 applied to each of the requested path computation. In order to 616 support this requirement, a new flag is defined in the SVEC object: 618 C flag (1 bit): This is a new flag in the SVEC object. When C flag 619 is set, this indicates that all of the path requests listed in the 620 body of the SVEC object should be computed applying the global 621 constraints and the global objective function. 623 When the C Flag is set in the SVEC Object, the OF and the GC objects, 624 if included, should directly follow the SVEC Object. 626 5.3. Request for the order of LSP 628 In order to minimize disruption associated with bulk path 629 provisioning, the PCC may indicate to the PCE that the response MUST 630 be ordered. That is, the PCE has to include the order in which LSPs 631 MUST be moved so as to minimize traffic disruption. To support such 632 indication a new flag, the D flag, is defined in the RP object as 633 follows: 635 0 1 2 3 636 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 637 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 638 | Reserved | Flags |D|M|F|O|B|R| Pri | 639 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 640 | Request-ID-number | 641 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 642 | | 643 // Optional TLV(s) // 644 | | 645 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 647 Figure 5: RP object body format in the PCReq Message 649 D bit (orDer - 1 bit): when set, in a PCReq message, the requesting 650 PCC requires the PCE to specify in the PCRep message the order in 651 which this particular path request is to be provisioned relative to 652 other requests. 654 M bit (Make-before-break - 1 bit): when set, this indicates that a 655 make-before-break reoptimization is required for this request. 657 When M bit is not set, this implies that a break-before-make 658 reoptimization is allowed for this request. Note that M bit can be 659 set only if the R (Reoptimization) flag is set. 661 5.4. The Order Response 663 The PCE MUST specify the order number in response to the Order 664 Request made by the PCC in the PCReq message if so requested by the 665 setting of the D bit in the RP object in the PCReq message. To 666 support such ordering indication a new optional TLV is defined in the 667 RP object, the Order TLV, as follows: 669 0 1 2 3 670 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 671 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 672 | Reserved | Flags |D|M|F|O|B|R| Pri | 673 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 674 | Request-ID-number | 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | | 677 // Order TLV (Optional TLV) // 678 | | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 Figure 6: RP object body format in the PCRep Message 683 The Order TLV is an optional TLV in the RP object, that indicates the 684 order in which the old LSP must be removed and the new LSP must be 685 setup during a reoptimization. It is carried in the PCRep message in 686 response to a reoptimization request. 688 The Order TLV SHOULD be included in the RP object in the PCRep 689 message if the D bit is set in the RP object in the PCReq message. 691 The format of the Order TLV is as follows: 693 0 1 2 3 694 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 695 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 696 | Type | Length | | 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Delete Order | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Setup Order | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 703 Type To be defined by IANA (suggested value = ) 704 Length Variable 705 Value Orders in which the old path should be removed 706 and the new path should be setup 708 Figure 7: The Order TLV in the RP object in the PCRep Message 710 Delete Order: 32 bit integer that indicates the order in which the 711 old LSP should be removed 712 Setup Order: 32 bit integer that indicates the order in which the new 713 LSP should be setup 715 The delete order should not be equal to the setup order. If the 716 delete order is higher than the setup order, this means that the 717 reoptimization can be done in a make-before-break manner, else it 718 cannot be done in a make-before-break manner. 720 To illustrate, consider a network with two established requests: R1 721 with path P1 and R2 with path P2. During a reoptimization the PCE 722 may provide the following ordered reply: 724 R1, path P1', remove order 1, setup order 4 725 R2, path P2', remove order 3, setup order 2 727 This indicates that the NMS should do the following sequence of 728 tasks: 730 1: Remove path P1 731 2: Setup path P2' 732 3: Remove path P2 733 4: Setup path P1' 735 That is, R1 is reoptimized in a break-before-make manner and R2 in a 736 make-before-break manner. 738 5.5. GLOBAL CONSTRAINTS (GC) Object 740 The Global Constraints (GC) Object is used in a PCReq message to 741 specify the necessary global constraints that should be applied to 742 all individual path computations for a global concurrent path 743 optimization request. 745 GLOBAL CONSTRAINT Object-Class is to be assigned by IANA (recommended 746 value=21) 748 GLOBAL CONSTRAINT Object-Type is to be assigned by IANA (recommended 749 value=1) 751 The format of the GC object body that includes the global constraints 752 is as follows: 754 0 1 2 3 755 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 756 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 757 | Reserved | 758 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 759 | MH | MU | mU | OB | 760 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 761 | | 762 // Optional TLV(s) // 763 | | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 766 Figure 10: GC body object format 768 MH (Max Hop: 8 bits): 8 bit integer that indicates the maximum hop 769 count for all the LSPs. 771 MU (Max Utilization Percentage: 8 bits) : 8 bits integer that 772 indicates the upper bound utilization percentage by which all link 773 should be bound. Utilization = (Link Capacity - Allocated Bandwidth 774 on the Link)/ Link Capacity 776 mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that 777 indicates the lower bound utilization percentage by which all link 778 should be bound. 780 OB (Over Booking factor Percentage: 8 bits) : 8 bits integer that 781 indicates the overbooking percentage that allows the reserved 782 bandwidth to be overbooked on each link beyond its physical capacity 783 limit. The value, for example, 10% means that 110 Mbps can be 784 reserved on a 100Mbps link. 786 Reserved bits (24 bits) of the GLOBAL CONSTRAINTS Object SHOULD be 787 transmitted as zero and SHOULD be ignored upon receipt. 789 The exclusion of the list of nodes/links from a global path 790 computation can be done by including the XRO object following the GC 791 object in the new SVEC list definition. 793 5.6. Error Indicator 795 To indicate errors associated with the global concurrent path 796 optimization request, a new Error-Type (14) and subsequent error- 797 values are defined as follows for inclusion in the PCEP-ERROR object: 799 A new Error-Type (14) and subsequent error-values are defined as 800 follows: 802 Error-Type=14 and Error-Value=1: if a PCE receives a global 803 concurrent path optimization request and the PCE is not capable of 804 the request due to insufficient memory, the PCE MUST send a PCErr 805 message with a PCEP ERROR object (Error-Type=14) and an Error-Value 806 (Error-Value=1). The corresponding global concurrent path 807 optimization request MUST be cancelled. 809 Error-Type=14; Error-Value=2: if a PCE receives a global concurrent 810 path optimization request and the PCE is not capable of global 811 concurrent optimization, the PCE MUST send a PCErr message with a 812 PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=2). 813 The corresponding global concurrent path optimization MUST be 814 cancelled. 816 To indicate an error associated with policy violation, a new error 817 value "global concurrent optimization not allowed" should be added to 818 an existing error code for policy violation (Error-Type=5) as defined 819 in [PCEP]. 821 Error-Type=5; Error-Value=3: if a PCE receives a global concurrent 822 path optimization request which is not compliant with administrative 823 privileges (i.e., the PCE policy does not support global concurrent 824 optimization), the PCE sends a PCErr message with a PCEP-ERROR Object 825 (Error-Type=5) and an Error-Value (Error-Value=3). The corresponding 826 global concurrent path computation MUST be cancelled. 828 5.7. NO-PATH Indicator 830 To communicate the reason(s) for not being able to find global 831 concurrent path computation, the NO-PATH object can be used in the 832 PCRep message. The format of the NO-PATH object body is as follows: 834 0 1 2 3 835 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 836 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 837 |C| Flags | Reserved | 838 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 839 | | 840 // Optional TLV(s) // 841 | | 842 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 844 Figure 11: NO-PATH object format 846 Flags (16 bits). The C flag is defined in [PCEP]. 848 Two new bit flags are defined in the NO-PATH-VECTOR TLV carried in 849 the NO-PATH Object: 851 0x08: when set, the PCE indicates that no migration path was found. 853 0x10: when set, the PCE indicates no feasible solution was found that 854 meets all the constraints associated with global concurrent path 855 optimization in the PCRep message. 857 6. Manageability Considerations 859 Manageability of Global Concurrent Path Computation with PCE must 860 address the following considerations: 862 6.1. Control of Function and Policy 864 In addition to the parameters already listed in section 8.1 of 865 [PCEP], a PCEP implementation SHOULD allow configuring the following 866 PCEP session parameters on a PCC: 868 o The ability to send a GCO request. 870 In addition to the parameters already listed in section 8.1 of 871 [PCEP], a PCEP implementation SHOULD allow configuring the following 872 PCEP session parameters on a PCE: 874 o The support for Global Concurrent Optimization. 876 o The maximum number of synchronized path requests per request 877 message. 879 o A set of GCO specific policies (authorized sender, request rate 880 limiter, etc). 882 These parameters may be configured as default parameters for any PCEP 883 session the PCEP speaker participates in, or may apply to a specific 884 session with a given PCEP peer or a specific group of sessions with a 885 specific group of PCEP peers. 887 6.2. Information and Data Models, e.g. MIB module 889 Extensions to the PCEP MIB module defined in [PCEP-MIB] should be 890 defined, so as to cover the GCO information introduced in this 891 document. 893 6.3. Liveness Detection and Monitoring 895 Mechanisms defined in this draft does not imply any new liveness 896 detection and monitoring requirements in addition to those already 897 listed in section 8.3 of [PCEP]. 899 6.4. Verifying Correct Operation 901 Mechanisms defined in this draft does not imply any new verification 902 requirements in addition to those already listed in section 8.4 of 903 [PCEP] 905 6.5. Requirements on Other Protocols and Functional Components 907 The PCE Discovery mechanisms ([ISIS PCED] and [OSPF PCED]) may be 908 used to advertise global concurrent path computation capabilities to 909 PCCs. 911 6.6. Impact on Network Operation 913 Mechanisms defined in this draft does not imply any new network 914 operation requirements in addition to those already listed in section 915 8.6 of [PCEP]. 917 7. Security Considerations 919 When global re-optimization is applied to an active network, it could 920 be extremely disruptive. Although the real security and policy 921 issues apply at the NMS, if the wrong results are returned to the 922 NMS, the wrong actions may be taken in the network. Therefore, it is 923 very important that the operator issuing the commands has sufficient 924 authority and is authenticated, and that the computation request is 925 subject to appropriate policy. 927 The mechanism defined in [PCEP] to secure a PCEP session can be used 928 to secure global concurrent path computation requests/responses. 930 8. Acknowledgements 932 We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning So 933 and Lucy Yong for their useful comments and suggestions. 935 9. IANA Considerations 937 A future revision of this document will present requests to IANA for 938 codepoint allocation. 940 10. References 942 10.1. Normative References 944 [BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based 945 Computation (BRPC) procedure to compute shortest inter- 946 domain Traffic Engineering Label Switched Paths, 947 draft-ietf-pce-brpc-05.txt, work in progress". 949 [PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 950 Function encoding in Path Computation Element 951 communication and discovery protocols, 952 draft-leroux-pce-of, work in progress". 954 [PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation 955 Element Communication Protocol (PCEP) for Route 956 Exclusions, draft-ietf-pce-pcep-xro-00.txt, work in 957 progress". 959 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 960 Element (PCE) communication Protocol (PCEP) - Version 1, 961 draft-ietf-pce-pcep, work in progress". 963 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 964 Requirement Levels", BCP 14, RFC 2119, March 1997. 966 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 967 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 968 Tunnels", RFC 3209, December 2001. 970 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 971 Element (PCE)-Based Architecture, RFC 4655, August 2006". 973 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 974 Communication Protocol Generic Requirements, RFC 4657, 975 September 2006". 977 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 978 (PCE) Discovery, RFC 4674, October 2006.". 980 10.2. Informative References 982 [ISIS-PCED] 983 Le Roux, J. and JP. Vasseur, "IS-IS protocol extensions 984 for Path Computation Element (PCE) Discovery, 985 draft-ietf-pce-disco-proto-isis, work in progress.". 987 [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- 988 region and multi-layer networks (MRN/MLN), 989 draft-ietf-ccamp-gmpls-mln-reqs, work in progress". 991 [OSPF-PCED] 992 Le Roux, J. and JP. Vasseur, "OSPF protocol extensions for 993 Path Computation Element (PCE) Discovery, 994 draft-ietf-pce-disco-proto-ospf, work in progress.". 996 [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- 997 based inter-layer MPLS and GMPL traffic engineering, 998 draft-ietf-pce-inter-layer-frwk, work in progress.". 1000 [PCEP-MIB] 1001 Stephen, E. and K. Koushik, "PCE communication 1002 protocol(PCEP) Management Information Base, 1003 draft-kkoushik-pce-pcep-mib, work in progress.". 1005 Authors' Addresses 1007 Young Lee 1008 Huawei 1009 1700 Alma Drive, Suite 100 1010 Plano, TX 75075 1011 US 1013 Phone: +1 972 509 5599 x2240 1014 Fax: +1 469 229 5397 1015 Email: ylee@huawei.com 1017 JL Le Roux 1018 France Telecom 1019 2, Avenue Pierre-Marzin 1020 Lannion 22307 1021 FRANCE 1023 Email: jeanlouis.leroux@orange-ftgroup.com 1025 Daniel King 1026 Aria Networks 1027 44/45 Market Place 1028 Chippenham SN15 3HU 1029 United Kingdom 1031 Phone: +44 7790 775187 1032 Fax: +44 1249 446530 1033 Email: daniel.king@aria-networks.com 1035 Eiji Oki 1036 NTT 1037 Midori 3-9-11 1038 Musashino, Tokyo 180-8585 1039 JAPAN 1041 Email: oki.eiji@lab.ntt.co.jp 1043 Full Copyright Statement 1045 Copyright (C) The IETF Trust (2007). 1047 This document is subject to the rights, licenses and restrictions 1048 contained in BCP 78, and except as set forth therein, the authors 1049 retain all their rights. 1051 This document and the information contained herein are provided on an 1052 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1053 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1054 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1055 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1056 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1057 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1059 Intellectual Property 1061 The IETF takes no position regarding the validity or scope of any 1062 Intellectual Property Rights or other rights that might be claimed to 1063 pertain to the implementation or use of the technology described in 1064 this document or the extent to which any license under such rights 1065 might or might not be available; nor does it represent that it has 1066 made any independent effort to identify any such rights. Information 1067 on the procedures with respect to rights in RFC documents can be 1068 found in BCP 78 and BCP 79. 1070 Copies of IPR disclosures made to the IETF Secretariat and any 1071 assurances of licenses to be made available, or the result of an 1072 attempt made to obtain a general license or permission for the use of 1073 such proprietary rights by implementers or users of this 1074 specification can be obtained from the IETF on-line IPR repository at 1075 http://www.ietf.org/ipr. 1077 The IETF invites any interested party to bring to its attention any 1078 copyrights, patents or patent applications, or other proprietary 1079 rights that may cover technology that may be required to implement 1080 this standard. Please address the information to the IETF at 1081 ietf-ipr@ietf.org. 1083 Acknowledgment 1085 Funding for the RFC Editor function is provided by the IETF 1086 Administrative Support Activity (IASA).