idnits 2.17.1 draft-lee-pce-global-concurrent-optimization-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** It looks like you're using RFC 3978 boilerplate. You should update this to the boilerplate described in the IETF Trust License Policy document (see https://trustee.ietf.org/license-info), which is required now. -- Found old boilerplate from RFC 3978, Section 5.1 on line 21. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 1122. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 1133. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 1140. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 1146. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (January 29, 2007) is 6290 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) ** Downref: Normative reference to an Informational RFC: RFC 4655 ** Downref: Normative reference to an Informational RFC: RFC 4657 == Outdated reference: A later version (-19) exists of draft-ietf-pce-pcep-04 Summary: 3 errors (**), 0 flaws (~~), 2 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group Y. Lee 3 Internet-Draft Huawei 4 Intended status: Standards Track JL. Le Roux 5 Expires: August 2, 2007 France Telecom 6 D. King 7 Aria Networks 8 E. Oki 9 NTT 10 January 29, 2007 12 Path Computation Element Communication Protocol (PCECP) Requirements and 13 Protocol Extensions In Support of Global Concurrent Optimization 14 draft-lee-pce-global-concurrent-optimization-01.txt 16 Status of this Memo 18 By submitting this Internet-Draft, each author represents that any 19 applicable patent or other IPR claims of which he or she is aware 20 have been or will be disclosed, and any of which he or she becomes 21 aware will be disclosed, in accordance with Section 6 of BCP 79. 23 Internet-Drafts are working documents of the Internet Engineering 24 Task Force (IETF), its areas, and its working groups. Note that 25 other groups may also distribute working documents as Internet- 26 Drafts. 28 Internet-Drafts are draft documents valid for a maximum of six months 29 and may be updated, replaced, or obsoleted by other documents at any 30 time. It is inappropriate to use Internet-Drafts as reference 31 material or to cite them other than as "work in progress." 33 The list of current Internet-Drafts can be accessed at 34 http://www.ietf.org/ietf/1id-abstracts.txt. 36 The list of Internet-Draft Shadow Directories can be accessed at 37 http://www.ietf.org/shadow.html. 39 This Internet-Draft will expire on August 2, 2007. 41 Copyright Notice 43 Copyright (C) The IETF Trust (2007). 45 Abstract 47 The Path Computation Element (PCE) is a network component, 48 application, or node that is capable of performing path computations 49 at the request of Path Computation Clients (PCCs). The PCE is 50 applied in Multiprotocol Label Switching Traffic Engineering 51 (MPLS-TE) networks and in Generalized MPLS (GMPLS) networks to 52 determine the routes of Label Switched Paths (LSPs) through the 53 network. The Path Computation Element Communication Protocol (PCEP) 54 is specified for communications between PCCs and PCEs, and between 55 cooperating PCEs. 57 When computing or re-optimizing the routes of a set of LSPs through a 58 network it may be advantageous to perform bulk path computations in 59 order to avoid blocking problems and to achieve more optimal network- 60 wide solutions. Such bulk optimization is termed Global Concurrent 61 Optimization. 63 This document provides application-specific requirements and the PCEP 64 extensions in support of a global concurrent path computation 65 application. 67 Table of Contents 69 1. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 70 2. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 71 3. Applicability of Global Concurrent Path Computation . . . . . 7 72 3.1. Greenfield Optimization . . . . . . . . . . . . . . . . . 7 73 3.1.1. Single-layer Traffic Engineering . . . . . . . . . . . 7 74 3.1.2. Multi-layer Traffic Engineering . . . . . . . . . . . 8 75 3.2. Re-optimization of Existing Networks . . . . . . . . . . . 8 76 3.2.1. Reconfiguration of the Virtual Network Topology 77 (VNT) . . . . . . . . . . . . . . . . . . . . . . . . 8 78 3.2.2. Traffic Migration . . . . . . . . . . . . . . . . . . 8 79 3.3. Application of the PCE Architecture . . . . . . . . . . . 9 80 4. PCECP Requirements . . . . . . . . . . . . . . . . . . . . . . 11 81 5. Protocol extensions for support of global concurrent 82 optimization . . . . . . . . . . . . . . . . . . . . . . . . . 15 83 5.1. Global Concurrent Optimization Indication . . . . . . . . 16 84 5.2. Global Objective Function (GOF) Specification . . . . . . 16 85 5.3. Indication of Global Concurrent Requests . . . . . . . . . 17 86 5.4. Request for the order of LSP . . . . . . . . . . . . . . . 17 87 5.5. The Order Response . . . . . . . . . . . . . . . . . . . . 18 88 5.6. Global Constraints (GC) Object . . . . . . . . . . . . . . 20 89 5.7. Multi-Session Processing . . . . . . . . . . . . . . . . . 21 90 5.8. Error Indicator . . . . . . . . . . . . . . . . . . . . . 23 91 5.9. NO-PATH Indicator . . . . . . . . . . . . . . . . . . . . 23 92 6. Manageability Considerations . . . . . . . . . . . . . . . . . 25 93 6.1. Control of Function and Policy . . . . . . . . . . . . . . 25 94 6.2. Information and Data Models, e.g. MIB module . . . . . . . 25 95 6.3. Liveness Detection and Monitoring . . . . . . . . . . . . 25 96 6.4. Verifying Correct Operation . . . . . . . . . . . . . . . 25 97 6.5. Requirements on Other Protocols and Functional 98 Components . . . . . . . . . . . . . . . . . . . . . . . . 25 99 6.6. Impact on Network Operation . . . . . . . . . . . . . . . 25 100 6.7. Other Considerations . . . . . . . . . . . . . . . . . . . 25 101 7. Security Considerations . . . . . . . . . . . . . . . . . . . 26 102 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 27 103 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 28 104 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 29 105 10.1. Normative References . . . . . . . . . . . . . . . . . . . 29 106 10.2. Informative References . . . . . . . . . . . . . . . . . . 29 107 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 108 Intellectual Property and Copyright Statements . . . . . . . . . . 31 110 1. Terminology 112 The terminology explained herein complies with [RFC4655]. 114 PCC: Path Computation Client: Any client application requesting a 115 path computation to be performed by a Path Computation Element. 117 PCE: Path Computation Element: An entity (component, application or 118 network node) that is capable of computing a network path or route 119 based on a network graph and applying computational constraints. 121 TED: Traffic Engineering Database which contains the topology and 122 resource information of the domain. The TED may be fed by IGP 123 extensions or potentially by other means. 125 PCECP: The PCE Communication Protocol: PCECP is the generic abstract 126 idea of a protocol that is used to communicate path computation 127 requests from PCCs to a PCE, and to return computed paths from the 128 PCE to the PCCs. The PCECP can also be used between cooperating 129 PCEs. 131 PCEP: The PCE communication Protocol: PCEP is the actual protocol 132 that implements the PCECP idea. 134 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 135 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 136 document are to be interpreted as described in RFC 2119 [RFC2119]. 137 These terms are also used in the parts of this document that specify 138 requirements for clarity of specification of those requirements. 140 2. Introduction 142 [RFC4655] defines the PCE based Architecture and explains how a PCE 143 may compute the paths of Multiprotocol Label Switching Traffic 144 Engineering (MPLS-TE) and Generalized MPLS (GMPLS) Label Switched 145 Paths (LSPs) at the request of PCCs. A PCC is shown to be any 146 network component that makes such a request and may be a Label 147 Switching Router (LSR) or a Network Management System (NMS). The 148 PCE, itself, is shown to be located anywhere within the network, and 149 may be within an LSR, an NMS or Operational Support System (OSS), or 150 may be an independent network server. 152 The PCECP is the communication protocol used between PCC and PCE, and 153 may also be used between cooperating PCEs. [RFC4657] sets out the 154 common protocol requirements for the PCECP. Additional application- 155 specific requirements for PCECP are deferred to separate documents. 157 This document provides a set of PCECP extension requirements and 158 solutions in support of concurrent path computation applications that 159 may arise during network operations. A concurrent path computation 160 is a path computation application where a set of TE paths are 161 computed concurrently in order to efficiently utilize network 162 resources. The computation method involved with a concurrent path 163 computation is referred to as global concurrent optimization in this 164 document. Appropriate computation algorithms to perform this type of 165 optimization are out of the scope of this document. 167 As new LSPs are added sequentially or removed from the network over 168 time, the global network resources become fragmented and the network 169 no longer provides the optimal use of the available capacity. A 170 global concurrent path computation is able to simultaneously consider 171 the entire topology of the network and the complete set of existing 172 LSPs, and their respective constraints, and look to re-optimize the 173 entire network to satisfy all constraints for all LSPs. 174 Alternatively, the application may consider a subset of the LSPs 175 and/or a subset of the network topology. 177 The need for a gloabl concurrent path computation may also arise when 178 network operators need to set up a large number of TE LSPs in their 179 network planning process. A global concurrent path computation is 180 typically an off-line computation. This document does not exclude 181 the possibility that network operators might require on-line 182 computation for a global concurrent path computation in the event of 183 catastrophic network failures, where a set of TE LSPs need to be 184 optimally rerouted in real-time. 186 The off-line computation requirements to support a set of TE LSPs are 187 quite different from on-line path computation requirements. While 188 on-line path computation is focused on finding a single best path in 189 a timely manner given the prevailing network conditions, an off-line 190 path computation application involves finding paths for a set of TE 191 LSPs concurrently to meet a global objective. While off-line 192 computation may not require such stringent time constraints as on- 193 line path computation, the key objective associated with off-line 194 computation is to efficiently allocate network resources from a 195 global network perspective. While on-line path computation is 196 tactical, off-line path computation is strategic. 198 As the PCE is envisioned to provide solutions in all path computation 199 matters, it is anticipated that the PCE would provide solutions for 200 global concurrent path computation needs. 202 The main focus of this document is to highlight the PCC-PCE 203 communication needs in support of a concurrent path computation 204 application and to define protocol extensions to meet those needs. 206 The PCC-PCE requirements addressed herein are specific to the context 207 where the PCE is a specialized PCE that is capable of solving global 208 concurrent path computation applications. Discovery of such 209 capabilities might be desirable and could be achieved through 210 extensions to the PCE discovery mechanisms [RFC4674], but that is out 211 of the scope of this document. 213 3. Applicability of Global Concurrent Path Computation 215 This section discusses scenarios for which global concurrent path 216 computation may be applied. It also discusses how these scenarios 217 apply to the PCE architecture. 219 3.1. Greenfield Optimization 221 When a new TE network needs to be provisioned from a green-field 222 perspective, a set of TE LSPs need to be created based on traffic 223 demand, network topology, service constraints, and network resources. 224 Under this scenario, concurrent computation ability is highly 225 desirable, or required, to utilize network resources in an optimal 226 manner and avoid blocking risks. Sequential path computation could 227 potentially result in sub-optimal use of network resources or even 228 blocking issues. 230 3.1.1. Single-layer Traffic Engineering 232 Greenfield optimization can be applied when layer-specific TE LSPs 233 need to be created from a green-field perspective. For example, 234 MPLS-TE network can be established based on layer 3 specific traffic 235 demand, network topology, and network resources. Greenfield 236 optimization for single-layer traffic engineering can be applied to 237 lower layer networks such as SDH/Sonet, Ethernet Transport, WDM, etc. 239 3.1.1.1. Pre-establishment of the Hierarchical-LSP (H-LSP)in the 240 Transport Network 242 When an optical transport layer provides lower-layer traffic 243 engineered LSPs for upper-layer client LSPs via the Hierarchical LSP 244 (H-LSP) mechanism, the operator may desire to pre-establish optical 245 LSPs in the optical transport network [MLN-REQ]. This whole multi- 246 layer network can be managed using PCE [PCE-MLN]. In this scenario, 247 it is anticipated that a set of H-LSPs would be created concurrently 248 in such a way as to efficiently utilize network resources in the 249 lower-layer network. Again, concurrent path computation capability 250 would result in more efficient network resource utilization than 251 sequential path computation. 253 3.1.1.2. VNT Configuration 255 A set of one or more of lower-layer LSPs providing information for 256 efficient path handling in upper-layer(s) can be described as a 257 virtual network topology (VNT)[MLN-REQ]. 259 When the VNT [MLN-REQ] is configured for the first time, greenfield 260 concurrent optimization may well be applied to find a set of LSPs 261 more efficiently than sequential path computation. 263 3.1.2. Multi-layer Traffic Engineering 265 Greenfield optimization is not limited to single-layer traffic 266 engineering. It can also be applied in multi-layer traffic 267 engineering. Both the client and the server layers network resources 268 and topology can be considered simultaneously in setting up a set of 269 TE LSPs that traverse the layer boundary. 271 3.2. Re-optimization of Existing Networks 273 The need for global concurrent path computation may also arise in 274 existing networks. When an existing TE LSP network experiences sub- 275 optimal use of its resources, the need for re-optimization or 276 reconfiguration may arise. The scope of re-optimization and 277 reconfiguration may vary depending on particular situations. The 278 scope of re-optimization may be limited to bandwidth modification to 279 an existing TE LSP. However, it could well be that a large number of 280 TE LSPs may need to be re-optimized concurrently. In an extreme 281 case, the TE LSPs may need to be globally re-optimized. Note that 282 sequential re-optimization of such TE LSPs is unlikely to produce 283 substantial improvements in overall network optimization except in 284 very sparsely utilized networks. 286 3.2.1. Reconfiguration of the Virtual Network Topology (VNT) 288 Reconfiguration of the VNT [MLN-REQ] is another application scenario 289 where global concurrent path computation may be applicable. Triggers 290 for VNT reconfiguration, such as traffic demand changes, network 291 failures, and topological configuration changes, may require a large 292 set of existing LSPs to be re-computed. Again, concurrent path 293 computation capability would result in more efficient network 294 resource utilization than sequential path computation. 296 3.2.2. Traffic Migration 298 When migrating from one set of TE LSPs to a reoptimized set of TE 299 LSPs it is important that the traffic be moved without causing 300 disruption. Various techniques exist in MPLS and GMPLS, such as 301 make-before-break [RFC3209], to establish the new LSPs before tearing 302 down the old LSPs. When multiple LSP routes are changed according to 303 the computed results, some of the LSPs may be disrupted due to the 304 resource constraints. In other words, it may prove to be impossible 305 to perform a direct migration from the old LSPs to the new optimal 306 LSPs without disrupting traffic because there are insufficient 307 network resources to support both sets of LSPs when make-before-break 308 is used. However, the PCE may be able determine an order of LSP 309 rerouting actions so that make-before-break can be performed within 310 the limited resources. 312 However, it may be the case that the reoptimization is radical. This 313 could mean that it is not possible to apply make-before-break in any 314 order to migrate from the old LSPs to the new LSPs. In this case a 315 migration strategy is required that may necessitate LSPs being 316 rerouted using make-before-break onto temporary paths in order to 317 make space for the full reoptimization. A PCE might indicate the 318 order in which reoptimized LSPs must be established and take over 319 from the old LSPs, and may indicate a series of different temporary 320 paths that must be used. Alternatively, the PCE might perform the 321 global reoptimization as a series of sub-reoptimizations by 322 reoptimizing subsets of the total set of LSPs. 324 Note also that during reoptimization, traffic disruption may be 325 allowed for some LSPs carrying low priority services (e.g., Internet 326 traffic) and not allowed for some LSPs carrying mission critical 327 services (e.g., voice traffic). 329 3.3. Application of the PCE Architecture 331 Figure 1 shows how the aforementioned functionality applies within 332 the PCE architecture. It must be observed that the PCC is not 333 necessarily an LSR [RFC4655]. Although Figure 1 shows the PCE as 334 remote from the NMS, it might be collocated with the NMS. 336 Upon receipt of an application request (e.g., a traffic demand matrix 337 is provided to the NMS by the operator's network planning procedure), 338 the NMS requests a global concurrent path computation from the PCE. 339 The PCE then computes the requested paths concurrently applying some 340 algorithms. When the requested path computation completes, the PCE 341 sends the resulting paths back to the NMS. The NMS then supplies the 342 head-end LSRs with a fully computed explicit path for each TE LSP 343 that needs to be established. 345 ----------- 346 Application | ----- | 347 Request | | TED | | 348 | | ----- | 349 v | | | 350 ------------- Request/ | v | 351 | | Response| ----- | 352 | NMS |<--------+> | PCE | | 353 | | | ----- | 354 ------------- ----------- 355 Service | 356 Request | 357 v 358 ---------- Signaling ---------- 359 | Head-End | Protocol | Adjacent | 360 | Node |<---------->| Node | 361 ---------- ---------- 363 Figure 1: PCE-Based Architecture for Global Concurrent Optimization 365 4. PCECP Requirements 367 This section provides the PCECP requirements to support large-scale 368 concurrent path computation applications. The requirements specified 369 here should be regarded as application-specific requirements and are 370 justifiable based on the extensibility clause found in section 6.1.14 371 of [RFC4657]: 373 The PCECP MUST support the requirements specified in the 374 application-specific requirements documents. The PCECP MUST also 375 allow extensions as more PCE applications will be introduced in 376 the future. 378 It is also to be noted that some of the requirements discussed in 379 this section have already been discussed in the PCECP requirement 380 document [RFC4657]. For example, Section 5.1.16 in [RFC4657] 381 provides a list of generic constraints while Section 5.1.17 in 382 [RFC4657] provides a list of generic objective functions that MUST be 383 supported by the PCECP. While using such generic requirements as the 384 baseline, this section provides application-specific requirements in 385 the context of global concurrent path computation and in a more 386 detail level than the generic requirements. 388 The PCEP SHOULD support the following capabilities either via 389 creation of new objects and/or modification of existing objects where 390 applicable. 392 o An indicator to convey that the request is for a global concurrent 393 path computation. This indicator is necessary to ensure 394 consistency in applying global objectives and global constraints 395 in all path computations. Note: This requirement is covered by 396 "synchronized path computation" in [RFC4655] and [RFC4657]. 397 However, an explicit indicator to request a global concurrent 398 optimization is a new requirement. 400 o A Global Objective Function (GOF) field in which to specify the 401 global objective function. The global objective function is the 402 overarching objective function to which all individual path 403 computation requests are subjected in order to find a globally 404 optimal solution. Note that this requirement is covered by 405 "synchronized objective functions" in section 5.1.7 [RFC4657]. A 406 list of available global objective functions SHOULD include the 407 following objective functions at the minimum and SHOULD be 408 expandable for future addition: 410 * Minimize the sum of all TE LSP costs (min cost) 411 * Maximize the residual bandwidth on the most loaded link 413 * Evenly allocate the network load to achieve the most uniform 414 link utilization across all links (this can be achieved by the 415 following objective function: minimize max over all links 416 {(C(i)-A(i))/C(i)} where C(i) is the link capacity for link i 417 and A(i) is the total bandwidth allocated on link i. 419 o A Global Constraints (GC) field in which to specify the list of 420 global constraints to which all the requested path computations 421 should be subjected. This list SHOULD include the following 422 constraints at the minimum and SHOULD be expandable for future 423 addition: 425 * Maximum link utilization value -- This value indicates the 426 highest possible link utilization percentage set for each link. 427 (Note: to avoid floating point numbers, the values should be 428 integer values.) 430 * Minimum link utilization value -- This value indicates the 431 lowest possible link utilization percentage set for each link. 432 (Note: same as above) 434 * Overbooking Factor -- The overbooking factor allows the 435 reserved bandwidth to be overbooked on each link beyond its 436 physical capacity limit. 438 * Maximum number of hops for all the LSPs -- This is the largest 439 number of hops that any LSP can have. Note that this 440 constraint can also be provided on a per LSP basis (as 441 requested in [RFC4657] and defined in [PCEP]). 443 * Exclusion of links/nodes in all LSP path computation (i.e., all 444 LSPs should not include the specified links/nodes in their 445 paths). Note that this constraint can also be provided on a 446 per LSP basis (as requested in [RFC4657] and defined in 447 [PCEP]). 449 * An indication should be available in a path computation 450 response that further reoptimization may only become available 451 once existing traffic has been moved to the new LSPs. 453 o A Global Concurrent Vector (GCV) field in which to specify all the 454 individual path computation requests that are subject to 455 concurrent path computation and subject to the global objective 456 function and all of the global constraints. Note that this 457 requirement is partially fulfilled by the SVEC object in the PCEP 458 specification [PCEP]. Since the SVEC object as defined in [PCEP] 459 allows identifying a set of concurrent path requests, the SVEC can 460 be reused to specify all the individual concurrent path requests 461 for a global concurrent optimization. This can be achieved by 462 defining a new flag in the SVEC object to indicate that this is a 463 global concurrent optimization. 465 o An indicator field in which to indicate the outcome of the 466 request. When the PCE could not find a feasible solution with the 467 initial request, the reason for failure SHOULD be indicated. This 468 requirement is partially covered by [RFC4657], but not in this 469 level of detail. The following indicators SHOULD be supported at 470 the minimum: 472 * no feasible solution found. Note that this is already covered 473 in [PCEP]. 475 * memory overflow 477 * PCE too busy. Note that this is already covered in [PCEP]. 479 * PCE not capable of concurrent reoptimization 481 * no migration path available 483 * administrative privileges do not allow global reoptimization 485 o A Multi-Session Indicator field in the case where the original 486 request is sub-divided into multiple sessions. This case may 487 arise when the reason for failure of the original request is due 488 to mathematical infeasibility, or memory overflow. The PCC may 489 follow up with subsequent actions under a local policy. The 490 motivation for multi-session application is to find a partial 491 feasible solution in the absence of the optimal solution. When 492 the PCC decides to scale down the original request into several 493 sessions, the PCC sends the first session path computation request 494 to the PCE. The next session path computation request is held 495 until the results from the first session would be available. Once 496 the results from the first session are available, the PCC then 497 sends the second session path computation request to the PCE. The 498 same procedure is repeated until the last session of the multiple 499 session has been completed. To support this requirement, it is 500 required that the PCE keep in memory the previously computed paths 501 until all paths of the multi-session have been computed. 503 * Multi-Session Indicator 505 * Multi-Session Sequence Number 506 * The Indication of the Final Session 508 o In order to minimize disruption associated with bulk path 509 provisioning, the following requirements MUST be supported: 511 * The request message MUST allow requesting the PCE to provide 512 the order in which LSPs should be reoptimized (i.e., the 513 migration path) in order to minimize traffic disruption during 514 the migration. That is the request message MUST allow 515 indicating the PCE that the set of paths that will be provided 516 in the response message (PCRep) has to be ordered. 518 * In response to the "ordering" request from the PCC, the PCE 519 MUST be able to indicate in the response message (PCRep) the 520 order in which LSPs should be reoptimized so as to minimize 521 traffic disruption. It should indicate for each request the 522 order in which the old LSP should be removed and the order in 523 which the new LSP should be setup. If the removal order is 524 lower than the setup order this means that make-before-break 525 cannot be done for this request. 527 * As stated in RFC 4657, the request for a reoptimization MUST 528 support the inclusion of the set of previously computed paths 529 along with their bandwidth. This is to avoid double bandwidth 530 accounting and also this allows running an algorithm that 531 minimizes perturbation and that can compute a migration path 532 (LSP setup/removal orders). This is particularly required for 533 stateless PCEs. 535 * During a migration it may not be possible to do a make-before- 536 break for all existing LSPs. The request message must allow 537 indicating for each request whether make-before-break is 538 required (e.g. Voice traffic) or break-before-make is 539 acceptable (e.g. Internet traffic). The response message must 540 allow indicating LSPs for which make-before-break 541 reoptimization is not possible (this will be deduced from the 542 LSP setup and deletion orders). 544 * During a reoptimization it may be required to move a LSP 545 several times so as to avoid traffic disruption. The response 546 message must allow indicating the path sequence for each 547 request. 549 5. Protocol extensions for support of global concurrent optimization 551 This section provides protocol extensions for support of global 552 concurrent optimization. Protocol extensions discussed in this 553 section are built on [PCEP]. 555 The format of a PCReq message is currently as follows per [PCEP]: 557 ::= 558 [] 559 561 where: 562 ::= [] 563 ::= [] 564 ::= 565 [] 566 [] 567 [] 568 [] 569 [] 570 [] 571 [] 573 The format of a PCReq message after incorporating new requirements 574 for support of global concurrent optimization is as follows: 576 ::= 577 [] 578 580 The is changed as follows: 582 :: = 583 [] 584 [] 585 [] 586 [] 588 Note that in the SVEC-list two new optional objects have been 589 defined: the GOF (Global Objective Function) Object and the GC 590 (Global Constraints) Object. Note also that the XRO is also added as 591 an optional Object in the list. Details of this change will be 592 discussed in the following sections. 594 5.1. Global Concurrent Optimization Indication 596 A global concurrent path computation request from other types of 597 computation request can be implicitly indicated by the presence of 598 the GOF object in the new SVEC-list as defined in the previous 599 section. That is when the SVEC-list includes the GOF object, it 600 indicates a request for global concurrent optimization. It can also 601 be explicitly indicated by the C flag in the SVEC object. 603 5.2. Global Objective Function (GOF) Specification 605 The global objective function can be specified in the GOF object. 606 The format of the GOF object body that includes the global objective 607 function is as follows: 609 0 1 2 3 610 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 611 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 612 | Reserved | Objective Function ID | 613 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 615 Figure 4: GOF body object format 617 The Objective Function ID (16 bit) identifies the objective function 618 for global concurrent request. 620 Currently three global objective functions are identified. Other 621 objective functions may be defined later. 623 1: Minimize the sum of all TE LSP costs (min cost) 625 2: Maximize the residual bandwidth on the most loaded link 627 3: Evenly allocate the network load to achieve the most uniform 628 link utilization across all links (this can be achieved by the 629 following objective function: minimize max over all links {(C(i)- 630 A(i))/C(i)} where C(i) is the link capacity for link i and A(i) is 631 the total bandwidth allocated on link i. 633 GOF Object-Class is to be assigned by IANA. 635 GOF Object-Type is to be assigned by IANA. 637 5.3. Indication of Global Concurrent Requests 639 All the path requests in this application should be indicated so that 640 the global objective function and all of the global constraints are 641 applied to each of the requested path computation. In order to 642 support this requirement, the SVEC object should be modified as 643 follows. 645 C flag (1 bit): This is a new flag in the SVEC object. When C flag 646 is set, this indicates that all of the path request listed in the 647 body of the SVEC object should be computed applying the global 648 constraints and the global objective function. 650 When the C Flag is set in the SVEC Object, the GOF and the GC objects 651 should directly follow the SVEC Object. Therefore, the format of the 652 PCReq is modified as follows: 654 ::= 655 [] 656 658 The is changed as follows: 660 ::= 661 [] 662 [] 663 [] 664 [] 666 5.4. Request for the order of LSP 668 In order to minimize disruption associated with bulk path 669 provisioning, the PCC MAY indicate to the PCE that the response MUST 670 be ordered. That is, it MUST include the order in which LSPs MUST be 671 moved so as to minimize traffic disruption. Such indication can be 672 included in the RP object which is revised as follows: 674 0 1 2 3 675 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 676 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 677 | Reserved | Flags |D|M|F|O|B|R| Pri | 678 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 679 | Request-ID-number | 680 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 681 | | 682 // Optional TLV(s) // 683 | | 684 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 686 Figure 6: RP object body format in the PCReq Message 688 D bit (orDer - 1 bit): when set, in a PCReq message, the requesting 689 PCC requires the PCE to specify in the PCRep message the order in 690 which this particular path request is to be provisioned relative to 691 other requests. 693 M bit (Make-before-break - 1 bit): when set, this indicates that a 694 make-before-break reoptimization is required for this request. 696 When M bit is not set, this implies that this request is allowed to a 697 break-before-make reoptimization. Note that M bit can be set only if 698 the R and D flags are set. 700 All other fields are unchanged from [PCEP]. 702 5.5. The Order Response 704 The PCE MUST specify the order number in response to the Order 705 Request made by the PCC in the PCReq message if so requested by the 706 setting of the D bit in the RP object in the PCReq message. The 707 format of the RP object body to be included in the PCRep message is 708 modified as follows: 710 0 1 2 3 711 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 712 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 713 | Reserved | Flags |D|M|F|O|B|R| Pri | 714 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 715 | Request-ID-number | 716 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 717 | | 718 // Order TLV (Optional TLV) // 719 | | 720 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 722 Figure 7: RP object body format in the PCRep Message 724 The Order TLV is an optional TLV in the RP object, that indicates the 725 order in which the old LSP must be removed and the new LSP must be 726 setup during a reoptimization. It is carried in the PCRep message in 727 response to a reoptimization request. 729 The Order TLV SHOULD be included in the RP object in the PCRep 730 message if the D bit is set in the RP object in the PCReq message. 732 The format of the Order TLV is as follows: 734 0 1 2 3 735 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 736 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 737 | Type | Length | 738 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 739 | Delete Order | 740 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 741 | Setup Order | 742 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 744 Type To be defined by IANA (suggested value = ) 745 Length Variable 746 Value Orders in which the old path should be removed 747 and the new path should be setup 749 Figure 8: The Order TLV in the RP object in the PCRep Message 751 Delete Order: 32 bit integer that indicates the order in which the 752 old LSP should be removed 753 Setup Order: 32 bit integer that indicates the order in which the new 754 LSP should be setup 756 The delete order should not be equal to the setup order. If the 757 delete order is higher than the setup order, this means that the 758 reoptimization can be done in a make-before-break manner, else it 759 cannot be done in a make-before-break manner. 761 To illustrate, consider a network with two established requests: R1 762 with path P1 and R2 with path P2. During a reoptimization the PCE 763 may provide the following ordered reply: 765 R1, path P1', remove order 1, setup order 4 766 R2, path P2', remove order 3, setup order 2 768 This indicates that the NMS should do the following sequence of 769 tasks: 771 1: Remove path P1 772 2: Setup path P2' 773 3: Remove path P2 774 4: Setup path P1' 776 That is, R1 is reoptimized in a break-before-make manner and R2 in a 777 make-before-break manner. 779 5.6. Global Constraints (GC) Object 781 The Global Constraints (GC) Object is used in a PCReq message to 782 specify the necessary global constraints that should be applied to 783 all individual path computations for a global concurrent path 784 optimization request. 786 The format of the GC object body that includes the global constraints 787 is as follows: 789 0 1 2 3 790 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 791 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 792 | MU | mU | OB | MH | 793 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 794 | | 795 // Optional TLV(s) // 796 | | 797 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 798 Figure 11: GC body object format 800 MU (Max Utilization) (8 bits) : 8 bit integer that indicates the 801 upper bound utilization percentage by which all link should be bound. 802 Utilization = (Link Capacity - Allocated Bandwidth on the Link)/ Link 803 Capacity 805 mU (minimum Utilization) (8 bits) : 8 bit integer that indicates the 806 lower bound utilization percentage by which all link should be bound. 808 OB (Over Booking factor) (8 bits) : 8 bit integer that indicates the 809 overbooking percentage that allows the reserved bandwidth to be 810 overbooked on each link beyond its physical capacity limit. The 811 value, for example, 10% means that 110 Mbps can be reserved on a 812 100Mbps link. 814 MH (Max Hop) (8 bits): 8 bit integer that indicates the maximum hop 815 count for all the LSPs. 817 GC Object-Class is to be assigned by IANA. 819 GC Object-Type is to be assigned by IANA. 821 The exclusion of the list of nodes/links from a global path 822 computation can be done by including the XRO object following the GC 823 object in the new SVEC definition. 825 5.7. Multi-Session Processing 827 When the initial global concurrent path computation request fails due 828 to scaling issues or memory overflow as indicated in the PCEP-ERROR 829 object in the PCRep message, multi-session processing may be 830 proceeded in an attempt to find a feasible solution in the absence of 831 an optimal solution. This should be driven by local policy decision. 832 How to divide up the original global concurrent optimization problem 833 into a number of smaller-scale optimization problems is out of the 834 scope of this document. 836 In order to meet these multi-session requirements, a new object, the 837 Multi-Session (MS) object is required. 839 This object should be defined on a per message basis. The message is 840 modified as follows: 842 ::= 843 [] 844 [] 845 847 The format of the MSO object is as follows: 849 0 1 2 3 850 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 851 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 852 |F| Reserved | Multi-Session ID | 853 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 854 | Sequence Number | Reserved | 855 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 857 Figure 13: MSO object body format 859 Multi-Session ID (16 bits): 16 bit integer that identifies the multi- 860 session computation. The Multi-Session ID will allow to map all 861 request messages for the same global computation. 863 Sequence Number (16 bits): 16 bit integer that indicates the sequence 864 number of the current multi-session request. This should be 865 incremented for each new request message during a multi-session 866 request until the final request is performed. 868 F (Final session - 1 bit): When set, the requesting PCC indicates 869 that the PCReq message is the final session of a multi-session 870 request. When it is not set, the PCE SHOULD keep in memory all the 871 computed paths until the final session of a multi-session is 872 completed. This is necessary to correctly account for already 873 computed LSPs. 875 MS Object-Class is to be assigned by IANA. 877 MS Object-Type is to be assigned by IANA. 879 For PCE not able to temporarily maintain previously computed paths, 880 the multi-session capability can be provided by simply adding the ERO 881 object and the Bandwidth object following the RP object in the PCReq 882 message. The ERO and the Bandwidth objects together provide all of 883 the previously computed paths by the PCE. 885 In order to distinguish a previously computed request from a new 886 request, a new flag in the RP object is required. 888 A (Already computed request - 1 bit): When set, this indicates that 889 the request has already been computed in a previous session, and its 890 result (as indicated by the ERO and the Bandwidth Object following 891 the RP object) must be taken account in the current session. 893 5.8. Error Indicator 895 To indicate errors associated with the global concurrent path 896 optimization request, a new Error-Type (11) and subsequent error- 897 values are defined as follows for inclusion in the PCEP-ERROR object: 899 A new Error-Type (11) and subsequent error-values are defined as 900 follows: 902 Error-Type=14 and Error-Value=1: if a PCE receives a global 903 concurrent path optimization request and the PCE is not capable of 904 the request due to insufficient memory, the PCE MUST send a PCErr 905 message with a PCEP ERROR object (Error-Type=14) and an Error-Value 906 (Error-Value=1). The corresponding global concurrent path 907 optimization request MUST be cancelled. 909 Error-Type=14; Error-Value=2: if a PCE receives a global concurrent 910 path optimization request and the PCE is not capable of global 911 concurrent optimization, the PCE MUST send a PCErr message with a 912 PCEP-ERROR Object (Error-Type=14) and an Error-Value (Error-Value=2). 913 The corresponding global concurrent path optimization MUST be 914 cancelled. 916 Error-Type=14; Error-Value=3: if a PCE receives a global concurrent 917 path optimization request which is not compliant with administrative 918 privileges (i.e., the PCE policy does not support global concurrent 919 optimization), the PCE send a PCErr message with a PCEP-ERROR Object 920 (Error-Type=14) and an Error-Value (Error-Value=3). The 921 corresponding global concurrent path computation MUST be cancelled. 923 5.9. NO-PATH Indicator 925 To communicate the reason(s) for not being able to find global 926 concurrent path computation, the NO-PATH object can be used in the 927 PCRep message. The format of the NO-PATH object body is as follows: 929 0 1 2 3 930 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 931 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 932 |C|G|M| Flags | Reserved | 933 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 934 | | 935 // Optional TLV(s) // 936 | | 937 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 938 Figure 14: NO-PATH object format 940 Flags (16 bits). The C flag is defined in [PCEP]. 942 Two additional flags are defined to support other reasons why the 943 path computation fails: G flag (1 bit) and M flag (1 bit). 945 M flag (1 bit): when set, the PCE indicates that no migration path 946 was found. 948 G flag (1 bit): when set, the PCE indicates no feasible solution was 949 found that meets all the constraints associated with global 950 concurrent path optimization in the PCRep message. 952 When either M or G flag is set in the PCRep Message, a subsequent 953 multi-session feature may be triggered if the PCC's local policy 954 allows it. The multi-session feature allows the original global 955 concurrent optimization to be split into a number of multiple 956 sessions so that the PCE would compute a number of smaller-scale 957 optimizations in a sequential manner. The trade-off is that a 958 partial feasible solution may be obtained using this approach which 959 is better than not having any solution at all, although such solution 960 might not be a global optimal solution. How to divide up the 961 original large-scale global concurrent optimization into a multiple 962 number of smaller-scale optimizations is out of the scope of this 963 document. 965 See Section 5.7 for multi-session processing details. 967 6. Manageability Considerations 969 Manageability of Global Concurrent Path Computation with PCE must 970 address the following considerations: 972 6.1. Control of Function and Policy 974 This sub-section will describe the configurable items that exist for 975 the control of global concurrent optimization functions or policies. 977 6.2. Information and Data Models, e.g. MIB module 979 This sub-section will describe the information and data models 980 necessary for the protocol or the protocol extensions. This 981 includes, but is not necessarily limited to, the MIB modules 982 developed specifically for the protocol functions specified in the 983 document. 985 6.3. Liveness Detection and Monitoring 987 This sub-section will describe liveness detection and monitoring 988 requirements for both the control plane and the data plane. 990 6.4. Verifying Correct Operation 992 This sub-section will describe Operations and Management (OAM) 993 features and functions for verifying the correct operation. 995 6.5. Requirements on Other Protocols and Functional Components 997 This sub-section will describe requirements or refer to the sections 998 that discuss the impact of global concurrent optimization on existing 999 protocols. 1001 6.6. Impact on Network Operation 1003 This sub-section will discuss the impact on the operation of existing 1004 networks. 1006 6.7. Other Considerations 1008 This sub-section will cover those manageability requirements not 1009 specifically in previous sub-sections. 1011 7. Security Considerations 1013 When global re-optimization is applied to an active network, it could 1014 be extremely disruptive. Although the real security and policy 1015 issues apply at the NMS, if the wrong results are returned to the 1016 NMS, the wrong actions may be taken in the network. Therefore, it is 1017 very important that the operator issuing the commands has sufficient 1018 authority and is authenticated, and that the computation request is 1019 subject to appropriate policy. 1021 The mechanisms defined in [PCEP] to secure a PCEP session (MD-5 1022 authentication, etc.) apply here as well. 1024 8. Acknowledgements 1026 We would like to thank Jerry Ash, Adrian Farrel, Ning So and Lucy 1027 Yong for their useful comments and suggestions. 1029 9. IANA Considerations 1031 A future revision of this document will present requests to IANA for 1032 codepoint allocation. 1034 10. References 1036 10.1. Normative References 1038 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1039 Requirement Levels", BCP 14, RFC 2119, March 1997. 1041 [RFC3209] Awduche, D., Berger, L., Gan, D., Li, T., Srinivasan, V., 1042 and G. Swallow, "RSVP-TE: Extensions to RSVP for LSP 1043 Tunnels", RFC 3209, December 2001. 1045 [RFC4655] Farrel, A., Vasseur, J., and J. Ash, "A Path Computation 1046 Element (PCE)-Based Architecture", RFC 4655, August 2006. 1048 [RFC4657] Ash, J. and J. Le Roux, "Path Computation Element (PCE) 1049 Communication Protocol Generic Requirements", RFC 4657, 1050 September 2006. 1052 10.2. Informative References 1054 [MLN-REQ] Shiomoto, K., Ed., "Requirements for GMPLS-based multi- 1055 region and multi-layer networks (MRN/MLN), 1056 draft-ietf-ccamp-gmpls-mln-reqs, work in progress". 1058 [PCE-MLN] Oki, E., Le Roux, J., and A. Farrel, "Framework for PCE- 1059 based inter-layer MPLS and GMPL traffic engineering, 1060 draft-ietf-pce-inter-layer-frwk, work in progress.". 1062 [PCEP] Vasseur, JP., Ed. and JL. Le Roux, Ed., "Path Computation 1063 Element (PCE) communication Protocol (PCEP) - Version 1, 1064 draft-ietf-pce-pcep-04.txt, work in progress". 1066 [RFC4674] Le Roux, J., "Requirements for Path Computation Element 1067 (PCE) Discovery, draft-ietf-pce-discovery-reqs, work in 1068 progress.". 1070 Authors' Addresses 1072 Young Lee 1073 Huawei 1074 1700 Alma Drive, Suite 100 1075 Plano, TX 75075 1076 US 1078 Phone: +1 972 509 5599 x2240 1079 Fax: +1 469 229 5397 1080 Email: ylee@huawei.com 1082 JL Le Roux 1083 France Telecom 1084 2, Avenue Pierre-Marzin 1085 Lannion 22307 1086 FRANCE 1088 Email: jeanlouis.leroux@orange-ftgroup.com 1090 Daniel King 1091 Aria Networks 1092 44/45 Market Place 1093 Chippenham SN15 3HU 1094 United Kingdom 1096 Phone: +44 7790 775187 1097 Fax: +44 1249 446530 1098 Email: daniel.king@aria-networks.com 1100 Eiji Oki 1101 NTT 1102 Midori 3-9-11 1103 Musashino, Tokyo 180-8585 1104 JAPAN 1106 Email: oki.eiji@lab.ntt.co.jp 1108 Full Copyright Statement 1110 Copyright (C) The IETF Trust (2007). 1112 This document is subject to the rights, licenses and restrictions 1113 contained in BCP 78, and except as set forth therein, the authors 1114 retain all their rights. 1116 This document and the information contained herein are provided on an 1117 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 1118 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 1119 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 1120 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 1121 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 1122 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 1124 Intellectual Property 1126 The IETF takes no position regarding the validity or scope of any 1127 Intellectual Property Rights or other rights that might be claimed to 1128 pertain to the implementation or use of the technology described in 1129 this document or the extent to which any license under such rights 1130 might or might not be available; nor does it represent that it has 1131 made any independent effort to identify any such rights. Information 1132 on the procedures with respect to rights in RFC documents can be 1133 found in BCP 78 and BCP 79. 1135 Copies of IPR disclosures made to the IETF Secretariat and any 1136 assurances of licenses to be made available, or the result of an 1137 attempt made to obtain a general license or permission for the use of 1138 such proprietary rights by implementers or users of this 1139 specification can be obtained from the IETF on-line IPR repository at 1140 http://www.ietf.org/ipr. 1142 The IETF invites any interested party to bring to its attention any 1143 copyrights, patents or patent applications, or other proprietary 1144 rights that may cover technology that may be required to implement 1145 this standard. Please address the information to the IETF at 1146 ietf-ipr@ietf.org. 1148 Acknowledgment 1150 Funding for the RFC Editor function is provided by the IETF 1151 Administrative Support Activity (IASA).