idnits 2.17.1 draft-marocco-alto-problem-statement-03.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 16. -- Found old boilerplate from RFC 3978, Section 5.5, updated by RFC 4748 on line 563. -- Found old boilerplate from RFC 3979, Section 5, paragraph 1 on line 574. -- Found old boilerplate from RFC 3979, Section 5, paragraph 2 on line 581. -- Found old boilerplate from RFC 3979, Section 5, paragraph 3 on line 587. 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 : ---------------------------------------------------------------------------- ** 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.) Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust Copyright Line does not match the current year -- The document seems to lack a disclaimer for pre-RFC5378 work, but may have content which was first submitted before 10 November 2008. If you have contacted all the original authors and they are all willing to grant the BCP78 rights to the IETF Trust, then this is fine, and you can ignore this comment. If not, you may need to add the pre-RFC5378 disclaimer. (See the Legal Provisions document at https://trustee.ietf.org/license-info for more information.) -- The document date (November 2, 2008) is 5654 days in the past. Is this intentional? Checking references for intended status: Informational ---------------------------------------------------------------------------- No issues found here. Summary: 2 errors (**), 0 flaws (~~), 1 warning (==), 7 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group E. Marocco 3 Internet-Draft Telecom Italia 4 Intended status: Informational V. Gurbani 5 Expires: May 6, 2009 Bell Laboratories, Alcatel-Lucent 6 November 2, 2008 8 Application-Layer Traffic Optimization (ALTO) Problem Statement 9 draft-marocco-alto-problem-statement-03 11 Status of this Memo 13 By submitting this Internet-Draft, each author represents that any 14 applicable patent or other IPR claims of which he or she is aware 15 have been or will be disclosed, and any of which he or she becomes 16 aware will be disclosed, in accordance with Section 6 of BCP 79. 18 Internet-Drafts are working documents of the Internet Engineering 19 Task Force (IETF), its areas, and its working groups. Note that 20 other groups may also distribute working documents as Internet- 21 Drafts. 23 Internet-Drafts are draft documents valid for a maximum of six months 24 and may be updated, replaced, or obsoleted by other documents at any 25 time. It is inappropriate to use Internet-Drafts as reference 26 material or to cite them other than as "work in progress." 28 The list of current Internet-Drafts can be accessed at 29 http://www.ietf.org/ietf/1id-abstracts.txt. 31 The list of Internet-Draft Shadow Directories can be accessed at 32 http://www.ietf.org/shadow.html. 34 This Internet-Draft will expire on May 6, 2009. 36 Copyright Notice 38 Copyright (C) The IETF Trust (2008). 40 Abstract 42 A significant part of the Internet traffic today is generated by 43 peer-to-peer applications used, for example, for file sharing, 44 realtime communications and live media streaming. Such applications 45 often deal with large amounts of data in direct peer-to-peer 46 connections, but they usually have little knowledge of the underlying 47 network topology. As a result, they may choose their peers based on 48 measurements and statistics which, in some situations, may lead to 49 suboptimal choices. This document describes problem related to 50 optimizing traffic generated by peer-to-peer applications through the 51 use of network-layer information, provides a representative set of 52 use cases that may exhibit this problem, and outlines considerations 53 that have to be taken in account when arriving at equitable 54 solutions. 56 Table of Contents 58 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 59 1.1. Research or Engineering? . . . . . . . . . . . . . . . . . 4 60 2. Definitions . . . . . . . . . . . . . . . . . . . . . . . . . 4 61 3. The Problem . . . . . . . . . . . . . . . . . . . . . . . . . 6 62 4. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 63 4.1. File sharing . . . . . . . . . . . . . . . . . . . . . . . 7 64 4.2. Cache/Mirror Selection . . . . . . . . . . . . . . . . . . 7 65 4.3. Live Media Streaming . . . . . . . . . . . . . . . . . . . 8 66 4.4. Realtime Communications . . . . . . . . . . . . . . . . . 8 67 4.5. Distributed Hash Tables . . . . . . . . . . . . . . . . . 8 68 5. Solution Considerations . . . . . . . . . . . . . . . . . . . 8 69 5.1. ALTO Service Providers . . . . . . . . . . . . . . . . . . 8 70 5.2. Discovery of ALTO servers . . . . . . . . . . . . . . . . 9 71 5.3. User Privacy . . . . . . . . . . . . . . . . . . . . . . . 9 72 5.4. Topology Hiding . . . . . . . . . . . . . . . . . . . . . 9 73 5.5. Coexistence with Caching . . . . . . . . . . . . . . . . . 9 74 6. Security Considerations . . . . . . . . . . . . . . . . . . . 10 75 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 76 8. Informative References . . . . . . . . . . . . . . . . . . . . 11 77 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12 78 Intellectual Property and Copyright Statements . . . . . . . . . . 13 80 1. Introduction 82 A significant part of the Internet traffic today is generated by 83 peer-to-peer (P2P) applications used, for example, for file sharing, 84 realtime communications and live media streaming 85 [WWW.cachelogic.picture] [WWW.wired.fuel]. Different from the 86 client/server architecture, P2P applications access resources (e.g. 87 files or media relays) distributed across the Internet and exchange 88 large amounts of data in connections that they establish directly 89 with nodes sharing such resources. 91 One advantage of P2P systems arises from the fact that the resources 92 such systems offer are often made available through multiple 93 replicas. Yet applications generally do not have reliable 94 information of the underlying network and thus have to select among 95 available instances based on information they deduce from empirical 96 measurements which, in some situations, lead to suboptimal choices. 98 For example, popular metrics based on round trip time estimation 99 sometimes used for initial sources selection (i.e. before actual 100 data transmissions begin, when goodput values are unknown) perform 101 quite badly for file sharing applications as they tend to ignore 102 bandwidth and reliability of underlying links, which have much 103 more influence than delay on file transfers. 105 Many of the existing P2P systems are based on an overlay network 106 consisting of direct connections peers establish among themselves; 107 such connections, obviously, do not account for the underlying 108 network topology. In addition to simply achieving suboptimal 109 performance, such networks can lead to congestions and cause serious 110 inefficiencies. As shown in [ACM.fear], traffic generated by popular 111 P2P applications often cross network boundaries multiple times, 112 overloading links which are frequently subject to congestion 113 [ACM.bottleneck]. 115 Recent studies [ACM.ispp2p] [WWW.p4p.overview] [ACM.ono] have shown 116 that if Internet Service Providers (ISP), network operators or third 117 parties in general provide reliable network information such as 118 topology and/or bandwidth to P2P applications, it would be possible 119 to greatly increase application performance, reduce congestion and 120 optimize the overall traffic across different networks. This 121 document gives the problem statement of optimizing traffic generated 122 by P2P applications using information provided by a separate party. 124 The rest of this document is structured as follows. Section 3 125 introduces the problem more formally. Section 4 describes some use 126 cases where both P2P applications and network operators would benefit 127 from a solution to such a problem. Section 5 describes the main 128 issues to consider when designing such a solution. 130 1.1. Research or Engineering? 132 At the time of writing, several solutions have been proposed to 133 address the problem described in this document, both inside and 134 outside the IETF accompanied by encouraging simulation and field test 135 results [I-D.bonaventure-informed-path-selection] [ACM.ispp2p] 136 [WWW.p4p.overview]. Such solutions have been proposed independently, 137 but all consists of two essential parts: 138 o a discovery mechanism which can be used by a P2P application to 139 find a reliable information source; 140 o a protocol used by P2P applications to query such sources in order 141 to retrieve the information needed to perform better-than-random 142 selection of the endpoints providing a desired resource. 144 It is not easy to foresee how such solutions would perform in the 145 Internet, but a more accurate evaluation would require representative 146 data collected from real systems by a critical mass of users. 148 However, wide adoption will probably never happen without an 149 agreement on a common solution based on open standard. 151 2. Definitions 153 The following terms have special meaning in the definition of the 154 Application-Layer Traffic Optimization (ALTO) problem. 156 Application: A distributed communication system (e.g., file sharing) 157 that uses the ALTO service to improve its performance (or quality 158 of experience) while reducing resource consumption in the 159 underlying network infrastructure. Applications may use the P2P 160 model to organize themselves, or they can be simple client-server 161 based, or even a hybrid of both. 162 Peer: A specific participant in an application. Colloquially, a 163 peer refers to a participant in a P2P network or system, and this 164 definition does not violate that assumption. If the application 165 is based on a client-server or hybrid model, then the usage of the 166 terms "client" and "server" imparts enough context for dis- 167 ambiguity. 168 Resource: A piece of content (e.g. a file or a chunk of a file) or a 169 server process (e.g. for relaying a media stream or for perfoming 170 a computation) which can be accessed by applications. In the ALTO 171 context a resource is often available in several equivalent 172 replicas, shared by different peers. 174 Resource Identifier: An application layer identifier used to 175 identify a resource, no matter how many replicas thereof exist. 176 Resource Provider: For P2P applications, a resource provider is a 177 specific peer that provides some resources. For client-server or 178 hybrid applications, a provider is a server that hosts a resource. 179 Resource Consumer: For P2P applications, a resource consumer is a 180 specific peer that needs to access resources. For client-server 181 or hybrid applications, a consumer is a client that needs to 182 access resources. 183 Transport Address: All address information that is needed by a 184 resource consumer to access the desired resource at a specific 185 resource provider. This information usually consists of the 186 resource provider's IP address, and it may include other 187 information, such as a transport protocol identifier or port 188 numbers. 189 Overlay Network: A virtual network consisting of direct connections 190 on top of another network, established by a group of peers. This 191 logical structure, which can be used to implement distributed 192 applications, may benefit from guidance from the ALTO service. 193 Resource Directory: An entity which is separate from the resource 194 consumer, and which assists a resource consumer to identify a set 195 of resource providers. In P2P applications, the resource 196 directory may be referred to as a P2P tracker. Some applications 197 do not use this concept and do the address mapping directly in the 198 resource consumer. 199 Host Location Attribute: Information which is related to the 200 location of a host in the network topology. The ALTO service 201 gives recommendations based on this information. A host location 202 attribute may consist, for example, of an IP address, an address 203 prefix or address range that contains the host, an autonomous 204 system (AS) number, or any other localization attribute. These 205 different options may provide different levels of detail. 206 Depending on the system architecture, this may have implications 207 on the quality of the recommendations ALTO is able to provide, on 208 whether recommendations can be aggregated, and on how much 209 privacy-sensitive information about users might be disclosed to 210 additional parties. 211 ALTO Service: If several resource providers are able to provide the 212 same resource, the ALTO service gives guidance to a resource 213 consumer or resource directory, on which resource provider(s) to 214 select, in order to optimize its performance (or quality of 215 experience) while minimizing resource consumption in the 216 underlying network infrastructure. 217 ALTO Server: A logical entity that provides interfaces that can be 218 used to query the ALTO service. 220 ALTO Client: The logical entity that sends ALTO queries. Depending 221 on the architecture of the application it may be embedded in the 222 resource consumer or in the resource directory. 223 ALTO Query: A message sent from an ALTO client to an ALTO server, 224 which requests guidance from the ALTO Service. 225 ALTO Reply: A message sent from an ALTO server to an ALTO client, 226 which contains guiding information from the ALTO service. 227 ALTO Transaction: An ALTO transaction consists of an ALTO query and 228 the corresponding ALTO reply. 229 Local Traffic: Internet traffic which stays within the network 230 infrastructure of one Internet Service Providers (ISP). This type 231 of traffic usually causes the least costs for the ISP. 232 Peering Traffic: Internet traffic exhcanged by two Internet Service 233 Providers whose networks are directly connected. Apart from 234 infrastructure and operational costs, peering traffic is usually 235 free, within the contract of a peering agreement. 236 Transit Traffic: Internet traffic exchanged on the basis of economic 237 agreements between Internet Service Providers (ISP). An ISP 238 generally pays a transit provider for the delivery of traffic 239 flowing between its network and networks that are not directly 240 connected. 242 3. The Problem 244 Network engineers have been facing the problem of traffic 245 optimization for a long time now and have already designed mechanisms 246 like MPLS [RFC3031] and DiffServ [RFC3260] to deal with it. The 247 problem they address consists in finding (or setting) optimal routes 248 for packets traveling between specific source and destination 249 addresses and based on requirements such as low latency, high 250 reliability, and priority. Such solutions are usually implemented at 251 the link and network layers, and tend to be almost transparent. At 252 best, applications can only "mark" the traffic they generate with the 253 corresponding properties. 255 However, P2P applications that are today posing serious challenges to 256 Internet infrastructures, do not benefit much from the above 257 techniques and "cooperating" with external services aware of the 258 network topology could greatly optimize the traffic they generate. 259 In fact, when a P2P application needs to establish a connection, the 260 logical target is not a host, but rather a resource (e.g. a file or a 261 media relay) generally available in multiple instances on different 262 peers; selection of the closest one -- or, in general, the best from 263 an overlay topological proximity -- has much more impact on the 264 overall traffic than the route followed by its packets to reach the 265 endpoint. 267 Optimization of the peer selection is particularly important in the 268 initial phase of the process. Consider a P2P protocol such as 269 BitTorrent, where a querying peer receives a list of candidate 270 destinations where a resource resides. From this list, the peer will 271 derive a smaller set of candidates to connect to and exchange 272 information with. In another example, a streaming video client may 273 be provided with a list of destinations from which it can download 274 content from. In both cases, the use of topology information in an 275 early stage will allow applications to improve their performance and 276 will help ISPs make a better use of their network resources (in 277 particular, reducing the transit traffic on interdomain links). 279 Addressing the Application-Layer Traffic Optimization (ALTO) problem 280 means, on the one hand, deploying an ALTO service to provide 281 applications with information regarding the underlying network and, 282 on the other hand, enhancing applications in order to use such 283 information to perform better-than-random selection of the endpoints 284 they establish connections with. 286 4. Use Cases 288 4.1. File sharing 290 File sharing applications allow users to search for content shared by 291 other users and download it. Typically, search results consist of 292 many instances of the same file (or chunk of a file) available from 293 multiple sources; the goal of an ALTO solution would be to help peers 294 find the best ones according to the underlying networks. 296 On the application side, integration of ALTO functionalities may 297 happen at different levels. For example, while in the completely 298 decentralized Gnutella network selection of the best sources is 299 totally up to the user, in systems like BitTorrent and eDonkey, 300 central elements (i.e. trackers or servers) act as mediators. 301 Therefore, in the former case, optimization would require 302 modification in the applications, while in the latter it could just 303 be implemented in some central elements. 305 4.2. Cache/Mirror Selection 307 Providers of popular content like media and software repositories 308 usually resort to geographically distributed caches and mirrors for 309 load balancing. Selection of the proper mirror/cache for a given 310 user is today based on inaccurate geolocation data, on proprietary 311 network location systems or often delegated to the user himself. An 312 ALTO solution could be easily adopted to ease such a selection in an 313 automated way. 315 4.3. Live Media Streaming 317 P2P applications for live streaming allow users to receive multimedia 318 content produced by one source and targeted to multiple destinations, 319 in a realtime or near-realtime way without recurring to multicast. 320 Such applications typically participate in the distribution of the 321 content, acting as both receivers and senders; the goal of an ALTO 322 solution would be to help peers to find the best sources and the best 323 destinations for media flows they receive and relay. 325 4.4. Realtime Communications 327 P2P realtime communications allow users to establish direct media 328 flows, usually to place audio and video calls, or to have text chats. 329 In the basic case, media would flow directly between the two 330 endpoints; however, in the general case, a significant portion of 331 communications between users with limited access to the Internet 332 (e.g. users behind NATs, firewalls or HTTP proxies) need to be 333 relayed by other elements. Such media relays are distributed over 334 the Internet -- in some cases co-located with applications with a 335 public address; the goal of an ALTO solution would be to help peers 336 to find the best relays. 338 4.5. Distributed Hash Tables 340 Distributed hash tables (DHT) are a class of overlay algorithms used 341 to implement lookup functionalities in popular P2P systems, without 342 recurring to centralized elements. In such systems, peers maintain 343 addresses of other peers participating in the same DHT in a routing 344 table, sorted according to specific criteria. An ALTO solution would 345 provide valuable information for DHT algorithms which, in order to 346 reduce path latency of distributed queries, include round trip time 347 estimations among such criteria [SIGCOMM.resprox]. 349 5. Solution Considerations 351 This section introduces some aspects to keep in consideration when 352 designing an ALTO service to provide applications with information 353 they can use to perform better-than-random peer selection. 355 5.1. ALTO Service Providers 357 ALTO services can be provided by at least three different kinds of 358 entity: 359 1. Network operators: usually have full knowledge of the network 360 they administer and are aware of the topology and policies that 361 transit and peering traffic are subject to; 363 2. Third parties: entities different from the network operators, but 364 which may have collected network information. Examples of such 365 entities are content delivery networks (like Akamai) which 366 control wide and highly distributed infrastructures, or companies 367 providing an ALTO service on behalf of ISPs (and thus acquire the 368 information from the ISPs themselves); 369 3. User communities: running distributed algorithms, for example for 370 estimating the topology of the Internet. 372 5.2. Discovery of ALTO servers 374 As a direct consequence of the totally decentralized architecture of 375 the Internet, it seems almost impossible to centralize all 376 information P2P applications may need to optimize traffic they 377 generate. Therefore, any solution for the ALTO problem will need to 378 specify a mechanism for applications to find a proper ALTO server to 379 query. 381 It is important to note that, depending on the implementation of the 382 ALTO service, an ALTO server could be a centralized entity for 383 example deployed by the network operator as well as a volatile node 384 participating in a distributed algorithm. 386 5.3. User Privacy 388 Information provided by the ALTO client querying the ALTO server 389 could help increase the level of accuracy in the replies. For 390 example, if the querying client indicates what kind of application it 391 is using (e.g. realtime communications or bulk data transfer), the 392 server will be able to indicate priorities in its replies 393 accomodating the requirements of the traffic the application will 394 generate. However, it is important that for using an ALTO service 395 the application does not have to disclose information it may consider 396 sensible. 398 5.4. Topology Hiding 400 Operators can play an important role in addressing the ALTO problem, 401 but they generally consider network information they own to be 402 confidential; therefore, in order to succeed and achieve wide 403 adoption, any solution should provide a method to help P2P 404 applications in peer selection without explicitly disclosing topology 405 of the underlying network. 407 5.5. Coexistence with Caching 409 A common approach to optimizing traffic generated by applications 410 which require large data transfers is based on caching techniques. 412 In some cases, such techniques have proven to be extremely effective 413 in both enhancing user experience and saving network resources; 414 however, they have two main limits in respect to the solutions based 415 on provision of topology information: 416 1. Application specificity: since a cache is meant to replace the 417 source of the content being accessed -- either explicitly or 418 transparently -- it must be able to speak the same protocol with 419 the querying peer. For this reason, caching solutions can be 420 reasonably adopted only for most popular applications (e.g. HTTP 421 and BitTorrent). 422 2. Content awareness: since caches need to actually store the 423 content being delivered, they are subject to legal threats 424 whenever the user does not have the right to access or distribute 425 such content. This limitation makes caching approaches unusable 426 in today's popular file sharing systems. 428 In general, solutions based on provision of topology information need 429 not to interfere with caching; to the contrary, if ALTO service used 430 by applications is aware of the presence of chaches, it can point 431 them out in its replies with higher priorities and thus achieve 432 greater optimization. 434 6. Security Considerations 436 The approach proposed in this document requires P2P applications to 437 delegate a portion of their routing capability to third parties, 438 giving them a significant role in systems where that would be 439 otherwise excluded. 441 In the case where an ALTO solution is deployed by the network 442 operator, it is conceivable that the P2P community would consider it 443 hostile because the operator could, for example: 444 o redirect applications to corrupted mediators providing malicious 445 content; 446 o track connections to perform content inspection; 447 o apply policies based on criteria other than network efficiency 448 (for example, to avoid peering points regulated by inconvenient 449 economic agreements). 451 However, ALTO is completely optional for P2P applications and its 452 purpose is to help improve performance of such applications. If, for 453 some reason, it fails to achieve this purpose, it would simply fail 454 to gain popularity and would not be used. 456 Even in cases where the ALTO service provider would decide to 457 maliciously alter results returned by queries only after the solution 458 has gained popularity (i.e. it behaves for a while to become popular 459 and then starts misbehaving), it would be fairly easy for P2P 460 application maintainers and users to revert to solutions that are not 461 using it. After all, it would all come down to change some 462 application settings in cases where the protocol is implemented 463 inside the client and upgrading centralized elements for 464 architectures like BitTorrent and eDonkey. 466 7. Acknowledgments 468 Vinay Aggarwal and the P4P working group conducted the research work 469 done outside the IETF. Emil Ivov, Rohan Mahy, Anthony Bryan, 470 Stanislav Shalunov, Laird Popkin, Stefano Previdi, Reinaldo Penno, 471 Dimitri Papadimitriou, Sebastian Kiesel, and many others provided 472 insightful discussions, specific comments and much needed 473 corrections. 475 Thanks in particular to Richard Yang for several reviews. 477 8. Informative References 479 [ACM.bottleneck] 480 Akella, A., Seshan, S., and A. Shaikh, "An Empirical 481 Evaluation of WideArea Internet Bottlenecks", Proceedings 482 of ACM SIGCOMM, October 2003. 484 [ACM.fear] 485 Karagiannis, T., Rodriguez, P., and K. Papagiannaki, 486 "Should ISPs fear Peer-Assisted Content Distribution?", 487 In ACM USENIX IMC, Berkeley 2005. 489 [ACM.ispp2p] 490 Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs 491 and P2P systems co-operate for improved performance?", In 492 ACM SIGCOMM Computer Communications Review (CCR), 37:3, 493 pp. 29-40. 495 [ACM.ono] Choffnes, D. and F. Bustamante, "Taming the Torrent: A 496 practical approach to reducing cross-ISP traffic in P2P 497 systems", Proceedings of ACM SIGCOMM, August 2008. 499 [I-D.bonaventure-informed-path-selection] 500 Saucez, D. and B. Donnet, "The case for an informed path 501 selection service", 502 draft-bonaventure-informed-path-selection-00 (work in 503 progress), February 2008. 505 [RFC3031] Rosen, E., Viswanathan, A., and R. Callon, "Multiprotocol 506 Label Switching Architecture", RFC 3031, January 2001. 508 [RFC3260] Grossman, D., "New Terminology and Clarifications for 509 Diffserv", RFC 3260, April 2002. 511 [SIGCOMM.resprox] 512 Gummadi, K., Gummadi, R., Ratnasamy, S., Gribble, S., 513 Shenker, S., and I. Stoica, "The impact of DHT routing 514 geometry on resilience and proximity", Proceedings of ACM 515 SIGCOMM, August 2003. 517 [WWW.cachelogic.picture] 518 Parker, A., "The true picture of peer-to-peer 519 filesharing", . 521 [WWW.p4p.overview] 522 Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang, 523 "P4P: Explicit Communications for Cooperative Control 524 Between P2P and Network Providers", 525 . 527 [WWW.wired.fuel] 528 Glasner, J., "P2P fuels global bandwidth binge", 529 . 531 Authors' Addresses 533 Enrico Marocco 534 Telecom Italia 535 Via G. Reiss Romoli, 274 536 Turin 10148 537 Italy 539 Email: enrico.marocco@telecomitalia.it 541 Vijay K. Gurbani 542 Bell Laboratories, Alcatel-Lucent 543 1960 Lucent Lane 544 Naperville, IL 60566 545 USA 547 Email: vkg@alcatel-lucent.com 549 Full Copyright Statement 551 Copyright (C) The IETF Trust (2008). 553 This document is subject to the rights, licenses and restrictions 554 contained in BCP 78, and except as set forth therein, the authors 555 retain all their rights. 557 This document and the information contained herein are provided on an 558 "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS 559 OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND 560 THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS 561 OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF 562 THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED 563 WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. 565 Intellectual Property 567 The IETF takes no position regarding the validity or scope of any 568 Intellectual Property Rights or other rights that might be claimed to 569 pertain to the implementation or use of the technology described in 570 this document or the extent to which any license under such rights 571 might or might not be available; nor does it represent that it has 572 made any independent effort to identify any such rights. Information 573 on the procedures with respect to rights in RFC documents can be 574 found in BCP 78 and BCP 79. 576 Copies of IPR disclosures made to the IETF Secretariat and any 577 assurances of licenses to be made available, or the result of an 578 attempt made to obtain a general license or permission for the use of 579 such proprietary rights by implementers or users of this 580 specification can be obtained from the IETF on-line IPR repository at 581 http://www.ietf.org/ipr. 583 The IETF invites any interested party to bring to its attention any 584 copyrights, patents or patent applications, or other proprietary 585 rights that may cover technology that may be required to implement 586 this standard. Please address the information to the IETF at 587 ietf-ipr@ietf.org. 589 Acknowledgment 591 Funding for the RFC Editor function is provided by the IETF 592 Administrative Support Activity (IASA).