ALTO WG                                                    R. Penno, Ed.
Internet-Draft                                          Juniper Networks
Intended status: Standards Track                            Y. Yang, Ed.
Expires: September 5, 2009                               Yale University
                                                          March 04, 2009


                             ALTO Protocol
                    draft-penno-alto-protocol-00.txt

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-
   Drafts.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at
   http://www.ietf.org/ietf/1id-abstracts.txt.

   The list of Internet-Draft Shadow Directories can be accessed at
   http://www.ietf.org/shadow.html.

   This Internet-Draft will expire on September 5, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents in effect on the date of
   publication of this document (http://trustee.ietf.org/license-info).
   Please review these documents carefully, as they describe your rights
   and restrictions with respect to this document.

Abstract

   The ALTO Service enables an Internet Service Provider (ISP) to convey
   cost preferences to network applications in order to modify network



Penno & Yang            Expires September 5, 2009               [Page 1]


Internet-Draft       ALTO InformationExport Service           March 2009


   resource consumption patterns while maintaining or improving
   application performance.  Applications that could use this service
   are those that have a choice in connection endpoints.  Examples of
   such applications are peer-to-peer (P2P) and content delivery
   networks.

   Applications already have access to great amount of underlying
   topology information.  For example, views of the Internet routing
   table are easily available at looking glass servers and entirely
   practical to download to every client.  What is missing is the cost
   information -- what does an ISP or Content Provider actually prefer?

   This document describes a very simple protocol that allows a ISP to
   convey such information to applications.  While such service would
   primarily be provided by the network, i.e., the local ISP, Content
   Provider and third parties could also operate this service.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [1].





























Penno & Yang            Expires September 5, 2009               [Page 2]


Internet-Draft       ALTO InformationExport Service           March 2009


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Protocol Design Approach . . . . . . . . . . . . . . . . . . .  5
   4.  Protocol Overview  . . . . . . . . . . . . . . . . . . . . . .  5
   5.  Discovery  . . . . . . . . . . . . . . . . . . . . . . . . . .  6
   6.  ALTO Specification . . . . . . . . . . . . . . . . . . . . . .  7
     6.1.  Protocol Version (v=)  . . . . . . . . . . . . . . . . . .  8
     6.2.  Message Identifier (m=)  . . . . . . . . . . . . . . . . .  8
     6.3.  Query Type (q=)  . . . . . . . . . . . . . . . . . . . . .  8
     6.4.  Response (r=)  . . . . . . . . . . . . . . . . . . . . . .  8
     6.5.  Originator (o=)  . . . . . . . . . . . . . . . . . . . . .  8
     6.6.  Network Location (n=)  . . . . . . . . . . . . . . . . . .  9
     6.7.  Cost (c=)  . . . . . . . . . . . . . . . . . . . . . . . .  9
   7.  ALTO Messages  . . . . . . . . . . . . . . . . . . . . . . . .  9
     7.1.  Getcost Query  . . . . . . . . . . . . . . . . . . . . . . 10
     7.2.  Getcost Response . . . . . . . . . . . . . . . . . . . . . 11
     7.3.  GetnetworkIdentifier Query . . . . . . . . . . . . . . . . 12
     7.4.  GetnetworkIdentifier Response  . . . . . . . . . . . . . . 12
     7.5.  Getnetworkmap Query  . . . . . . . . . . . . . . . . . . . 13
     7.6.  Getnetworkmap Response . . . . . . . . . . . . . . . . . . 13
   8.  Alto Server Message Processing . . . . . . . . . . . . . . . . 13
     8.1.  Exception Handling . . . . . . . . . . . . . . . . . . . . 13
     8.2.  Successful Responses . . . . . . . . . . . . . . . . . . . 13
     8.3.  Invalid Query Format . . . . . . . . . . . . . . . . . . . 13
     8.4.  Unsupported Query  . . . . . . . . . . . . . . . . . . . . 13
   9.  Semantics  . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   10. P2P Client Peer Selection Example  . . . . . . . . . . . . . . 14
   11. Message Exchanges Examples . . . . . . . . . . . . . . . . . . 15
     11.1. Request cost for all NL-IDs  . . . . . . . . . . . . . . . 15
     11.2. Request NL-ID for Own IP Address . . . . . . . . . . . . . 16
     11.3. Request NL-IDs for List of IP Addresses  . . . . . . . . . 16
     11.4. Request NL-ID Map  . . . . . . . . . . . . . . . . . . . . 16
     11.5. Request the Cost Between two NL-IDs  . . . . . . . . . . . 16
   12. Network Address Translation Considerations . . . . . . . . . . 16
   13. Mapping IPs to ASNs  . . . . . . . . . . . . . . . . . . . . . 16
   14. ALTO Protocol Grammar  . . . . . . . . . . . . . . . . . . . . 17
   15. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   16. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 18
   17. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 19
   18. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   19. References . . . . . . . . . . . . . . . . . . . . . . . . . . 19
     19.1. Normative References . . . . . . . . . . . . . . . . . . . 19
     19.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20





Penno & Yang            Expires September 5, 2009               [Page 3]


Internet-Draft       ALTO InformationExport Service           March 2009


1.  Introduction

   Applications employ a variety of methods to get the best performance
   out of the network.  Today the information available to applications
   is mostly the view from end hosts.  There is no clear mechanism to
   convey information about the network's preferences to applications.
   For example, peer-to-peer applications have been successful in
   achieving a good level of service for bulk transfer applications, but
   can work with the network better if they can leverage ISP policy and
   information.  The ALTO service intends to provide a simple way to
   convey ISP preferences to applications.

   This document describes a very simple protocol that allows a ISP to
   convey such information to applications.  The protocol specified here
   is a merge between two other protocols, Alto Info-Export[4] and
   P4P[5][6] and due to this fact is a work in progress.


2.  Terminology

   We use the following terms defined in [7]: Application, Overlay
   Network, Peer, Resource, Resource Identifier, Resource Provider,
   Resource Consumer, Resource Directory, Transport Address, Host
   Location Attribute, ALTO Service, ALTO Server, ALTO Client, ALTO
   Query, ALTO Reply, ALTO Transaction, Local Traffic, Peering Traffic,
   Transit Traffic.

   The terminology introduced in this document is listed below.

   o  Cost: Cost defines the preference of a network location type and
      identifier from the point of view of another network location
      identifier.  The notion of cost was decouple from the network
      location type to allow for maximum flexibility in meeting
      different requirements.

   o  Network location type (NL-T): There are many types of network
      location types: IP Prefixes, Autonomous System, PIDs, geographical
      location, etc

   o  Network Location Identifier (NL-ID): A specific value of a network
      location type.

   o  PID: A Partition ID, or a PID for short, is an identifier that
      provide an indirect and network agnostic way to specifying NL-IDs.
      It can denote a subnet, a set of subnets, or an autonomous system
      (AS), for example.





Penno & Yang            Expires September 5, 2009               [Page 4]


Internet-Draft       ALTO InformationExport Service           March 2009


3.  Protocol Design Approach

   The protocol specified in this document is a merge between two other
   protocols, Alto Info-Export[4] and P4P[5][6].  The goal is to provide
   an unified protocol that meets the ALTO requirement[8], provides an
   migration path for ISP, Content Providers, and clients that have
   deployed the above mentioned protocols and yet remain simple.


4.  Protocol Overview

   Each network region can choose to support the ALTO service.  (A
   network region in this context is an Autonomous System, an ISP, or
   perhaps a smaller region -- the details depend on the mechanism of
   discovery.)

  +--------------------------------------------------------------------+
  |                                ISP                                 |
  |                                                                    |
  |                     +---------+                                    |
  |                     | Routing |                                    |
  | +--------------+    | Policy  |                                    |
  | | Provisioning |    +---------+                                    |
  | | Policy       |          |                                        |
  | +--------------+\         |                                        |
  |                  `.       |                                        |
  |                    \      |                                        |
  |   +-----------+     `.+---------+                      +--------+  |
  |   |Dynamic    |       | ALTO    | ALTO Query/Response  | ALTO   |  |
  |   |Network    |.......| Server  | -------------------- | Client |  |
  |   |Information|       +---------+                      +--------+  |
  |   +-----------+       .,-                             /            |
  |                    _,-'       ALTO SD Query/Response /             |
  |                  ,-'                                /              |
  |           +----------+                  +--------------+           |
  |           | External |                  | ALTO Service |           |
  |           | Interface|                  | Discovery    |           |
  |           +----------+                  +--------------+           |
  |                |                                                   |
  |                |           Figure 1: Basic ALTO Architecture.      |
  |                |                                                   |
  +--------------------------------------------------------------------+
                   |
         +------------------+
         | Third Parties    |
         |                  |
         | Content Providers|
         +------------------+



Penno & Yang            Expires September 5, 2009               [Page 5]


Internet-Draft       ALTO InformationExport Service           March 2009


   The service works as follows:

   1.  The ISP prepares the ALTO information which constitutes the ISP's
       "My-Internet view" [9] and populates the ALTO Server.  This
       information mainly consists of network locations identifiers and
       their associated cost.  The information in the ALTO Server can be
       updated dynamically based on network conditions or can be seen as
       a policy, which is updated on much longer time-scales.  In the
       most simple case this maps some IP prefixes or AS numbers into
       priority values.

   2.  The ISP serializes the information into a sequence of octets.

   3.  The application, running on a given host, discovers the resource
       and fetches the serialized ALTO information (Section 7).

   4.  The application makes use of the information by preferring
       network locations with higher priority (Section 8)

   The part of the ISP MAY be implemented, to give a few examples, that
   do not preclude other implementation options:

      by running a script connecting to existing equipment, fetching
      routing information, and then generating and uploading the
      requisite file;

      by running a database-backed application that is obtains routing
      information from existing equipment and generates the requisite
      file dynamically;

      by modifying the software or hardware of existing equipment to
      support these functions; or

      by using new equipment for the purpose of operating this network
      service.


5.  Discovery

   Discovery of the ALTO Server is out of scope for this document and
   will be handled separately.  A discussion of the different possible
   protocols to discover an ALTO Service can be found in [10]

   The necessary property of discovery is that a client, starting from
   nothing on today's Internet that does not yet universally support
   global-scope multicast and may include NATO's, can ultimately find
   the IP address of the ALTO Server as configured by the ISP.
   Subsequent sections assume that this IP address is known to the



Penno & Yang            Expires September 5, 2009               [Page 6]


Internet-Draft       ALTO InformationExport Service           March 2009


   client


6.  ALTO Specification

   The ALTO protocol design borrows ideas from the Session Description
   Protocol[2] with the goal of leveraging the current HTTP[[3]RFC2616]
   implementations and infrastructure.  An ALTO information exchange is
   denoted by the HTTP header Content-Type "application/alto" and is
   carried within HTTP similarly to how SDP is carried within SIP.  This
   approach has several advantages:

   o  It leverages the huge installed base of HTTP infrastructure

   o  It leverages all the mature software that has been implemented for
      both HTTP and SDP.

   o  It leaves HTTP free of proprietary headers ("X-")

   o  It does not require use of specific URIs to denote service

   o  It allows the protocol to evolve separately from HTTP.

   o  it makes the protocol easy to understand and debug

   o  It leverages the fact that many P2P clients already have an
      embedded HTTP client

   o  Finally it allows the ALTO protocol to be carried by other
      protocols other than HTTP in the future, such as SIP.

   An ALTO Information description consists of a number of lines of text
   of the form: <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 "*".

   Support Types:






Penno & Yang            Expires September 5, 2009               [Page 7]


Internet-Draft       ALTO InformationExport Service           March 2009


      v=(protocol version)

      m=(message identifier)

      q=(Query type)

      r=(Response)

      o=(originator)

      c=(cost)

      n=(network)

6.1.  Protocol Version (v=)

   v=1

   The line defines the protocol version.  The version specified in this
   document is 1.

6.2.  Message Identifier (m=)

   m=<integer>

   This allows transactions and demultiplexing of messages at the
   application level

6.3.  Query Type (q=)

   q=<query type> [<network location type>[:SRC <source network location
   identifier>]]

   The query type can be getcost, getnetworklocation and getstatus.
   Depending on the query type, different types of parameters are sent
   and received from the server

6.4.  Response (r=)

   r = <query type> [[<success code> | [<failure code> <failure desc>]]

   This line is used by the Server in a response to a previous query.

6.5.  Originator (o=)

   o= <FQDN | IP Address>

   This line identifies the originator of cost information, which is not



Penno & Yang            Expires September 5, 2009               [Page 8]


Internet-Draft       ALTO InformationExport Service           March 2009


   necessarily related to the source IP address of the message.

6.6.  Network Location (n=)

   n=[<network location type>:]SRC <source network location identifier>
   DEST [<destination network location identifier>]

   The following network location types are specified in this document:

   o  ASN: Autonomous System Number

   o  IPV4: IP Protocol version 4

   o  IPV6: IP Protocol version 6

   o  PID: Partition ID

   The network location can be used in the getcost and
   getnetworklocation query to specify the mapping needed.

6.7.  Cost (c=)

   c=<network location type>:SRC <network location identifier> DEST
   <network location identifier> <cost type> <cost value>

   The cost is the measure of an network identifier preference.  This
   document specifies the following network location types: IP Prefixes,
   ASNs and PIDs.  The cost needs to include the location type unless it
   is present at the subsection level.  Network Locations with positive
   priorities are more desirable than the default.  Network Locations
   with negative priorities are less desirable than the default.

   The cost type defines the contextual representation of the cost.  The
   specification defines two cost types: rank and generic distance.


7.  ALTO Messages

   ALTO Queries must have the following lines:

      v=(version)

      m=(message identifier)

      q=(query type)

   Alto responses must have:




Penno & Yang            Expires September 5, 2009               [Page 9]


Internet-Draft       ALTO InformationExport Service           March 2009


      v=(version )

      m=(message identifier)

      r=(response)

7.1.  Getcost Query

      q=getcost [<network location type>[:SRC <source network location
      identifier>]]

      n=[<network location type>:]SRC <source network location
      identifier> DEST [<destination network location identifier>]

   A getcost request causes the server to return a list of network
   location types, identifiers and their associated cost.  If the
   message does not specify the source network identifier and type the
   server should assume that the source IP addresses indicates the
   source network identifier.  Alternatively the client can specify a
   source network location type and identifier to be used for computing
   the cost to other locations.

      q=getcost <network location type>:SRC <source network location
      identifier>

   The response from the server in both of these cases is an unordered
   list of costs for the network source and type specified by the client
   such as:

      r = getcost [[<success code> | [<failure code> <failure desc>]]

      c=<network location type>[:SRC <source network location
      identifier>] <cost type>

      <network location identifier> <cost>

      <network location identifier> <cost>

      <network location identifier> <cost>

      ...

   Another possibility is for the client to request the cost between one
   or more pair of network identifiers.

      q=getcost [network location type]





Penno & Yang            Expires September 5, 2009              [Page 10]


Internet-Draft       ALTO InformationExport Service           March 2009


      n=[<network location type>]:SRC <network location identifier> DEST
      <network location identifier>

   In this case the response contain an ordered list of costs
   corresponding to each pair specified in the request.  If the server
   for any reason cannot compute the cost between a certain SRC-DEST
   pair, it needs to use an invalid cost in the reply.

   The default network location type for request and responses are IP
   Prefixes.

7.2.  Getcost Response

   The network location types used in the response should match the one
   specified in the request unless none was specified.  If a network
   location type was specified, the response would be as follows:

      r=getcost [[<success code> | [<failure code> <failure desc>]]

      c=<network location type>[:SRC <source network location
      identifier>] <cost type>

      <network location identifier> <cost>

      <network location identifier> <cost>

      <network location identifier> <cost>

      <network location identifier> <cost>

      ....

   If a network location type was not specified the server can bundle
   the costs for each network type in sections as below:

      r=getcost [[<success code> | [<failure code> <failure desc>]]

      c=<network location type>[:SRC <source network location
      identifier>] <cost type>

      <network location identifier> <cost>

      <network location identifier> <cost>

      <network location identifier> <cost>

      ....




Penno & Yang            Expires September 5, 2009              [Page 11]


Internet-Draft       ALTO InformationExport Service           March 2009


      c=<network location type>[:SRC <source network location
      identifier>] <cost type>

      <network location identifier> <cost>

      <network location identifier> <cost>

      <network location identifier> <cost>

      ....

   In the case the server responds the request with interleaved network
   types, each cost needs to be present in a fully specified line as
   below:

      c=<network location type>:<network location identifier> <cost
      type> <cost>

7.3.  GetnetworkIdentifier Query

      q=getnetworklocation [<network location type>[:SRC <source network
      location identifier>]]

      n=[<network location type>:]SRC <source network location
      identifier>

   This request allows the client to query the network location for a
   certain network identifier.  The network location types used in the
   request and response can be different.  This query assumes a 1->1
   relationship between the network identifier in the query and the one
   in the response.  This means that the query can be used to map from a
   more fine grained network identifier to a more less granular one.
   So, the client can use an IP address in the request and get a PID in
   the response.

7.4.  GetnetworkIdentifier Response

      r=getnetworklocation [[<success code> | [<failure code> <failure
      desc>]]

      n=<network location type>:<network location identifier>

   The response to q network location query includes the network
   location type and identifier.  More than one network location line
   can be present for a single query.






Penno & Yang            Expires September 5, 2009              [Page 12]


Internet-Draft       ALTO InformationExport Service           March 2009


7.5.  Getnetworkmap Query

   TBD

7.6.  Getnetworkmap Response

   TBD


8.  Alto Server Message Processing

   This section specifies ALTO Server behavior when processing ALTO
   queries.  In general the ALTO protocol uses the same status codes as
   HTTP.

8.1.  Exception Handling

   Standard HTTP status codes are returned by an ALTO Server in the
   response (r=) line.

8.2.   Successful Responses

   An ALTO Server MUST use Status Code 200 when replying to an operation
   that completed successfully.  Note that this includes cases where the
   ALTO Server responds with only a subset of the requested information.
   The requesting application is expected to detect such cases if
   necessary.

8.3.  Invalid Query Format

   If the Request Data is formatted incorrectly (i.e., it does not
   follow the syntax in Section 6), the ALTO Server MUST return an
   status code and reason of "400 Bad Request".

8.4.  Unsupported Query

   If an Alto Server does not support a certain type of query, e.g.,
   cost for SRC-DEST pairs, a status code and reason of "501 Not
   Implemented" might be returned in lieu of returning an invalid cost.


9.  Semantics

   Network location identifiers with positive priorities are more
   desirable than the default.  Network locations identifiers with
   negative priorities are less desirable than the default.  In general,
   greater values are more desirable.  Zero priority is the default.
   Network Location Identifiers not specified are treated as if they had



Penno & Yang            Expires September 5, 2009              [Page 13]


Internet-Draft       ALTO InformationExport Service           March 2009


   priority zero.

   The absolute value of the priorities does not matter.  Only their
   relative order is meaningful.  Higher values are more desirable.  For
   example, multiplying all the priority values in a given file by the
   same positive integer constant does not change the semantics of the
   file.

   Some ISPs already convey information such as "traffic in the local
   country is free" to their customers.  These ISPs will find the ALTO
   service an excellent means of conveying similar information in a
   machine-readable form.  Only one (positive) priority value is needed
   for such use.

   It is up to the ISP deploying the file to choose how much information
   to publish in it.


10.  P2P Client Peer Selection Example

   After the client application receives a list of network location
   identifier and their cost from the ALTO Server, it needs to make a
   selection on of which peers to use based on this and other sources of
   information.  With this in mind, the semantics of the information are
   intentionally flexible, because:

      Different applications will necessarily use the information
      differently.  For example, an application that connects to just
      one address is going to have a different algorithm for selecting
      it than an application that connects to many.

      Given lack of Internet-scale experimentation with using the
      information, we don't yet know what the best ways are.  We want to
      give different approaches a chance to compete.

   However, it's important to provide at least a non-normative example
   of how such cost information could be used.

   Consider a BitTorrent client that wishes to use the ALTO information.
   The client will have a list of perhaps up to 200 initial candidate
   peers, out of which it will select perhaps 50 peers to try to connect
   to.  In an initial implementation, the client could:

      Split the candidates into three sets: preferred (those with
      positive priorities), to-be-avoided (those with negative
      priorities), and default (0 or unspecified priority)





Penno & Yang            Expires September 5, 2009              [Page 14]


Internet-Draft       ALTO InformationExport Service           March 2009


      Select up to 25 candidates randomly from the preferred set.  In
      particular, if there are fewer than 25 in the preferred set,
      select them all.

      Fill remaining slots up to 50 with candidates from the default
      set.

      If this didn't fill the slots (i.e., fewer than 50 of the
      candidates were in the union of preferred and default sets), fill
      the rest by candidates from the to-be-avoided set.

      When establishing connections after the initial startup, continue
      using the policy of giving up to half the slots to preferred with
      the rest for default and to-be-avoided only as last resort.

      When selecting a peer to optimistically unchoke, half the time
      select a preferred peer if there is one.

   (The particular numbers could be different.)  If the preferred peers
   perform better than default ones, they will dominate the transfers.
   To-be-avoided peers are largely not contacted, unless the prohibitive
   policy is broad enough or the swarm is small enough that it is
   necessary to contact them to fill the slots.

   In addition, the application might use some form of randomized test
   to see if it performs better or worse when the ALTO service use is
   on.


11.  Message Exchanges Examples

   The sections below depict a few typical messages examples.  The ALTO
   protocol can be used with both GET and POST HTTP methods, the
   difference is mainly how caching would work.  This section will be
   further specified in the next revisions of the document.

11.1.  Request cost for all NL-IDs

   In the simplest form the client sends a getcost query to the ALTO
   Server specifying nothing else.  The server assumes the source NL-ID
   is the source IP address of the packet and returns the cost for all
   NL-IDs from this point of view.  See below

      v=1

      q=getcost

   This allow the protocol to work through NATO's without ALGs support.



Penno & Yang            Expires September 5, 2009              [Page 15]


Internet-Draft       ALTO InformationExport Service           March 2009


   The format and purpose of the query becomes is to download the full
   list of costs to every other NL-ID from the client point of view.

11.2.  Request NL-ID for Own IP Address

   The following message exchange illustrates a client requesting its
   own NL-ID from the ALTO Server.  The client uses an empty query, and
   the Alto Server responds with the client's IP address and the NL-ID
   corresponding to the IP address.

11.3.  Request NL-IDs for List of IP Addresses

   The following message exchange illustrates a client directly asking
   the ALTO Server to map a set of IP addresses into their corresponding
   NL-IDs.

11.4.  Request NL-ID Map

   The following message exchange illustrates an application requesting
   the set of IP addresses contained within a set of NL-IDs.

11.5.  Request the Cost Between two NL-IDs

   The following message exchange illustrates an application requesting
   the routing cost between particular NL-IDs.


12.  Network Address Translation Considerations

   At this day and age of v4<->v4, v4<->v6[11] and possibly v6<->v6[12]
   NATO's, a protocol should strive to be NAT friendly and minimize
   carrying IP addresses in the payload, or provide a mode of operation
   where the source IP address provide the information necessary to the
   server.

   The protocol specified in this document provides a mode of operation
   where the source NL-ID is the source IP address of the packet.  This
   is very similar to how Tracker based P2P networks such as Bittorrent
   work.  See "Tracker HTTP/HTTPS Protocol" in [13].  This allows a
   client to work through NATO's without the need for ALGs or NAT
   traversal mechanisms.


13.  Mapping IPs to ASNs

   DISCUSSION: Applications can already map IPs to ASNs using
   information from a BGP looking glass.  To do so, they have to
   download a file of about 1.5MB when compressed (as of October 2008,



Penno & Yang            Expires September 5, 2009              [Page 16]


Internet-Draft       ALTO InformationExport Service           March 2009


   with all information not needed for IP to ASN mapping removed) and
   periodically (perhaps monthly) refresh it.

   Alternatively, the ALTO service as defined in this document could be
   expanded so that there is another file that expands every ASN
   mentioned in the policy file into a set of IP prefixes.  In that
   case, the ASNs in the policy file, from a client's perspective, would
   be treated like macros.  The mapping file provided by the ISP would
   be both smaller and more authoritative.

   For simplicity of implementation, it's highly desirable that clients
   only have to implement exactly one mechanism of mapping IPs to ASNs.

   We're interested in perspectives of others on this.


14.  ALTO Protocol Grammar

   All of the mechanisms specified in this document are described in
   both prose and an augmented Backus-Naur Form (BNF) defined in RFC
   2234 [10].  Section 6.1 of RFC 2234 defines a set of core rules that
   are used by this specification, and not repeated here.  Implementers
   need to be familiar with the notation and content of RFC 2234 in
   order to understand this specification.  Certain basic rules are in
   uppercase, such as SP, LWS, HTAB, CRLF, DIGIT, ALPHA, etc.  Angle
   brackets are used within definitions to clarify the use of rule
   names.

   hostport = host [ ":" port ]

   host = hostname / IPv4address / IPv6reference

   IPv4address = 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT "." 1*3DIGIT

   IPv6address = hexpart [ ":" IPv4address ]

   hexpart = hexseq / hexseq "::" [ hexseq ] / "::" [ hexseq ]

   hexseq = hex4 *( ":" hex4)

   hex4 = 1*4HEXDIG

   port = 1*DIGIT


15.  Acknowledgements

   TBD.



Penno & Yang            Expires September 5, 2009              [Page 17]


Internet-Draft       ALTO InformationExport Service           March 2009


16.  Contributors

   The people listed here should be viewed as co-authors of the
   document.  Due to the limit of 5 authors per draft the co-authors
   were moved to the contributors section at this point.

      Richard Alimi

      Yale University

      EMail: richard.alimi@yale.edu



      D. Pasko

      Verizon

      EMail: pasko@verizon.com



      L. Popkin

      Pando Networks

      EMail: laird@pando.com



      Satish Raghunath

      Juniper Networks

      satishr@juniper.net



      Stanislav Shalunov

      BitTorrent

      EMail: shalunov@bittorrent.com



      Yu-Shun Wang




Penno & Yang            Expires September 5, 2009              [Page 18]


Internet-Draft       ALTO InformationExport Service           March 2009


      Microsoft Corp.

      yu-shun.wang@microsoft.com



      Richard Woundy

      Comcast

      Richard_Woundy@cable.comcast.com


17.  IANA Considerations

   This document request the registration of a new media type:
   "application/alto"


18.  Security Considerations

   The ISP publishing the ALTO policy information has to treat it as
   publishing to the entire world.

   Applications using the information must be cognizant of the
   possibility that the information is malformed or incorrect.  Even
   when it is correct, its use might harm the performance.  When an
   application concludes that it would get better performance
   disregarding the ALTO information, the decision to discontinue the
   use of ALTO information is likely best left to the user.

   The use of TLS (using the "https" URL schema) will make it easier for
   clients to verify the origin of ALTO information.


19.  References

19.1.  Normative References

   [1]   Bradner, S., "Key words for use in RFCs to Indicate Requirement
         Levels", BCP 14, RFC 2119, March 1997.

   [2]   Handley, M., Jacobson, V., and C. Perkins, "SDP: Session
         Description Protocol", July 2006.

   [3]   Fielding, R., J. Gettys, V., Mogul, J., Frystyk, H., Masinter,
         L., Leach, P., and T. Berners-Lee, "Hypertext Transfer Protocol
         -- HTTP/1.1", June 1999.



Penno & Yang            Expires September 5, 2009              [Page 19]


Internet-Draft       ALTO InformationExport Service           March 2009


19.2.  Informative References

   [4]   S. Shalunov, R. Penno, and R. Woundy, "ALTO Information Export
         Service", draft-shalunov-alto-infoexport-00 (work
         in progress) 2008.

   [5]   R. Alimi, D. Pasko, L. Popkin, Y. Wang., "P4P: Provider Portal
         for (P2P) Applications", draft-p4p-framework-00 (work in
         Progress) 2008.

   [6]   Wang, Y., Alimi, R., Popkin, L., and YR. Yang, "P4P Protocol
         Spec", draft-wang-p4p-spec-00, 2009.

   [7]   Seedorf, J. and E. Burger, "Application-Layer Traffic
         Optimization (ALTO) Problem Statement",
         draft-marocco-alto-problem-statement-04 (work in
         progress) 2009.

   [8]   S. Kiesel, L. Popkin, S. Previdi, R. Woundy, and YR. Yang,
         "Application-Layer Traffic Optimization (ALTO) Requirements",
         draft-kiesel-alto-reqs-01 (work in               progress)
         2008.

   [9]   Yang (Ed.), YR., "An Architecture of ALTO for P2P
         Applications", draft-yang-alto-architecture-00.txt, 2009.

   [10]  Garcia, G., Tomsu, M., and Wang, Y., "Alto Discovery Protocol",
         draft-wang-alto-discovery-00.txt, 2009.

   [11]  Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6
         Translation", February draft-baker-behave-v4v6-framework-02,
         2009.

   [12]  Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address
         Translation (NAT66)", November draft-mrw-behave-nat66-01.txt,
         2008.

   [13]  "Bittorrent Protocol Specification v1.0",
         http://wiki.theory.org/BitTorrentSpecification, 2009.

   [14]  H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A.
         Silberschatz., "P4P: Provider Portal for (P2P) Applications",
         In SIGCOMM 2008.








Penno & Yang            Expires September 5, 2009              [Page 20]


Internet-Draft       ALTO InformationExport Service           March 2009


Authors' Addresses

   Reinaldo Penno (editor)
   Juniper Networks
   1194 N Mathilda Avenue
   Sunnyvale,


   Phone:
   Fax:
   Email: rpenno@juniper.net
   URI:


   Y. Richard Yang (editor)
   Yale University


   Phone:
   Fax:
   Email: yry@cs.yale.edu
   URI:





























Penno & Yang            Expires September 5, 2009              [Page 21]