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