ALTO S. Kiesel Internet-Draft M. Stiemerling Intended status: Standards Track NEC Europe Ltd. Expires: September 4, 2009 March 3, 2009 ALTO H12 draft-kiesel-alto-h12-00 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 4, 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. Kiesel & Stiemerling Expires September 4, 2009 [Page 1] Internet-Draft ALTO H12 March 2009 Abstract Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This memo proposes one possible way of implementing the ALTO protocol, called H12. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Solution Space . . . . . . . . . . . . . . . . . . . . . . . . 4 3. Proposed Solution . . . . . . . . . . . . . . . . . . . . . . 6 4. Security Considerations . . . . . . . . . . . . . . . . . . . 8 5. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 9 6. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6.1. Normative References . . . . . . . . . . . . . . . . . . . 10 6.2. Informative References . . . . . . . . . . . . . . . . . . 10 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11 Kiesel & Stiemerling Expires September 4, 2009 [Page 2] Internet-Draft ALTO H12 March 2009 1. Introduction Many Internet applications are used to access resources, such as pieces of information or server processes, which are available in several equivalent replicas on different hosts. This includes, but is not limited to, peer-to-peer file sharing applications. The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This memo proposes one possible way of implementing the ALTO protocol, called H12. The H12 protocol is a client/server protocol between end hosts and ALTO servers. The problem space of ALTO is described in [I-D.marocco-alto-problem-statement] and the set of requirements is discussed in [I-D.kiesel-alto-reqs]. Comments and discussions about this protocol proposal should be directed to the ALTO working group: alto@ietf.org. Kiesel & Stiemerling Expires September 4, 2009 [Page 3] Internet-Draft ALTO H12 March 2009 2. Solution Space The ALTO protocol is a client/server protocol, operating between a number of ALTO clients and an ALTO server, as sketched in Figure 1 +----------+ | ALTO | | Server | +----------+ ^ _.-----|------. ,-'' | `--. ,' | `. ( Network | ) `. | ,' `--. | _.-' `------|-----'' v +----------+ +----------+ +----------+ | ALTO | | ALTO |...| ALTO | | Client | | Client | | Client | +----------+ +----------+ +----------+ Figure 1: Network Overview of ALTO Protocol An ALTO server stores information about preferences (e.g., a list of preferred autonomous systems, IP ranges, etc) and ALTO clients can retrieve these preferences. However, there are basically two different approaches on where the preferences are actually processed: 1. The ALTO server has a list of preferences and clients can retrieve this list via the ALTO protocol. This preference list can be partially updated by the server. The actual processing of the data is done on the client and thus there is no data of the client's operation revealed to the ALTO server . This approach has been proposed by [I-D.shalunov-alto-infoexport]. 2. The ALTO server has a list of preferences or preferences calculated during runtime and the ALTO client is sending information of its operation (e.g., a list of IP addresses) to the server. The server is using this operational information to determine its preferences and returns these preferences (e.g., a sorted list of the IP addresses) back to the ALTO client. This approach has been initially described in [ACM.ispp2p], but never been described on the protocol level. Approach 1 (we call it H1) has the advantage (seen from the client) that all operational information stays within the client and is not Kiesel & Stiemerling Expires September 4, 2009 [Page 4] Internet-Draft ALTO H12 March 2009 revealed to the provider of the server. On the other hand, does approach 1 require that the provider of the ALTO server, i.e., the network operator, reveals information about its network structure (e.g., AS numbers, IP ranges, topology information in general) to the ALTO client. Approach 2 (we call it H2) has the advantage (seen from the operator) that all operational information stays with the ALTO server and is not revealed to the ALTO client. On the other hand, does approach 2 require that the clients send their operational information to the server. Both approaches have their pros and cons and are extensively discussed on the ALTO mailing list. But there is basically a dilemma: Approach 1 is seen as the only working solution by peer-to- peer software vendors and approach 2 is seen as the only working by the network operators. But neither the software vendors nor the operators seem to willing to change their position. However, there is the need to get both sides on board, to come to a solution. Therefore, this does memo proposes to integrate both approaches in one protocol and offer a way for clients and servers to learn each preferred way of operating. Kiesel & Stiemerling Expires September 4, 2009 [Page 5] Internet-Draft ALTO H12 March 2009 3. Proposed Solution The current proposed solution is not yet defining a bit level syntax but describes the protocol on a high-level, i.e., it is not yet a complete solution that can be implemented and deployed. The H12 protocol uses TCP as transport protocol between clients and server and some encoding of the messages to be defined later on. Unlike the H1H2 protocol[I-D.stiemerling-alto-h1h2-protocol] the H12 protocol does not have several modes of operation, which have to be negotiated at the startup. Instead it allows the client and the server some flexibility in the requests and the responses while using only on mode of operation. The client puts one or several host location attributes, about which it wants to receive a rating, in the query message. We proposes, as example and not to predetermine the final encoding scheme, that the client uses the TLV defined in Figure 2. 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | Type | Length | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ // IPv4 or IPv6 address // +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ | PrefixLength | Reserved | +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ Figure 2: TLV for IP addresses and ranges The Type and Length fields are tbd. The IPv4 or IPv6 address field carries the actual address or address prefix (actually there might be two different TLVs for each IP version). The PrefixLength field carries the length of the prefix (e.g., 32 for a full IPv4 address). This TLV carries a full IP address or an IP address prefix, leaving the client the choice how much of an IP address it wants to reveal to the server. That is, the client can request information for one or several specific IP addresses (PrefixLength equal 32 or 128), for address ranges, or for "the whole Internet" (PrefixLength equal 0). However, the "whole Internet" is not really referring to the whole Internet as such, as no single entity can have such a big knowledge, but to whatever broader scope the server can give guidance about. This scop can include, for instance, its own complete network. Kiesel & Stiemerling Expires September 4, 2009 [Page 6] Internet-Draft ALTO H12 March 2009 Furthermore, the client specifies one or several rating criteria, such as operator preference, lower bound for delay, etc. For a work- in-progress list of such rating criteria see [I-D.kiesel-alto-reqs]. The server replies with a list of network location attributes, in the same format as in the query, and the respective ratings for the requested attributes. However, the number of lines in this list may be shorter or longer than in the query, and the PrefixLengths may be different: o The server may decide not to give any rating for a specific location attribute. In this case, a default value applies. o Instead of rating several location attributes with long PrefixLengths (in particular: individual IP addresses) individually, the server may decide to give only one rating for a broader address range (i.e., PrefixLength is shorter). o Instead of giving one rating for a large address range, the server may decide to give several ratings for smaller ranges (i.e., i.e., each returned TLV has a PrefixLength that is longer that requested). The actual rating is given for each rating criterion as a signed integer value. A value of zero (0) means "default value". This value is to be used if the server has no information regarding this (network location attribute, rating criteria) tuple, or if it does not want to disclose it. Positive values mean that this location is "better" than default and therefore should be preferred for peer selection, while negative values indicate the location to be "worse" than default and therefore that it should be avoided. The meaning of "better" and "worse", as well as the scale has to be defined individually for each rating criterion. This approach gives both sides, i.e., server and clients, to still exchange their desired information and level of precision, but also gives the chance to hide information if necessary and desired. Kiesel & Stiemerling Expires September 4, 2009 [Page 7] Internet-Draft ALTO H12 March 2009 4. Security Considerations This initial version of this memo does not yet have any security considerations, but they will be added in future revision. Kiesel & Stiemerling Expires September 4, 2009 [Page 8] Internet-Draft ALTO H12 March 2009 5. Conclusion This memo presents a very basic straw man protocol, is for sure work in progress, and is requesting feedback from the ALTO working group. Ask the authors why it is called H12. Kiesel & Stiemerling Expires September 4, 2009 [Page 9] Internet-Draft ALTO H12 March 2009 6. References 6.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. 6.2. Informative References [ACM.ispp2p] Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs and P2P systems co-operate for improved performance?", In ACM SIGCOMM Computer Communications Review (CCR), 37:3, pp. 29-40. [I-D.kiesel-alto-reqs] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-kiesel-alto-reqs-01 (work in progress), November 2008. [I-D.marocco-alto-problem-statement] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-marocco-alto-problem-statement-04 (work in progress), February 2009. [I-D.shalunov-alto-infoexport] Shalunov, S., Penno, R., and R. Woundy, "ALTO Information Export Service", draft-shalunov-alto-infoexport-00 (work in progress), October 2008. [I-D.stiemerling-alto-h1h2-protocol] Stiemerling, M. and S. Kiesel, "ALTO H1/H2 Protocol", draft-stiemerling-alto-h1h2-protocol-00 (work in progress), March 2009. Kiesel & Stiemerling Expires September 4, 2009 [Page 10] Internet-Draft ALTO H12 March 2009 Authors' Addresses Sebastian Kiesel NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 232 Fax: +49 6221 4342 155 Email: kiesel@nw.neclab.eu URI: http://www.nw.neclab.eu/ Martin Stiemerling NEC Laboratories Europe/University of Goettingen Kurfuerstenanlage 36 Heidelberg 69115 Germany Phone: +49 6221 4342 113 Fax: +49 6221 4342 155 Email: stiemerling@nw.neclab.eu URI: http://www.nw.neclab.eu/ Kiesel & Stiemerling Expires September 4, 2009 [Page 11]