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]