idnits 2.17.1 draft-ietf-pce-global-concurrent-optimization-10.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.i or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? -- It seems you're using the 'non-IETF stream' Licence Notice instead 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 : ---------------------------------------------------------------------------- ** There are 3 instances of too long lines in the document, the longest one being 2 characters in excess of 72. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (March 29, 2009) is 5504 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: 'PCEP' is mentioned on line 565, but not defined Summary: 2 errors (**), 0 flaws (~~), 3 warnings (==), 3 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: Aug 2009 France Telecom 6 D. King 7 Old Dog Consulting 8 E. Oki 9 Univeristy of Electro Communications 10 March 29, 2009 12 Path Computation Element Communication Protocol (PCEP) Requirements and 13 Protocol Extensions In Support of Global Concurrent Optimization 15 draft-ietf-pce-global-concurrent-optimization-10.txt 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on August 29, 2009. 40 Abstract 42 The Path Computation Element Communication Protocol (PCEP) allows 43 Path Computation Clients (PCCs) to request path computations from 44 Path Computation Elements (PCEs), and lets the PCEs return responses. 45 When computing or re-optimizing the routes of a set of TE LSPs 46 through a network it may be advantageous to perform bulk path 47 computations in order to avoid blocking problems and to achieve more 48 optimal network-wide solutions. Such bulk optimization is termed 49 Global Concurrent Optimization (GCO). A GCO is able to 50 simultaneously consider the entire topology of the network and the 51 complete set of existing TE LSPs, and their respective constraints, 52 and look to optimize or re-optimize the entire network to satisfy all 53 constraints for all TE LSPs. A GCO may also be applied to some 54 subset of the TE LSPs in a network. The GCO application is primarily 55 a Network Management System (NMS) solution. 57 This document provides application-specific requirements and the PCEP 58 extensions in support of GCO applications. 60 Table of Contents 62 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 63 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 6 64 3. Applicability of Global Concurrent Optimization (GCO) . . . . 7 65 3.1. Application of the PCE Architecture . . . . . . . . . . . 7 66 3.2. Greenfield Optimization . . . . . . . . . . . . . . . . . 8 67 3.2.1. Single-layer Traffic Engineering . . . . . . . . . . . 8 68 3.2.2. Multi-layer Traffic Engineering . . . . . . . . . . . 8 69 3.3. Re-optimization of Existing Networks . . . . . . . . . . . 8 70 3.3.1. Reconfiguration of the Virtual Network Topology 71 (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 9 72 3.3.2. Traffic Migration . . . . . . . . . . . . . . . . . . 9 73 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 10 74 5. Protocol Extensions for Support of Global Concurrent 75 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 14 76 5.1. Global Objective Function (GOF) Specification . . . . . . 14 77 5.2. Indication of Global Concurrent Optimization Requests . . 15 78 5.3. Request for The Order of TE LSP . . . . . . . . . . . . . 15 79 5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 16 80 5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 17 81 5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 18 82 5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 19 83 6. Manageability Considerations . . . . . . . . . . . . . . . . . 20 84 6.1. Control of Function and Policy . . . . . . . . . . . . . . 20 85 6.2. Information and Data Models, e.g. MIB module . . . . . . . 20 86 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 20 87 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 20 88 6.5. Requirements on Other Protocols and Functional 89 Components . . . . . . . . . . . . . . . . . . . . . . . . 21 90 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 21 91 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21 92 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21 93 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 94 9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 22 95 9.2. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . 22 96 9.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED . . . . . . . . 22 97 9.4. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 23 98 9.5. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 23 99 9.5.1. New Error-Values for Existing Error-Types . . . . . . 23 100 9.5.2. New Error-Types and Error-Values . . . . . . . . . . . 23 101 9.6. New No-Path Reasons . . . . . . . . . . . . . . . . . . . 24 102 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24 103 10.1. Normative References . . . . . . . . . . . . . . . . . . . 24 104 10.2. Informative References . . . . . . . . . . . . . . . . . . 25 105 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 106 Intellectual Property and Copyright Statements . . . . . . . . . . 26 108 1. Introduction 110 [RFC4655] defines the Path Computation Element (PCE) based 111 Architecture and explains how a PCE may compute Label Switched Paths 112 (LSPs) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) 113 and Generalized MPLS (GMPLS) networks at the request of Path 114 Computation Clients (PCCs). A PCC is shown to be any network 115 component that makes such a request and may be for instance a Label 116 Switching Router (LSR) or a Network Management System (NMS). The 117 PCE, itself, is shown to be located anywhere within the network, and 118 may be within an LSR, an NMS or Operational Support System (OSS), or 119 may be an independent network server. 121 The PCE Communication Protocol (PCEP) is the communication protocol 122 used between PCC and PCE, and may also be used between cooperating 123 PCEs. [RFC4657] sets out generic protocol requirements for PCEP. 124 Additional application-specific requirements for PCEP are defined in 125 separate documents. 127 This document provides a set of requirements and PCEP extensions in 128 support of concurrent path computation applications. A concurrent 129 path computation is a path computation application where a set of TE 130 paths are computed concurrently in order to efficiently utilize 131 network resources. The computation method involved with a concurrent 132 path computation is referred to as global concurrent optimization in 133 this document. Appropriate computation algorithms to perform this 134 type of optimization are out of the scope of this document. 136 The Global Concurrent Optimization (GCO) application is primarily an 137 NMS or a PCE Server based solution. Owing to complex synchronization 138 issues associated with GCO applications, the management based PCE 139 architecture defined in Section 5.5 of [RFC4655] is considered as the 140 most suitable usage to support GCO application. This does not 141 preclude other architectural alternatives to support GCO application, 142 but they are NOT RECOMMENDED. For instance, GCO might be enabled by 143 distributed LSRs through complex synchronization mechanisms. 144 However, this approach might suffer from significant synchronization 145 overhead between the PCE and each of the PCCs. It would likely 146 affect the network stability and hence significantly diminish the 147 benefits of deploying PCEs. 149 The need for global concurrent path computation may also arise when 150 network operators need to establish a set of TE LSPs in their network 151 planning process. It is also envisioned that network operators might 152 require global concurrent path computation in the event of 153 catastrophic network failures, where a set of TE LSPs need to be 154 optimally rerouted. The nature of this work promote the use of such 155 systems for offline processing. Online application of this work 156 should only be considered with proven empirical validation. 158 As new TE LSPs are added or removed from the network over time, the 159 global network resources become fragmented and the existing placement 160 of TE LSPs within network no longer provides optimal use of the 161 available capacity. A global concurrent path computation is able to 162 simultaneously consider the entire topology of the network and the 163 complete set of existing TE LSPs and their respective constraints, 164 and look to re-optimize the entire network to satisfy all constraints 165 for all TE LSPs. Alternatively, the application may consider a 166 subset of the TE LSPs and/or a subset of the network topology. Note 167 that other preemption can also help reducing the fragmentation 168 issues. 170 While GCO is applicable to any simultaneous request for multiple TE 171 LSPs (for example, a request for end-to-end protection), it is NOT 172 RECOMMENDED that global concurrent reoptimization would be applied in 173 a network (such as an MPLS-TE network) that contains a very large 174 number of very low bandwidth or zero bandwidth TE LSPs since the 175 large scope of the problem and the small benefit of concurrent 176 reoptimization relative to single TE LSP reoptimization is unlikely 177 to make the process worthwhile. Further, applying global concurrent 178 reoptimization in a network with a high rate of change of TE LSPs 179 (churn) is NOT RECOMMENDED because of the likelihood that TE LSPs 180 would change before they could be globally reoptimized. Global 181 reoptimization is more applicable to stable networks such as 182 transport networks or those with long-term TE LSP tunnels. 184 The main focus of this document is to highlight the PCC-PCE 185 communication needs in support of a concurrent path computation 186 applications and to define protocol extensions to meet those needs. 188 The PCC-PCE requirements addressed herein are specific to the context 189 where the PCE is a specialized PCE that is capable of performing 190 computations in support of GCO. Discovery of such capabilities might 191 be desirable and could be achieved through extensions to the PCE 192 discovery mechanisms [RFC4674], [RFC5088], [RFC5089], but that is out 193 of the scope of this document. 195 It is to be noted that Backward Recursive Path Computation (BRPC) 196 [BRPC] is a multi-PCE path computation technique used to compute a 197 shortest constrained inter-domain path whereas this ID specifies a 198 technique where a set of path computation requests are bundled and 199 send to a PCE with the objective of "optimizing" the set of computed 200 paths. 202 2. Terminology 204 Most of the terminology used in this document is explained in 205 [RFC4655]. A few key terms are repeated here for clarity. 207 PCC: Path Computation Client: Any client application requesting a 208 path computation to be performed by a Path Computation Element. 210 PCE: Path Computation Element: An entity (component, application or 211 network node) that is capable of computing a network path or route 212 based on a network graph and applying computational constraints. 214 TED: Traffic Engineering Database which contains the topology and 215 resource information of the domain. The TED may be fed by IGP 216 extensions or potentially by other means. 218 PCECP: The PCE Communication Protocol: PCECP is the generic abstract 219 idea of a protocol that is used to communicate path computation 220 requests from a PCC to a PCE, and to return computed paths from the 221 PCE to the PCC. The PCECP can also be used between cooperating PCEs. 223 PCEP: The PCE communication Protocol: PCEP is the actual protocol 224 that implements the PCECP idea. 226 GCO: Global Concurrent Optimization: A concurrent path computation 227 application where a set of TE paths are computed concurrently in 228 order to optimize network resources. A GCO path computation is able 229 to simultaneously consider the entire topology of the network and the 230 complete set of existing TE LSPs, and their respective constraints, 231 and look to optimize or re-optimize the entire network to satisfy all 232 constraints for all TE LSPs. A GCO path computation can also provide 233 an optimal way to migrate from an existing set of TE LSPs to a 234 reoptimized set (Morphing Problem). 236 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 237 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 238 document are to be interpreted as described in RFC 2119 [RFC2119]. 239 These terms are also used in the parts of this document that specify 240 requirements for clarity of specification of those requirements. 242 3. Applicability of Global Concurrent Optimization (GCO) 244 This section discusses the PCE architecture to which GCO is applied. 245 It also discusses various application scenarios for which global 246 concurrent path computation may be applied. 248 3.1. Application of the PCE Architecture 250 Figure 1 shows the PCE-based network architecture as defined in 251 [RFC4655] to which GCO application is applied. It must be observed 252 that the PCC is not necessarily an LSR [RFC4655]. The GCO 253 application is primarily an NMS-based solution in which an NMS plays 254 the function of the PCC. Although Figure 1 shows the PCE as remote 255 from the NMS, it might be collocated with the NMS. Note that in the 256 collocated case there is no need for a standard communication 257 protocol; this can rely on internal APIs. 259 ----------- 260 Application | ----- | 261 Request | | TED | | 262 | | ----- | 263 v | | | 264 ------------- Request/ | v | 265 | PCC | Response| ----- | 266 | (NMS/Server)|<--------+> | PCE | | 267 | | | ----- | 268 ------------- ----------- 269 Service | 270 Request | 271 v 272 ---------- Signaling ---------- 273 | Head-End | Protocol | Adjacent | 274 | Node |<---------->| Node | 275 ---------- ---------- 277 Figure 1: PCE-Based Architecture for Global Concurrent Optimization 279 Upon receipt of an application request (e.g., a traffic demand matrix 280 is provided to the NMS by the operator's network planning procedure), 281 the NMS requests a global concurrent path computation from the PCE. 282 The PCE then computes the requested paths concurrently applying some 283 algorithms. Various algorithms and computation techniques have been 284 proposed to perform this function. Specification of such algorithms 285 or techniques is outside the scope of this document. 287 When the requested path computation completes, the PCE sends the 288 resulting paths back to the NMS. The NMS then supplies the head-end 289 LSRs with a fully computed explicit path for each TE LSP that needs 290 to be established. 292 3.2. Greenfield Optimization 294 Greenfield optimization is a special case of GCO application when 295 there are no TE LSPs already set up in the network. The need for 296 greenfield optimization arises when network planner wants to make use 297 of a computation server to plan the TE LSPs that will be provisioned 298 in the network. Note that once greenfield operation is one-time 299 optimization. When network conditions change due to failure or other 300 changes, then re-optimization mode of operation will kick in. 302 When a new TE network needs to be provisioned from a greenfield 303 perspective, a set of TE LSPs needs to be created based on traffic 304 demand, network topology, service constraints, and network resources. 305 In this scenario, the ability to perform concurrent computation is 306 desirable, or required, to utilize network resources in an optimal 307 manner and avoid blocking. 309 3.2.1. Single-layer Traffic Engineering 311 Greenfield optimization can be applied when layer-specific TE LSPs 312 need to be created from a greenfield perspective. For example, an 313 MPLS-TE network can be planned based on layer 3 specific traffic 314 demands, the network topology, and available network resources. 315 Greenfield optimization for single-layer traffic engineering can be 316 applied to optical transport networks such as SDH/Sonet, Ethernet 317 Transport, WDM, etc. 319 3.2.2. Multi-layer Traffic Engineering 321 Greenfield optimization is not limited to single-layer traffic 322 engineering. It can also be applied to multi-layer traffic 323 engineering [PCE-MLN]. Both the client and the server layers network 324 resources and topology can be considered simultaneously in setting up 325 a set of TE LSPs that traverse the layer boundary. 327 3.3. Re-optimization of Existing Networks 329 The need for global concurrent path computation may arise in existing 330 networks. When an existing TE LSP network experiences sub-optimal 331 use of its resources, the need for re-optimization or reconfiguration 332 may arise. The scope of re-optimization and reconfiguration may vary 333 depending on particular situations. The scope of re-optimization may 334 be limited to bandwidth modification to an existing TE LSP. However, 335 it could well be that a set of TE LSPs may need to be re-optimized 336 concurrently. In an extreme case, the TE LSPs may need to be 337 globally re-optimized. 339 In loaded networks, with large size TE LSPs, a sequential re- 340 optimization may not produce substantial improvements in terms of 341 overall network optimization. Sequential re-optimization refers to a 342 path computation method that computes the re-optimized path of 343 one TE LSP at a time without giving any consideration to the other TE 344 LSPs that need to be re-optimized in the network. The potential for 345 network-wide gains from reoptimization of TE LSPs sequentially is 346 dependent upon the network usage and size of the TE LSPs being 347 optimized. However, the key point remains: computing the reoptimized 348 path of one TE LSP at a time without giving any consideration to the 349 other TE LSPs in the network could result in sub-optimal use of 350 network resources. This may be far more visible in an optical 351 network with a low ratio of potential TE LSPs per link, and far less 352 visible in packet networks with micro-flow TE LSPs. 354 With regards to applicability of GCO in the event of catastrophic 355 failures, there may be a real benefit in computing the paths of the 356 TE LSPs as a set rather than computing new paths from the head-end 357 LSRs in a distributed manner. Distributed jittering is a technique 358 that could prevent race condition (i.e., competing for the same 359 resource from different head-end LSRs) with a distributed 360 computation. GCO provides an alternative way that could also prevent 361 race condition in a centralized manner. However, a centralized 362 system will typically suffer from a slower response time than a 363 distributed system. 365 3.3.1. Reconfiguration of the Virtual Network Topology (VNT) 367 Reconfiguration of the VNT [RFC5212] [PCE-MLN] is a typical 368 application scenario where global concurrent path computation may be 369 applicable. Triggers for VNT reconfiguration, such as traffic demand 370 changes, network failures, and topological configuration changes, may 371 require a set of existing TE LSPs to be re-computed. 373 3.3.2. Traffic Migration 375 When migrating from one set of TE LSPs to a reoptimized set of TE 376 LSPs it is important that the traffic be moved without causing 377 disruption. Various techniques exist in MPLS and GMPLS, such as 378 make-before-break [RFC3209], to establish the new TE LSPs before 379 tearing down the old TE LSPs. When multiple TE LSP routes are 380 changed according to the computed results, some of the TE LSPs may be 381 disrupted due to the resource constraints. In other words, it may 382 prove to be impossible to perform a direct migration from the old TE 383 LSPs to the new optimal TE LSPs without disrupting traffic because 384 there are insufficient network resources to support both sets of TE 385 LSPs when make-before-break is used. However, a PCE may be able to 386 determine a sequence of make-before- break replacement of individual 387 TE LSPs or small sets of TE LSPs so that the full set of TE LSPs can 388 be migrated without any disruption. This scenario assumes that the 389 bandwidth of existing TE LSP is kept during the migration which is 390 required in optical networks. In packet networks, this assumption 391 can be relaxed as the bandwidth of temporary TE LSPs during migration 392 can be zeroed. 394 It may be the case that the reoptimization is radical. This could 395 mean that it is not possible to apply make-before-break in any order 396 to migrate from the old TE LSPs to the new TE LSPs. In this case a 397 migration strategy is required that may necessitate TE LSPs being 398 rerouted using make-before-break onto temporary paths in order to 399 make space for the full reoptimization. A PCE might indicate the 400 order in which reoptimized TE LSPs must be established and take over 401 from the old TE LSPs, and may indicate a series of different 402 temporary paths that must be used. Alternatively, the PCE might 403 perform the global reoptimization as a series of sub-reoptimizations 404 by reoptimizing subsets of the total set of TE LSPs. 406 The benefit of this multi-step rerouting includes minimization of 407 traffic discruption and optimization gain. However this approach may 408 imply some transient packets desequencing, jitter as well as control 409 plane stress. 411 Note also that during reoptimization, traffic disruption may be 412 allowed for some TE LSPs carrying low priority services (e.g., 413 Internet traffic) and not allowed for some TE LSPs carrying mission 414 critical services (e.g., voice traffic). 416 4. PCECP Requirements 418 This section provides the PCECP requirements to support global 419 concurrent path computation applications. The requirements specified 420 here should be regarded as application-specific requirements and are 421 justifiable based on the extensibility clause found in Section 6.1.14 422 of [RFC4657]: 424 The PCECP MUST support the requirements specified in the 425 application-specific requirements documents. The PCECP MUST also 426 allow extensions as more PCE applications will be introduced in 427 the future. 429 It is also to be noted that some of the requirements discussed in 430 this section have already been discussed in the PCECP requirement 431 document [RFC4657]. For example, Section 5.1.16 in [RFC4657] 432 provides a list of generic constraints while Section 5.1.17 in 433 [RFC4657] provides a list of generic objective functions that MUST be 434 supported by the PCECP. While using such generic requirements as the 435 baseline, this section provides application-specific requirements in 436 the context of global concurrent path computation and in a more 437 detailed level than the generic requirements. 439 The PCEP SHOULD support the following capabilities either via 440 creation of new objects and/or modification of existing objects where 441 applicable. 443 o An indicator to convey that the request is for a global concurrent 444 path computation. This indicator is necessary to ensure 445 consistency in applying global objectives and global constraints 446 in all path computations. Note: This requirement is covered by 447 "synchronized path computation" in [RFC4655] and [RFC4657]. 448 However, an explicit indicator to request a global concurrent 449 optimization is a new requirement. 451 o A Global Objective Function (GOF) field in which to specify the 452 global objective function. The global objective function is the 453 overarching objective function to which all individual path 454 computation requests are subjected in order to find a globally 455 optimal solution. Note that this requirement is covered by 456 "synchronized objective functions" in Section 5.1.7 [RFC4657] and 457 that [PCE-OF] defined three global objective functions as follows. 458 A list of available global objective functions SHOULD include the 459 following objective functions at the minimum and SHOULD be 460 expandable for future addition: 462 * Minimize aggregate Bandwidth Consumption (MBC) 464 * Minimize the load of the Most Loaded Link (MLL) 466 * Minimize Cumulative Cost of a set of paths (MCC) 468 o A Global Constraints (GC) field in which to specify the list of 469 global constraints to which all the requested path computations 470 should be subjected. This list SHOULD include the following 471 constraints at the minimum and SHOULD be expandable for future 472 addition: 474 * Maximum link utilization value -- This value indicates the 475 highest possible link utilization percentage set for each link. 476 (Note: to avoid floating point numbers, the values should be 477 integer values.) 479 * Minimum link utilization value -- This value indicates the 480 lowest possible link utilization percentage set for each link. 481 (Note: same as above) 483 * Overbooking Factor -- The overbooking factor allows the 484 reserved bandwidth to be overbooked on each link beyond its 485 physical capacity limit. 487 * Maximum number of hops for all the TE LSPs -- This is the 488 largest number of hops that any TE LSP can have. Note that 489 this constraint can also be provided on a per TE LSP basis (as 490 requested in [RFC4657] and defined in [PCEP]). 492 * Exclusion of links/nodes in all TE LSP path computation (i.e., 493 all TE LSPs should not include the specified links/nodes in 494 their paths). Note that this constraint can also be provided 495 on a per TE LSP basis (as requested in [RFC4657] and defined in 496 [PCEP]). 498 * An indication should be available in a path computation 499 response that further reoptimization may only become available 500 once existing traffic has been moved to the new TE LSPs. 502 o A Global Concurrent Vector (GCV) field in which to specify all the 503 individual path computation requests that are subject to 504 concurrent path computation and subject to the global objective 505 function and all of the global constraints. Note that this 506 requirement is entirely fulfilled by the SVEC object in the PCEP 507 specification [PCEP]. Since the SVEC object as defined in [PCEP] 508 allows identifying a set of concurrent path requests, the SVEC can 509 be reused to specify all the individual concurrent path requests 510 for a global concurrent optimization. 512 o An indicator field in which to indicate the outcome of the 513 request. When the PCE cannot find a feasible solution with the 514 initial request, the reason for failure SHOULD be indicated. This 515 requirement is partially covered by [RFC4657], but not in this 516 level of detail. The following indicators SHOULD be supported at 517 the minimum: 519 * no feasible solution found. Note that this is already covered 520 in [PCEP]. 522 * memory overflow 524 * PCE too busy. Note that this is already covered in [PCEP]. 526 * PCE not capable of concurrent reoptimization 527 * no migration path available 529 * administrative privileges do not allow global reoptimization 531 o In order to minimize disruption associated with bulk path 532 provisioning, the following requirements MUST be supported: 534 * The request message MUST allow requesting the PCE to provide 535 the order in which TE LSPs should be reoptimized (i.e., the 536 migration path) in order to minimize traffic disruption during 537 the migration. That is the request message MUST allow 538 indicating to the PCE that the set of paths that will be 539 provided in the response message (PCRep) has to be ordered. 541 * In response to the "ordering" request from the PCC, the PCE 542 MUST be able to indicate in the response message (PCRep) the 543 order in which TE LSPs should be reoptimized so as to minimize 544 traffic disruption. It should indicate for each request the 545 order in which the old TE LSP should be removed and the order 546 in which the new TE LSP should be setup. If the removal order 547 is lower than the setup order this means that make-before-break 548 cannot be done for this request. It MAY also be desirable to 549 have the PCE indicate whether ordering is in fact required or 550 not. 552 * During a migration it may not be possible to do a make-before- 553 break for all existing TE LSPs. The request message MUST allow 554 indicating for each request whether make-before-break is 555 required (e.g. Voice traffic) or break-before-make is 556 acceptable (e.g. Internet traffic). The response message must 557 allow indicating TE LSPs for which make-before-break 558 reoptimization is not possible (this will be deduced from the 559 TE LSP setup and deletion orders). 561 5. Protocol Extensions for Support of Global Concurrent Optimization 563 This section provides protocol extensions for support of global 564 concurrent optimization. Protocol extensions discussed in this 565 section are built on [PCEP]. 567 The format of a PCReq message after incorporating new requirements 568 for support of global concurrent optimization is as follows. The 569 message format uses Reduced Backus-Naur Format as defined in [RBNF]. 571 ::= 572 [] 573 575 The is changed as follows: 577 ::= 578 [] 579 [] 580 [] 581 [] 583 Note that three optional objects are added, following the SVEC 584 object: the OF (Objective Function) object, which is defined in 585 [PCE-OF], the GC (Global Constraints) object, which is defined in 586 this document (Section 5.5), as well as the eXclude Route Object 587 (XRO) which is defined in [PCE-XRO]. The placement of the OF object 588 (in which the global objective function is specified) in the SVEC- 589 list is defined in [PCE-OF]. Details of this change will be 590 discussed in the following sections. 592 Note also that when the XRO is global to a SVEC, and F bit is set, it 593 SHOULD be allowed to specify multiple Record Route Objects in the 594 PCReq message. 596 5.1. Global Objective Function (GOF) Specification 598 The global objective function can be specified in the PCEP Objective 599 Function (OF) object, defined in [PCE-OF]. The OF object includes a 600 16 bit Objective Function identifier. As per discussed in [PCE-OF], 601 objective function identifier code points are managed by IANA. 603 Three global objective functions defined in [PCE-OF] are used in the 604 context of GCO. 606 Function 607 Code Description 609 4 Minimize aggregate Bandwidth Consumption (MBC) 611 5 Minimize the load of the Most Loaded Link (MLL)* 613 6 Minimize Cumulative Cost of a set of paths (MCC) 615 * Note: This can be achieved by the following objective function: 616 minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the 617 link capacity for link i and A(i) is the total bandwidth allocated 618 on link i. 620 5.2. Indication of Global Concurrent Optimization Requests 622 All the path requests in this application should be indicated so that 623 the global objective function and all of the global constraints are 624 applied to each of the requested path computation. This can be 625 indicated implicitly by placing the GCO related objects (GOF, GC or 626 XRO) after the SVEC object. That is, if any of these objects follows 627 the SVEC object in the PCReq message, all of the requested path 628 computations specified in the SVEC object are subject to GOF, GC or 629 XRO. 631 5.3. Request for The Order of TE LSP 633 In order to minimize disruption associated with bulk path 634 provisioning, the PCC may indicate to the PCE that the response MUST 635 be ordered. That is, the PCE has to include the order in which TE 636 LSPs MUST be moved so as to minimize traffic disruption. To support 637 such indication a new flag, the D flag, is defined in the RP object 638 as follows: 640 D bit (orDer - 1 bit): when set, in a PCReq message, the requesting 641 PCC requires the PCE to specify in the PCRep message the order in 642 which this particular path request is to be provisioned relative to 643 other requests. 645 To support the determination of whether make-before-break 646 optimization is required, a new flag, the M flag, is defined in the 647 RP object as follows. 649 M bit (Make-before-break - 1 bit): when set, this indicates that a 650 make-before-break reoptimization is required for this request. 652 When M bit is not set, this implies that a break-before-make 653 reoptimization is allowed for this request. Note that M bit can be 654 set only if the R (Reoptimization) flag is set. 656 Two new bit flags are defined to be carried in the Flags field 657 in the RP Object. 659 Bit 22 (D-bit): When set, report of the request order is required. 660 Bit 21 (M-bit): When set, make-before-break is required. 662 5.4. The Order Response 664 The PCE MUST specify the order number in response to the Order 665 Request made by the PCC in the PCReq message if so requested by the 666 setting of the D bit in the RP object in the PCReq message. To 667 support such ordering indication a new optional TLV, the Order TLV, 668 is defined in the RP object. 670 The Order TLV is an optional TLV in the RP object, that indicates the 671 order in which the old TE LSP must be removed and the new TE LSP must 672 be setup during a reoptimization. It is carried in the PCRep message 673 in response to a reoptimization request. 675 The Order TLV MUST be included in the RP object in the PCRep message 676 if the D bit is set in the RP object in the PCReq message. 678 The format of the Order TLV is as follows: 680 0 1 2 3 681 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 682 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 683 | Type | Length | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 685 | Delete Order | 686 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 687 | Setup Order | 688 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 690 Figure 2: The Order TLV in the RP object in the PCRep Message 692 Type: To be defined by IANA (suggested value = 5) 693 Length: Variable 695 Delete Order: 32 bit integer that indicates the order in which the 696 old TE LSP should be removed 698 Setup Order: 32 bit integer that indicates the order in which the new 699 TE LSP should be setup 700 The delete order SHOULD NOT be equal to the setup order. If the 701 delete order is higher than the setup order, this means that the 702 reoptimization can be done in a make-before-break manner, else it 703 cannot be done in a make-before-break manner. 705 For a new TE LSP the delete order is not applicable. The value 0 is 706 designated to specify this case. When the value of the delete order 707 is 0, it implies that the resulting TE LSP is a new TE LSP. 709 To illustrate this, consider a network with two established TE LSPs: 710 R1 with path P1 and R2 with path P2. During a reoptimization the PCE 711 may provide the following ordered reply: 713 R1, path P1', remove order 1, setup order 4 714 R2, path P2', remove order 3, setup order 2 716 This indicates that the NMS should do the following sequence of 717 tasks: 719 1: Remove path P1 720 2: Setup path P2' 721 3: Remove path P2 722 4: Setup path P1' 724 That is, R1 is reoptimized in a break-before-make manner and R2 in a 725 make-before-break manner. 727 5.5. GLOBAL CONSTRAINTS (GC) Object 729 The GLOBAL CONSTRAINTS (GC) Object is used in a PCReq message to 730 specify the necessary global constraints that should be applied to 731 all individual path computations for a global concurrent path 732 optimization request. 734 GLOBAL CONSTRAINTS Object-Class is to be assigned by IANA 735 (recommended value=24) 737 GLOBAL CONSTRAINTS Object-Type is to be assigned by IANA (recommended 738 value=1) 740 The format of the GC object body that includes the global constraints 741 is as follows: 743 0 1 2 3 744 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 2 745 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 746 | MH | MU | mU | OB | 747 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 748 | | 749 // Optional TLV(s) // 750 | | 751 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 753 Figure 3: GC body object format 755 MH (Max Hop: 8 bits): 8 bit integer that indicates the maximum hop 756 count for all the TE LSPs. 758 MU (Max Utilization Percentage: 8 bits) : 8 bits integer that 759 indicates the upper bound utilization percentage by which all link 760 should be bound. Utilization = (Link Capacity - Allocated Bandwidth 761 on the Link)/ Link Capacity 763 mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that 764 indicates the lower bound utilization percentage by which all link 765 should be bound. 767 OB (Over Booking factor Percentage: 8 bits) : 8 bits integer that 768 indicates the overbooking percentage that allows the reserved 769 bandwidth to be overbooked on each link beyond its physical capacity 770 limit. The value, for example, 10% means that 110 Mbps can be 771 reserved on a 100Mbps link. 773 Reserved bits (24 bits) of the GLOBAL CONSTRAINTS Object SHOULD be 774 transmitted as zero and SHOULD be ignored upon receipt. 776 The exclusion of the list of nodes/links from a global path 777 computation can be done by including the XRO object following the GC 778 object in the new SVEC list definition. 780 Optional TLVs may be included within the GC object body to specify 781 additional global constraints. The TLV format and processing is 782 consistent with Section 7.1 of RFC5440. Any TLVs will be allocated 783 from the "PCEP TLV Type Indicators" registry. Note that no TLVs are 784 defined in this document. 786 5.6. Error Indicator 788 To indicate errors associated with the global concurrent path 789 optimization request, a new Error-Type (14) and subsequent error- 790 values are defined as follows for inclusion in the PCEP-ERROR object: 792 A new Error-Type (15) and subsequent error-values are defined as 793 follows: 795 Error-Type=15 and Error-Value=1: if a PCE receives a global 796 concurrent path optimization request and the PCE is not capable of 797 processing the request due to insufficient memory, the PCE MUST send 798 a PCErr message with a PCEP ERROR object (Error-Type=15) and an 799 Error-Value (Error-Value=1). The PCE stops processing the request. 800 The corresponding global concurrent path optimization request MUST be 801 cancelled at the PCC. 803 Error-Type=15; Error-Value=2: if a PCE receives a global concurrent 804 path optimization request and the PCE is not capable of global 805 concurrent optimization, the PCE MUST send a PCErr message with a 806 PCEP-ERROR Object (Error-Type=15) and an Error-Value (Error-Value=2). 807 The PCE stops processing the request. The corresponding global 808 concurrent path optimization MUST be cancelled at the PCC. 810 To indicate an error associated with policy violation, a new error 811 value "global concurrent optimization not allowed" should be added to 812 an existing error code for policy violation (Error-Type=5) as defined 813 in [RFC5440]. 815 Error-Type=5; Error-Value=5: if a PCE receives a global concurrent 816 path optimization request which is not compliant with administrative 817 privileges (i.e., the PCE policy does not support global concurrent 818 optimization), the PCE sends a PCErr message with a PCEP-ERROR Object 819 (Error-Type=5) and an Error-Value (Error-Value=5). The PCE stops the 820 processing the request. The corresponding global concurrent path 821 computation MUST be cancelled at the PCC. 823 5.7. NO-PATH Indicator 825 To communicate the reason(s) for not being able to find global 826 concurrent path computation, the NO-PATH object can be used in the 827 PCRep message. The format of the NO-PATH object body is defined in 828 [RFC5440]. The object may contain a NO-PATH-VECTOR TLV to provide 829 additional information about why a path computation has failed. 831 Two new bit flags are defined to be carried in the Flags field in the 832 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 834 Bit 6: When set, the PCE indicates that no migration path was found. 836 Bit 7: When set, the PCE indicates no feasible solution was found 837 that meets all the constraints associated with global concurrent path 838 optimization in the PCRep message. 840 6. Manageability Considerations 842 Manageability of Global Concurrent Path Computation with PCE must 843 address the following considerations: 845 6.1. Control of Function and Policy 847 In addition to the parameters already listed in Section 8.1 of 848 [RFC5440], a PCEP implementation SHOULD allow configuring the following 849 PCEP session parameters on a PCC: 851 o The ability to send a GCO request. 853 In addition to the parameters already listed in Section 8.1 of 854 [RFC5440], a PCEP implementation SHOULD allow configuring the following 855 PCEP session parameters on a PCE: 857 o The support for Global Concurrent Optimization. 859 o The maximum number of synchronized path requests per request 860 message. 862 o A set of GCO specific policies (authorized sender, request rate 863 limiter, etc). 865 These parameters may be configured as default parameters for any PCEP 866 session the PCEP speaker participates in, or may apply to a specific 867 session with a given PCEP peer or a specific group of sessions with a 868 specific group of PCEP peers. 870 6.2. Information and Data Models, e.g. MIB module 872 Extensions to the PCEP MIB module defined in [PCEP-MIB] should be 873 defined, so as to cover the GCO information introduced in this 874 document. 876 6.3. Liveness Detection and Monitoring 878 Mechanisms defined in this document do not imply any new liveness 879 detection and monitoring requirements in addition to those already 880 listed in Section 8.3 of [RFC5440]. 882 6.4. Verifying Correct Operation 884 Mechanisms defined in this document do not imply any new verification 885 requirements in addition to those already listed in Section 8.4 of 886 [RFC5440] 888 6.5. Requirements on Other Protocols and Functional Components 890 The PCE Discovery mechanisms ([RFC5088] and [RFC5089]) may be used 891 to advertise global concurrent path computation capabilities to PCCs. 892 A New Flag (value=9) in PCE-CAP-FLAGs Sub-TLV should be assigned to 893 be able to indicate GCO capability. 895 6.6. Impact on Network Operation 897 Mechanisms defined in this document do not imply any new network 898 operation requirements in addition to those already listed in Section 899 8.6 of [RFC5440]. 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 [RFC5440] 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 IANA maintains a registry of PCEP parameters. IANA is requested to 923 make allocations from the sub-registries as described in the 924 following sections. 926 9.1. Request Parameter Bit Flags 928 As described in Section 5.3, two new bit flags are defined for 929 inclusion in the Flags field of the RP object. IANA is requested to 930 make the following allocations from the "Request Parameter Bit Flags" 931 sub-registry. 933 Bit Name Description Reference 935 22 D-bit Report the request order [This.I-D] 936 21 M-bit Make-before-break [This.I-D] 938 9.2. New PCEP TLV 940 As described in Section 5.4, a new PCEP TLV is defined to indicate 941 the setup and delete order of TE LSPs in a GCO. IANA is requested to 942 make the following allocation from the "PCEP TLV Types" sub-registry. 944 TLV Type Meaning Reference 946 5 Order TLV [This.I-D] 948 9.3. New Flag in PCE-CAP-FLAGS Sub-TLV in PCED 950 As described in Section 6.5, a new PCE-CAP-FLAGS Sub-TLV is 951 defined to indicate a GCO capability. IANA is requested to make the 952 following allocation from the "PCE-CAP-FLAGS TLV Types" sub-registry. 953 The "PCE Capability Flags Registry" is created by section 7.2 of 954 RFC 5088. It is an OSPF registry. 956 FLAG Meaning Reference 958 9 Global Concurrent Optimization (GCO)[This.I-D] 960 9.4. New PCEP Object 962 As descried in Section 5.5, a new PCEP object is defined to carry 963 global constraints. IANA is requested to make the following 964 allocation from the "PCEP Objects" sub-registry. 966 Object Name Reference 967 Class 969 24 GLOBAL-CONSTRAINTS [This.I-D] 970 Object-Type 971 1: Global Constraints [This.I-D] 973 9.5. New PCEP Error Codes 975 As described in Section 5.6, new PCEP error codes are defined for GCO 976 errors. IANA is requested to make allocations from the "PCEP Error 977 Types and Values" sub-registry as set out in the following sections. 979 9.5.1. New Error-Values for Existing Error-Types 981 Error 982 Type Meaning Reference 984 5 Policy violation 985 Error-value=5: [This.I-D] 986 Global concurrent optimization not allowed 988 9.5.2. New Error-Types and Error-Values 990 Error 991 Type Meaning Reference 993 15 Global Concurrent Optimization Error [This.I-D] 994 Error-value=1: 995 Insufficient memory [This.I-D] 996 Error-value=2: 997 Global concurrent optimization not supported 998 [This.I-D] 1000 9.6. New No-Path Reasons 1002 IANA is requested to make the following allocations from the "No-Path 1003 Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV 1004 in the PCEP NO-PATH object as described in Section 5.7. 1006 Bit 1007 Number Name Reference 1009 26 No GCO migration path found [This.I-D] 1010 25 No GCO solution found [This.I-D] 1012 10. References 1014 10.1. Normative References 1016 [BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based 1017 Computation (BRPC) procedure to compute shortest inter- 1018 domain Traffic Engineering Label Switched Paths, 1019 draft-ietf-pce-brpc, work in progress". 1021 [PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 1022 Function encoding in Path Computation Element 1023 communication and discovery protocols, 1024 draft-ietf-pce-of, work in progress". 1026 [PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation 1027 Element Communication Protocol (PCEP) for Route 1028 Exclusions, draft-ietf-pce-pcep-xro, work in progress". 1030 [RFC5440] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1031 Element (PCE) communication Protocol (PCEP)", RFC 5440, 1032 March 2009. 1034 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1035 Requirement Levels", BCP 14, RFC 2119, March 1997. 1037 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1038 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1039 Tunnels", RFC 3209, December 2001. 1041 [RFC5088] Le Roux, J., Vasseur, J., Ikejiri, Y., and R. Zhang, "OSPF 1042 Protocol Extensions for Path Computation Element (PCE) 1043 Discovery", RFC 5088, January 2008. 1045 [RFC5089] Le Roux, J., Vasseur, J., Ikejiri, Y., and R. Zhang, 1046 "IS-IS Protocol Extensions for Path Computation Element 1047 (PCE) Discovery", RFC 5089, January 2008. 1049 10.2. Informative References 1051 [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- 1052 based inter-layer MPLS and GMPLS traffic engineering", 1053 draft-ietf-pce-inter-layer-frwk, work in progress. 1055 [PCEP-MIB] Stephen, E. and K. Koushik, "PCE communication 1056 protocol(PCEP) Management Information Base", 1057 draft-kkoushik-pce-pcep-mib, work in progress. 1059 [RBNF] A. Farrel, "Reduced Backus-Naur Form (RBNF) - A Syntax 1060 Used in Various Protocol Specifications", draft-farrel- 1061 rtg-common-bnf, work in progress. 1063 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1064 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1066 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 1067 Communication Protocol Generic Requirements", RFC 4657, 1068 September 2006. 1070 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 1071 (PCE) Discovery", RFC 4674, October 2006. 1073 [RFC5212] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- 1074 region and multi-layer networks (MRN/MLN)", RFC 5212, 1075 July 2008. 1077 Authors' Addresses 1079 Young Lee 1080 Huawei 1081 1700 Alma Drive, Suite 100 1082 Plano, TX 75075 1083 US 1085 Phone: +1 972 509 5599 x2240 1086 Fax: +1 469 229 5397 1087 Email: ylee@huawei.com 1089 JL Le Roux 1090 France Telecom 1091 2, Avenue Pierre-Marzin 1092 Lannion 22307 1093 FRANCE 1095 Email: jeanlouis.leroux@orange-ftgroup.com 1096 Daniel King 1097 Old Dog Consulting 1098 United Kingdom 1100 Phone: 1101 Fax: 1102 Email: daniel@olddog.co.uk 1104 Eiji Oki 1105 University of Electro-Communications 1106 1-5-1 Chofugaoka 1107 Chofu, Tokyo 182-8585 1108 JAPAN 1110 Email: oki@ice.uec.ac.jp 1112 Full Copyright Statement 1114 Copyright (c) 2009 IETF Trust and the persons identified as the 1115 document authors. All rights reserved. 1117 This document is subject to BCP 78 and the IETF Trust's Legal 1118 Provisions Relating to IETF Documents 1119 (http://trustee.ietf.org/license-info) in effect on the date of 1120 publication of this document. Please review these documents 1121 carefully, as they describe your rights and restrictions with respect 1122 to this document. 1124 ALL IETF Documents and the information contained herein are provided 1125 on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE 1126 REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE 1127 IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL 1128 WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY 1129 WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE 1130 ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS 1131 FOR A PARTICULAR PURPOSE. 1133 Intellectual Property 1135 The definitive version of an IETF Document is that published by, or 1136 under the auspices of, the IETF. Versions of IETF Documents that are 1137 published by third parties, including those that are translated into 1138 other languages, should not be considered to be definitive versions 1139 of IETF Documents. The definitive version of these Legal Provisions 1140 is that published by, or under the auspices of, the IETF. Versions of 1141 these Legal Provisions that are published by third parties, including 1142 those that are translated into other languages, should not be 1143 considered to be definitive versions of these Legal Provisions. 1145 For the avoidance of doubt, each Contributor to the IETF Standards 1146 Process licenses each Contribution that he or she makes as part of 1147 the IETF Standards Process to the IETF Trust pursuant to the 1148 provisions of RFC 5378. No language to the contrary, or terms, 1149 conditions or rights that differ from or are inconsistent with the 1150 rights and licenses granted under RFC 5378, shall have any effect and 1151 shall be null and void, whether published or posted by such 1152 Contributor, or included with or in such Contribution.