idnits 2.17.1 draft-ietf-pce-discovery-reqs-00.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 18. -- Found old boilerplate from RFC 3978, Section 5.5 on line 591. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 568. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 575. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 581. ** The document claims conformance with section 10 of RFC 2026, but uses some RFC 3978/3979 boilerplate. As RFC 3978/3979 replaces section 10 of RFC 2026, you should not claim conformance with it if you have changed to using RFC 3978/3979 boilerplate. ** This document has an original RFC 3978 Section 5.4 Copyright Line, instead of the newer IETF Trust Copyright according to RFC 4748. ** This document has an original RFC 3978 Section 5.5 Disclaimer, instead of the newer disclaimer which includes the IETF Trust according to RFC 4748. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- ** The document seems to lack a 1id_guidelines paragraph about Internet-Drafts being working documents. ** The document seems to lack a 1id_guidelines paragraph about 6 months document validity -- however, there's a paragraph with a matching beginning. Boilerplate error? Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- ** The document seems to lack an IANA Considerations section. (See Section 2.2 of https://www.ietf.org/id-info/checklist for how to handle the case when there are no actions for IANA.) ** The document seems to lack separate sections for Informative/Normative References. All references will be assumed normative when checking for downward references. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the RFC 3978 Section 5.4 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 (July 2005) is 6860 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- == Unused Reference: 'RFC2119' is defined on line 498, but no explicit reference was found in the text == Unused Reference: 'RFC3667' is defined on line 501, but no explicit reference was found in the text == Unused Reference: 'RFC3668' is defined on line 504, but no explicit reference was found in the text ** Obsolete normative reference: RFC 3667 (Obsoleted by RFC 3978) ** Obsolete normative reference: RFC 3668 (Obsoleted by RFC 3979) == Outdated reference: A later version (-05) exists of draft-ietf-pce-architecture-00 == Outdated reference: A later version (-07) exists of draft-ietf-pce-comm-protocol-gen-reqs-00 Summary: 10 errors (**), 0 flaws (~~), 6 warnings (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 PCE Working Group J.L. Le Roux (Editor) 3 Internet Draft France Telecom 4 Category: Informational 5 Expires: January 2006 7 July 2005 9 Requirements for Path Computation Element (PCE) Discovery 11 draft-ietf-pce-discovery-reqs-00.txt 13 Status of this Memo 15 By submitting this Internet-Draft, each author represents that any 16 applicable patent or other IPR claims of which he or she is aware 17 have been or will be disclosed, and any of which he or she becomes 18 aware will be disclosed, in accordance with Section 6 of BCP 79. 20 This document is an Internet-Draft and is in full conformance with 21 all provisions of Section 10 of RFC2026. Internet-Drafts are working 22 documents of the Internet Engineering Task Force (IETF), its areas, 23 and its working groups. Note that other groups may also distribute 24 working documents as Internet-Drafts. 26 Internet-Drafts are draft documents valid for a maximum of six months 27 and may be updated, replaced, or obsoleted by other documents at any 28 time. It is inappropriate to use Internet- Drafts as reference 29 material or to cite them other than as "work in progress." 31 The list of current Internet-Drafts can be accessed at 32 http://www.ietf.org/ietf/1id-abstracts.txt. 34 The list of Internet-Draft Shadow Directories can be accessed at 35 http://www.ietf.org/shadow.html. 37 Abstract 39 This document presents a set of requirements for a Path Computation 40 Element (PCE) discovery mechanism that would allow a Path Computation 41 Client (PCC) to discover dynamically and automatically a set of PCEs 42 along with their capabilities. It is intended that solutions that 43 specify procedures and protocol extensions for such PCE discovery 44 satisfy these requirements. 46 Conventions used in this document 48 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 49 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 50 document are to be interpreted as described in RFC-2119. 52 Table of Contents 54 1. Contributors................................................2 55 2. Terminology.................................................3 56 3. Introduction................................................3 57 4. Problem Statement and Requirements overview.................4 58 4.1. Problem Statement...........................................4 59 4.2. Requirements overview.......................................5 60 5. Example of application scenario.............................6 61 6. Detailed Requirements.......................................7 62 6.1. PCE Information to be disclosed.............................7 63 6.1.1. Discovery of PCE Location...................................7 64 6.1.2. Discovery of PCE computation scopes and domain(s) under 65 control...................................................7 66 6.1.3. Discovery of PCE Capabilities...............................8 67 6.1.4. Discovery of Alternate PCEs.................................9 68 6.2. Scope of PCE Discovery......................................9 69 6.3. PCE Information Synchronization.............................9 70 6.4. Detecting PCE Liveliness...................................10 71 6.5. Discovery of PCE capacity and congestion...................10 72 6.6. Extensibility..............................................10 73 6.7. Scalability................................................10 74 6.8. PCE Selection..............................................10 75 7. Security Considerations....................................11 76 8. Acknowledgments............................................11 77 9. References.................................................11 78 10. Authors' Addresses:........................................12 79 11. Intellectual Property Statement............................13 81 1. Contributors 83 The following are the authors that contributed to the present 84 document: 86 Jean-Louis Le Roux (France Telecom) 87 Paul Mabey (Qwest Communications) 88 Eiji Oki (NTT) 89 Richard Rabbat (Fujitsu) 90 Ting Wo Chung (Bell Canada) 91 Raymond Zhang (BT Infonet) 93 2. Terminology 95 Terminology used in this document 97 LSR: Label Switch Router 99 TE-LSP: Traffic Engineered Label Switched Path 101 PCE: Path Computation Element: an entity (component, application, 102 or network node) that is capable of computing a network path or 103 route based on a network graph, and applying computational 104 constraints. 106 PCC: Path Computation Client: any client application requesting a 107 path computation to be performed by a Path Computation Element. 109 IGP Area: OSPF Area or ISIS level/area 111 ABR: IGP Area Border Router (OSPF ABR or ISIS L1L2 router) 113 Intra-area TE LSP: A TE LSP whose path does not cross IGP area 114 boundaries. 116 Inter-area TE LSP: A TE LSP whose path transits through 117 two or more IGP areas. 119 Inter-AS MPLS TE LSP: A TE LSP whose path transits 120 through two or more ASes or sub-ASes (BGP confederations). 122 Domain: any collection of network elements within a common sphere 123 of address management or path computational responsibility. 124 Examples of domains include IGP areas and Autonomous Systems. 126 3. Introduction 128 The PCE Architecture [PCE-ARCH] defines a Path Computation Element 129 (PCE) as an entity capable of computing TE-LSPs paths satisfying a 130 set of constraints. The PCE function can be located on a router/LSR 131 (composite PCE) or on a network server (external PCE). 132 A PCE serves TE-LSP path computation requests sent by Path 133 Computation Clients (PCC). 134 A Path Computation Client (PCC) is a client application requesting a 135 path computation to be performed by a PCE. This can be, for instance, 136 an LSR requesting a path for a TE-LSP for which it is the head-end, 137 or a PCE requesting a path computation of another PCE (inter-PCE 138 communication). The communication between a PCC and a PCE requires a 139 client-server protocol whose requirements are listed in [PCE-COM- 140 REQ]. 142 There are several motivations for the adoption of a PCE-based 143 architecture to perform a TE-LSP path computation. They are listed in 144 [PCE-ARCH]. This includes applications such as CPU intensive path 145 computation, inter-domain path computation and backup path 146 computation. 148 The PCE architecture requires, of course, that a PCC be aware of the 149 location and capabilities of one or more PCEs in its domain, and also 150 potentially of some relevant PCEs in other domains (in the context of 151 inter-domain path computation). 153 In that context it would be highly desirable to define a mechanism 154 for automatic and dynamic PCE discovery, which would allow PCCs to 155 automatically discover a set of PCEs along with their capabilities, 156 and to dynamically detect new PCEs or any modification of the PCE 157 capabilities. This includes the discovery by a PCC of a set of one or 158 more PCEs in its domain, and potentially in some other domains. The 159 latter is a desirable function in the case of inter-domain path 160 computation for example. 162 This document lists a set of functional requirements for such an 163 automatic and dynamic PCE discovery mechanism. Section 3 points out 164 the problem statement. Section 4 illustrates an application scenario. 165 Finally section 5 addresses detailed requirements. 167 It is intended that solutions that specify procedures and protocol 168 extensions for such PCE discovery satisfy these requirements. There 169 is no intent either to specify solution specific requirements or to 170 make any assumption on the protocol(s) that could be used for the 171 discovery. 173 Note that requirements listed in this document apply equally to MPLS- 174 TE and GMPLS-capable PCEs. 176 It is also important to note that the notion of a PCC encompasses a 177 PCE acting as PCC when requesting a TE-LSP path computation of 178 another PCE (inter-PCE communication). Thus this document does not 179 make the distinction between PCE discovery by PCCs and PCE discovery 180 by PCEs. 182 4. Problem Statement and Requirements overview 184 4.1. Problem Statement 186 A routing domain may in practice be comprised of multiple PCEs: 187 -The path computation load may be balanced among a set of PCEs 188 to improve scalability; 189 -For the purpose of redundancy, primary and backup PCEs may be 190 used; 191 -PCEs may have distinct path computation capabilities (multi- 192 constrained path computation, backup path computation...); 193 -In an inter-domain context there can be several PCEs with 194 distinct path computation scopes (intra-area, inter-area, 195 inter-AS, inter-layer), each PCE being responsible for path 196 computation in one or more domains within its scope. 198 As an example, in a multi-area network made of one backbone area and 199 N peripheral areas, and where inter-area MPLS-TE path computation 200 relies on multiple-PCE path computation with ABRs acting as PCEs, the 201 backbone area would comprise at least N PCEs. In existing multi-area 202 networks, N can be quite large (e.g. beyond fifty). 204 In order to allow for efficient PCE selection by PCCs and efficient 205 load balancing of requests, a PCC has to know the location of PCEs in 206 its domain, along with their capabilities, and also potentially of 207 some relevant PCEs in other domains (for inter-domain path 208 computation purpose). 209 Such PCE information could be learnt through manual configuration, on 210 each PCC, of the set of PCEs along with their capabilities and 211 scope(s). Such manual configuration approach may be sufficient, and 212 even desired in some particular situations, but it obviously faces 213 several limitations: 214 -This may imply a substantial configuration overhead (see the 215 above example with N PCEs); 216 -This would not allow a PCC to dynamically detect that a new 217 PCE is available, that an existing PCE is no longer available, 218 or that there is a change in the PCE's capabilities. 220 Furthermore, as with any manual configuration approach, this may lead 221 to undesirable configuration errors. 223 Hence, an automated PCE discovery mechanism allowing a PCC to 224 dynamically discover a set of PCEs and their capabilities is highly 225 desirable. 227 4.2. Requirements overview 229 A PCE discovery mechanism that satisfies the requirements set forth 230 in this document MUST allow a PCC to automatically discover the 231 location of one or more PCEs in its domain and also, potentially, of 232 PCEs in other domains, of interest for inter-domain path computation 233 purpose. 235 A PCE discovery mechanism MUST allow discovering the path computation 236 scope(s) of a PCE. It MUST also allow a PCC to discover the set of 237 one or more domains under the path computation responsibility of a 238 PCE. 240 A PCE discovery mechanism MUST allow PCCs to dynamically discover 241 that a new PCE has appeared or that there is a change in PCE 242 information. 244 It MUST also allow PCCs to dynamically discover that a PCE is no 245 longer available. 247 A PCE discovery mechanism SHOULD also allow PCCs to learn about a set 248 of PCE path computation capabilities. 250 5. Example of application scenario 252 <----------------AS1--------------------> <----AS2--- 253 Area 1 Area 0 Area 2 254 R1---------R3-----R5-------R6-----------R9----------R11----R13 255 | | | | | 256 | | | | | 257 R2---------R4-----R7-------R8-----------R10---------R12----R14 259 S1 261 Figure 1. 263 Figure 1 above illustrates a network with several PCEs: 264 -The ABR R3 is a composite PCE that can take part in inter area path 265 computation. It can compute paths in area 1 and area 0. 266 -The ABR R6 is a composite PCE that can take part in inter-area path 267 computation. It can compute paths in area 0 and area2 268 -The ASBR R9 is a composite PCE that can take part in inter-AS path 269 computation, responsible for path computation in AS1 towards AS2. 270 -The ASBR R12 is a composite PCE that can take part in inter-AS path 271 computation, responsible for path computation in AS2 towards AS1. 272 -The server S1 is an external PCE that can be used to compute diverse 273 paths and backup paths in area 1. 275 The PCE discovery mechanism will allow: 276 -each LSR in area 1 and 0 to dynamically discover R3, as a PCE for 277 inter-area path computation as well as its path computation domains: 278 area1 and area0. 279 -each LSR in area 0 and 2 to dynamically discover R6, as a PCE for 280 inter-area path computation, as well as its path computation domains: 281 area2 and area0. 282 -each LSR in AS1 and some PCEs in AS2 to dynamically discover R9 as a 283 PCE for inter-AS path computation as well as its path computation 284 domain: AS1 285 -each LSR in area 1 to dynamically discover S1, as a PCE for diverse 286 path computation and backup path computation in area1. 288 6. Detailed Requirements 290 6.1. PCE Information to be disclosed 292 The PCE discovery mechanism MUST disclose some PCE information that 293 will allow PCCs to select appropriate PCEs. 294 This section details the kind of information that has to be 295 disclosed. 297 6.1.1. Discovery of PCE Location 299 The PCE discovery mechanism MUST allow discovering, for a given PCE, 300 the IPv4 and/or IPv6 address to be used to reach the PCE. This 301 address will typically be a loop-back address that is always 302 reachable, if there is any connectivity to the PCE. 303 This address will be used by PCCs to communicate with a PCE, thanks 304 to a PCC-PCE communication protocol. 306 6.1.2. Discovery of PCE computation scopes and domain(s) under control 308 Inter-domain path computation is a key application of the PCE 309 architecture. This can rely on a multiple-PCE path computation, 310 where PCEs in each domain compute a part of the end-to-end path and 311 collaborate with each other to find the end-to-end-path. This can 312 also rely on a single-PCE path computation where a PCE has visibility 313 inside multiple domains and can compute an inter-domain path. 315 Hence the PCE discovery mechanism MUST allow discovering the path 316 computation scope of a PCE, i.e. if a PCE can be used to compute or 317 to take part in the computation of intra-area, inter-area or inter-AS 318 TE-LSP. Note that these path computation scopes are not mutually 319 exclusive. 321 Also the PCE discovery mechanism MUST allow discovering the set of 322 one or more domains under the path computation responsibility of a 323 PCE, i.e. where a PCE has visibility and can compute TE-LSP paths. 324 These domains can be identified using a domain identifier: For 325 instance, an IGP area can be identified by the Area ID (OSPF or 326 ISIS), and an AS can be identified by the AS number. 328 6.1.3. Discovery of PCE Capabilities 330 In the case where there are several PCEs with distinct capabilities, 331 available, a PCC has to select one or more appropriate PCEs. 333 For that purpose the PCE discovery mechanism SHOULD allow the 334 discovery of some PCE capabilities. 335 For the sake of illustration this could include for instance some 336 path computation related capabilities: 337 -The capability to compute MPLS-TE and/or GMPLS paths; 338 -The type of link and path constraints supported: e.g. 339 bandwidth, affinities, delay; 340 -The objective functions supported: e.g. shortest constrained 341 path, shortest bounded delay path; 342 -The capability to compute multiple paths in a synchronized 343 manner: e.g. diverse path computation, load balancing 344 computation; 345 -Some GMPLS specific capabilities: e.g. the supported interface 346 switching capabilities, the capability to compute multi-layer 347 paths. 348 And this could also include some general capabilities: 349 -The capability to handle request prioritization; 350 -The capability to authenticate PCCs and to be authenticated. 352 Such information regarding PCE capabilities could then be used by a 353 PCC to select an appropriate PCE from a list of candidate PCEs. 355 Note that the description of general and path computation specific 356 PCE capabilities is out of the scope of this document. It is expected 357 that this will be described in a separate document. 359 It is paramount that dynamic capability discovery MUST NOT generate 360 an excessive amount of information and SHOULD be limited to a small 361 set of generic capabilities. 362 If required, the exhaustive discovery of detailed capabilities could 363 be ensured by means of the PCC-PCE communication protocol. 364 Actually a tradeoff should be found between capability discovery by 365 the PCE discovery mechanism and by the PCC-PCE communication 366 protocol. One of the objectives of the PCE discovery mechanism is to 367 help PCCs to select appropriate PCEs and limit the likelihood of PCC- 368 PCE communication rejections that may occur in case a PCE cannot 369 support a given capability. 371 6.1.4. Discovery of Alternate PCEs 373 In the case of a PCE failure, a PCC has to select another PCE, if one 374 is available. It could be useful in various situations, to indicate a 375 set of one or more alternate PCEs that can be selected in case a 376 given PCE fails. 377 Hence the PCE Discovery mechanism SHOULD allow the advertising, for a 378 given PCE of the location of one or more assigned alternate PCEs. 380 6.2. Scope of PCE Discovery 382 The PCE Discovery mechanism MUST allow the control of the scope of 383 the PCE information discovery (IGP Area, AS, set of AS) on a per PCE 384 basis. In other words it MUST allow to control to which PCC or group 385 of PCCs the information related to a PCE may be disclosed. 387 The choice for the discovery scope of a given PCE MUST include the 388 followings: 390 -All PCCs in a single IGP area 392 -All PCCs in a set of adjacent IGP areas 394 -All PCCs in a single AS 396 -All PCCs in a set of ASes 398 -A set of one or more PCCs in a set of one or more ASes 400 Particularly this also implies that the PCE Discovery mechanism MUST 401 allow for the discovery of PCE information across IGP areas and 402 across AS boundaries. 404 Note that it MUST be possible to deactivate PCE discovery on a per 405 PCE basis. 407 6.3. PCE Information Synchronization 409 The PCE discovery mechanism MUST allow a PCC to detect any change in 410 the information related to a PCE (e.g. capability modifications). 412 In addition it MUST be possible to dynamically detect new PCEs. 414 The PCE Discovery Mechanism SHOULD allow such detection under 60 415 seconds. 417 Note that PCE capabilities are expected to be fairly stable and not 418 to change frequently. 420 6.4. Detecting PCE Liveliness 422 The PCE discovery mechanism MUST allow a PCC to detect when a PCE is 423 no longer alive. This allows a PCC to rapidly switch to another PCE 424 (for instance a predefined alternate PCE), and thus minimizes path 425 computation service disruption. 427 The PCE discovery mechanism SHOULD allow such PCE liveliness 428 detection under 60 seconds. 430 6.5. Discovery of PCE capacity and congestion 432 PCE WG feedback is requested on the following items: 433 -Is there a need for the discovery of PCE capacity in terms of 434 computation power? This static parameter could be used to 435 ensure weighted load balancing of requests in case PCEs do not 436 have the same capacity. 437 -Would it be useful that a PCE report its status as "congested" 438 in case it is too busy? PCCs may then use this dynamic 439 information to prefer a different PCE. 441 6.6. Extensibility 443 The PCE discovery mechanism MUST be flexible and extensible so as to 444 easily allow for the addition of some additional PCE information that 445 could be defined in the future. 447 6.7. Scalability 449 The PCE discovery mechanism MUST be designed to scale well with an 450 increase of any of the following parameters: 451 -Number of PCCs; 452 -Number of PCEs; 453 -Number of IGP Areas in the discovery scope; 454 -Number of ASs in the discovery scope. 456 Particularly, in case routing protocols (IGP, BGP) are extended to 457 support PCE discovery, the extensions MUST NOT cause a degradation in 458 routing protocol performance. The same applies to a signaling 459 solution that could serve for this communication. 461 6.8. PCE Selection 463 A PCC may have to select among a set of candidate PCEs that have the 464 same capabilities. A specific PCE selection procedure SHOULD be 465 defined in order to ensure consistent behaviour when doing load 466 balancing and avoid that all PCCs send the requests to only one PCE. 467 The precise requirements and mechanisms for this function are out of 468 the scope of this document. It is expected that this requirement will 469 be covered in another document. 471 7. Security Considerations 473 PCE discovery and particularly inter-AS PCE discovery may raise new 474 security issues. PCE discovery procedures or protocol extensions MUST 475 deliver the operational security objectives where required. The 476 overall security objectives of confidentiality, integrity and 477 availability may take on varying level of importance. These 478 objectives MAY be met by other established means and protocols. 480 The PCE discovery mechanism MUST be able to restrict the scope of 481 discovery to a set of authorized PCCs. The identity of any PCE MUST 482 only be learnt by authorized PCCs. It MUST be possible to encrypt 483 discovery information. 485 Note that a threat analysis of the proposed procedures and/or 486 protocol extensions SHOULD address masquerade, eavesdropping, 487 unauthorized access, loss or corruption of information (includes 488 replay attacks), repudiation, forgery and denial of service attacks. 490 8. Acknowledgments 492 We would like to thank Benoit Fondeviole, Thomas Morin, Emile 493 Stephan, Jean-Philippe Vasseur, Dean Cheng and Mohamed Boucadair for 494 their useful comments and suggestions. 496 9. References 498 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 499 Requirement Levels", BCP 14, RFC 2119, March 1997. 501 [RFC3667] Bradner, S., "IETF Rights in Contributions", BCP 78, RFC 502 3667, February 2004. 504 [RFC3668] Bradner, S., "Intellectual Property Rights in IETF 505 Technology", BCP 79, RFC 3668, February 2004. 507 [PCE-ARCH] Farrel, A., Vasseur, J.P., Ash, J., "Path Computation 508 Element (PCE) Architecture", draft-ietf-pce-architecture-00.txt, work 509 in progress. 511 [PCE-COM-REQ] Ash, J., Le Roux, J.L., " PCE Communication Protocol 512 Generic Requirements", draft-ietf-pce-comm-protocol-gen-reqs-00.txt, 513 work in progress. 515 10. Authors' Addresses: 517 Jean-Louis Le Roux 518 France Telecom 519 2, avenue Pierre-Marzin 520 22307 Lannion Cedex 521 FRANCE 522 Email: jeanlouis.leroux@francetelecom.com 524 Paul Mabey 525 Qwest Communications 526 950 17th Street, 527 Denver, CO 80202, 528 USA 529 Email: pmabey@qwest.com 531 Eiji Oki 532 NTT 533 Midori-cho 3-9-11 534 Musashino-shi, Tokyo 180-8585, 535 JAPAN 536 Email: oki.eiji@lab.ntt.co.jp 538 Richard Rabbat 539 Fujitsu Laboratories of America 540 1240 East Arques Ave, MS 345 541 Sunnyvale, CA 94085 542 USA 543 Email: richard@us.fujitsu.com 545 Ting Wo Chung 546 Bell Canada 547 181 Bay Street, Suite 350 548 Toronto, Ontario, M5J 2T3 549 CANADA, 550 Email: ting_wo.chung@bell.ca 552 Raymond Zhang 553 BT Infonet 554 2160 E. Grand Ave. 555 El Segundo, CA 90025 556 USA 557 Email: raymond_zhang@infonet.com 559 11. Intellectual Property Statement 561 The IETF takes no position regarding the validity or scope of any 562 Intellectual Property Rights or other rights that might be claimed to 563 pertain to the implementation or use of the technology described in 564 this document or the extent to which any license under such rights 565 might or might not be available; nor does it represent that it has 566 made any independent effort to identify any such rights. Information 567 on the procedures with respect to rights in RFC documents can be 568 found in BCP 78 and BCP 79. 570 Copies of IPR disclosures made to the IETF Secretariat and any 571 assurances of licenses to be made available, or the result of an 572 attempt made to obtain a general license or permission for the use of 573 such proprietary rights by implementers or users of this 574 specification can be obtained from the IETF on-line IPR repository at 575 http://www.ietf.org/ipr. 577 The IETF invites any interested party to bring to its attention any 578 copyrights, patents or patent applications, or other proprietary 579 rights that may cover technology that may be required to implement 580 this standard. Please address the information to the IETF at 581 ietf-ipr@ietf.org. 583 Disclaimer of Validity 585 This document and the information contained herein are provided on an 586 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 587 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY AND THE INTERNET 588 ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, 589 INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE 590 INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 591 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 593 Copyright Statement 595 Copyright (C) The Internet Society (2005). This document is subject 596 to the rights, licenses and restrictions contained in BCP 78, and 597 except as set forth therein, the authors retain all their rights.