Network Working Group S. Das Internet-Draft V. Narayanan Intended status: Standards Track L. Dondeti Expires: April 26, 2009 Qualcomm, Inc. October 23, 2008 ALTO: A Multi Dimensional Peer Selection Problem draft-saumitra-alto-multi-ps-00 Status of this Memo By submitting this Internet-Draft, each author represents that any applicable patent or other IPR claims of which he or she is aware have been or will be disclosed, and any of which he or she becomes aware will be disclosed, in accordance with Section 6 of BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF), its areas, and its working groups. Note that other groups may also distribute working documents as Internet- Drafts. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." The list of current Internet-Drafts can be accessed at http://www.ietf.org/ietf/1id-abstracts.txt. The list of Internet-Draft Shadow Directories can be accessed at http://www.ietf.org/shadow.html. This Internet-Draft will expire on April 26, 2009. Abstract Bulk data applications are posing serious challenges to the Internet infrastructure and more mass adoption of such applications would only increase that challenge. P2P bulk data applications and other large volume HTTP traffic such as video currently dominate the Internet traffic. These applications do not generally benefit from the traffic engineering techniques developed for the Internet. In the HTTP traffic case, the traffic optimization issues are often addressed using the CDN infrastructure. For P2P bulk data applications, the problem is about picking the right peers to communicate with and the criteria for doing this vary greatly based on the application. Hence, intelligent peer selection is the Das, et al. Expires April 26, 2009 [Page 1] Internet-Draft multi October 2008 fundamental problem to address for these applications. This document explains the multiple dimensions of the peer selection problem with respect to obtaining information from the network as well from other peers and argues for an integrated, common framework to share such information. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 3. Problem Statement . . . . . . . . . . . . . . . . . . . . . . 5 3.1. Network-assisted ALTO . . . . . . . . . . . . . . . . . . 6 3.2. Peer-assisted ALTO . . . . . . . . . . . . . . . . . . . . 6 3.3. The need for multiple criterion . . . . . . . . . . . . . 6 3.3.1. Peer-assisted ALTO alone . . . . . . . . . . . . . . . 7 3.3.2. Network-assisted ALTO alone . . . . . . . . . . . . . 7 3.4. Applicability and Discussion . . . . . . . . . . . . . . . 8 4. Design Goals . . . . . . . . . . . . . . . . . . . . . . . . . 9 5. Security Considerations . . . . . . . . . . . . . . . . . . . 11 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 7. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 8.2. Informative References . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Intellectual Property and Copyright Statements . . . . . . . . . . 14 Das, et al. Expires April 26, 2009 [Page 2] Internet-Draft multi October 2008 1. Introduction A large portion of the Internet traffic today is from P2P (peer-to- peer) applications. Such an architecture for data transfer is attractive because it reduces the bandwidth costs of the content provider since they simply need to seed the content to a few nodes in the network which would then contribute upload bandwidth to assist the content provider's servers in the data transfer. Thus, the single point bottleneck at the content provider is eliminated and both users and content providers benefit. However such an approach is detrimental to another important entity in the system: the ISPs. While p2p has led to increased popularity of broadband connections and arguably increased subscribers for ISPs; it has also increased traffic costs for the ISPs. This is because P2P applications' peer selection does not consider underlying network topology and link costs in that topology. Most p2p applications typically are only interested in improving their data transfer performance which is satisfied if the download link of the user is saturated. As shown in [2], traffic generated by popular P2P applications often cross network boundaries multiple times, overloading links which are frequently subject to congestion [3]. This happens because most p2p applications simply use random peer selection followed by monitoring and reevaluation. Even if p2p applications perform some network measurements, these typically tend to be round trip time estimation which may or may not lead to peer selection conducive to ISP interests. This led to ISPs efforts at shaping or blocking P2P traffic on specific ports. In response, p2p applictions started using dynamic ports to transfer data following whcih ISPs had to use deep packet protocol specific information to shape p2p flows. In response, p2p applications have started encrypting their connections. The use of TCP RST messages to deter costly p2p application data transfer has led to some conflicts as well. It is in the ISP's interests to avoid the cat-and-mouse games of protocol-specific detection and mitigation while still not having to increase costs significantly to accomodate p2p traffic. One way to reduce the impact on ISPs would be the deployment of caching entities in the networks to reduce cross-ISP traffic and network distance of data transfer. However such an approach has several issues: o It is not clear who would deploy these high-bandwidth large- storage capable caches since it can be argued that caching pushes the costs from the content provider to the ISPs Das, et al. Expires April 26, 2009 [Page 3] Internet-Draft multi October 2008 o The caches would need to be able to cache data from all p2p applications and consequently become complicated to deploy and maintain over time as p2p application evolve o The use of caches opens up the issue of storage of copyrighted content Thus, a solution is needed that can allow for peer selection by the p2p application themselves that is friendly to the ISP's network costs while being friendly to the applications' objective of good performance for the user. Recent studies [4], [5], [6] have suggested that it may be possible to reduce the impact that P2P applications have on ISPs traffic costs. This is mainly achieved by informed peer selection in the P2P applications guided by network level metrics instead of random selection. However, p2p applications do not have a trust relationship with network operators and what may be good for the ISP is not necessarily good for the performance of the p2p applications. These competing interests necessitate a solution for ALTO that addresses the interests of both the entities in the system. This document describes the problem of optimizing traffic generated by P2P applications using information provided by third parties, i.e. the other peers in the network or the network operator. The overall goal of optimizing the P2P application is for them to become more network-friendly, while at the same time allowing the networks to remain application-friendly. The following are key arguments that we put forth in this draft: o The problem of peer selection needs to take into account the interests of the ISPs, application providers and the peers. The goal should be to reduce the impact on ISP without sacrificing the performance of p2p applications. There are many situations we elaborate upon in Section 3 where simply considering ISP interests leads to poor performance for p2p applications. Information about peer connectivity characteristics is an important component of the ALTO problem of peer selection (in conjunction with ISP routing information) and together with network topology information, can enable peers to optimize their performance as well as take into account ISP interests. o An ALTO system with information about ISP routing alone does not provide enough incentives for adoption in p2p applications, due to the competing interests of the two parties and the lack of trust. Combining both elements of peer selection creates an incentive for p2p applications to actually use the ALTO service. Das, et al. Expires April 26, 2009 [Page 4] Internet-Draft multi October 2008 o Application-specific solutions for sharing peer connectivity characteristics are inefficient and cause unnecessary overhead in the network. A common information plane allows reuse of such information across a wide range of applications ranging from DHT next hop selection, multi-source file download, relay selection, mirror selection, etc., since many of the connectivity characteristics of peers such as upload/download bandwidth, network coordinate, wireless link information are useful to a multitude of p2p applications in peer selection. The rest of this draft is structured as follows. Section 3 introduces the problem and argues for the multiple criterion that need to be considered when developing solutions, while Section 4 describes the design goals of the system. 2. Terminology The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [1]. 3. Problem Statement Bulk data applications are posing serious challenges to the Internet infrastructure and more mass adoption of such applications would only increase that challenge. P2P bulk data applications and other large volume HTTP traffic such as video currently dominate the Internet traffic. These applications do not generally benefit from the traffic engineering techniques developed for the Internet. In the HTTP traffic case, the traffic optimization issues are often addressed using the CDN infrastructure. For P2P bulk data applications, the problem is about picking the right peers to communicate with and the criteria for doing this vary greatly based on the application. Hence, intelligent peer selection is the fundamental problem to address for these applications. One necessary input for intelligent peer selection has been shown to be network topology information. And, accurate network topology information can only be obtained with the help of ISPs. However, there is more to peer selection than just network topology information. Consider a Client Application at node A which wants to access a service for peer selection such as ALTO. Overall peer selection in ALTO can be performed using two sets of information: (1) One set of information is that from the network, i.e. network-assisted ALTO Das, et al. Expires April 26, 2009 [Page 5] Internet-Draft multi October 2008 which promotes peer selection that is beneficial to the ISP by either reducing the interdomain traffic or reducing congestion on bottleneck links inside the ISP. (2) The other set of information is from the set of potential Client Application Providers are targets for peer connectivity, i.e. peer-assisted ALTO. 3.1. Network-assisted ALTO Network-assisted application layer traffic optimization refers to the use of network operators in guiding peer selection for p2p applications. Network operators can use network topology and traffic statistics to provide hints to the P2P applications on which hosts it would prefer the application pick for data transfer. For example, peers that involve inter-domain routing would be given lower priority in the response to the querying P2P application. Another example would be that peers whose connectivity is such that their choice would increase the congestion on an already congested link inside the ISP. Such peers would also be given lower priority. Some recent work has proposed solutions in this space [5],[4]. 3.2. Peer-assisted ALTO Peer-assisted application layer traffic optimization refers to the use of published information about peers and their connectivity to the Internet in guiding peer selection for p2p applications. For example, BitTorrent-like data transfer applications would query metrics related to the peer of interest to decide on the peers to select for initial data transfer. This information could be for example the upload bandwidth of the peer. These choices could then be refined or changed by monitoring data connections. Another example would be for VoIP applications to query the ALTO service for peers that it wants to use as relays to find one with low latency. Altough latency information is pairwise the peer could publish its network coordinate calculated by a system such as GNP (Global Network Positioning) into the ALTO service which could then be retrieved and used by a querying peer to estimate network latency. Publishing peer connectivity could also involve edge-specific information such as which cell id a peer is connected to in a cellular network so that another peer in the same cell is discouraged from making a connection within the same cell to minimize the congestion and avoid occuping 2 downlink and 2 uplink channels in the same cell. This type of traffic optimization cannot be acheived via network-assisted ALTO. 3.3. The need for multiple criterion This section justifies the need for multiple criterion in ALTO: i.e. the need for both ISP related information and peer related information. Note that the underlying assumption is that peers and Das, et al. Expires April 26, 2009 [Page 6] Internet-Draft multi October 2008 ISPs may not necessarily trust each other and thus any solution in this space needs to consider the interests of both parties. 3.3.1. Peer-assisted ALTO alone It is already well known that using peer related information alone is not enough. Simply randomly selecting peers and trying them out and reevaluating the choices based on observed performance is suboptimal as it takes time to converge on a good set of peers as well as causes unnecessary overhead in the network. Incorporating locality into peer selection using either active measurements or some sort of information plane (e.g. [7]) has been shown to improve the download completion time performance of BitTorrent. For example, [7] showed a 35% reduction in download time for 60% of the peers in a swarm. Other studies [5] showed this gain to be around 10-25%. However, [5] also showed that such an approach increases the traffic on congestion on bottleneck links by 69%. In summary, while peer related information is powerful in improving performance, it affects ISP performance and can lead to shaping and throttling. 3.3.2. Network-assisted ALTO alone On the other hand there are several situations where relying on ISP information by itself is not sufficient. If ISPs simply return a rank ordered list of node identifiers in response to a list of node identifiers sent in a query, the querying node may not be optimizing its performance. It is possible that the peers in a swarm that are within the ISP are all DSL hosts which can upload at 128Kbps while some of the other peers that may involve interdomain routing are actually high bandwidth fiber or cable connected hosts with high upload bandwidth. In such cases, the p2p application user would sustain high download times to meet the ISP's objective. Similarly, peers that are nearby geographically (which is correlated with latency typically) may be preferred for relays in VoIP but do not meet the ISP's objective since they use a different access network. The reasons for these problems are two-fold: (1) The ISPs' objectives in general may not always match the users objective of improved performance, and (2) The ISP can only provide an indication of its preference for connectivity to certain peers outside its domain but it does not have any notion of end-to-end performance provided by these outside peers. Thus neither network-asissted ALTO or peer-assisted ALTO alone help in bringing together these competing interests together. Thus, in this draft we argue for a combined solution that provides a true information plane for peer selection, i.e. one that does not sacrifice but, in fact improves the performance of p2p applications Das, et al. Expires April 26, 2009 [Page 7] Internet-Draft multi October 2008 while getting cooperation from p2p applications for the ISP. ISP information is only one of the two pillars of the ALTO service - it is an important one, given that the ISPs have knowledge of internal congestion, interdomain peering policies and connectivity information. Peer information is the other pillar of the ALTO service; and by providing it as a service to all p2p applications we reduce the overhead and inefficiency of each application performing their own measurements which is inefficient for the network and complicated for application developers. 3.4. Applicability and Discussion The problem of peer selection has been studied at various dimensions and has pretty broad applicability. At the very basic level, intelligent peer selection can be applied, in file sharing networks, to the problem of choosing the right source to download a file from. However, there are a variety of other applications for such intelligent peer selection. For example, locality aware structured overlays are built with topology-assisted neighbor selection models or topology-based identity generation shcemes. The more accurate the topology information is, the more efficient such schemes will be. Very fundamentally, intelligent neighbor selection schemes aim at improving the query latency in such systems. Peer selection is also applicable to other problems such as identifying the best super peer to contact in a system, using the best relay for NAT traversal, identifying the best next hop for a query based on several criteria (e.g., quality, reputation, semantic expertise, etc.), etc. A lot of study has been done on the applicability of the peer selection problem. Some examples include [8], [9], [10], [11], [12], [13]. Two observations can be made from these applicability aspects of peer selection. One is that the problem is applicable to a wide range of scenarios with some possible generalization - in all cases, while the criteria for peer selection and the context in which it is done may be different, the basic model for peer selection revolves around ranking a list of peers based on information collected about the peers in accordance with the given criteria. A second observation is that the same piece of information collected could be put to use in very different ways in different scenarios - e.g., the use of topology information in determining source peers to download content from and neighbor peers to make connections with are very different applications. Peer selection is also equally important for application providers, ISPs and the peers themselves for very different reasons. ISPs have an incentive to keep their operational costs to a minimum, while Das, et al. Expires April 26, 2009 [Page 8] Internet-Draft multi October 2008 ensuring their customers a good experience. Application providers are interested in keeping their own operational costs to a minimum, which by nature, conflicts with the ISP's interests of keeping the costs low. Application providers are also interested in ensuring that the application performs well to keep the peers interested in the application. For the peers themselves, the emphasis is on performance as well as their own access costs. The varied scenarios of applicability of peer selection information, the diverse interests of various parties in peer selection and the underlying common nature of these models suggest that the problem should be tackled in a uniform manner, allowing for generality and extensibility of information. The scenarios also broadly fall under two buckets - one, where information may be obtained from specific hosts (e.g., ISP hosts, reputation tracking servers, etc.) and another, where information may be obtained from any number of peers. The final peer selection algorithm may be a combination of various pieces of such information in a manner that fits a given scenario and criterion. Solving any one piece of this puzzle separately is likely to lead to multiple different protocols and mechanisms for the same problem. Further, any one such protocol is unlikely to result in a dramatic improvement of the scenario (be it bandwidth utilization or latency reduction, etc.). For instance, as argued earlier in this draft, network-assistance and peer information are both important to consider for peer selection. Hence, the adoption of any one of these protocols will be less incentivized in such a fragmented model. The ALTO service, given a set of host location identifiers for peers, may annotate them with ISP information (such as the p-distance from P4P) as well as peer connectivity information (which is variable and could be related to bandwidth, network coordinates, wireless link information etc ) and return the annotated set to the p2p application. The p2p application can use this data to perform peer selection based on its requirements. We argue that the peer connectivity information be a generic container that can contain different types of information. However the request response protocol can be unified as an ALTO protocol for retrieving the annotated information for each destination peer. Note that the data pertaining peer-assisted ALTO and network-assisted ALTO may be stored differently but the interface to p2p applications can be kept consistent. 4. Design Goals The fundamental goal of ALTO, extracting from what has been described thus far, has to do with allowing the use of both network-assisted and peer-assisted information exchanges for various categories of Das, et al. Expires April 26, 2009 [Page 9] Internet-Draft multi October 2008 applications that can use it. The main idea is to model ALTO as a service that these applications may use to apply the peer selection intelligence in the specific context of interest to the application. The following are design goals for the ALTO service framework: 1. The ALTO service should accommodate specific hosts providing network topology information. Network topology information may be provided by hosts in an ISP network with much greater accuracy than can be done via other schemes. Hence, a model that allows for such information exchange from specific hosts is useful. The discovery of such hosts capable of providing this information falls in this territory as well. 2. The ALTO service should allow peers to publish ALTO related information in an application agnostic manner. Peers may publish information of various kinds that helps in peer selection. A primary example of such information is the connectivity characteristics of a peer. This type of information allows other criteria to be taken into account for peer selection, such as the uplink/downlink bandwidth of peers, the wireless nature of links, etc. This information, coupled with topology or proximity information, will allow exchange of bulk data in a manner that benefits the ISPs and the peers. 3. The ALTO service should allow for both centralized and distributed service models. ISP hosts and any servers that are queried for ALTO related information may be offering the ALTO service in a centralized model. On the other hand, peer information related to ALTO may be obtained in a distributed fashion, e.g., by querying an overlay. It is important to cater to both models and also allow for the two models to be linked. For instance, a query on an overlay for ALTO related information may result in a different node on the overlay querying the ISP's ALTO host. 4. The ALTO protocols should be agnostic to the actual peer selection algorithm in use. The peer selection algorithm itself is contextual and depends on different factors for different scenarios. For instance, source selection for bulk data downloads involves optimal bandwidth usage and performance as criteria, neighbor selection in structured overlays may be a function of hop Das, et al. Expires April 26, 2009 [Page 10] Internet-Draft multi October 2008 count and delay, relay selection for NAT traversal may be a function of the relay capacity and connectivity characteristics and so on. Hence, the ALTO protocols should be agnostic to the specific peer selection algorithm for any given instantiation. 5. The ALTO protocols should be generic to allow any type of information useful for performing ALTO services to be exchanged. The ALTO protocols should be extensible to allow carrying new types of information that may be defined at a future point. As in the case of the algorithm, the types of information exchanged for peer selection are also contextual to various scenarios. For instance, bandwidth or latency based peer selection may involve topology information and connectivity characteristics of peers, relevance based peer selection may involve the semantic expertise of various peers, and so on. Hence, the ALTO protocols should simply be a container to transport information that assists in peer selection without being dependent on the actual type of information exchanged. 5. Security Considerations Information exchange, as facilitated by ALTO, may be sensitive and may require secure communication. Hence, the ALTO protocols must provide for channel security properties such as confidentiality and integrity protection. Further, the exchange of some of this information may need to be limited to certain entities. This calls for authentication and authorization of entities prior to exchange of ALTO information. Hence, the ALTO framework should provide for entity authentication and authorization as part of the service. When various types of information to be carried in the ALTO protocols are standardized, a call must be made about whether it is subject to the authorization model. Further, some types of information exchanges could lead to privacy issues to various parties and the implications of that need to be studied prior to standardization. 6. IANA Considerations This document does not have any IANA considerations. 7. Acknowledgments This draft has benefited from the insights presented in several IETF drafts namely the ALTO problem statement, requirements and survey Das, et al. Expires April 26, 2009 [Page 11] Internet-Draft multi October 2008 drafts. The research work done on IPlane, P4P, Taming the torrent, and ISP and P2P oracles as well as the various measurement studies on P2P applications impact on ISPs performed by the research community have helped inform us in creating this draft. 8. References 8.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 8.2. Informative References [2] Karagiannis, T., Rodriguez, P., and K. Papagiannaki, "Should ISPs fear Peer-Assisted Content Distribution?", IMC Proceedings of the Internet Measurement Conference, 2005. [3] Akella, A., Seshan, S., and A. Shaikh, "An Empirical Evaluation of WideArea Internet Bottlenecks", Proceedings of ACM SIGCOMM, 2003. [4] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and P2P systems co-operate for improved performance?", ACM SIGCOMM Computer Communications Review (CCR), 37:3, pp. 29-40, 2006. [5] Xie, H., Krishnamurthy, A., Silberschatz, A., and R. Yang, "P4P: Explicit Communications for Cooperative Control Between P2P and Network Providers", Proceedings of ACM SIGCOMM, 2008. [6] Choffnes, D. and F. Bustamante, "Taming the Torrent: A practical approach to reducing cross-ISP traffic in P2P systems", Proceedings of ACM SIGCOMM, 2008. [7] Madhyastha, H., Isdal, T., Piatek, M., Dixon, C., Anderson, T., Krishnamurthy, A., and A. Venkataramani, "iPlane: an information plane for distributed services", Proceedings of USENIX OSDI, 2006. [8] Lo, V., Liu, Y., GauthierDickey, C., and J. Li, "Scalable Leader Selection in Peer-to-Peer Overlay Networks", Proceedings of Second International Workshop on Hot Topics in Peer-to-Peer Systems (Hot-P2P), 2005. [9] Xhafa, F., Barolli, L., Fernandez, R., and T. Daradoumis, "An Experimental Study on Peer Selection in a P2P Network over PlanetLab", Proceedings of International Conference on Das, et al. Expires April 26, 2009 [Page 12] Internet-Draft multi October 2008 Parallel Processing Workshops, 2007. [10] Yang, X. and G. Veciana, "Service Capacity of Peer to Peer Networks", Proceedings of IEEE INFOCOM, 2004. [11] Habib, A. and J. Chuang, "Service Differentiated Peer Selection: An Incentive Mechanism for Peer-to-Peer Media Streaming", Proceedings of IWQoS, 2004. [12] Tang, S., Wang, H., and P. Meigham, "The Effect of Peer Selection with Hopcount or Delay Constraint on Peer-to-Peer Networking", Proceedings of IFIP NETWORKING, 2008. [13] Haas, P. and R. Siebes, "Peer Selection in PeertoPeer Networks with Semantic Topologies", Proceedings of WWW, 2004. Authors' Addresses Saumitra M. Das Qualcomm, Inc. 3195 Kifer Road Santa Clara, CA USA Phone: +1 408-533-9529 Email: saumitra@qualcomm.com Vidya Narayanan Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-2483 Email: vidyan@qualcomm.com Lakshminath Dondeti Qualcomm, Inc. 5775 Morehouse Dr San Diego, CA USA Phone: +1 858-845-1267 Email: ldondeti@qualcomm.com Das, et al. Expires April 26, 2009 [Page 13] Internet-Draft multi October 2008 Full Copyright Statement Copyright (C) The IETF Trust (2008). This document is subject to the rights, licenses and restrictions contained in BCP 78, and except as set forth therein, the authors retain all their rights. This document and the information contained herein are provided on an "AS IS" basis and THE CONTRIBUTOR, THE ORGANIZATION HE/SHE REPRESENTS OR IS SPONSORED BY (IF ANY), THE INTERNET SOCIETY, THE IETF TRUST AND THE INTERNET ENGINEERING TASK FORCE DISCLAIM ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY OR FITNESS FOR A PARTICULAR PURPOSE. Intellectual Property The IETF takes no position regarding the validity or scope of any Intellectual Property Rights or other rights that might be claimed to pertain to the implementation or use of the technology described in this document or the extent to which any license under such rights might or might not be available; nor does it represent that it has made any independent effort to identify any such rights. Information on the procedures with respect to rights in RFC documents can be found in BCP 78 and BCP 79. Copies of IPR disclosures made to the IETF Secretariat and any assurances of licenses to be made available, or the result of an attempt made to obtain a general license or permission for the use of such proprietary rights by implementers or users of this specification can be obtained from the IETF on-line IPR repository at http://www.ietf.org/ipr. The IETF invites any interested party to bring to its attention any copyrights, patents or patent applications, or other proprietary rights that may cover technology that may be required to implement this standard. Please address the information to the IETF at ietf-ipr@ietf.org. Das, et al. Expires April 26, 2009 [Page 14]