ALTO WG R. Penno, Ed. Internet-Draft Juniper Networks Intended status: Standards Track Y. Yang, Ed. Expires: September 10, 2009 Yale University March 09, 2009 ALTO Protocol draft-penno-alto-protocol-01.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 Protocol 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 Protocol March 2009 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 5 1.2. Architecture . . . . . . . . . . . . . . . . . . . . . . . 6 2. ALTO Network Information . . . . . . . . . . . . . . . . . . . 8 2.1. Network Map . . . . . . . . . . . . . . . . . . . . . . . 8 2.2. Cost Map . . . . . . . . . . . . . . . . . . . . . . . . . 8 2.3. Version Tag . . . . . . . . . . . . . . . . . . . . . . . 8 3. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 9 3.1. Example Scenario . . . . . . . . . . . . . . . . . . . . . 9 3.2. Design Approach . . . . . . . . . . . . . . . . . . . . . 9 3.2.1. Key Features . . . . . . . . . . . . . . . . . . . . . 9 3.2.2. Use of HTTP . . . . . . . . . . . . . . . . . . . . . 10 3.2.3. ALTO Information Reuse . . . . . . . . . . . . . . . . 10 3.2.4. ALTO Interfaces . . . . . . . . . . . . . . . . . . . 10 4. ALTO Messages . . . . . . . . . . . . . . . . . . . . . . . . 11 4.1. Basic Syntax . . . . . . . . . . . . . . . . . . . . . . . 11 4.1.1. Protocol Version (v=) . . . . . . . . . . . . . . . . 12 4.1.2. Transaction Identifier (t=) . . . . . . . . . . . . . 12 4.1.3. Query Type (q=) . . . . . . . . . . . . . . . . . . . 12 4.1.4. Response (r=) . . . . . . . . . . . . . . . . . . . . 13 4.1.5. Originator (o=) . . . . . . . . . . . . . . . . . . . 13 4.1.6. Cost (c=) . . . . . . . . . . . . . . . . . . . . . . 13 4.1.7. Network Locations (n=) . . . . . . . . . . . . . . . . 13 4.1.8. Network Map (m=) . . . . . . . . . . . . . . . . . . . 14 4.1.9. Interface Definition (i=) . . . . . . . . . . . . . . 14 4.2. Message Syntax . . . . . . . . . . . . . . . . . . . . . . 14 4.2.1. getcost . . . . . . . . . . . . . . . . . . . . . . . 14 4.2.2. getnetworkidentifier . . . . . . . . . . . . . . . . . 16 4.2.3. getnetworkmap . . . . . . . . . . . . . . . . . . . . 16 4.3. ALTO Server Message Processing . . . . . . . . . . . . . . 17 4.3.1. Exception Handling . . . . . . . . . . . . . . . . . . 17 4.3.2. Successful Responses . . . . . . . . . . . . . . . . . 17 4.3.3. Invalid Query Format . . . . . . . . . . . . . . . . . 18 4.3.4. Unsupported Query . . . . . . . . . . . . . . . . . . 18 5. ALTO Interfaces . . . . . . . . . . . . . . . . . . . . . . . 18 5.1. Interface Descriptor . . . . . . . . . . . . . . . . . . . 19 5.2. Cost Map Interfaces . . . . . . . . . . . . . . . . . . . 20 5.2.1. GetCost . . . . . . . . . . . . . . . . . . . . . . . 20 5.2.2. GetCost-Source . . . . . . . . . . . . . . . . . . . . 20 5.2.3. GetCost-Complete . . . . . . . . . . . . . . . . . . . 20 5.3. Network Map Interfaces . . . . . . . . . . . . . . . . . . 21 5.3.1. GetNetworkIdentifier . . . . . . . . . . . . . . . . . 21 5.3.2. GetNetworkMap . . . . . . . . . . . . . . . . . . . . 21 5.3.3. GetNetworkMap-Source . . . . . . . . . . . . . . . . . 22 5.3.4. GetNetworkMap-Complete . . . . . . . . . . . . . . . . 22 5.4. Example Usage . . . . . . . . . . . . . . . . . . . . . . 22 Penno & Yang Expires September 5, 2009 [Page 3] Internet-Draft ALTO Protocol March 2009 6. ALTO Costs . . . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Type Attribute . . . . . . . . . . . . . . . . . . . . . . 23 6.2. Mode Attribute . . . . . . . . . . . . . . . . . . . . . . 23 6.3. Semantics . . . . . . . . . . . . . . . . . . . . . . . . 24 7. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 24 7.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 24 7.2. Network Address Translation Considerations . . . . . . . . 24 7.3. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 25 7.4. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 25 7.4.1. Client-based Peer Selection . . . . . . . . . . . . . 26 7.4.2. Server-based Peer Selection . . . . . . . . . . . . . 26 8. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 26 9. Security Considerations . . . . . . . . . . . . . . . . . . . 26 9.1. ISPs . . . . . . . . . . . . . . . . . . . . . . . . . . . 26 9.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 27 9.3. ALTO Information . . . . . . . . . . . . . . . . . . . . . 27 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 27 10.1. Normative References . . . . . . . . . . . . . . . . . . . 27 10.2. Informative References . . . . . . . . . . . . . . . . . . 27 Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 29 Appendix B. Acknowledgements . . . . . . . . . . . . . . . . . . 30 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 30 Penno & Yang Expires September 5, 2009 [Page 4] Internet-Draft ALTO Protocol March 2009 1. Introduction Today, information available to applications is mostly from the view of endhosts. Using this view, they currently employ a variety of methods to improve performance. However, there is no clear mechanism to convey information about the network's preferences to applications. By better leveraging network-provided information, applications can become more network-efficient and acheive better performance. For example, peer-to-peer applications have been successful in achieving a good level of service for bulk-transfer applications. By also considering network preferences, downloads can be accelerated and network resource consumption can be reduced. The ALTO service intends to provide a simple way to convey ISP preferences to applications. This document describes a simple protocol that allows an ISP to convey such information to applications. The protocol specified here is a merge between two other designs, ALTO Info-Export [5] and P4P [6] [7]. The goal is to provide a simple, unified protocol that meets the ALTO requirements [8], provides a migration path for ISPs, Content Providers, and clients that have deployed the above mentioned protocols. This document is a work in progress and will be updated with further developments. 1.1. Terminology We use the following terms defined in [9]: 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 Network Location Identifier (NL-ID): identifier indicating a particular host or group of hosts. Currently-defined types of Network Location Identifiers are IP Address, IP Prefix, Autonomous System, PID, Geographical Location. Others may be defined. o PID (Partition ID): identifier providing an indirect and network- agnostic way to specify a group of NL-IDs. For example, a PID may be defined (by a network operator) to denote a subnet, set of subnets, autonomous system, PoP, or metropolitan area. Aggregation into PIDs can improve scalablity. In particular, network preferences (costs) may be specified between PIDs, allowing cost information to be more compact and updated at a smaller time scale than the network locations themselves. Penno & Yang Expires September 5, 2009 [Page 5] Internet-Draft ALTO Protocol March 2009 o Top-Level NL-ID: NL-ID that is either a PID, or a NL-ID not contained within another PID. For example, if a PID 'pid1' containing the NL-IDs '1.2.0.0/16' and 'AS29', then 'pid1' is a Top-Level NL-ID, but '1.2.0.0/16' and 'AS29' are not. o Cost: indicates the preference of a NL-ID from the point of view of another NL-ID. Costs have attributes indicating their type (e.g., routing cost, hop-count, air-miles), and mode (numerical or ordinal interpretation). o ALTO Message: Single message (either request or response) carried between an ALTO Server and ALTO Client. o ALTO Interface: Endpoint offered by an ALTO Server for accepting ALTO Messages. o Source Grouping: A group of ALTO Clients which can have similar costs to other network locations. See [10] for further discussion. This current document assumes that Source Groups ar denoted as top-level PIDs. 1.2. Architecture 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 discovery mechanism. An illustration of the overall system architecture is presented in the following figure. Penno & Yang Expires September 5, 2009 [Page 6] Internet-Draft ALTO Protocol March 2009 +-------------------------------------------------------------------+ | 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| +------------------+ ALTO Architecture The network information provided by an ALTO Server may be influenced (at the operator's discretion) by other systems. Examples include (but are not limited to) dynamic network information, routing policies, provisioning policies, and interfaces to outside parties. These components are outside the scope of this document. After using ALTO Service Discovery to identify an appropriate ALTO Server, an ALTO Client may then request available network information from the ALTO Server. This document specifies a protocol through which this network information is made available. Penno & Yang Expires September 5, 2009 [Page 7] Internet-Draft ALTO Protocol March 2009 2. ALTO Network Information An ISP prepares the ALTO information constituting the ISP's "my- Internet View" [10]. The ALTO information provided by the ALTO Server can be updated dynamically based on network conditions, or can be seen as a policy which is updated at a larger time-scale. In a simple case, the ALTO information maps, for a particular Source Group, a cost for IP prefixes and AS numbers as viewed from that group. ALTO information is comprised of two sets of information: the Network Map and Cost Map. Separating ALTO information into a Network Map and Cost Map as the two components can be updated at different time scales. For example, Network Maps may be stable for a longer time while Cost Maps may be updated to reflect dynamic network conditions. Version Tags are introduced to ensure that ALTO Clients are able to use consistent information even though the information is provided in two sets. 2.1. Network Map The Network Map defines a set of network locations (NL-IDs) within the network. Network locations may also be logically grouped into PIDs. The GetNetworkMap and GetNetworkIdentifier interfaces allow ALTO Clients to query the Network Map. 2.2. Cost Map The Cost Map defines the network costs, or preferences, between network locations. Note that the network costs may be dependent on the specific network locations and groupings defined in the Network Map. Thus, we say that a particular Cost Map is generated based on a particular Network Map. The GetCost interfaces allow ALTO Clients to query the Cost Map. 2.3. Version Tag When an ALTO Client retrieves cost information in the ALTO Server's current Cost Map, it must ensure that the cost information is consistent with any locally-stored Network Map information. If the ALTO Server had recently updated its Network Map (perhaps causing changes in the Cost Map), the ALTO Client must be able to detect that the new costs pertain to a Network Map different than the one currently stored. The ALTO Client can then refresh the Network Map Penno & Yang Expires September 5, 2009 [Page 8] Internet-Draft ALTO Protocol March 2009 information from the ALTO Server. Version Tags allow ALTO Clients to detect this case. The Network Map maintained by the ALTO Server has an associated opaque identifier called a Version Tag. When the Network Map is modified, its Version Tag is changed. A simple way to implement the Version Tag is as an integer that incremented (wrapping around to 0 as necessary) when the Network Map changes. When ALTO information (either generated from the Network Map or Cost Map) is returned by the ALTO Server, the Version Tag is included in the response message. Specifically, if the returned information is from the Network Map, the Network Map's Version Tag is included. If the returned information is from the Cost Map, the Version Tag of the Network Map used to generate the Cost Map is included. 3. Protocol Overview 3.1. Example Scenario The ALTO service may operate as follows: 1. The ISP prepares ALTO information as discussed in Section 2. 2. An application (ALTO Client), running on a given host, discovers the ALTO Server and fetches the ALTO information (Section 4.2). 3. The application may integrate ALTO information into its decision making process, possibly by making use of network locations with lower cost. See Section 6 for further discussion on semantics of network costs. 3.2. Design Approach 3.2.1. Key Features The ALTO Protocol design borrows ideas from the Session Description Protocol [2] with the goal of leveraging current HTTP [3] [4] implementations and infrastructure. An ALTO information exchange is carried within HTTP similarly to how SDP is carried within SIP. ALTO messages are denoted with HTTP Content-Type "application/alto". The ALTO Protocol described in this document has several features: o Leverages the huge installed base of HTTP infrastructure, including HTTP caches Penno & Yang Expires September 5, 2009 [Page 9] Internet-Draft ALTO Protocol March 2009 o Leverages mature software implementations for both HTTP and SDP o Leverages the fact that many P2P clients already have an embedded HTTP client o Makes protocol easy to understand and debug o Allows the protocol to evolve separately from HTTP; Leaves HTTP free of proprietary headers ("X-") o Allows the ALTO protocol to be carried by other protocols other than HTTP in the future, such as SIP. o Allows flexible ALTO Server implementation strategies. The rest of this section elaborates on the key design considerations use in the protocol. 3.2.2. Use of HTTP An important design consideration for the ALTO Protocol is easy integration with existing applications and infrastructure. As outlined above, HTTP is a natural choice. The message formats themselves, however, remain independent of HTTP to allow flexibility and transition to other transport protocols. 3.2.3. ALTO Information Reuse ALTO information may be useful to a large number of applications and users. Distributing ALTO information must be efficient and not become a bottleneck. Therefore, the ALTO Protocol specified in this document integrates with existing HTTP caching infrastructure to allow reuse of ALTO information by ALTO Clients and reduce load on ALTO servers. ALTO information may also be cached using application- dependent mechanisms, such as P2P DHTs. For example, a Cost Map may be reused by all ALTO Clients within a particular Source Grouping [10]. A full Network Map may be reused by all ALTO Clients using the ALTO Server. 3.2.4. ALTO Interfaces Three basic interfaces are provided by the ALTO Protocol, which allow ALTO Clients to request specific information: GetNetworkIdentifier, GetNetworkMap, and GetCost. An ALTO Server additionally defines instances of the GetNetworkMap and GetCost interfaces that provide the full Network Map and Cost Map, or only the subset pertaining to the Source Grouping containing the ALTO Client. Penno & Yang Expires September 5, 2009 [Page 10] Internet-Draft ALTO Protocol March 2009 Each ISP may have different infrastructure and services which produce and update the ALTO information, and may provide ALTO information using any number of implementation strategies. The ALTO Protocol specified in this document uses a single endpoint URI (e.g., discovered via ALTO Service Discovery), and offers ALTO interfaces using URI endpoints advertised by the ALTO Server. Using distinct URIs for each ALTO Interface provides the following benefits: o Flexible implementation strategies for ALTO Server (e.g., flat files, database-backed CGI script, dedicated server, etc) o Allows ALTO information to be provided using existing, mature software (e.g., web servers) o Integration with HTTP Caching while reducing dependence of messaging format on HTTP. Further details are provided in Section 5. ALTO Interfaces and their URIs are provided to an ALTO Client via an Interface Descriptor. A Interface Descriptor is expected to be stable for a long period of time, so an ALTO Client may cache it locally and possibly share amongst many ALTO clients running on the same physical machine. 4. ALTO Messages 4.1. Basic Syntax This section describes the basic components of an ALTO Protocol message. The ALTO Protocol borrows its message encoding syntax from SDP [2], but necessary definitions are included here. 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 "*". ALTO Messages use lowercase names to distinguish them from the names Penno & Yang Expires September 5, 2009 [Page 11] Internet-Draft ALTO Protocol March 2009 of their corresponding ALTO Interfaces. The textual encoding of a particular NL-ID indicates its type (IP prefix, AS number, PID, etc). ALTO Protocol messages use the following types: v=(Protocol Version) t=(Transaction Identifier) q=(Query) r=(Response) o=(Originator) c=(Cost) n=(Network Location) m=(Network Map) i=(Interface Description) 4.1.1. Protocol Version (v=) v=1 The line defines the protocol version. The version specified in this document is 1. 4.1.2. Transaction Identifier (t=) t= This allows transactions and demultiplexing of messages at the application level. It is possible that response for queries are not received in order (e.g., if a transport other than HTTP is used), so a mechanism is needed to match responses to queries. 4.1.3. Query Type (q=) q= [SRC | complete] The query type can be 'getcost', 'getnetworkidentifier', 'getnetworkmap' or 'getstatus'. Certain queries allow either complete ALTO information to be requested, or only a subset of ALTO Penno & Yang Expires September 5, 2009 [Page 12] Internet-Draft ALTO Protocol March 2009 information. 4.1.4. Response (r=) r= [ | [ ]] [] [COST ] This line is used by the Server in a response to a previous query. Success and failures codes are based on HTTP's status codes but specific to the ALTO Protocol, so semantically different from those of HTTP or other protocol serving as transport. For example, if ALTO protocol is carried within HTTP, the HTTP status code can be "200 OK", but the ALTO status code can be "400 Bad Request". The map version tag is used when the query type is 'getnetworkidentifier', 'getnetworkmap', or 'getcost'. It tells the client which version of the Network Map was used to generated response data. The type and mode of costs returned is indicated in the 'getcost' response. See Section 6 for details about costs as well as the type and mode attributes. 4.1.5. Originator (o=) o= | This line identifies the originator of cost information, which is not necessarily related to the source IP address of the message. 4.1.6. Cost (c=) c=SRC [DEST ] The cost is a generic measure of network preference. 4.1.7. Network Locations (n=) n=SRC [DEST ] The network location line can be used in the 'getcost', 'getnetworkmap', and 'getnetworkidentifier' messages to indicate specific mappings that are needed. The following network location types are specified in this document: Penno & Yang Expires September 5, 2009 [Page 13] Internet-Draft ALTO Protocol March 2009 o 'ASN': Autonomous System Number o 'IPV4': IP Protocol version 4 o 'IPV6': IP Protocol version 6 o 'PID': Partition ID 4.1.8. Network Map (m=) m= [ ... ] The network map line is sent by server in a 'getnetworkmap' or 'getnetworkidentifier' response message. It conveys which Network Location Identifiers are mapped to particular Top-Level NL-IDs (PIDs). 4.1.9. Interface Definition (i=) i= The interface definition line is sent by a server in a 'getinterfaces' response. It identifies an interface available from an ALTO Server. See Section 5 for details. 4.2. Message Syntax ALTO queries (requests) MUST have the following lines: v=(version) t=(transaction identifier) q=(query type) ALTO responses MUST have: v=(version) t=(transaction identifier) r=(response) 4.2.1. getcost This message instructs the server to return costs amongst Network Location Identifiers. Penno & Yang Expires September 5, 2009 [Page 14] Internet-Draft ALTO Protocol March 2009 4.2.1.1. Query q=getcost [SRC ] | complete [COST ] n=SRC [DEST ] n=SRC [DEST ] ... If the request does not specify either the Source NL-ID or the 'complete' token, the server assumes that the requesting IP addresses indicates the Source NL-ID. If the request does not specify the desired cost type and mode, then the server assumes the type to be 'routingcost' and the mode to be 'numerical'. If the 'complete' token is specified, costs between each pair of Top- level NL-IDs are returned. Otherwise, the costs from Source NL-ID to all Top-Level NL-IDs is returned. 4.2.1.2. Response The server may reply with a message enumerating pairs of Network Location Identifiers and associated costs: r=getcost [ | [ ]] COST c=SRC DEST c=SRC DEST ... If the server replies with multiple costs from a particular Source NL-ID to multiple Destination NL-IDs, a more efficient encoding may be used: r=getcost [ | [ ]] COST c=SRC ... c=SRC ... If the server for any reason cannot compute the cost between a certain SRC-DEST pair contained in the request, it may omit the pair Penno & Yang Expires September 5, 2009 [Page 15] Internet-Draft ALTO Protocol March 2009 from the response. 4.2.2. getnetworkidentifier This message requests the server to map a requested Network Location Identifier into its corresponding Top-Level NL-ID. The default query (with no parameters listed) can be used to discover the Source Group for a particular ALTO Client. 4.2.2.1. Query q=getnetworkidentifier [SRC ] n=SRC If the request does not specify any Source NL-IDs, the server assumes that the requesting IP addresses indicates the Source NL-ID. 4.2.2.2. Response r=getnetworkidentifier [ | [ ]] m= [ ... ] m= [ ... ] ... The response includes the corresponding Top-Level NL-IDs for the requested list of Source NL-IDs. If the server for any reason cannot compute the Top-Level NL-ID for a particular Source NL-ID, it may omit the Source NL-ID in the response. For example, if the query is for IP address 1.2.3.4 (in PID1), 1.2.3.5 (in PID1) and 128.1.1.2 (in PID2) the response would be: r=getnetworkidentifier 200 1 m=PID1 IPV4:1.2.3.4 IPV4:1.2.3.5 m=PID2 IPV4:128.1.1.2 4.2.3. getnetworkmap This message instructs the server to return the Network Location Identifiers (e.g., IP Prefixes) contained within the specified Top- Level NL-IDs (e.g., PIDs). By storing such a mapping, an ALTO Client can locally map from IP addresses to PIDs without consulting the ALTO Server. Penno & Yang Expires September 5, 2009 [Page 16] Internet-Draft ALTO Protocol March 2009 4.2.3.1. Query q=getnetworkmap [SRC ] | complete n=SRC n=SRC ... If the 'complete' token is specified, the server assumes the set of Top-Level NL-IDs to be all Top-Level NL-IDs defined in the Network Map. Otherwise, mappings for only the specified Top-Level NL-IDs are queried. 4.2.3.2. Response r=getnetworkmap [ | [ | ]] m= [ ... ] m= [ ... ] ... Each line of the response indicates the NL-IDs contained within a particular Top-Level NL-ID. If the server for any reason cannot identify a particular Top-Level NL-ID contained in the request, it may omit that Top-Level NL-ID from the response. 4.3. 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. 4.3.1. Exception Handling Standard HTTP status codes are returned by an ALTO Server in the response (r=) line. 4.3.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. Penno & Yang Expires September 5, 2009 [Page 17] Internet-Draft ALTO Protocol March 2009 4.3.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". 4.3.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. 5. ALTO Interfaces An ALTO Server exposes multiple interfaces to ALTO Clients, each of which provides certain ALTO information to clients. Clients send ALTO Messages (Section 4.2) to the ALTO Server interfaces to query information, and receive ALTO Messages containing the requested information. Two sets of ALTO Interfaces are provided, corresponding to the two sets of ALTO information: o Network Map Interfaces: GetNetworkIdentifier, GetNetworkMap o Cost Map Interfaces: GetCost The GetNetworkMap and GetCost interfaces each define instances that may reply with static messages as opposed to dynamically-constructed responses. In particular: o GetNetworkMap-Source, GetCost-Source: provide at least subset the of the ALTO information reusable by all ALTO Clients within a particular Source Grouping (e.g., PID). These interfaces are expected to be used by ALTO Clients such as P2P clients which primarily consider costs from themselves to other network locations. o GetNetworkMap-Complete, GetCost-Complete: provide the complete set of ALTO information, which is reusable by all ALTO Clients. These interfaces are expected to be used by ALTO Clients such as P2P trackers which may require global information. Note that it is possible for GetNetworkMap-Source and GetCost-Source to return more than the subset specific to ALTO Clients within the particular Source Group. In particular, they may be pointers to the GetNetworkMap-Complete and GetCost-Complete interfaces. However, Penno & Yang Expires September 5, 2009 [Page 18] Internet-Draft ALTO Protocol March 2009 this approach is only recommended if the total amount ALTO information returned is small. Each ALTO Interface has a corresponding URI. Using separate URIs for each interface allows for implementation flexibility, the ability to reuse common ALTO information based on the request URI (e.g., existing HTTP cache servers), and avoids defining the protocol to explicitly duplicate request parameters in HTTP headers or query- string parameters. This section defines the ALTO Interfaces provided by the ALTO Server and messages that may be sent to each interface's URI: o Accepted Query: query type for messages allowed to be sent to the interface. The ALTO Server MUST indicate an error if the query type does not match the expected query type. o Accepted Parameters: expected query parameters in request message. The ALTO Server MUST indicate an error if the supplied parameters do not meet these preconditions. 5.1. Interface Descriptor The URI for each interface exposed by an ALTO Server is listed in the Interface Descriptor given to an ALTO Client. The URIs for the GetNetworkMap-Source and GetCost-Source interfaces MAY include the string '', which is replaced by ALTO Clients with the Network Location Identifier denoting a particular Source Group. An ALTO Server accepts the 'getinterfaces' query at a well-known URI. This URI could either be discovered directly by the ALTO Discovery mechanism, or be standardized (e.g., '/alto-interfaces') and appended to a hostname and port discovered by the ALTO Discovery mechanism. An ALTO Client requests the Interface Descriptor using the 'getinterfaces' query: q=getinterfaces The returned Interface Descriptor is encoded as: r=getinterfaces i= ... i= Penno & Yang Expires September 5, 2009 [Page 19] Internet-Draft ALTO Protocol March 2009 If an ALTO Server does not provide a certain interface, it does not appear in the Interface Descriptor. 5.2. Cost Map Interfaces 5.2.1. GetCost This interface returns all or a subset of the Cost Map. It also allows ALTO Clients to query for costs with Type or Mode different from the ALTO Server's default cost Type and Mode. This interface should only be used by ALTO Clients requiring customized cost information. ALTO Clients should use the GetCost-Source and GetCost- Complete where possible. The GetCost interface MAY be provided by an ALTO Server. Interface Specification: o Accepted Query: getcost o Accepted Parameters: Any There are no guarantees about the reusability of successful requests to this interface. Thus, the ALTO Server MUST indicate in the HTTP response that it is not cacheable. 5.2.2. GetCost-Source This interface returns a subset of the Cost Map containing only costs from a particular Source Group to other network locations. The GetCost-Source interface MAY be provided by an ALTO Server. Interface Specification: o Accepted Query: getcost o Accepted Parameters: Indicate Source NL-ID consistent with URI. Successful requests to this interface MUST generate a response message that is independent of the querying ALTO Client. Thus, the ALTO Server MAY indicate caching parameters in the HTTP response. 5.2.3. GetCost-Complete This interface returns the complete Cost Map. The GetCost-Complete interface MUST be provided by an ALTO Server. Penno & Yang Expires September 5, 2009 [Page 20] Internet-Draft ALTO Protocol March 2009 Interface Specification: o Accepted Query: getcost o Accepted Parameters: Indicate 'complete' token Successful requests to this interface MUST generate a response message that is independent of the querying ALTO Client. Thus, the ALTO Server MAY indicate caching parameters in the HTTP response. 5.3. Network Map Interfaces 5.3.1. GetNetworkIdentifier This interface returns mappings between Network Location Identifiers computed using the Network Map. Without any request parameters, it returns the Source Group containing the requesting ALTO Client. The GetNetworkIdentifier interface MUST be provided by an ALTO Server for the case of replying with the Source Group for the requesting ALTO Client. Interface Specification: o Accepted Query: getnetworkidentifier o Accepted Parameters: Any There are no guarantees about the reusability of successful requests to this interface. Thus, the ALTO Server MUST indicate in the HTTP response that it is not cacheable. 5.3.2. GetNetworkMap This interface returns all or a subset of the Network Map. This interface should only be used by ALTO Clients requiring specific portions of the Network Map. ALTO Clients should use the GetNetworkMap-Source and GetNetworkMap-Complete where possible. The GetNetworkMap interface MAY be provided by an ALTO Server. Interface Specification: o Accepted Query: getnetworkmap o Accepted Parameters: Any There are no guarantees about the reusability of successful requests Penno & Yang Expires September 5, 2009 [Page 21] Internet-Draft ALTO Protocol March 2009 to this interface. Thus, the ALTO Server MUST indicate in the HTTP response that it is not cacheable. 5.3.3. GetNetworkMap-Source This interface returns a subset of the Network Map containing at least Network Locations used in the response to the GetCost-Source interface. The GetNetworkMap-Source interface MAY be provided by an ALTO Server. Interface Specification: o Accepted Query: getnetworkmap o Accepted Parameters: Indicate Source NL-ID consistent with URI. Successful requests to this interface MUST generate a response message that is independent of the querying ALTO Client. Thus, the ALTO Server MAY indicate caching parameters in the HTTP response. 5.3.4. GetNetworkMap-Complete This interface returns the full Network Map. The GetNetworkMap-Complete interface MUST be provided by an ALTO Server. Interface Specification: o Accepted Query: getnetworkmap o Accepted Parameters: Indicate 'complete' token Successful requests to this interface MUST generate a response message that is independent of the querying ALTO Client. Thus, the ALTO Server MAY indicate caching parameters in the HTTP response. 5.4. Example Usage An ALTO Client embedded in a P2P client (e.g., BitTorrent client) may request an Interface Descriptor from its ALTO Server. The ALTO Server may return the following Interface Descriptor: Penno & Yang Expires September 5, 2009 [Page 22] Internet-Draft ALTO Protocol March 2009 GetNetworkIdentifier /alto/msg.cgi?query=getnetworkidentifier GetNetworkMap /alto/msg.cgi?query=getnetworkmap GetNetworkMap-Source /alto/networkmap-src-.txt GetNetworkMap-Complete /alto/networkmap-complete.txt GetCost /alto/msg.cgi?query=getcost GetCost-Source /alto/costmap-src-.txt GetCost-Complete /alto/costmap-complete.txt Next, if any URI used by the client contains the '' token, the P2P client queries GetNetworkIdentifier without any parameters to obtain its Source Group. It then replaces the '' token in the URI template. Last, the client may then use the GetCost-Source interface with the computed URI. 6. ALTO Costs Preferences are communicated to ALTO Clients in the form of network costs. ALTO Costs have two attributes: o Type: identifies what the costs represent o Mode: identifies how the costs should be interprested 6.1. Type Attribute The Type attribute indicates what the cost represents. For example, an ALTO Server could define costs representing air-miles, hop-counts, ranking, or generic routing costs. Cost types are indicated in protocol messages as alphanumeric strings. An ALTO Server MUST at least define the routing cost type denoted by the string 'routingcost'. Note that an ISP may internally compute routing cost using any method it chooses (including air-miles or hop-count). If an ALTO Client requests a cost Type that is not available, the ALTO Server responds with an error as specified in Section 4.3.4. 6.2. Mode Attribute The Mode attribute indicates how costs should be interpreted. For example, an ALTO Server could return costs that should be interpreted as numerical values or ordinal rankings. Penno & Yang Expires September 5, 2009 [Page 23] Internet-Draft ALTO Protocol March 2009 It is important to communicate such information to ALTO Clients, as certain operations may not be valid on certain costs returned by an ALTO Server. For example, it is possible for an ALTO Server to return a set of IP addresses with costs indicating a ranking of the IP addresses. Arithmetic operations, such as summation, that would make sense for numerical values, do not make sense for ordinal rankings. ALTO Clients may want to handle such costs differently. Cost Modes are indicated in protocol messages as alphanumeric strings. An ALTO Server MUST at least define the modes 'numerical' and 'ordinal'. If an ALTO Client requests a cost Mode that is not supported, the ALTO Server MUST reply with costs having Mode either 'numerical' or 'ordinal'. Thus, an ALTO Server must implement at least one of 'numerical' or 'ordinal' Costs, but it may choose which to support. ALTO Clients may choose how to handle such situations. Two particular possibilities are to use the returned costs as-is (e.g., treat numerical costs as ordinal rankings) or ignore the ALTO information altogether. 6.3. Semantics Costs returned by an ALTO Server SHOULD be defined such that higher values indicate a lower preference, while smaller values indicate a higher preference. 7. Discussions 7.1. Discovery The particular mechanism by which an ALTO Client discovers its ALTO Server is an important component to the ALTO architecture and numerous techniques have been discussed [11] [12]. However, the discovery mechanism is out of scope for this document. Some ISPs have proposed the possibility of delegation, in which an ISP provides information for customer networks which do not wish to run Portal Servers themselves. A consideration for delegation is that customer networks may wish to explicitly configure such delegation. 7.2. Network Address Translation Considerations At this day and age of v4<->v4, v4<->v6[13], and possibly v6<->v6[14] NATO's, a protocol should strive to be NAT friendly and minimize carrying IP addresses in the payload, or provide a mode of operation Penno & Yang Expires September 5, 2009 [Page 24] Internet-Draft ALTO Protocol March 2009 where the source IP address provide the information necessary to the server. The protocol specified in this document provides a mode of operation (the GetCost-Source interface) where the source NL-ID is computed by the ALTO Server (via the GetNetworkIdentifier interface) from the source IP address ALTO Client requests. This is similar to how some P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS Protocol" in [15]). 7.3. Mapping IPs to ASNs The ALTO Protocol described in this document allows ISPs to provide ALTO information including ASNs. Thus, ALTO Clients may need to identify the ASN for a Resource Provider to determine the cost to that Resource Provider. Applications can already map IPs to ASNs using information from a BGP Looking Glass. To do so, they must download a file of about 1.5MB when compressed (as of October 2008, with all information not needed for IP to ASN mapping removed) and periodically (perhaps monthly) refresh it. Alternatively, the GetNetworkMap interface defined in this document could be extended to map ASNs into a set of IP prefixes. The mappings 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. 7.4. P2P Peer Selection This section discusses possible approaches to peer selection using ALTO information (Network Location Identifiers and associated Costs) from an ALTO Server. Specifically, the application must select which peers to use based on this and other sources of information. With this in mind, the usage of ALTO Costs is intentionally flexible, because: Different applications may use the information differently. For example, an application that connects to just one address may have a different algorithm for selecting it than an application that connects to many. Though initial experiments have been conducted [16], more investigation is needed to identify other methods. Penno & Yang Expires September 5, 2009 [Page 25] Internet-Draft ALTO Protocol March 2009 In addition, the application might account for robustness, perhaps using randomized exploration to determine if it performs better without ALTO information. 7.4.1. Client-based Peer Selection One possibility is for peer selection using ALTO costs to be done entirely by a P2P client. The following are some techniques have been proposed and/or used: o Prefer network locations with lower ordinal rankings (i.e., higher priority) [17] [5]. o Optimistically unchoking low-cost peers with higher probability [5]. 7.4.2. Server-based Peer Selection Another possibility is for ALTO costs to be used by an Application Tracker (e.g., BitTorrent Tracker) when returning peer lists. The following are techniques that have been proposed and/or used: o Using bandwidth matching (e.g., at an Application Tracker) and choosing solution (within bound of optimal) with minimal network cost [16]. 8. IANA Considerations This document request the registration of a new media type: "application/alto" 9. Security Considerations 9.1. ISPs ISPs must be cognizant of the network topology and provisioning information provided through ALTO Interfaces. ISPs should evaluate how much information is revealed and the associated risks. In particular, providing overly fine-grained information may make it easier for attackers to infer network topology. On the other hand, revealing overly coarse-grained information may not provide benefits to network efficiency or performance improvements to ALTO Clients. Penno & Yang Expires September 5, 2009 [Page 26] Internet-Draft ALTO Protocol March 2009 9.2. ALTO Clients 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. ALTO Clients should also be cognizant of revealing Network Location Identifiers (IP addresses or fine-grained PIDs) to the ALTO Server, as doing so may allow the ALTO Server to infer communication patterns. One possibility is for the ALTO Client to only rely on the GetNetworkMap-Source/GetNetworkMap-Complete and GetCost-Source/ GetCost-Complete interfaces. The use of SSL/TLS can make it easier for clients to verify the origin of ALTO information. 9.3. ALTO Information An ALTO Server may optionally use authentication and encryption to protect ALTO information. Authentication and encryption may be provided using HTTP Basic or Digest Authentication and/or SSL/TLS. 10. References 10.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", RFC 4566, July 2006. [3] Berners-Lee, T., Fielding, R., and H. Nielsen, "Hypertext Transfer Protocol -- HTTP/1.0", RFC 1945, May 1996. [4] Fielding, R., Gettys, J., Mogul, J., Frystyk, H., Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999. 10.2. Informative References [5] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information Export Service", draft-shalunov-alto-infoexport-00 (work in progress), October 2008. Penno & Yang Expires September 5, 2009 [Page 27] Internet-Draft ALTO Protocol March 2009 [6] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P: Provider Portal for P2P Applications", draft-p4p-framework-00 (work in progress), November 2008. [7] Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, "P4P Protocol Specification", draft-wang-alto-p4p-specification-00 (work in progress), March 2009. [8] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-kiesel-alto-reqs-02 (work in progress), March 2009. [9] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-marocco-alto-problem-statement-05 (work in progress), March 2009. [10] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An Architecture of ALTO for P2P Applications", draft-yang-alto-architecture-00 (work in progress), March 2009. [11] Garcia, G., Tomsu, M., and Y. Wang, "ALTO Discovery Protocols", draft-wang-alto-discovery-00 (work in progress), March 2009. [12] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application- Layer Traffic Optimization (ALTO): Discover ALTO Servers", draft-song-alto-server-discovery-00 (work in progress), March 2009. [13] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 Translation", draft-baker-behave-v4v6-framework-02 (work in progress), February 2009. [14] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address Translation (NAT66)", draft-mrw-behave-nat66-01 (work in progress), November 2008. [15] "Bittorrent Protocol Specification v1.0", http://wiki.theory.org/BitTorrentSpecification, 2009. [16] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. Silberschatz., "P4P: Provider Portal for (P2P) Applications", In SIGCOMM 2008. [17] Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D. Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 (work in progress), March 2009. Penno & Yang Expires September 5, 2009 [Page 28] Internet-Draft ALTO Protocol March 2009 Appendix A. 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 29] Internet-Draft ALTO Protocol March 2009 Microsoft Corp. yu-shun.wang@microsoft.com Richard Woundy Comcast Richard_Woundy@cable.comcast.com Appendix B. Acknowledgements We would like to thank the following additional people who were involved in either of the projects (P4P or ALTO Info-Export) that contributed to this merged document: Alex Gerber (AT&T), Chris Griffiths (Comcast), Ramit Hora (Pando Networks), Arvind Krishnamurthy (University of Washington), Marty Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), Stefano Previdi (Cisco), James Royalty (Pando Networks), Thomas Scholl (AT&T), Emilio Sepulveda (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell Canada), Haibin Song (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), Haiyong Xie (Yale University), and David Zhang (PPLive). Authors' Addresses Reinaldo Penno (editor) Juniper Networks 1194 N Mathilda Avenue Sunnyvale, CA USA Email: rpenno@juniper.net Y. Richard Yang (editor) Yale University Email: yry@cs.yale.edu Penno & Yang Expires September 5, 2009 [Page 30]