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