idnits 2.17.1 draft-ietf-pce-global-concurrent-optimization-02.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1042. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1053. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1060. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1066. 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 (February 21, 2008) is 5899 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 891, but not defined == Missing Reference: 'OSPF PCED' is mentioned on line 891, but not defined == Unused Reference: 'ISIS-PCED' is defined on line 967, but no explicit reference was found in the text == Unused Reference: 'OSPF-PCED' is defined on line 976, but no explicit reference was found in the text == Unused Reference: 'PCE-MLN' is defined on line 981, 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: August 24, 2008 France Telecom 6 D. King 7 Aria Networks 8 E. Oki 9 NTT 10 February 21, 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-02.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 24, 2008. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2008). 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 . . . . . . 15 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 . . . . . . . . . . . . . . . . . 22 96 6.1. Control of Function and Policy . . . . . . . . . . . . . . 22 97 6.2. Information and Data Models, e.g. MIB module . . . . . . . 22 98 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 22 99 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 22 100 6.5. Requirements on Other Protocols and Functional 101 Components . . . . . . . . . . . . . . . . . . . . . . . . 23 102 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 23 103 7. Security Considerations . . . . . . . . . . . . . . . . . . . 24 104 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 25 105 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 106 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 107 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 108 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 109 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 110 Intellectual Property and Copyright Statements . . . . . . . . . . 30 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 after incorporating new requirements 549 for support of global concurrent optimization is as follows: 551 ::= 552 [] 553 555 The is changed as follows: 557 :: = 558 [] 559 [] 560 [] 561 [] 563 Note that three optional objects are added, following the SVEC 564 object: the OF (Objective Function) object, which is defined in 565 [PCE-OF], the GC (Global Constraints) object, which is defined in 566 this document (section 5.5), as well as the eXclude Route Object 567 (XRO) which is defined in [PCE-XRO]. Details of this change will be 568 discussed in the following sections. 570 Note also that when the XRO is global to a SVEC, and F bit is set, it 571 should be allowed to specify multiple RRO objects in the PCReq 572 message. 574 5.1. Global Objective Function (GOF) Specification 576 The global objective function can be specified in the PCEP Objective 577 Function (OF) object, defined in [PCE-OF]. The OF object includes a 578 16 bit Objective Function identifier. As per discussed in [PCE-OF], 579 objective function identifier code points are managed by IANA. 581 Two global objective functions are defined in this document and their 582 identifier should be assigned by IANA (suggested value) 583 Function 584 Code Description 586 1 Minimize the sum of all TE LSP costs (min cost) 588 2 Evenly allocate the network load to achieve the 589 most uniform link utilization across all links* 591 * Note: This can be achieved by the following objective function: 592 minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link 593 capacity for link i and A(i) is the total bandwidth allocated on link 594 i.) 596 5.2. Indication of Global Concurrent Optimization Requests 598 All the path requests in this application should be indicated so that 599 the global objective function and all of the global constraints are 600 applied to each of the requested path computation. This can be 601 indicated implicitly by placing the GCO related objects (GOF, GC or 602 XRO) after the SVEC object. That is, if any of these objects follows 603 the SVEC object in the PCReq message, all of the requested path 604 computations specified in the SVEC object are subject to GOF, GC or 605 XRO. 607 5.3. Request for the order of LSP 609 In order to minimize disruption associated with bulk path 610 provisioning, the PCC may indicate to the PCE that the response MUST 611 be ordered. That is, the PCE has to include the order in which LSPs 612 MUST be moved so as to minimize traffic disruption. To support such 613 indication a new flag, the D flag, is defined in the RP object as 614 follows: 616 0 1 2 3 617 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 618 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 619 | Reserved | Flags |D|M|F|O|B|R| Pri | 620 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 621 | Request-ID-number | 622 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 623 | | 624 // Optional TLV(s) // 625 | | 626 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 627 Figure 4: RP object body format in the PCReq Message 629 D bit (orDer - 1 bit): when set, in a PCReq message, the requesting 630 PCC requires the PCE to specify in the PCRep message the order in 631 which this particular path request is to be provisioned relative to 632 other requests. 634 M bit (Make-before-break - 1 bit): when set, this indicates that a 635 make-before-break reoptimization is required for this request. 637 When M bit is not set, this implies that a break-before-make 638 reoptimization is allowed for this request. Note that M bit can be 639 set only if the R (Reoptimization) flag is set. 641 5.4. The Order Response 643 The PCE MUST specify the order number in response to the Order 644 Request made by the PCC in the PCReq message if so requested by the 645 setting of the D bit in the RP object in the PCReq message. To 646 support such ordering indication a new optional TLV is defined in the 647 RP object, the Order TLV, as follows: 649 0 1 2 3 650 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 651 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 652 | Reserved | Flags |D|M|F|O|B|R| Pri | 653 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 654 | Request-ID-number | 655 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 656 | | 657 // Order TLV (Optional TLV) // 658 | | 659 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 661 Figure 5: RP object body format in the PCRep Message 663 The Order TLV is an optional TLV in the RP object, that indicates the 664 order in which the old LSP must be removed and the new LSP must be 665 setup during a reoptimization. It is carried in the PCRep message in 666 response to a reoptimization request. 668 The Order TLV SHOULD be included in the RP object in the PCRep 669 message if the D bit is set in the RP object in the PCReq message. 671 The format of the Order TLV is as follows: 673 0 1 2 3 674 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 675 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 676 | Type | Length | 677 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 678 | Delete Order | 679 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 680 | Setup Order | 681 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 Type To be defined by IANA (suggested value = ) 684 Length Variable 685 Value Orders in which the old path should be removed 686 and the new path should be setup 688 Figure 6: The Order TLV in the RP object in the PCRep Message 690 Delete Order: 32 bit integer that indicates the order in which the 691 old LSP should be removed 693 Setup Order: 32 bit integer that indicates the order in which the new 694 LSP should be setup 696 The delete order should not be equal to the setup order. If the 697 delete order is higher than the setup order, this means that the 698 reoptimization can be done in a make-before-break manner, else it 699 cannot be done in a make-before-break manner. 701 For a new LSP the delete order is not applicable. The value 0 is 702 designated to specify this case. When the value of the delete order 703 is 0, it implies that the resulting LSP is a new LSP. 705 To illustrate, consider a network with two established requests: R1 706 with path P1 and R2 with path P2. During a reoptimization the PCE 707 may provide the following ordered reply: 709 R1, path P1', remove order 1, setup order 4 710 R2, path P2', remove order 3, setup order 2 712 This indicates that the NMS should do the following sequence of 713 tasks: 715 1: Remove path P1 716 2: Setup path P2' 717 3: Remove path P2 718 4: Setup path P1' 719 That is, R1 is reoptimized in a break-before-make manner and R2 in a 720 make-before-break manner. 722 5.5. GLOBAL CONSTRAINTS (GC) Object 724 The Global Constraints (GC) Object is used in a PCReq message to 725 specify the necessary global constraints that should be applied to 726 all individual path computations for a global concurrent path 727 optimization request. 729 GLOBAL CONSTRAINT Object-Class is to be assigned by IANA (recommended 730 value=22) 732 GLOBAL CONSTRAINT Object-Type is to be assigned by IANA (recommended 733 value=1) 735 The format of the GC object body that includes the global constraints 736 is as follows: 738 0 1 2 3 739 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 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Reserved | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 743 | MH | MU | mU | OB | 744 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 745 | | 746 // Optional TLV(s) // 747 | | 748 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 750 Figure 9: GC body object format 752 MH (Max Hop: 8 bits): 8 bit integer that indicates the maximum hop 753 count for all the LSPs. 755 MU (Max Utilization Percentage: 8 bits) : 8 bits integer that 756 indicates the upper bound utilization percentage by which all link 757 should be bound. Utilization = (Link Capacity - Allocated Bandwidth 758 on the Link)/ Link Capacity 760 mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that 761 indicates the lower bound utilization percentage by which all link 762 should be bound. 764 OB (Over Booking factor Percentage: 8 bits) : 8 bits integer that 765 indicates the overbooking percentage that allows the reserved 766 bandwidth to be overbooked on each link beyond its physical capacity 767 limit. The value, for example, 10% means that 110 Mbps can be 768 reserved on a 100Mbps link. 770 Reserved bits (24 bits) of the GLOBAL CONSTRAINTS Object SHOULD be 771 transmitted as zero and SHOULD be ignored upon receipt. 773 The exclusion of the list of nodes/links from a global path 774 computation can be done by including the XRO object following the GC 775 object in the new SVEC list definition. 777 5.6. Error Indicator 779 To indicate errors associated with the global concurrent path 780 optimization request, a new Error-Type (14) and subsequent error- 781 values are defined as follows for inclusion in the PCEP-ERROR object: 783 A new Error-Type (14) and subsequent error-values are defined as 784 follows: 786 Error-Type=14 and Error-Value=1: if a PCE receives a global 787 concurrent path optimization request and the PCE is not capable of 788 the request due to insufficient memory, the PCE MUST send a PCErr 789 message with a PCEP ERROR object (Error-Type=14) and an Error-Value 790 (Error-Value=1). The corresponding global concurrent path 791 optimization request MUST be cancelled. 793 Error-Type=14; Error-Value=2: if a PCE receives a global concurrent 794 path optimization request and the PCE is not capable of global 795 concurrent optimization, the PCE MUST send a PCErr message with a 796 PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=2). 797 The corresponding global concurrent path optimization MUST be 798 cancelled. 800 To indicate an error associated with policy violation, a new error 801 value "global concurrent optimization not allowed" should be added to 802 an existing error code for policy violation (Error-Type=5) as defined 803 in [PCEP]. 805 Error-Type=5; Error-Value=3: if a PCE receives a global concurrent 806 path optimization request which is not compliant with administrative 807 privileges (i.e., the PCE policy does not support global concurrent 808 optimization), the PCE sends a PCErr message with a PCEP-ERROR Object 809 (Error-Type=5) and an Error-Value (Error-Value=3). The corresponding 810 global concurrent path computation MUST be cancelled. 812 5.7. NO-PATH Indicator 814 To communicate the reason(s) for not being able to find global 815 concurrent path computation, the NO-PATH object can be used in the 816 PCRep message. The format of the NO-PATH object body is as follows: 818 0 1 2 3 819 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 820 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 821 |C| Flags | Reserved | 822 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 823 | | 824 // Optional TLV(s) // 825 | | 826 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 828 Figure 10: NO-PATH object format 830 Flags (16 bits). The C flag is defined in [PCEP]. 832 Two new bit flags are defined in the NO-PATH-VECTOR TLV carried in 833 the NO-PATH Object: 835 0x08: when set, the PCE indicates that no migration path was found. 837 0x10: when set, the PCE indicates no feasible solution was found that 838 meets all the constraints associated with global concurrent path 839 optimization in the PCRep message. 841 6. Manageability Considerations 843 Manageability of Global Concurrent Path Computation with PCE must 844 address the following considerations: 846 6.1. Control of Function and Policy 848 In addition to the parameters already listed in section 8.1 of 849 [PCEP], a PCEP implementation SHOULD allow configuring the following 850 PCEP session parameters on a PCC: 852 o The ability to send a GCO request. 854 In addition to the parameters already listed in section 8.1 of 855 [PCEP], a PCEP implementation SHOULD allow configuring the following 856 PCEP session parameters on a PCE: 858 o The support for Global Concurrent Optimization. 860 o The maximum number of synchronized path requests per request 861 message. 863 o A set of GCO specific policies (authorized sender, request rate 864 limiter, etc). 866 These parameters may be configured as default parameters for any PCEP 867 session the PCEP speaker participates in, or may apply to a specific 868 session with a given PCEP peer or a specific group of sessions with a 869 specific group of PCEP peers. 871 6.2. Information and Data Models, e.g. MIB module 873 Extensions to the PCEP MIB module defined in [PCEP-MIB] should be 874 defined, so as to cover the GCO information introduced in this 875 document. 877 6.3. Liveness Detection and Monitoring 879 Mechanisms defined in this draft does not imply any new liveness 880 detection and monitoring requirements in addition to those already 881 listed in section 8.3 of [PCEP]. 883 6.4. Verifying Correct Operation 885 Mechanisms defined in this draft does not imply any new verification 886 requirements in addition to those already listed in section 8.4 of 887 [PCEP] 889 6.5. Requirements on Other Protocols and Functional Components 891 The PCE Discovery mechanisms ([ISIS PCED] and [OSPF PCED]) may be 892 used to advertise global concurrent path computation capabilities to 893 PCCs. 895 6.6. Impact on Network Operation 897 Mechanisms defined in this draft does not imply any new network 898 operation requirements in addition to those already listed in section 899 8.6 of [PCEP]. 901 7. Security Considerations 903 When global re-optimization is applied to an active network, it could 904 be extremely disruptive. Although the real security and policy 905 issues apply at the NMS, if the wrong results are returned to the 906 NMS, the wrong actions may be taken in the network. Therefore, it is 907 very important that the operator issuing the commands has sufficient 908 authority and is authenticated, and that the computation request is 909 subject to appropriate policy. 911 The mechanism defined in [PCEP] to secure a PCEP session can be used 912 to secure global concurrent path computation requests/responses. 914 8. Acknowledgements 916 We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning 917 So, Lucy Yong and Fabien Verhaeghe for their useful comments and 918 suggestions. 920 9. IANA Considerations 922 A future revision of this document will present requests to IANA for 923 codepoint allocation. 925 10. References 927 10.1. Normative References 929 [BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based 930 Computation (BRPC) procedure to compute shortest inter- 931 domain Traffic Engineering Label Switched Paths, 932 draft-ietf-pce-brpc-05.txt, work in progress". 934 [PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 935 Function encoding in Path Computation Element 936 communication and discovery protocols, 937 draft-leroux-pce-of, work in progress". 939 [PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation 940 Element Communication Protocol (PCEP) for Route 941 Exclusions, draft-ietf-pce-pcep-xro-00.txt, work in 942 progress". 944 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 945 Element (PCE) communication Protocol (PCEP) - Version 1, 946 draft-ietf-pce-pcep, work in progress". 948 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 949 Requirement Levels", BCP 14, RFC 2119, March 1997. 951 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 952 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 953 Tunnels", RFC 3209, December 2001. 955 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 956 Element (PCE)-Based Architecture, RFC 4655, August 2006". 958 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 959 Communication Protocol Generic Requirements, RFC 4657, 960 September 2006". 962 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 963 (PCE) Discovery, RFC 4674, October 2006.". 965 10.2. Informative References 967 [ISIS-PCED] 968 Le Roux, J. and JP. Vasseur, "IS-IS protocol extensions 969 for Path Computation Element (PCE) Discovery, 970 draft-ietf-pce-disco-proto-isis, work in progress.". 972 [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- 973 region and multi-layer networks (MRN/MLN), 974 draft-ietf-ccamp-gmpls-mln-reqs, work in progress". 976 [OSPF-PCED] 977 Le Roux, J. and JP. Vasseur, "OSPF protocol extensions for 978 Path Computation Element (PCE) Discovery, 979 draft-ietf-pce-disco-proto-ospf, work in progress.". 981 [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- 982 based inter-layer MPLS and GMPL traffic engineering, 983 draft-ietf-pce-inter-layer-frwk, work in progress.". 985 [PCEP-MIB] 986 Stephen, E. and K. Koushik, "PCE communication 987 protocol(PCEP) Management Information Base, 988 draft-kkoushik-pce-pcep-mib, work in progress.". 990 Authors' Addresses 992 Young Lee 993 Huawei 994 1700 Alma Drive, Suite 100 995 Plano, TX 75075 996 US 998 Phone: +1 972 509 5599 x2240 999 Fax: +1 469 229 5397 1000 Email: ylee@huawei.com 1002 JL Le Roux 1003 France Telecom 1004 2, Avenue Pierre-Marzin 1005 Lannion 22307 1006 FRANCE 1008 Email: jeanlouis.leroux@orange-ftgroup.com 1010 Daniel King 1011 Aria Networks 1012 44/45 Market Place 1013 Chippenham SN15 3HU 1014 United Kingdom 1016 Phone: +44 7790 775187 1017 Fax: +44 1249 446530 1018 Email: daniel.king@aria-networks.com 1020 Eiji Oki 1021 NTT 1022 Midori 3-9-11 1023 Musashino, Tokyo 180-8585 1024 JAPAN 1026 Email: oki.eiji@lab.ntt.co.jp 1028 Full Copyright Statement 1030 Copyright (C) The IETF Trust (2008). 1032 This document is subject to the rights, licenses and restrictions 1033 contained in BCP 78, and except as set forth therein, the authors 1034 retain all their rights. 1036 This document and the information contained herein are provided on an 1037 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1038 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1039 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1040 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1041 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1042 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1044 Intellectual Property 1046 The IETF takes no position regarding the validity or scope of any 1047 Intellectual Property Rights or other rights that might be claimed to 1048 pertain to the implementation or use of the technology described in 1049 this document or the extent to which any license under such rights 1050 might or might not be available; nor does it represent that it has 1051 made any independent effort to identify any such rights. Information 1052 on the procedures with respect to rights in RFC documents can be 1053 found in BCP 78 and BCP 79. 1055 Copies of IPR disclosures made to the IETF Secretariat and any 1056 assurances of licenses to be made available, or the result of an 1057 attempt made to obtain a general license or permission for the use of 1058 such proprietary rights by implementers or users of this 1059 specification can be obtained from the IETF on-line IPR repository at 1060 http://www.ietf.org/ipr. 1062 The IETF invites any interested party to bring to its attention any 1063 copyrights, patents or patent applications, or other proprietary 1064 rights that may cover technology that may be required to implement 1065 this standard. Please address the information to the IETF at 1066 ietf-ipr@ietf.org. 1068 Acknowledgment 1070 Funding for the RFC Editor function is provided by the IETF 1071 Administrative Support Activity (IASA).