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