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: <type>=<value> where <type> MUST be exactly one case-
   significant character and <value> is structured text whose format
   depends on <type>.  In general, <value> 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=<integer>

   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=<query type> [SRC <Source NL-ID> | 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=<query type> [<success code> | [<failure code> <failure desc>]]
           [<map version tag>] [COST <cost type> <cost mode>]

   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=<FQDN> | <IP address>

   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 <Source NL-ID> [DEST <Dest NL-ID> <cost value>]

   The cost is a generic measure of network preference.

4.1.7.  Network Locations (n=)

       n=SRC <Source NL-ID> [DEST <Dest NL-ID>]

   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=<Top-Level NL-ID> [<NL-ID> ... <NL-ID>]

   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=<interface name> <interface URI>

   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 <Source NL-ID>] | complete
           [COST <cost type> <cost mode>]
       n=SRC <Source NL-ID> [DEST <Dest NL-ID>]
       n=SRC <Source NL-ID> [DEST <Dest NL-ID>]
       ...

   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 [<success code> | [<failure code> <failur desc>]]
           <map version tag> COST <cost type> <cost mode>
       c=SRC <Source NL-ID> DEST <Dest NL-ID> <cost value>
       c=SRC <Source NL-ID> DEST <Dest NL-ID> <cost value>
       ...

   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 [<success code> | [<failure code> <failur desc>]]
           <map version tag> COST <cost type> <cost mode>
       c=SRC <Source NL-ID>
       <Dest NL-ID> <cost value>
       <Dest NL-ID> <cost value>
       ...
       c=SRC <Source NL-ID>
       <Dest NL-ID> <cost value>
       <Dest NL-ID> <cost value>
       ...

   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 <Source NL-ID>]
       n=SRC <Source NL-ID>

   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 [<success code> | [<failure code>
           <failur desc>]] <map version tag>
       m=<Top-Level NL-ID> [ <NL-ID> ... <NL-ID> ]
       m=<Top-Level NL-ID> [ <NL-ID> ... <NL-ID> ]
       ...

   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 <Top-Level NL-ID>] | complete
       n=SRC <Top-Level NL-ID>
       n=SRC <Top-Level NL-ID>
       ...

   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 [<success code> | [<failure code>
           | <failure desc>]] <map version tag>
       m=<Top-Level NL-ID> [<NL-ID> ... <NL-ID>]
       m=<Top-Level NL-ID> [<NL-ID> ... <NL-ID>]
       ...

   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 '<SRC-GRP>', 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 <success code>
       i=<interface name> <interface URI template>
       ...
       i=<interface name> <interface URI template>




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-<SRC-GRP>.txt
       GetNetworkMap-Complete  /alto/networkmap-complete.txt
       GetCost                 /alto/msg.cgi?query=getcost
       GetCost-Source          /alto/costmap-src-<SRC-GRP>.txt
       GetCost-Complete        /alto/costmap-complete.txt

   Next, if any URI used by the client contains the '<SRC-GRP>' token,
   the P2P client queries GetNetworkIdentifier without any parameters to
   obtain its Source Group.  It then replaces the '<SRC-GRP>' 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]