ALTO WG R. Penno, Ed. Internet-Draft Juniper Networks Intended status: Standards Track Y. Yang, Ed. Expires: September 5, 2009 Yale University March 04, 2009 ALTO Protocol draft-penno-alto-protocol-00.txt Status of this Memo This Internet-Draft is submitted to IETF in full conformance with the provisions of BCP 78 and 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 September 5, 2009. Copyright Notice Copyright (c) 2009 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents in effect on the date of publication of this document (http://trustee.ietf.org/license-info). Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Abstract The ALTO Service enables an Internet Service Provider (ISP) to convey cost preferences to network applications in order to modify network Penno & Yang Expires September 5, 2009 [Page 1] Internet-Draft ALTO InformationExport Service March 2009 resource consumption patterns while maintaining or improving application performance. Applications that could use this service are those that have a choice in connection endpoints. Examples of such applications are peer-to-peer (P2P) and content delivery networks. Applications already have access to great amount of underlying topology information. For example, views of the Internet routing table are easily available at looking glass servers and entirely practical to download to every client. What is missing is the cost information -- what does an ISP or Content Provider actually prefer? This document describes a very simple protocol that allows a ISP to convey such information to applications. While such service would primarily be provided by the network, i.e., the local ISP, Content Provider and third parties could also operate this service. Requirements Language 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]. Penno & Yang Expires September 5, 2009 [Page 2] Internet-Draft ALTO InformationExport Service March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Protocol Design Approach . . . . . . . . . . . . . . . . . . . 5 4. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 5 5. Discovery . . . . . . . . . . . . . . . . . . . . . . . . . . 6 6. ALTO Specification . . . . . . . . . . . . . . . . . . . . . . 7 6.1. Protocol Version (v=) . . . . . . . . . . . . . . . . . . 8 6.2. Message Identifier (m=) . . . . . . . . . . . . . . . . . 8 6.3. Query Type (q=) . . . . . . . . . . . . . . . . . . . . . 8 6.4. Response (r=) . . . . . . . . . . . . . . . . . . . . . . 8 6.5. Originator (o=) . . . . . . . . . . . . . . . . . . . . . 8 6.6. Network Location (n=) . . . . . . . . . . . . . . . . . . 9 6.7. Cost (c=) . . . . . . . . . . . . . . . . . . . . . . . . 9 7. ALTO Messages . . . . . . . . . . . . . . . . . . . . . . . . 9 7.1. Getcost Query . . . . . . . . . . . . . . . . . . . . . . 10 7.2. Getcost Response . . . . . . . . . . . . . . . . . . . . . 11 7.3. GetnetworkIdentifier Query . . . . . . . . . . . . . . . . 12 7.4. GetnetworkIdentifier Response . . . . . . . . . . . . . . 12 7.5. Getnetworkmap Query . . . . . . . . . . . . . . . . . . . 13 7.6. Getnetworkmap Response . . . . . . . . . . . . . . . . . . 13 8. Alto Server Message Processing . . . . . . . . . . . . . . . . 13 8.1. Exception Handling . . . . . . . . . . . . . . . . . . . . 13 8.2. Successful Responses . . . . . . . . . . . . . . . . . . . 13 8.3. Invalid Query Format . . . . . . . . . . . . . . . . . . . 13 8.4. Unsupported Query . . . . . . . . . . . . . . . . . . . . 13 9. Semantics . . . . . . . . . . . . . . . . . . . . . . . . . . 13 10. P2P Client Peer Selection Example . . . . . . . . . . . . . . 14 11. Message Exchanges Examples . . . . . . . . . . . . . . . . . . 15 11.1. Request cost for all NL-IDs . . . . . . . . . . . . . . . 15 11.2. Request NL-ID for Own IP Address . . . . . . . . . . . . . 16 11.3. Request NL-IDs for List of IP Addresses . . . . . . . . . 16 11.4. Request NL-ID Map . . . . . . . . . . . . . . . . . . . . 16 11.5. Request the Cost Between two NL-IDs . . . . . . . . . . . 16 12. Network Address Translation Considerations . . . . . . . . . . 16 13. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . . . 16 14. ALTO Protocol Grammar . . . . . . . . . . . . . . . . . . . . 17 15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18 17. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 19 18. Security Considerations . . . . . . . . . . . . . . . . . . . 19 19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19 19.1. Normative References . . . . . . . . . . . . . . . . . . . 19 19.2. Informative References . . . . . . . . . . . . . . . . . . 20 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20 Penno & Yang Expires September 5, 2009 [Page 3] Internet-Draft ALTO InformationExport Service March 2009 1. Introduction Applications employ a variety of methods to get the best performance out of the network. Today the information available to applications is mostly the view from end hosts. There is no clear mechanism to convey information about the network's preferences to applications. For example, peer-to-peer applications have been successful in achieving a good level of service for bulk transfer applications, but can work with the network better if they can leverage ISP policy and information. The ALTO service intends to provide a simple way to convey ISP preferences to applications. This document describes a very simple protocol that allows a ISP to convey such information to applications. The protocol specified here is a merge between two other protocols, Alto Info-Export[4] and P4P[5][6] and due to this fact is a work in progress. 2. Terminology We use the following terms defined in [7]: Application, Overlay Network, Peer, Resource, Resource Identifier, Resource Provider, Resource Consumer, Resource Directory, Transport Address, Host Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic, Transit Traffic. The terminology introduced in this document is listed below. o Cost: Cost defines the preference of a network location type and identifier from the point of view of another network location identifier. The notion of cost was decouple from the network location type to allow for maximum flexibility in meeting different requirements. o Network location type (NL-T): There are many types of network location types: IP Prefixes, Autonomous System, PIDs, geographical location, etc o Network Location Identifier (NL-ID): A specific value of a network location type. o PID: A Partition ID, or a PID for short, is an identifier that provide an indirect and network agnostic way to specifying NL-IDs. It can denote a subnet, a set of subnets, or an autonomous system (AS), for example. Penno & Yang Expires September 5, 2009 [Page 4] Internet-Draft ALTO InformationExport Service March 2009 3. Protocol Design Approach The protocol specified in this document is a merge between two other protocols, Alto Info-Export[4] and P4P[5][6]. The goal is to provide an unified protocol that meets the ALTO requirement[8], provides an migration path for ISP, Content Providers, and clients that have deployed the above mentioned protocols and yet remain simple. 4. Protocol Overview Each network region can choose to support the ALTO service. (A network region in this context is an Autonomous System, an ISP, or perhaps a smaller region -- the details depend on the mechanism of discovery.) +--------------------------------------------------------------------+ | ISP | | | | +---------+ | | | Routing | | | +--------------+ | Policy | | | | Provisioning | +---------+ | | | Policy | | | | +--------------+\ | | | `. | | | \ | | | +-----------+ `.+---------+ +--------+ | | |Dynamic | | ALTO | ALTO Query/Response | ALTO | | | |Network |.......| Server | -------------------- | Client | | | |Information| +---------+ +--------+ | | +-----------+ .,- / | | _,-' ALTO SD Query/Response / | | ,-' / | | +----------+ +--------------+ | | | External | | ALTO Service | | | | Interface| | Discovery | | | +----------+ +--------------+ | | | | | | Figure 1: Basic ALTO Architecture. | | | | +--------------------------------------------------------------------+ | +------------------+ | Third Parties | | | | Content Providers| +------------------+ Penno & Yang Expires September 5, 2009 [Page 5] Internet-Draft ALTO InformationExport Service March 2009 The service works as follows: 1. The ISP prepares the ALTO information which constitutes the ISP's "My-Internet view" [9] and populates the ALTO Server. This information mainly consists of network locations identifiers and their associated cost. The information in the ALTO Server can be updated dynamically based on network conditions or can be seen as a policy, which is updated on much longer time-scales. In the most simple case this maps some IP prefixes or AS numbers into priority values. 2. The ISP serializes the information into a sequence of octets. 3. The application, running on a given host, discovers the resource and fetches the serialized ALTO information (Section 7). 4. The application makes use of the information by preferring network locations with higher priority (Section 8) The part of the ISP MAY be implemented, to give a few examples, that do not preclude other implementation options: by running a script connecting to existing equipment, fetching routing information, and then generating and uploading the requisite file; by running a database-backed application that is obtains routing information from existing equipment and generates the requisite file dynamically; by modifying the software or hardware of existing equipment to support these functions; or by using new equipment for the purpose of operating this network service. 5. Discovery Discovery of the ALTO Server is out of scope for this document and will be handled separately. A discussion of the different possible protocols to discover an ALTO Service can be found in [10] The necessary property of discovery is that a client, starting from nothing on today's Internet that does not yet universally support global-scope multicast and may include NATO's, can ultimately find the IP address of the ALTO Server as configured by the ISP. Subsequent sections assume that this IP address is known to the Penno & Yang Expires September 5, 2009 [Page 6] Internet-Draft ALTO InformationExport Service March 2009 client 6. ALTO Specification The ALTO protocol design borrows ideas from the Session Description Protocol[2] with the goal of leveraging the current HTTP[[3]RFC2616] implementations and infrastructure. An ALTO information exchange is denoted by the HTTP header Content-Type "application/alto" and is carried within HTTP similarly to how SDP is carried within SIP. This approach has several advantages: o It leverages the huge installed base of HTTP infrastructure o It leverages all the mature software that has been implemented for both HTTP and SDP. o It leaves HTTP free of proprietary headers ("X-") o It does not require use of specific URIs to denote service o It allows the protocol to evolve separately from HTTP. o it makes the protocol easy to understand and debug o It leverages the fact that many P2P clients already have an embedded HTTP client o Finally it allows the ALTO protocol to be carried by other protocols other than HTTP in the future, such as SIP. An ALTO Information description consists of a number of lines of text of the form: = where MUST be exactly one case- significant character and is structured text whose format depends on . In general, is either a number of fields delimited by a single space character or a free format string, and is case-significant unless a specific field defines otherwise. Whitespace MUST NOT be used on either side of the "=" sign. Some lines in each description are REQUIRED and some are OPTIONAL, but all MUST appear in exactly the order given here (the fixed order greatly enhances error detection and allows for a simple parser). OPTIONAL items are marked with a "*". Support Types: Penno & Yang Expires September 5, 2009 [Page 7] Internet-Draft ALTO InformationExport Service March 2009 v=(protocol version) m=(message identifier) q=(Query type) r=(Response) o=(originator) c=(cost) n=(network) 6.1. Protocol Version (v=) v=1 The line defines the protocol version. The version specified in this document is 1. 6.2. Message Identifier (m=) m= This allows transactions and demultiplexing of messages at the application level 6.3. Query Type (q=) q= [[:SRC ]] The query type can be getcost, getnetworklocation and getstatus. Depending on the query type, different types of parameters are sent and received from the server 6.4. Response (r=) r = [[ | [ ]] This line is used by the Server in a response to a previous query. 6.5. Originator (o=) o= This line identifies the originator of cost information, which is not Penno & Yang Expires September 5, 2009 [Page 8] Internet-Draft ALTO InformationExport Service March 2009 necessarily related to the source IP address of the message. 6.6. Network Location (n=) n=[:]SRC DEST [] The following network location types are specified in this document: o ASN: Autonomous System Number o IPV4: IP Protocol version 4 o IPV6: IP Protocol version 6 o PID: Partition ID The network location can be used in the getcost and getnetworklocation query to specify the mapping needed. 6.7. Cost (c=) c=:SRC DEST The cost is the measure of an network identifier preference. This document specifies the following network location types: IP Prefixes, ASNs and PIDs. The cost needs to include the location type unless it is present at the subsection level. Network Locations with positive priorities are more desirable than the default. Network Locations with negative priorities are less desirable than the default. The cost type defines the contextual representation of the cost. The specification defines two cost types: rank and generic distance. 7. ALTO Messages ALTO Queries must have the following lines: v=(version) m=(message identifier) q=(query type) Alto responses must have: Penno & Yang Expires September 5, 2009 [Page 9] Internet-Draft ALTO InformationExport Service March 2009 v=(version ) m=(message identifier) r=(response) 7.1. Getcost Query q=getcost [[:SRC ]] n=[:]SRC DEST [] A getcost request causes the server to return a list of network location types, identifiers and their associated cost. If the message does not specify the source network identifier and type the server should assume that the source IP addresses indicates the source network identifier. Alternatively the client can specify a source network location type and identifier to be used for computing the cost to other locations. q=getcost :SRC The response from the server in both of these cases is an unordered list of costs for the network source and type specified by the client such as: r = getcost [[ | [ ]] c=[:SRC ] ... Another possibility is for the client to request the cost between one or more pair of network identifiers. q=getcost [network location type] Penno & Yang Expires September 5, 2009 [Page 10] Internet-Draft ALTO InformationExport Service March 2009 n=[]:SRC DEST In this case the response contain an ordered list of costs corresponding to each pair specified in the request. If the server for any reason cannot compute the cost between a certain SRC-DEST pair, it needs to use an invalid cost in the reply. The default network location type for request and responses are IP Prefixes. 7.2. Getcost Response The network location types used in the response should match the one specified in the request unless none was specified. If a network location type was specified, the response would be as follows: r=getcost [[ | [ ]] c=[:SRC ] .... If a network location type was not specified the server can bundle the costs for each network type in sections as below: r=getcost [[ | [ ]] c=[:SRC ] .... Penno & Yang Expires September 5, 2009 [Page 11] Internet-Draft ALTO InformationExport Service March 2009 c=[:SRC ] .... In the case the server responds the request with interleaved network types, each cost needs to be present in a fully specified line as below: c=: 7.3. GetnetworkIdentifier Query q=getnetworklocation [[:SRC ]] n=[:]SRC This request allows the client to query the network location for a certain network identifier. The network location types used in the request and response can be different. This query assumes a 1->1 relationship between the network identifier in the query and the one in the response. This means that the query can be used to map from a more fine grained network identifier to a more less granular one. So, the client can use an IP address in the request and get a PID in the response. 7.4. GetnetworkIdentifier Response r=getnetworklocation [[ | [ ]] n=: The response to q network location query includes the network location type and identifier. More than one network location line can be present for a single query. Penno & Yang Expires September 5, 2009 [Page 12] Internet-Draft ALTO InformationExport Service March 2009 7.5. Getnetworkmap Query TBD 7.6. Getnetworkmap Response TBD 8. Alto Server Message Processing This section specifies ALTO Server behavior when processing ALTO queries. In general the ALTO protocol uses the same status codes as HTTP. 8.1. Exception Handling Standard HTTP status codes are returned by an ALTO Server in the response (r=) line. 8.2. Successful Responses An ALTO Server MUST use Status Code 200 when replying to an operation that completed successfully. Note that this includes cases where the ALTO Server responds with only a subset of the requested information. The requesting application is expected to detect such cases if necessary. 8.3. Invalid Query Format If the Request Data is formatted incorrectly (i.e., it does not follow the syntax in Section 6), the ALTO Server MUST return an status code and reason of "400 Bad Request". 8.4. Unsupported Query If an Alto Server does not support a certain type of query, e.g., cost for SRC-DEST pairs, a status code and reason of "501 Not Implemented" might be returned in lieu of returning an invalid cost. 9. Semantics Network location identifiers with positive priorities are more desirable than the default. Network locations identifiers with negative priorities are less desirable than the default. In general, greater values are more desirable. Zero priority is the default. Network Location Identifiers not specified are treated as if they had Penno & Yang Expires September 5, 2009 [Page 13] Internet-Draft ALTO InformationExport Service March 2009 priority zero. The absolute value of the priorities does not matter. Only their relative order is meaningful. Higher values are more desirable. For example, multiplying all the priority values in a given file by the same positive integer constant does not change the semantics of the file. Some ISPs already convey information such as "traffic in the local country is free" to their customers. These ISPs will find the ALTO service an excellent means of conveying similar information in a machine-readable form. Only one (positive) priority value is needed for such use. It is up to the ISP deploying the file to choose how much information to publish in it. 10. P2P Client Peer Selection Example After the client application receives a list of network location identifier and their cost from the ALTO Server, it needs to make a selection on of which peers to use based on this and other sources of information. With this in mind, the semantics of the information are intentionally flexible, because: Different applications will necessarily use the information differently. For example, an application that connects to just one address is going to have a different algorithm for selecting it than an application that connects to many. Given lack of Internet-scale experimentation with using the information, we don't yet know what the best ways are. We want to give different approaches a chance to compete. However, it's important to provide at least a non-normative example of how such cost information could be used. Consider a BitTorrent client that wishes to use the ALTO information. The client will have a list of perhaps up to 200 initial candidate peers, out of which it will select perhaps 50 peers to try to connect to. In an initial implementation, the client could: Split the candidates into three sets: preferred (those with positive priorities), to-be-avoided (those with negative priorities), and default (0 or unspecified priority) Penno & Yang Expires September 5, 2009 [Page 14] Internet-Draft ALTO InformationExport Service March 2009 Select up to 25 candidates randomly from the preferred set. In particular, if there are fewer than 25 in the preferred set, select them all. Fill remaining slots up to 50 with candidates from the default set. If this didn't fill the slots (i.e., fewer than 50 of the candidates were in the union of preferred and default sets), fill the rest by candidates from the to-be-avoided set. When establishing connections after the initial startup, continue using the policy of giving up to half the slots to preferred with the rest for default and to-be-avoided only as last resort. When selecting a peer to optimistically unchoke, half the time select a preferred peer if there is one. (The particular numbers could be different.) If the preferred peers perform better than default ones, they will dominate the transfers. To-be-avoided peers are largely not contacted, unless the prohibitive policy is broad enough or the swarm is small enough that it is necessary to contact them to fill the slots. In addition, the application might use some form of randomized test to see if it performs better or worse when the ALTO service use is on. 11. Message Exchanges Examples The sections below depict a few typical messages examples. The ALTO protocol can be used with both GET and POST HTTP methods, the difference is mainly how caching would work. This section will be further specified in the next revisions of the document. 11.1. Request cost for all NL-IDs In the simplest form the client sends a getcost query to the ALTO Server specifying nothing else. The server assumes the source NL-ID is the source IP address of the packet and returns the cost for all NL-IDs from this point of view. See below v=1 q=getcost This allow the protocol to work through NATO's without ALGs support. Penno & Yang Expires September 5, 2009 [Page 15] Internet-Draft ALTO InformationExport Service March 2009 The format and purpose of the query becomes is to download the full list of costs to every other NL-ID from the client point of view. 11.2. Request NL-ID for Own IP Address The following message exchange illustrates a client requesting its own NL-ID from the ALTO Server. The client uses an empty query, and the Alto Server responds with the client's IP address and the NL-ID corresponding to the IP address. 11.3. Request NL-IDs for List of IP Addresses The following message exchange illustrates a client directly asking the ALTO Server to map a set of IP addresses into their corresponding NL-IDs. 11.4. Request NL-ID Map The following message exchange illustrates an application requesting the set of IP addresses contained within a set of NL-IDs. 11.5. Request the Cost Between two NL-IDs The following message exchange illustrates an application requesting the routing cost between particular NL-IDs. 12. Network Address Translation Considerations At this day and age of v4<->v4, v4<->v6[11] and possibly v6<->v6[12] NATO's, a protocol should strive to be NAT friendly and minimize carrying IP addresses in the payload, or provide a mode of operation where the source IP address provide the information necessary to the server. The protocol specified in this document provides a mode of operation where the source NL-ID is the source IP address of the packet. This is very similar to how Tracker based P2P networks such as Bittorrent work. See "Tracker HTTP/HTTPS Protocol" in [13]. This allows a client to work through NATO's without the need for ALGs or NAT traversal mechanisms. 13. Mapping IPs to ASNs DISCUSSION: Applications can already map IPs to ASNs using information from a BGP looking glass. To do so, they have to download a file of about 1.5MB when compressed (as of October 2008, Penno & Yang Expires September 5, 2009 [Page 16] Internet-Draft ALTO InformationExport Service March 2009 with all information not needed for IP to ASN mapping removed) and periodically (perhaps monthly) refresh it. Alternatively, the ALTO service as defined in this document could be expanded so that there is another file that expands every ASN mentioned in the policy file into a set of IP prefixes. In that case, the ASNs in the policy file, from a client's perspective, would be treated like macros. The mapping file provided by the ISP would be both smaller and more authoritative. For simplicity of implementation, it's highly desirable that clients only have to implement exactly one mechanism of mapping IPs to ASNs. We're interested in perspectives of others on this. 14. ALTO Protocol Grammar All of the mechanisms specified in this document are described in both prose and an augmented Backus-Naur Form (BNF) defined in RFC 2234 [10]. Section 6.1 of RFC 2234 defines a set of core rules that are used by this specification, and not repeated here. Implementers need to be familiar with the notation and content of RFC 2234 in order to understand this specification. Certain basic rules are in uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc. Angle brackets are used within definitions to clarify the use of rule names. hostport = host [ ":" port ] host = hostname / IPv4address / IPv6reference IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT IPv6address = hexpart [ ":" IPv4address ] hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ] hexseq = hex4 *( ":" hex4) hex4 = 1*4HEXDIG port = 1*DIGIT 15. Acknowledgements TBD. Penno & Yang Expires September 5, 2009 [Page 17] Internet-Draft ALTO InformationExport Service March 2009 16. Contributors The people listed here should be viewed as co-authors of the document. Due to the limit of 5 authors per draft the co-authors were moved to the contributors section at this point. Richard Alimi Yale University EMail: richard.alimi@yale.edu D. Pasko Verizon EMail: pasko@verizon.com L. Popkin Pando Networks EMail: laird@pando.com Satish Raghunath Juniper Networks satishr@juniper.net Stanislav Shalunov BitTorrent EMail: shalunov@bittorrent.com Yu-Shun Wang Penno & Yang Expires September 5, 2009 [Page 18] Internet-Draft ALTO InformationExport Service March 2009 Microsoft Corp. yu-shun.wang@microsoft.com Richard Woundy Comcast Richard_Woundy@cable.comcast.com 17. IANA Considerations This document request the registration of a new media type: "application/alto" 18. Security Considerations The ISP publishing the ALTO policy information has to treat it as publishing to the entire world. Applications using the information must be cognizant of the possibility that the information is malformed or incorrect. Even when it is correct, its use might harm the performance. When an application concludes that it would get better performance disregarding the ALTO information, the decision to discontinue the use of ALTO information is likely best left to the user. The use of TLS (using the "https" URL schema) will make it easier for clients to verify the origin of ALTO information. 19. References 19.1. Normative References [1] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [2] Handley, M., Jacobson, V., and C. Perkins, "SDP: Session Description Protocol", July 2006. [3] Fielding, R., J. Gettys, V., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", June 1999. Penno & Yang Expires September 5, 2009 [Page 19] Internet-Draft ALTO InformationExport Service March 2009 19.2. Informative References [4] S. Shalunov, R. Penno, and R. Woundy, "ALTO Information Export Service", draft-shalunov-alto-infoexport-00 (work in progress) 2008. [5] R. Alimi, D. Pasko, L. Popkin, Y. Wang., "P4P: Provider Portal for (P2P) Applications", draft-p4p-framework-00 (work in Progress) 2008. [6] Wang, Y., Alimi, R., Popkin, L., and YR. Yang, "P4P Protocol Spec", draft-wang-p4p-spec-00, 2009. [7] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-marocco-alto-problem-statement-04 (work in progress) 2009. [8] S. Kiesel, L. Popkin, S. Previdi, R. Woundy, and YR. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-kiesel-alto-reqs-01 (work in progress) 2008. [9] Yang (Ed.), YR., "An Architecture of ALTO for P2P Applications", draft-yang-alto-architecture-00.txt, 2009. [10] Garcia, G., Tomsu, M., and Wang, Y., "Alto Discovery Protocol", draft-wang-alto-discovery-00.txt, 2009. [11] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 Translation", February draft-baker-behave-v4v6-framework-02, 2009. [12] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address Translation (NAT66)", November draft-mrw-behave-nat66-01.txt, 2008. [13] "Bittorrent Protocol Specification v1.0", http://wiki.theory.org/BitTorrentSpecification, 2009. [14] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. Silberschatz., "P4P: Provider Portal for (P2P) Applications", In SIGCOMM 2008. Penno & Yang Expires September 5, 2009 [Page 20] Internet-Draft ALTO InformationExport Service March 2009 Authors' Addresses Reinaldo Penno (editor) Juniper Networks 1194 N Mathilda Avenue Sunnyvale, Phone: Fax: Email: rpenno@juniper.net URI: Y. Richard Yang (editor) Yale University Phone: Fax: Email: yry@cs.yale.edu URI: Penno & Yang Expires September 5, 2009 [Page 21]