idnits 2.17.1 draft-ietf-pce-global-concurrent-optimization-04.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1121. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1132. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1139. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1145. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year == The document seems to use 'NOT RECOMMENDED' as an RFC 2119 keyword, but does not include the phrase in its RFC 2119 key words list. == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'SHOULD not' in this paragraph: The delete order SHOULD not be equal to the setup order. If the delete order is higher than the setup order, this means that the reoptimization can be done in a make-before-break manner, else it cannot be done in a make-before-break manner. -- 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 (July 14, 2008) is 5758 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: 'RFC 5088' is mentioned on line 901, but not defined == Missing Reference: 'RFC 5089' is mentioned on line 901, but not defined -- Possible downref: Normative reference to a draft: ref. 'PCE-OF' Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 8 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Lee 3 Internet-Draft Huawei 4 Intended status: Standards Track JL. Le Roux 5 Expires: January 15, 2009 France Telecom 6 D. King 7 Old Dog Consulting 8 E. Oki 9 NTT 10 July 14, 2008 12 Path Computation Element Communication Protocol (PCECP) Requirements and 13 Protocol Extensions In Support of Global Concurrent Optimization 14 draft-ietf-pce-global-concurrent-optimization-04.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on January 15, 2009. 41 Abstract 43 The Path Computation Element (PCE) is a network component, 44 application, or node that is capable of performing path computations 45 at the request of Path Computation Clients (PCCs). The PCE is 46 applied in Multiprotocol Label Switching Traffic Engineering 47 (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to 48 determine the routes of Label Switched Paths (LSPs) through the 49 network. In this context a PCC may be a Label Switching Router 50 (LSR), a Network Management System (NMS), or another PCE. The Path 51 Computation Element Communication Protocol (PCEP) is specified for 52 communications between PCCs and PCEs, and between cooperating PCEs. 54 When computing or re-optimizing the routes of a set of LSPs through a 55 network it may be advantageous to perform bulk path computations in 56 order to avoid blocking problems and to achieve more optimal network- 57 wide solutions. Such bulk optimization is termed Global Concurrent 58 Optimization (GCO). A GCO is able to simultaneously consider the 59 entire topology of the network and the complete set of existing LSPs, 60 and their respective constraints, and look to optimize or re-optimize 61 the entire network to satisfy all constraints for all LSPs. A GCO 62 may also be applied to some subset of the LSPs in a network. The GCO 63 application is primarily a Network Management System (NMS) solution. 65 While GCO is applicable to any simultaneous request for multiple LSPs 66 (for example, a request for end-to-end protection), it is not 67 invisaged 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 LSPs since the large 70 scope of the problem and the small benefit of concurrent 71 reoptimization relative to single LSP reoptimization is unlikely to 72 make the process worthwhile. Further, applying global concurrent 73 reoptimization in a network with a high rate of change of LSPs 74 (churn) is not advised because of the likelihood that LSPs would 75 change before they could be gloablly 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 . . . . . . . . . . . . . . . . . . . . . . 11 96 5. Protocol Extensions for Support of Global Concurrent 97 Optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 98 5.1. Global Objective Function (GOF) Specification . . . . . . 15 99 5.2. Indication of Global Concurrent Optimization Requests . . 16 100 5.3. Request for The Order of LSP . . . . . . . . . . . . . . . 16 101 5.4. The Order Response . . . . . . . . . . . . . . . . . . . . 17 102 5.5. GLOBAL CONSTRAINTS (GC) Object . . . . . . . . . . . . . . 18 103 5.6. Error Indicator . . . . . . . . . . . . . . . . . . . . . 19 104 5.7. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 20 105 6. Manageability Considerations . . . . . . . . . . . . . . . . . 21 106 6.1. Control of Function and Policy . . . . . . . . . . . . . . 21 107 6.2. Information and Data Models, e.g. MIB module . . . . . . . 21 108 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 21 109 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 21 110 6.5. Requirements on Other Protocols and Functional 111 Components . . . . . . . . . . . . . . . . . . . . . . . . 22 112 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 22 113 7. Security Considerations . . . . . . . . . . . . . . . . . . . 23 114 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 24 115 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 25 116 9.1. Request Parameter Bit Flags . . . . . . . . . . . . . . . 25 117 9.2. New PCEP TLV . . . . . . . . . . . . . . . . . . . . . . . 25 118 9.3. New PCEP Object . . . . . . . . . . . . . . . . . . . . . 25 119 9.4. New PCEP Error Codes . . . . . . . . . . . . . . . . . . . 26 120 9.4.1. New Error-Values for Existing Error-Types . . . . . . 26 121 9.4.2. New Error-Types and Error-Values . . . . . . . . . . . 26 122 9.5. New No-Path Reasons . . . . . . . . . . . . . . . . . . . 26 123 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 124 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 125 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 126 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 29 127 Intellectual Property and Copyright Statements . . . . . . . . . . 30 129 1. Introduction 131 [RFC4655] defines the Path Computation Element (PCE) based 132 Architecture and explains how a PCE may compute Label Switched Paths 133 (LSPs) in Multiprotocol Label Switching Traffic Engineering (MPLS-TE) 134 and Generalized MPLS (GMPLS) networks at the request of Path 135 Computation Clients (PCCs). A PCC is shown to be any network 136 component that makes such a request and may be for instance a Label 137 Switching Router (LSR) or a Network Management System (NMS). The 138 PCE, itself, is shown to be located anywhere within the network, and 139 may be within an LSR, an NMS or Operational Support System (OSS), or 140 may be an independent network server. 142 The PCE Communication Protocol (PCEP) is the communication protocol 143 used between PCC and PCE, and may also be used between cooperating 144 PCEs. [RFC4657] sets out generic protocol requirements for PCEP. 145 Additional application-specific requirements for PCEP are defined in 146 separate documents. 148 This document provides a set of requirements and PCEP extensions in 149 support of concurrent path computation applications. A concurrent 150 path computation is a path computation application where a set of TE 151 paths are computed concurrently in order to efficiently utilize 152 network resources. The computation method involved with a concurrent 153 path computation is referred to as global concurrent optimization in 154 this document. Appropriate computation algorithms to perform this 155 type of optimization are out of the scope of this document. 157 The Global Concurrent Optimization (GCO) application is primarily an 158 NMS or a PCE Server based solution. Owing to complex synchronization 159 issues associated with GCO applications, the management based PCE 160 architecture defined in section 5.5 of [RFC4655] is considered as the 161 most suitable usage to support GCO application. This does not 162 preclude other architectural alternatives to support GCO application, 163 but they are NOT RECOMMENDED. For instance, GCO might be enabled by 164 distributed LSRs through complex synchronization mechanisms. 165 However, this approach might suffer from significant synchronization 166 overhead between the PCE and each of the PCCs. It would likely 167 affect the network stability and hence significantly diminish the 168 benefits of deploying PCEs. 170 The need for global concurrent path computation may also arise when 171 network operators need to establish a set of TE LSPs in their network 172 planning process. It is also envisioned that network operators might 173 require global concurrent path computation in the event of 174 catastrophic network failures, where a set of TE LSPs need to be 175 optimally rerouted. The nature of this work promote the use of such 176 systems for offline processing. Online application of this work 177 should only be considered with proven empirical validation. 179 As new LSPs are added or removed from the network over time, the 180 global network resources become fragmented and the existing placement 181 of LSPs within network no longer provides optimal use of the 182 available capacity. A global concurrent path computation is able to 183 simultaneously consider the entire topology of the network and the 184 complete set of existing LSPs and their respective constraints, and 185 look to re-optimize the entire network to satisfy all constraints for 186 all LSPs. Alternatively, the application may consider a subset of 187 the LSPs and/or a subset of the network topology. 189 While GCO is applicable to any simultaneous request for multiple LSPs 190 (for example, a request for end-to-end protection), it is not 191 invisaged that global concurrent reoptimization would be applied in a 192 network (such as an MPLS-TE network) that contains a very large 193 number of very low bandwidth or zero bandwidth LSPs since the large 194 scope of the problem and the small benefit of concurrent 195 reoptimization relative to single LSP reoptimization is unlikely to 196 make the process worthwhile. Further, applying global concurrent 197 reoptimization in a network with a high rate of change of LSPs 198 (churn) is not advised because of the likelihood that LSPs would 199 change before they could be gloablly reoptimized. Global 200 reoptimization is more applicable to stable networks such as 201 transport networks or those with long-term TE LSP tunnels. 203 As the PCE has the potential to provide solutions in all path 204 computation solutions in a variety of environments and is a candidate 205 for performing path computations in support of GCO. 207 The main focus of this document is to highlight the PCC-PCE 208 communication needs in support of a concurrent path computation 209 applications and to define protocol extensions to meet those needs. 211 The PCC-PCE requirements addressed herein are specific to the context 212 where the PCE is a specialized PCE that is capable of performing 213 computations in support of GCO. Discovery of such capabilities might 214 be desirable and could be achieved through extensions to the PCE 215 discovery mechanisms [RFC4674], [RFC5088], [RFC5089], but that is out 216 of the scope of this document. 218 It is to be noted that Backward Recursive Path Computation (BRPC) 219 [BRPC] is a multi-PCE path computation technique used to compute a 220 shortest constrained inter-domain path wheres this ID specifies a 221 technique where a set of path computation requests are bundled and 222 send to a PCE with the objective of "optimizing" the set of computed 223 paths. 225 2. Terminology 227 Most of the terminology used in this document is explained in 228 [RFC4655]. A few key terms are repeated here for clarity. 230 PCC: Path Computation Client: Any client application requesting a 231 path computation to be performed by a Path Computation Element. 233 PCE: Path Computation Element: An entity (component, application or 234 network node) that is capable of computing a network path or route 235 based on a network graph and applying computational constraints. 237 TED: Traffic Engineering Database which contains the topology and 238 resource information of the domain. The TED may be fed by IGP 239 extensions or potentially by other means. 241 PCECP: The PCE Communication Protocol: PCECP is the generic abstract 242 idea of a protocol that is used to communicate path computation 243 requests a PCC to a PCE, and to return computed paths from the PCE to 244 the PCC. The PCECP can also be used between cooperating PCEs. 246 PCEP: The PCE communication Protocol: PCEP is the actual protocol 247 that implements the PCECP idea. 249 GCO: Global Concurrent Optimization: A concurrent path computation 250 application where a set of TE paths are computed concurrently in 251 order to efficiently utilize network resources. A GCO path 252 computation is able to simultaneously consider the entire topology of 253 the network and the complete set of existing LSPs, and their 254 respective constraints, and look to optimize or re-optimize the 255 entire network to satisfy all constraints for all LSPs. A GCO path 256 computation can also provide an optimal way to migrate from an 257 existing set of LSPs to a reoptimized set (Morphing Problem). 259 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 260 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 261 document are to be interpreted as described in RFC 2119 [RFC2119]. 262 These terms are also used in the parts of this document that specify 263 requirements for clarity of specification of those requirements. 265 3. Applicability of Global Concurrent Optimization (GCO) 267 This section discusses the PCE architecture to which GCO is applied. 268 It also discusses various application scenarios for which global 269 concurrent path computation may be applied. 271 3.1. Application of the PCE Architecture 273 Figure 1 shows the PCE-based network architecture as defined in 274 [RFC4655] to which GCO application is applied. It must be observed 275 that the PCC is not necessarily an LSR [RFC4655]. The GCO 276 application is primarily an NMS-based solution in which an NMS plays 277 the function of the PCC. Although Figure 1 shows the PCE as remote 278 from the NMS, it might be collocated with the NMS. Note that in the 279 collocated case there is no need for a standard communication 280 protocol; this can rely on internal APIs. 282 ----------- 283 Application | ----- | 284 Request | | TED | | 285 | | ----- | 286 v | | | 287 ------------- Request/ | v | 288 | PCC | Response| ----- | 289 | (NMS/Server)|<--------+> | PCE | | 290 | | | ----- | 291 ------------- ----------- 292 Service | 293 Request | 294 v 295 ---------- Signaling ---------- 296 | Head-End | Protocol | Adjacent | 297 | Node |<---------->| Node | 298 ---------- ---------- 300 Figure 1: PCE-Based Architecture for Global Concurrent Optimization 302 Upon receipt of an application request (e.g., a traffic demand matrix 303 is provided to the NMS by the operator's network planning procedure), 304 the NMS requests a global concurrent path computation from the PCE. 305 The PCE then computes the requested paths concurrently applying some 306 algorithms. Various algorithms and computation techniques have been 307 proposed to perform this function. Specification of such algorithms 308 or techniques is outside the scope of this document. 310 When the requested path computation completes, the PCE sends the 311 resulting paths back to the NMS. The NMS then supplies the head-end 312 LSRs with a fully computed explicit path for each TE LSP that needs 313 to be established. 315 3.2. Greenfield Optimization 317 Greenfield optimization is a special case of GCO application when 318 there are no LSPs already set up in the network. The need for 319 greenfield optimization arises when network planner wants to make use 320 of a computation server to plan the LSPs that will be provisioned in 321 the network. 323 When a new TE network needs to be provisioned from a greenfield 324 perspective, a set of TE LSPs needs to be created based on traffic 325 demand, network topology, service constraints, and network resources. 326 In this scenario, the ability to perform concurrent computation is 327 desirable, or required, to utilize network resources in an optimal 328 manner and avoid blocking. 330 3.2.1. Single-layer Traffic Engineering 332 Greenfield optimization can be applied when layer-specific TE LSPs 333 need to be created from a greenfield perspective. For example, an 334 MPLS-TE network can be planned based on layer 3 specific traffic 335 demands, the network topology, and available network resources. 336 Greenfield optimization for single-layer traffic engineering can be 337 applied to optical transport networks such as SDH/Sonet, Ethernet 338 Transport, WDM, etc. 340 3.2.2. Multi-layer Traffic Engineering 342 Greenfield optimization is not limited to single-layer traffic 343 engineering. It can also be applied to multi-layer traffic 344 engineering [PCE-MLN]. Both the client and the server layers network 345 resources and topology can be considered simultaneously in setting up 346 a set of TE LSPs that traverse the layer boundary. 348 3.3. Re-optimization of Existing Networks 350 The need for global concurrent path computation may arise in existing 351 networks. When an existing TE LSP network experiences sub-optimal 352 use of its resources, the need for re-optimization or reconfiguration 353 may arise. The scope of re-optimization and reconfiguration may vary 354 depending on particular situations. The scope of re-optimization may 355 be limited to bandwidth modification to an existing TE LSP. However, 356 it could well be that a set of TE LSPs may need to be re-optimized 357 concurrently. In an extreme case, the TE LSPs may need to be 358 globally re-optimized. 360 In loaded networks, with large size LSPs, a sequential re- 361 optimization may not produce substantial improvements in terms of 362 overall network optimization. Sequential re-optimization refers to a 363 path computation method in which to compute the re-optimized path of 364 one LSP at a time without giving any consideration to the other LSPs 365 that need to be re-optimized in the network. The potential for 366 network-wide gains from reoptimization of LSPs sequentially is 367 dependent upon the network usage and size of the LSPs being 368 optimized. However, the key point remains: computing the reoptimized 369 path of one LSP at a time without giving any consideration to the 370 other LSPs in the network could result in sub-optimal use of network 371 resources. This may be far more visible in an optical network with a 372 low ratio of potential LSPs per link, and far less visible in packet 373 networks with micro-flow LSPs. 375 With regards to applicability of GCO in the event of catastrophic 376 failures, there may be a real benefit in computing the paths of the 377 LSPs as a set rather than computing new paths from the head-end LSRs 378 in a distributed manner. GCO could prevent race condition (i.e., 379 competing for the same resource from different head-end LSRs) that 380 may be associated with a distributed computation. However, a 381 centralized system will typically suffer from a slower response time 382 than a distributed system. 384 3.3.1. Reconfiguration of the Virtual Network Topology (VNT) 386 Reconfiguration of the VNT [MLN-REQ] [PCE-MLN] is a typical 387 application scenario where global concurrent path computation may be 388 applicable. Triggers for VNT reconfiguration, such as traffic demand 389 changes, network failures, and topological configuration changes, may 390 require a set of existing LSPs to be re-computed. 392 3.3.2. Traffic Migration 394 When migrating from one set of TE LSPs to a reoptimized set of TE 395 LSPs it is important that the traffic be moved without causing 396 disruption. Various techniques exist in MPLS and GMPLS, such as 397 make-before-break [RFC3209], to establish the new LSPs before tearing 398 down the old LSPs. When multiple LSP routes are changed according to 399 the computed results, some of the LSPs may be disrupted due to the 400 resource constraints. In other words, it may prove to be impossible 401 to perform a direct migration from the old LSPs to the new optimal 402 LSPs without disrupting traffic because there are insufficient 403 network resources to support both sets of LSPs when make-before-break 404 is used. However, a PCE may be able to determine a sequence of make- 405 before- break replacement of individual LSPs or small sets of LSPs so 406 that the full set of LSPs can be migrated without any disruption. 408 It may be the case that the reoptimization is radical. This could 409 mean that it is not possible to apply make-before-break in any order 410 to migrate from the old LSPs to the new LSPs. In this case a 411 migration strategy is required that may necessitate LSPs being 412 rerouted using make-before-break onto temporary paths in order to 413 make space for the full reoptimization. A PCE might indicate the 414 order in which reoptimized LSPs must be established and take over 415 from the old LSPs, and may indicate a series of different temporary 416 paths that must be used. Alternatively, the PCE might perform the 417 global reoptimization as a series of sub-reoptimizations by 418 reoptimizing subsets of the total set of LSPs. 420 The benefit of this multi-step rerouting includes minimization of 421 traffic discruption and optimization gain. However this approach may 422 imply some transient packets desequencing, jitter as well as control 423 plane stress. 425 Note also that during reoptimization, traffic disruption may be 426 allowed for some LSPs carrying low priority services (e.g., Internet 427 traffic) and not allowed for some LSPs carrying mission critical 428 services (e.g., voice traffic). 430 4. PCECP Requirements 432 This section provides the PCECP requirements to support global 433 concurrent path computation applications. The requirements specified 434 here should be regarded as application-specific requirements and are 435 justifiable based on the extensibility clause found in section 6.1.14 436 of [RFC4657]: 438 The PCECP MUST support the requirements specified in the 439 application-specific requirements documents. The PCECP MUST also 440 allow extensions as more PCE applications will be introduced in 441 the future. 443 It is also to be noted that some of the requirements discussed in 444 this section have already been discussed in the PCECP requirement 445 document [RFC4657]. For example, Section 5.1.16 in [RFC4657] 446 provides a list of generic constraints while Section 5.1.17 in 447 [RFC4657] provides a list of generic objective functions that MUST be 448 supported by the PCECP. While using such generic requirements as the 449 baseline, this section provides application-specific requirements in 450 the context of global concurrent path computation and in a more 451 detailed level than the generic requirements. 453 The PCEP SHOULD support the following capabilities either via 454 creation of new objects and/or modification of existing objects where 455 applicable. 457 o An indicator to convey that the request is for a global concurrent 458 path computation. This indicator is necessary to ensure 459 consistency in applying global objectives and global constraints 460 in all path computations. Note: This requirement is covered by 461 "synchronized path computation" in [RFC4655] and [RFC4657]. 462 However, an explicit indicator to request a global concurrent 463 optimization is a new requirement. 465 o A Global Objective Function (GOF) field in which to specify the 466 global objective function. The global objective function is the 467 overarching objective function to which all individual path 468 computation requests are subjected in order to find a globally 469 optimal solution. Note that this requirement is covered by 470 "synchronized objective functions" in section 5.1.7 [RFC4657] and 471 that [PCE-OF] defined three global objective functions as follows. 472 A list of available global objective functions SHOULD include the 473 following objective functions at the minimum and SHOULD be 474 expandable for future addition: 476 * Minimize aggregate Bandwidth Consumption (MBC) 477 * Minimize the load of the Most Loaded Link (MLL) 479 * Minimize Cumulative Cost of a set of paths (MCC) 481 o A Global Constraints (GC) field in which to specify the list of 482 global constraints to which all the requested path computations 483 should be subjected. This list SHOULD include the following 484 constraints at the minimum and SHOULD be expandable for future 485 addition: 487 * Maximum link utilization value -- This value indicates the 488 highest possible link utilization percentage set for each link. 489 (Note: to avoid floating point numbers, the values should be 490 integer values.) 492 * Minimum link utilization value -- This value indicates the 493 lowest possible link utilization percentage set for each link. 494 (Note: same as above) 496 * Overbooking Factor -- The overbooking factor allows the 497 reserved bandwidth to be overbooked on each link beyond its 498 physical capacity limit. 500 * Maximum number of hops for all the LSPs -- This is the largest 501 number of hops that any LSP can have. Note that this 502 constraint can also be provided on a per LSP basis (as 503 requested in [RFC4657] and defined in [PCEP]). 505 * Exclusion of links/nodes in all LSP path computation (i.e., all 506 LSPs should not include the specified links/nodes in their 507 paths). Note that this constraint can also be provided on a 508 per LSP basis (as requested in [RFC4657] and defined in 509 [PCEP]). 511 * An indication should be available in a path computation 512 response that further reoptimization may only become available 513 once existing traffic has been moved to the new LSPs. 515 o A Global Concurrent Vector (GCV) field in which to specify all the 516 individual path computation requests that are subject to 517 concurrent path computation and subject to the global objective 518 function and all of the global constraints. Note that this 519 requirement is entirely fulfilled by the SVEC object in the PCEP 520 specification [PCEP]. Since the SVEC object as defined in [PCEP] 521 allows identifying a set of concurrent path requests, the SVEC can 522 be reused to specify all the individual concurrent path requests 523 for a global concurrent optimization. 525 o An indicator field in which to indicate the outcome of the 526 request. When the PCE cannot find a feasible solution with the 527 initial request, the reason for failure SHOULD be indicated. This 528 requirement is partially covered by [RFC4657], but not in this 529 level of detail. The following indicators SHOULD be supported at 530 the minimum: 532 * no feasible solution found. Note that this is already covered 533 in [PCEP]. 535 * memory overflow 537 * PCE too busy. Note that this is already covered in [PCEP]. 539 * PCE not capable of concurrent reoptimization 541 * no migration path available 543 * administrative privileges do not allow global reoptimization 545 o In order to minimize disruption associated with bulk path 546 provisioning, the following requirements MUST be supported: 548 * The request message MUST allow requesting the PCE to provide 549 the order in which LSPs should be reoptimized (i.e., the 550 migration path) in order to minimize traffic disruption during 551 the migration. That is the request message MUST allow 552 indicating to the PCE that the set of paths that will be 553 provided in the response message (PCRep) has to be ordered. 555 * In response to the "ordering" request from the PCC, the PCE 556 MUST be able to indicate in the response message (PCRep) the 557 order in which LSPs should be reoptimized so as to minimize 558 traffic disruption. It should indicate for each request the 559 order in which the old LSP should be removed and the order in 560 which the new LSP should be setup. If the removal order is 561 lower than the setup order this means that make-before-break 562 cannot be done for this request. It MAY also be desirable to 563 have the PCE indicate whether ordering is in fact required or 564 not. 566 * As stated in RFC 4657, the request for a reoptimization MUST 567 support the inclusion of the set of previously computed paths 568 along with their bandwidth. This is to avoid double bandwidth 569 accounting and also this allows running an algorithm that 570 minimizes perturbation and that can compute a migration path 571 (LSP setup/removal orders). This is particularly required for 572 stateless PCEs. 574 * During a migration it may not be possible to do a make-before- 575 break for all existing 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 LSPs for which make-before-break 580 reoptimization is not possible (this will be deduced from the 581 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: 592 ::= 593 [] 594 596 The is changed as follows: 598 :: = 599 [] 600 [] 601 [] 602 [] 604 Note that three optional objects are added, following the SVEC 605 object: the OF (Objective Function) object, which is defined in 606 [PCE-OF], the GC (Global Constraints) object, which is defined in 607 this document (section 5.5), as well as the eXclude Route Object 608 (XRO) which is defined in [PCE-XRO]. The placement of the OF object 609 (in which the global objective function is specified) in the SVEC- 610 list is defined in [PCE-OF]. Details of this change will be 611 discussed in the following sections. 613 Note also that when the XRO is global to a SVEC, and F bit is set, it 614 SHOULD be allowed to specify multiple Reported Route Objects (RROs) 615 in the PCReq message. 617 5.1. Global Objective Function (GOF) Specification 619 The global objective function can be specified in the PCEP Objective 620 Function (OF) object, defined in [PCE-OF]. The OF object includes a 621 16 bit Objective Function identifier. As per discussed in [PCE-OF], 622 objective function identifier code points are managed by IANA. 624 Three global objective functions defined in [PCE-OF] are used in the 625 context of GCO. 627 Function 628 Code Description 630 4 Minimize aggregate Bandwidth Consumption (MBC) 632 5 Minimize the load of the Most Loaded Link (MLL)* 634 6 Minimize Cumulative Cost of a set of paths (MCC) 636 * Note: This can be achieved by the following objective function: 637 minimize max over all links {(C(i)-A(i))/C(i)} where C(i) is the link 638 capacity for link i and A(i) is the total bandwidth allocated on link 639 i. 641 5.2. Indication of Global Concurrent Optimization Requests 643 All the path requests in this application should be indicated so that 644 the global objective function and all of the global constraints are 645 applied to each of the requested path computation. This can be 646 indicated implicitly by placing the GCO related objects (GOF, GC or 647 XRO) after the SVEC object. That is, if any of these objects follows 648 the SVEC object in the PCReq message, all of the requested path 649 computations specified in the SVEC object are subject to GOF, GC or 650 XRO. 652 5.3. Request for The Order of LSP 654 In order to minimize disruption associated with bulk path 655 provisioning, the PCC may indicate to the PCE that the response MUST 656 be ordered. That is, the PCE has to include the order in which LSPs 657 MUST be moved so as to minimize traffic disruption. To support such 658 indication a new flag, the D flag, is defined in the RP object as 659 follows: 661 D bit (orDer - 1 bit): when set, in a PCReq message, the requesting 662 PCC requires the PCE to specify in the PCRep message the order in 663 which this particular path request is to be provisioned relative to 664 other requests. 666 To support the determination of whether make-before-break 667 optimization is required, a new flag, the M flag, is defined in the 668 RP object as follows. 670 M bit (Make-before-break - 1 bit): when set, this indicates that a 671 make-before-break reoptimization is required for this request. 673 When M bit is not set, this implies that a break-before-make 674 reoptimization is allowed for this request. Note that M bit can be 675 set only if the R (Reoptimization) flag is set. 677 5.4. The Order Response 679 The PCE MUST specify the order number in response to the Order 680 Request made by the PCC in the PCReq message if so requested by the 681 setting of the D bit in the RP object in the PCReq message. To 682 support such ordering indication a new optional TLV, the Order TLV, 683 is defined in the RP object. 685 The Order TLV is an optional TLV in the RP object, that indicates the 686 order in which the old LSP must be removed and the new LSP must be 687 setup during a reoptimization. It is carried in the PCRep message in 688 response to a reoptimization request. 690 The Order TLV SHOULD be included in the RP object in the PCRep 691 message if the D bit is set in the RP object in the PCReq message. 693 The format of the Order TLV is as follows: 695 0 1 2 3 696 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 697 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 698 | Type | Length | 699 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 700 | Delete Order | 701 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 702 | Setup Order | 703 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 705 Figure 2: The Order TLV in the RP object in the PCRep Message 707 Type: To be defined by IANA (suggested value = 5) 709 Length: Variable 711 Delete Order: 32 bit integer that indicates the order in which the 712 old LSP should be removed 714 Setup Order: 32 bit integer that indicates the order in which the new 715 LSP should be setup 717 The delete order SHOULD not be equal to the setup order. If the 718 delete order is higher than the setup order, this means that the 719 reoptimization can be done in a make-before-break manner, else it 720 cannot be done in a make-before-break manner. 722 For a new LSP the delete order is not applicable. The value 0 is 723 designated to specify this case. When the value of the delete order 724 is 0, it implies that the resulting LSP is a new LSP. 726 To illustrate this, consider a network with two established LSPs: R1 727 with path P1 and R2 with path P2. During a reoptimization the PCE 728 may provide the following ordered reply: 730 R1, path P1', remove order 1, setup order 4 731 R2, path P2', remove order 3, setup order 2 733 This indicates that the NMS should do the following sequence of 734 tasks: 736 1: Remove path P1 737 2: Setup path P2' 738 3: Remove path P2 739 4: Setup path P1' 741 That is, R1 is reoptimized in a break-before-make manner and R2 in a 742 make-before-break manner. 744 5.5. GLOBAL CONSTRAINTS (GC) Object 746 The GLOBAL CONSTRAINTS (GC) Object is used in a PCReq message to 747 specify the necessary global constraints that should be applied to 748 all individual path computations for a global concurrent path 749 optimization request. 751 GLOBAL CONSTRAINTS Object-Class is to be assigned by IANA 752 (recommended value=24) 754 GLOBAL CONSTRAINTS Object-Type is to be assigned by IANA (recommended 755 value=1) 757 The format of the GC object body that includes the global constraints 758 is as follows: 760 0 1 2 3 761 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 762 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 763 | MH | MU | mU | OB | 764 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 765 | | 766 // Optional TLV(s) // 767 | | 768 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 770 Figure 3: GC body object format 772 MH (Max Hop: 8 bits): 8 bit integer that indicates the maximum hop 773 count for all the LSPs. 775 MU (Max Utilization Percentage: 8 bits) : 8 bits integer that 776 indicates the upper bound utilization percentage by which all link 777 should be bound. Utilization = (Link Capacity - Allocated Bandwidth 778 on the Link)/ Link Capacity 780 mU (minimum Utilization Percentage: 8 bits) : 8 bits integer that 781 indicates the lower bound utilization percentage by which all link 782 should be bound. 784 OB (Over Booking factor Percentage: 8 bits) : 8 bits integer that 785 indicates the overbooking percentage that allows the reserved 786 bandwidth to be overbooked on each link beyond its physical capacity 787 limit. The value, for example, 10% means that 110 Mbps can be 788 reserved on a 100Mbps link. 790 Reserved bits (24 bits) of the GLOBAL CONSTRAINTS Object SHOULD be 791 transmitted as zero and SHOULD be ignored upon receipt. 793 The exclusion of the list of nodes/links from a global path 794 computation can be done by including the XRO object following the GC 795 object in the new SVEC list definition. 797 5.6. Error Indicator 799 To indicate errors associated with the global concurrent path 800 optimization request, a new Error-Type (14) and subsequent error- 801 values are defined as follows for inclusion in the PCEP-ERROR object: 803 A new Error-Type (15) and subsequent error-values are defined as 804 follows: 806 Error-Type=15 and Error-Value=1: if a PCE receives a global 807 concurrent path optimization request and the PCE is not capable of 808 processing the request due to insufficient memory, the PCE MUST send 809 a PCErr message with a PCEP ERROR object (Error-Type=15) and an 810 Error-Value (Error-Value=1). The PCE stops processing the request. 811 The corresponding global concurrent path optimization request MUST be 812 cancelled at the PCC. 814 Error-Type=15; Error-Value=2: if a PCE receives a global concurrent 815 path optimization request and the PCE is not capable of global 816 concurrent optimization, the PCE MUST send a PCErr message with a 817 PCEP-ERROR Object (Error-Type=15) and an Error-Value (Error-Value=2). 818 The PCE stops processing the request. The corresponding global 819 concurrent path optimization MUST be cancelled at the PCC. 821 To indicate an error associated with policy violation, a new error 822 value "global concurrent optimization not allowed" should be added to 823 an existing error code for policy violation (Error-Type=5) as defined 824 in [PCEP]. 826 Error-Type=5; Error-Value=5: if a PCE receives a global concurrent 827 path optimization request which is not compliant with administrative 828 privileges (i.e., the PCE policy does not support global concurrent 829 optimization), the PCE sends a PCErr message with a PCEP-ERROR Object 830 (Error-Type=5) and an Error-Value (Error-Value=5). The PCE stops the 831 processing the request. The corresponding global concurrent path 832 computation MUST be cancelled at the PCC. 834 5.7. NO-PATH Indicator 836 To communicate the reason(s) for not being able to find global 837 concurrent path computation, the NO-PATH object can be used in the 838 PCRep message. The format of the NO-PATH object body is defined in 839 [PCEP]. The object may contain a NO-PATH-VECTOR TLV to provide 840 additional information about why a path computation has failed. 842 Two new bit flags are defined to be carried in the Flags field in the 843 NO-PATH-VECTOR TLV carried in the NO-PATH Object. 845 Bit 6: When set, the PCE indicates that no migration path was found. 847 Bit 7: When set, the PCE indicates no feasible solution was found 848 that meets all the constraints associated with global concurrent path 849 optimization in the PCRep message. 851 6. Manageability Considerations 853 Manageability of Global Concurrent Path Computation with PCE must 854 address the following considerations: 856 6.1. Control of Function and Policy 858 In addition to the parameters already listed in section 8.1 of 859 [PCEP], a PCEP implementation SHOULD allow configuring the following 860 PCEP session parameters on a PCC: 862 o The ability to send a GCO request. 864 In addition to the parameters already listed in section 8.1 of 865 [PCEP], a PCEP implementation SHOULD allow configuring the following 866 PCEP session parameters on a PCE: 868 o The support for Global Concurrent Optimization. 870 o The maximum number of synchronized path requests per request 871 message. 873 o A set of GCO specific policies (authorized sender, request rate 874 limiter, etc). 876 These parameters may be configured as default parameters for any PCEP 877 session the PCEP speaker participates in, or may apply to a specific 878 session with a given PCEP peer or a specific group of sessions with a 879 specific group of PCEP peers. 881 6.2. Information and Data Models, e.g. MIB module 883 Extensions to the PCEP MIB module defined in [PCEP-MIB] should be 884 defined, so as to cover the GCO information introduced in this 885 document. 887 6.3. Liveness Detection and Monitoring 889 Mechanisms defined in this draft does not imply any new liveness 890 detection and monitoring requirements in addition to those already 891 listed in section 8.3 of [PCEP]. 893 6.4. Verifying Correct Operation 895 Mechanisms defined in this draft do not imply any new verification 896 requirements in addition to those already listed in section 8.4 of 897 [PCEP] 899 6.5. Requirements on Other Protocols and Functional Components 901 The PCE Discovery mechanisms ([RFC 5088] and [RFC 5089]) may be used 902 to advertise global concurrent path computation capabilities to PCCs. 904 6.6. Impact on Network Operation 906 Mechanisms defined in this draft do not imply any new network 907 operation requirements in addition to those already listed in section 908 8.6 of [PCEP]. 910 7. Security Considerations 912 When global re-optimization is applied to an active network, it could 913 be extremely disruptive. Although the real security and policy 914 issues apply at the NMS, if the wrong results are returned to the 915 NMS, the wrong actions may be taken in the network. Therefore, it is 916 very important that the operator issuing the commands has sufficient 917 authority and is authenticated, and that the computation request is 918 subject to appropriate policy. 920 The mechanism defined in [PCEP] to secure a PCEP session can be used 921 to secure global concurrent path computation requests/responses. 923 8. Acknowledgements 925 We would like to thank Jerry Ash, Adrian Farrel, J-P Vasseur, Ning 926 So, Lucy Yong and Fabien Verhaeghe for their useful comments and 927 suggestions. 929 9. IANA Considerations 931 IANA maintains a registry of PCEP parameters. IANA is requested to 932 make allocations from the sub-registries as described in the 933 following sections. 935 9.1. Request Parameter Bit Flags 937 As described in Section 5.3, two new bit lfags are defined for 938 inclusion in the Flags field of the RP object. IANA is requested to 939 make the following allocations from the "Request Parameter Bit Flags" 940 sub-registry. 942 Bit Name Description Reference 944 11 D-bit Report the request order [This.I-D] 945 12 M-bit Make-before-break [This.I-D] 947 9.2. New PCEP TLV 949 As described in Section 5.4, a new PCEP TLV is defined to indicate 950 the setup and delete order of LSPs in a GCO. IANA is requested to 951 make the following allocation from the "PCEP TLV Types" sub-registry. 953 TLV Type Meaning Reference 955 5 Order TLV [This.I-D] 957 9.3. New PCEP Object 959 As descried in Section 5.5, a new PCEP object is defined to carry 960 global constraints. IANA is requested to make the following 961 allocation from the "PCEP Objects" sub-registry. 963 Object Name Reference 964 Class 966 24 GLOBAL-CONSTRAINTS [This.I-D] 967 Object-Type 968 1: Global Constraints [This.I-D] 970 9.4. New PCEP Error Codes 972 As described in Section 5.6, new PCEP error codes are defined for GCO 973 errors. IANA is requested to make allocations from the "PCEP Error 974 Types and Values" sub-registry as set out in the following sections. 976 9.4.1. New Error-Values for Existing Error-Types 978 Error 979 Type Meaning Reference 981 5 Policy violation 982 Error-value=5: [This.I-D] 983 Global concurrent optimization not allowed 985 9.4.2. New Error-Types and Error-Values 987 Error 988 Type Meaning Reference 990 15 Global Concurrent Optimization Error [This.I-D] 991 Error-value=1: 992 Insufficient memory [This.I-D] 993 Error-value=2: 994 Global concurrent optimization not supported 995 [This.I-D] 997 9.5. New No-Path Reasons 999 IANA is requested to make the following allocations from the "No-Path 1000 Reasons" sub-registry for bit flags carried in the NO-PATH-VECTOR TLV 1001 in the PCEP NO-PATH object as described in Section 5.7. 1003 Bit 1004 Number Name Reference 1006 6 No GCO migration path found [This.I-D] 1007 7 No GCO solution found [This.I-D] 1009 10. References 1011 10.1. Normative References 1013 [BRPC] Vasseur, JP., Ed., "A Backward Recursive PCE-based 1014 Computation (BRPC) procedure to compute shortest inter- 1015 domain Traffic Engineering Label Switched Paths, 1016 draft-ietf-pce-brpc, work in progress". 1018 [PCE-OF] Le Roux, JL., Vasseur, JP., and Y. Lee, "Objective 1019 Function encoding in Path Computation Element 1020 communication and discovery protocols, 1021 draft-leroux-pce-of, work in progress". 1023 [PCE-XRO] Oki, E. and A. Farrel, "Extensions to the Path Computation 1024 Element Communication Protocol (PCEP) for Route 1025 Exclusions, draft-ietf-pce-pcep-xro, work in progress". 1027 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1028 Element (PCE) communication Protocol (PCEP) - Version 1, 1029 draft-ietf-pce-pcep, work in progress". 1031 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1032 Requirement Levels", BCP 14, RFC 2119, March 1997. 1034 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1035 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1036 Tunnels", RFC 3209, December 2001. 1038 [RFC5088] Le Roux, J., Vasseur, J., Ikejiri, Y., and R. Zhang, "OSPF 1039 Protocol Extensions for Path Computation Element (PCE) 1040 Discovery, RFC 5088, January 2008.". 1042 [RFC5089] Le Roux, J., Vasseur, J., Ikejiri, Y., and R. Zhang, 1043 "IS-IS Protocol Extensions for Path Computation Element 1044 (PCE) Discovery, RFC 5089, January 2008.". 1046 10.2. Informative References 1048 [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- 1049 region and multi-layer networks (MRN/MLN), 1050 draft-ietf-ccamp-gmpls-mln-reqs, work in progress". 1052 [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- 1053 based inter-layer MPLS and GMPLS traffic engineering, 1054 draft-ietf-pce-inter-layer-frwk, work in progress.". 1056 [PCEP-MIB] 1057 Stephen, E. and K. Koushik, "PCE communication 1058 protocol(PCEP) Management Information Base, 1059 draft-kkoushik-pce-pcep-mib, work in progress.". 1061 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1062 Element (PCE)-Based Architecture, RFC 4655, August 2006". 1064 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 1065 Communication Protocol Generic Requirements, RFC 4657, 1066 September 2006". 1068 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 1069 (PCE) Discovery, RFC 4674, October 2006.". 1071 Authors' Addresses 1073 Young Lee 1074 Huawei 1075 1700 Alma Drive, Suite 100 1076 Plano, TX 75075 1077 US 1079 Phone: +1 972 509 5599 x2240 1080 Fax: +1 469 229 5397 1081 Email: ylee@huawei.com 1083 JL Le Roux 1084 France Telecom 1085 2, Avenue Pierre-Marzin 1086 Lannion 22307 1087 FRANCE 1089 Email: jeanlouis.leroux@orange-ftgroup.com 1091 Daniel King 1092 Aria Networks 1093 United Kingdom 1095 Phone: 1096 Fax: 1097 Email: daniel@olddog.co.uk 1099 Eiji Oki 1100 NTT 1101 Midori 3-9-11 1102 Musashino, Tokyo 180-8585 1103 JAPAN 1105 Email: oki.eiji@lab.ntt.co.jp 1107 Full Copyright Statement 1109 Copyright (C) The IETF Trust (2008). 1111 This document is subject to the rights, licenses and restrictions 1112 contained in BCP 78, and except as set forth therein, the authors 1113 retain all their rights. 1115 This document and the information contained herein are provided on an 1116 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1117 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1118 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1119 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1120 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1121 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1123 Intellectual Property 1125 The IETF takes no position regarding the validity or scope of any 1126 Intellectual Property Rights or other rights that might be claimed to 1127 pertain to the implementation or use of the technology described in 1128 this document or the extent to which any license under such rights 1129 might or might not be available; nor does it represent that it has 1130 made any independent effort to identify any such rights. Information 1131 on the procedures with respect to rights in RFC documents can be 1132 found in BCP 78 and BCP 79. 1134 Copies of IPR disclosures made to the IETF Secretariat and any 1135 assurances of licenses to be made available, or the result of an 1136 attempt made to obtain a general license or permission for the use of 1137 such proprietary rights by implementers or users of this 1138 specification can be obtained from the IETF on-line IPR repository at 1139 http://www.ietf.org/ipr. 1141 The IETF invites any interested party to bring to its attention any 1142 copyrights, patents or patent applications, or other proprietary 1143 rights that may cover technology that may be required to implement 1144 this standard. Please address the information to the IETF at 1145 ietf-ipr@ietf.org.