< draft-ietf-alto-protocol-04.txt   draft-ietf-alto-protocol-05.txt >
ALTO WG R. Alimi, Ed. ALTO WG R. Alimi, Ed.
Internet-Draft Yale University Internet-Draft Yale University
Intended status: Standards Track R. Penno, Ed. Intended status: Standards Track R. Penno, Ed.
Expires: December 2, 2010 Juniper Networks Expires: January 13, 2011 Juniper Networks
Y. Yang, Ed. Y. Yang, Ed.
Yale University Yale University
May 31, 2010 July 12, 2010
ALTO Protocol ALTO Protocol
draft-ietf-alto-protocol-04.txt draft-ietf-alto-protocol-05.txt
Abstract Abstract
Networking applications today already have access to a great amount Networking applications today already have access to a great amount
of Inter-Provider network topology information. For example, views of Inter-Provider network topology information. For example, views
of the Internet routing table are easily available at looking glass of the Internet routing table are easily available at looking glass
servers and entirely practical to be downloaded by clients. What is servers and entirely practical to be downloaded by clients. What is
missing is knowledge of the underlying network topology from the ISP missing is knowledge of the underlying network topology from the ISP
or Content Provider (henceforth referred as Provider) point of view. or Content Provider (henceforth referred as Provider) point of view.
In other words, what a Provider prefers in terms of traffic In other words, what a Provider prefers in terms of traffic
skipping to change at page 2, line 16 skipping to change at page 2, line 16
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at The list of current Internet-Drafts can be accessed at
http://www.ietf.org/ietf/1id-abstracts.txt. http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html. http://www.ietf.org/shadow.html.
This Internet-Draft will expire on December 2, 2010. This Internet-Draft will expire on January 13, 2011.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the Copyright (c) 2010 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 3, line 45 skipping to change at page 3, line 45
5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 13 5.1.1. Cost Type . . . . . . . . . . . . . . . . . . . . . . 13
5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 13 5.1.2. Cost Mode . . . . . . . . . . . . . . . . . . . . . . 13
5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 14 5.2. Cost Map Structure . . . . . . . . . . . . . . . . . . . . 14
5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 14 5.3. Network Map and Cost Map Dependency . . . . . . . . . . . 14
6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 15 6. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 15
6.1. Design Approach . . . . . . . . . . . . . . . . . . . . . 15 6.1. Design Approach . . . . . . . . . . . . . . . . . . . . . 15
6.1.1. Use of Existing Infrastructure . . . . . . . . . . . . 15 6.1.1. Use of Existing Infrastructure . . . . . . . . . . . . 15
6.1.2. ALTO Information Reuse and Redistribution . . . . . . 16 6.1.2. ALTO Information Reuse and Redistribution . . . . . . 16
7. Protocol Messaging . . . . . . . . . . . . . . . . . . . . . . 16 7. Protocol Messaging . . . . . . . . . . . . . . . . . . . . . . 16
7.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 16 7.1. Notation . . . . . . . . . . . . . . . . . . . . . . . . . 16
7.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 16 7.2. Message Format . . . . . . . . . . . . . . . . . . . . . . 17
7.2.1. Protocol Versioning Approach . . . . . . . . . . . . . 17 7.2.1. Protocol Versioning Approach . . . . . . . . . . . . . 17
7.2.2. Request Message . . . . . . . . . . . . . . . . . . . 17 7.2.2. Request Message . . . . . . . . . . . . . . . . . . . 17
7.2.3. Response Message . . . . . . . . . . . . . . . . . . . 18 7.2.3. Response Message . . . . . . . . . . . . . . . . . . . 18
7.3. General Processing . . . . . . . . . . . . . . . . . . . . 21 7.3. General Processing . . . . . . . . . . . . . . . . . . . . 21
7.4. ALTO Status Codes . . . . . . . . . . . . . . . . . . . . 21 7.4. ALTO Status Codes . . . . . . . . . . . . . . . . . . . . 21
7.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 22 7.5. Client Behavior . . . . . . . . . . . . . . . . . . . . . 22
7.5.1. Successful Response . . . . . . . . . . . . . . . . . 22 7.5.1. Successful Response . . . . . . . . . . . . . . . . . 22
7.5.2. Error Conditions . . . . . . . . . . . . . . . . . . . 22 7.5.2. Error Conditions . . . . . . . . . . . . . . . . . . . 22
7.6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . 22 7.6. HTTP Usage . . . . . . . . . . . . . . . . . . . . . . . . 22
7.6.1. Authentication and Encryption . . . . . . . . . . . . 22 7.6.1. Authentication and Encryption . . . . . . . . . . . . 23
7.6.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . 23 7.6.2. Cookies . . . . . . . . . . . . . . . . . . . . . . . 23
7.6.3. Caching Parameters . . . . . . . . . . . . . . . . . . 23 7.6.3. Caching Parameters . . . . . . . . . . . . . . . . . . 23
7.7. ALTO Requests . . . . . . . . . . . . . . . . . . . . . . 23 7.7. ALTO Requests . . . . . . . . . . . . . . . . . . . . . . 23
7.7.1. Server Information Service . . . . . . . . . . . . . . 23 7.7.1. Server Information Service . . . . . . . . . . . . . . 24
7.7.2. Map Service . . . . . . . . . . . . . . . . . . . . . 27 7.7.2. Map Service . . . . . . . . . . . . . . . . . . . . . 27
7.7.3. Map Filtering Service . . . . . . . . . . . . . . . . 31 7.7.3. Map Filtering Service . . . . . . . . . . . . . . . . 31
7.7.4. Endpoint Property Service . . . . . . . . . . . . . . 35 7.7.4. Endpoint Property Service . . . . . . . . . . . . . . 35
7.7.5. Endpoint Cost Service . . . . . . . . . . . . . . . . 38 7.7.5. Endpoint Cost Service . . . . . . . . . . . . . . . . 38
7.8. Redistributable Responses . . . . . . . . . . . . . . . . 40 7.8. Redistributable Responses . . . . . . . . . . . . . . . . 40
7.8.1. Server Capability Requirements . . . . . . . . . . . . 40 7.8.1. Server Capability Requirements . . . . . . . . . . . . 40
7.8.2. Service ID . . . . . . . . . . . . . . . . . . . . . . 40 7.8.2. Service ID . . . . . . . . . . . . . . . . . . . . . . 40
7.8.3. Server and Request Parameters . . . . . . . . . . . . 41 7.8.3. Server and Request Parameters . . . . . . . . . . . . 41
7.8.4. Expiration Time . . . . . . . . . . . . . . . . . . . 41 7.8.4. Expiration Time . . . . . . . . . . . . . . . . . . . 41
7.8.5. Signature . . . . . . . . . . . . . . . . . . . . . . 42 7.8.5. Signature . . . . . . . . . . . . . . . . . . . . . . 42
8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 43 8. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 43
8.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 43 8.1. ALTO Client Embedded in P2P Tracker . . . . . . . . . . . 43
8.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 45 8.2. ALTO Client Embedded in P2P Client: Numerical Costs . . . 45
8.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 46 8.3. ALTO Client Embedded in P2P Client: Ranking . . . . . . . 46
9. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 46 9. Discussions . . . . . . . . . . . . . . . . . . . . . . . . . 46
9.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 47 9.1. Discovery . . . . . . . . . . . . . . . . . . . . . . . . 47
9.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 47 9.2. Hosts with Multiple Endpoint Addresses . . . . . . . . . . 47
9.3. Network Address Translation Considerations . . . . . . . . 47 9.3. Network Address Translation Considerations . . . . . . . . 47
9.4. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 48 9.4. Mapping IPs to ASNs . . . . . . . . . . . . . . . . . . . 48
9.5. Endpoint and Path Properties . . . . . . . . . . . . . . . 48 9.5. Endpoint and Path Properties . . . . . . . . . . . . . . . 48
9.6. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 48 9.6. P2P Peer Selection . . . . . . . . . . . . . . . . . . . . 49
9.6.1. Client-based Peer Selection . . . . . . . . . . . . . 49 9.6.1. Client-based Peer Selection . . . . . . . . . . . . . 49
9.6.2. Server-based Peer Selection . . . . . . . . . . . . . 49 9.6.2. Server-based Peer Selection . . . . . . . . . . . . . 49
10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 49 9.6.3. Protocol Extension: 'Location-Only' Peer Selection . . 50
11. Security Considerations . . . . . . . . . . . . . . . . . . . 49 10. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 51
11.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 49 11. Security Considerations . . . . . . . . . . . . . . . . . . . 51
11.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 50 11.1. Privacy Considerations for ISPs . . . . . . . . . . . . . 51
11.3. Authentication, Integrity Protection, and Encryption . . . 50 11.2. ALTO Clients . . . . . . . . . . . . . . . . . . . . . . . 51
11.4. ALTO Information Redistribution . . . . . . . . . . . . . 51 11.3. Authentication, Integrity Protection, and Encryption . . . 52
11.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 52 11.4. ALTO Information Redistribution . . . . . . . . . . . . . 52
11.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 52 11.5. Denial of Service . . . . . . . . . . . . . . . . . . . . 53
12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 52 11.6. ALTO Server Access Control . . . . . . . . . . . . . . . . 53
12.1. Normative References . . . . . . . . . . . . . . . . . . . 52 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 54
12.2. Informative References . . . . . . . . . . . . . . . . . . 53 12.1. Normative References . . . . . . . . . . . . . . . . . . . 54
Appendix A. ALTO Protocol Grammar . . . . . . . . . . . . . . . . 55 12.2. Informative References . . . . . . . . . . . . . . . . . . 54
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 55 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 56
Appendix C. Authors . . . . . . . . . . . . . . . . . . . . . . . 56 Appendix B. Authors . . . . . . . . . . . . . . . . . . . . . . . 57
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 56 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 57
1. Introduction 1. Introduction
1.1. Background and Problem Statement 1.1. Background and Problem Statement
Today, network information available to applications is mostly from Today, network information available to applications is mostly from
the view of endhosts. There is no clear mechanism to convey the view of endhosts. There is no clear mechanism to convey
information about the network's preferences to applications. By information about the network's preferences to applications. By
leveraging better network-provided information, applications have the leveraging better network-provided information, applications have the
potential to become more network-efficient (e.g., reduce network potential to become more network-efficient (e.g., reduce network
skipping to change at page 5, line 39 skipping to change at page 5, line 39
o P4P [9], [10]; o P4P [9], [10];
o ALTO Info-Export [11]; o ALTO Info-Export [11];
o Query/Response [12], [13]; o Query/Response [12], [13];
o ATTP [ATTP]; o ATTP [ATTP];
o Proxidor [14]. o Proxidor [14].
See Appendix B for a list of people that have contributed See Appendix A for a list of people that have contributed
significantly to this effort and the projects and proposals listed significantly to this effort and the projects and proposals listed
above. above.
1.3. Solution Benefits 1.3. Solution Benefits
The ALTO Service offers many benefits to both end-users (consumers of The ALTO Service offers many benefits to both end-users (consumers of
the service) and Internet Service Providers (providers of the the service) and Internet Service Providers (providers of the
service). service).
1.3.1. Service Providers 1.3.1. Service Providers
skipping to change at page 11, line 13 skipping to change at page 11, line 13
In reality, many endpoints are very close to one another in terms of In reality, many endpoints are very close to one another in terms of
network connectivity, for example, endpoints on the same site of an network connectivity, for example, endpoints on the same site of an
enterprise. By treating a group of endpoints together as a single enterprise. By treating a group of endpoints together as a single
entity in ALTO, we can achieve much greater scalability without entity in ALTO, we can achieve much greater scalability without
losing critical information. losing critical information.
The Network Location endpoint property allows an ALTO Server to group The Network Location endpoint property allows an ALTO Server to group
endpoints together to indicate their proximity. The resulting set of endpoints together to indicate their proximity. The resulting set of
groupings is called the ALTO Network Map. groupings is called the ALTO Network Map.
The Network Map may also be used to communicate simple preferences.
For example, an ISP may prefer that endpoints associated with the
same PoP (Point-of-Presence) in a P2P application communicate locally
instead of communicating with endpoints in other PoPs. [[Comment.1:
Preferring peers within the same PID may be a reasonable default, but
some ALTO providers may prefer to discourage such peering. A flag
(e.g., attribute in the map) might be used to communicate such non-
default preferences.]] [[Comment.2: Experiments in the context of
live streaming have shown significant benefits of a simple algorithm
that does not use the cost map, and simply prefers intra-PID peers,
then intra-ISP peers, then inter-ISP peers. It may be helpful to add
a flag to a PID that indicates whether it is an "internal" PID (i.e.,
defines endpoints within the ISP) or "external" PID (i.e., defines
endpoints outside the ISP).]]
The definition of proximity varies depending on the granularity of The definition of proximity varies depending on the granularity of
the ALTO information configured by the provider. In one deployment, the ALTO information configured by the provider. In one deployment,
endpoints on the same subnet may be considered close; while in endpoints on the same subnet may be considered close; while in
another deployment, endpoints connected to the same PoP may be another deployment, endpoints connected to the same PoP may be
considered close. considered close.
As used in this document, the Network Map refers to the syntax and As used in this document, the Network Map refers to the syntax and
semantics of the information distributed by the ALTO Server. This semantics of the information distributed by the ALTO Server. This
document does not discuss the internal representation of this data document does not discuss the internal representation of this data
structure within the ALTO Server. structure within the ALTO Server.
skipping to change at page 12, line 7 skipping to change at page 11, line 40
A PID is an identifier that provides an indirect and network-agnostic A PID is an identifier that provides an indirect and network-agnostic
way to specify a network aggregation. For example, a PID may be way to specify a network aggregation. For example, a PID may be
defined by the ALTO service provider to denote a subnet, a set of defined by the ALTO service provider to denote a subnet, a set of
subnets, a metropolitan area, a PoP, an autonomous system, or a set subnets, a metropolitan area, a PoP, an autonomous system, or a set
of autonomous systems. Aggregation of endpoints into PIDs can of autonomous systems. Aggregation of endpoints into PIDs can
indicate proximity and can improve scalability. In particular, indicate proximity and can improve scalability. In particular,
network preferences (costs) may be specified between PIDs, allowing network preferences (costs) may be specified between PIDs, allowing
cost information to be more compact and updated at a smaller time cost information to be more compact and updated at a smaller time
scale than the network aggregations themselves. scale than the network aggregations themselves.
Using PIDs, the Network Map may also be used to communicate simple
preferences with only minimal information from the Cost Map. For
example, an ISP may prefer that endpoints associated with the same
PoP (Point-of-Presence) in a P2P application communicate locally
instead of communicating with endpoints in other PoPs. The ISP may
aggregate endhosts within a PoP into a single PID in the Network Map.
The Cost Map may be encoded to indicate that peering within the same
PID is preferred; for example, cost(PID_i, PID_i) == c* and
cost(PID_i, PID_j) > c* for i != j. Section 5 provides further
details about Cost Map structure.
4.2. Endpoint Addresses 4.2. Endpoint Addresses
Communicating endpoints may have many types of addresses, such as IP Communicating endpoints may have many types of addresses, such as IP
addresses, MAC addresses, or overlay IDs. The current specification addresses, MAC addresses, or overlay IDs. The current specification
only considers IP addresses. only considers IP addresses.
4.2.1. IP Addresses 4.2.1. IP Addresses
The endpoints aggregated into a PID are denoted by a list of IP The endpoints aggregated into a PID are denoted by a list of IP
prefixes. When either an ALTO Client or ALTO Server needs to prefixes. When either an ALTO Client or ALTO Server needs to
skipping to change at page 15, line 28 skipping to change at page 15, line 28
6. Protocol Overview 6. Protocol Overview
6.1. Design Approach 6.1. Design Approach
The ALTO Protocol design uses a REST-like interface with the goal of The ALTO Protocol design uses a REST-like interface with the goal of
leveraging current HTTP [2] [3] implementations and infrastructure, leveraging current HTTP [2] [3] implementations and infrastructure,
as well as familiarity with existing REST-like services in popular as well as familiarity with existing REST-like services in popular
use. ALTO messages are denoted with HTTP Content-Type "application/ use. ALTO messages are denoted with HTTP Content-Type "application/
alto" and use JSON [4] to encode message bodies. alto" and use JSON [4] to encode message bodies.
This document currently specifies both services and and the message
encoding in a descriptive fashion. Care is taken to make
descriptions precise and unambiguous, but it still lacks benefits of
automatic tooling that exists for certain encoding formats.
Standards such as WSDL 2.0 and WADL are capable of describing
available interfaces. JSON Schema [17] allows message encodings to
be specified precisely and messages may be verified against the
schema. It is not yet clear whether such an approach should be taken
in this document.
Other benefits enabled by these design choices include easier Other benefits enabled by these design choices include easier
understanding and debugging, flexible ALTO Server implementation understanding and debugging, flexible ALTO Server implementation
strategies, and more importantly, simple caching and redistribution strategies, and more importantly, simple caching and redistribution
of ALTO information to increase scalability. of ALTO information to increase scalability.
6.1.1. Use of Existing Infrastructure 6.1.1. Use of Existing Infrastructure
HTTP is a natural choice for integration with existing applications HTTP is a natural choice for integration with existing applications
and infrastructure. In particular, the ALTO Protocol design and infrastructure. In particular, the ALTO Protocol design
leverages: leverages:
skipping to change at page 16, line 19 skipping to change at page 16, line 28
Clients querying a particular ALTO Server. At the same time, Clients querying a particular ALTO Server. At the same time,
distributing ALTO information must be efficient and not become a distributing ALTO information must be efficient and not become a
bottleneck. Therefore, the ALTO Protocol specified in this document bottleneck. Therefore, the ALTO Protocol specified in this document
integrates with existing HTTP caching infrastructure to allow reuse integrates with existing HTTP caching infrastructure to allow reuse
of ALTO information by ALTO Clients and reduce load on ALTO servers. of ALTO information by ALTO Clients and reduce load on ALTO servers.
ALTO information may also be cached or redistributed using ALTO information may also be cached or redistributed using
application-dependent mechanisms, such as P2P DHTs or P2P file- application-dependent mechanisms, such as P2P DHTs or P2P file-
sharing. This document does not define particular mechanisms for sharing. This document does not define particular mechanisms for
such redistribution, but it does define the primitives (e.g., digital such redistribution, but it does define the primitives (e.g., digital
signatures) needed to support such a mechanism. signatures) needed to support such a mechanism. See [18] for further
discussion.
Note that if caching or redistribution is used, the Response message Note that if caching or redistribution is used, the Response message
may be returned from another (possibly third-party) entity. Reuse may be returned from another (possibly third-party) entity. Reuse
and Redistribution is further discussed in Section 11.4. Protocol and Redistribution is further discussed in Section 11.4. Protocol
support for redistribution is specified in Section 7.8. support for redistribution is specified in Section 7.8.
7. Protocol Messaging 7. Protocol Messaging
This section specifies client and server processing, as well as This section specifies client and server processing, as well as
messages in the ALTO Protocol. Details common to ALTO Server messages in the ALTO Protocol. Details common to ALTO Server
skipping to change at page 21, line 39 skipping to change at page 22, line 4
clients. When an ALTO Server returns a particular ALTO Status Code, clients. When an ALTO Server returns a particular ALTO Status Code,
it MUST indicate one of the corresponding HTTP Status Codes in it MUST indicate one of the corresponding HTTP Status Codes in
Table 1. Table 1.
If multiple errors are present in a single ALTO Request (e.g., a If multiple errors are present in a single ALTO Request (e.g., a
request uses a JSONString when a JSONInteger is expected and a request uses a JSONString when a JSONInteger is expected and a
required field is missing), then the ALTO Server MUST return exactly required field is missing), then the ALTO Server MUST return exactly
one of the detected errors. However, the reported error is one of the detected errors. However, the reported error is
implementation defined, since specifying a particular order for implementation defined, since specifying a particular order for
message processing encroaches needlessly on implementation technique. message processing encroaches needlessly on implementation technique.
[[Comment.3: It is currently deemed unnecessary to report multiple
errors. Feedback?]] +----------------------+------------------+-------------------------+
+-----------------+--------------------+----------------------------+ | ALTO Status Code | HTTP Status | Description |
| ALTO Status | HTTP Status | Description | | | Code(s) | |
| Code | Code(s) | | +----------------------+------------------+-------------------------+
+-----------------+--------------------+----------------------------+ | SUCCESS | 2xx | Success |
| 1 | 2xx | Success | | E_JSON_SYNTAX | 400 | JSON parsing error in |
| 2 | 400 | JSON parsing error in | | | | request |
| | | request | | E_JSON_FIELD_MISSING | 400 | Required field missing |
| 3 | 400 | Required field missing | | E_JSON_VALUE_TYPE | 400 | JSON Value of |
| 4 | 400 | JSON Value of unexpected | | | | unexpected type |
| | | type | | E_INVALID_OPERATION | 501 | Invalid operation |
| 5 | 501 | Invalid operation | | | | requested |
| | | requested | | E_INVALID_COST_TYPE | 501 | Invalid cost type |
| 6 | 501 | Invalid cost type | +----------------------+------------------+-------------------------+
+-----------------+--------------------+----------------------------+
Table 1: Defined ALTO Status Codes Table 1: Defined ALTO Status Codes
[[Comment.4: TODO: Assign reasonable values for ALTO Status Codes. Status codes described in Table 1 are a work in progress. The set of
Can we use string constants (e.g., SUCCESS, E_JSON_SYNTAX, etc) which status codes will be modified or expanded as implementation
may be easier when debugging?]] experience is gained; feedback is welcomed.
In addition, feedback from implementers of ALTO Clients is welcomed
to identify if there is a need to communicate multiple status codes
in a single response.
7.5. Client Behavior 7.5. Client Behavior
7.5.1. Successful Response 7.5.1. Successful Response
This specification does not indicate any required actions taken by This specification does not indicate any required actions taken by
ALTO Clients upon receiving a successful response from an ALTO ALTO Clients upon receiving a successful response from an ALTO
Server. Although ALTO Clients are suggested to interpret the Server. Although ALTO Clients are suggested to interpret the
received ALTO Information and adapt application behavior, ALTO received ALTO Information and adapt application behavior, ALTO
Clients may also choose to ignore the received information. Clients may also choose to ignore the received information.
skipping to change at page 24, line 14 skipping to change at page 24, line 21
implement all operations defined in this section. implement all operations defined in this section.
7.7.1.1. Server List 7.7.1.1. Server List
The Server List request allows an ALTO Client to discover other ALTO The Server List request allows an ALTO Client to discover other ALTO
Servers provided by the ALTO Service Provider. Upon discovering an Servers provided by the ALTO Service Provider. Upon discovering an
additional ALTO Server, the ALTO Client may then query the server additional ALTO Server, the ALTO Client may then query the server
capabilities (see Section 7.7.1.2) to test if it supports desired capabilities (see Section 7.7.1.2) to test if it supports desired
functionality. functionality.
The Server List request is intended to help an ALTO Client find an
ALTO Server supporting the desired ALTO Protocol version and
capabilities. It is not intended to serve as a substitute for the
ALTO Server Discovery which helps an ALTO Client locate an initial
ALTO Server.
This operation MUST be supported by the ALTO Server. This operation MUST be supported by the ALTO Server.
7.7.1.1.1. Request Syntax 7.7.1.1.1. Request Syntax
GET /info/servers HTTP/1.1 GET /info/servers HTTP/1.1
Host: <Host> Host: <Host>
7.7.1.1.2. Response Syntax 7.7.1.1.2. Response Syntax
HTTP/1.1 200 <StatusMsg> HTTP/1.1 200 <StatusMsg>
skipping to change at page 26, line 35 skipping to change at page 26, line 43
redistribution. redistribution.
RspCapability has members: RspCapability has members:
o services: Lists the services supported by the ALTO Server. The o services: Lists the services supported by the ALTO Server. The
service names defined in this document are are "map", service names defined in this document are are "map",
"map_filtering", "endpoint_property", and "endpoint_cost". "map_filtering", "endpoint_property", and "endpoint_cost".
o cost_types: Array of cost type information for additional o cost_types: Array of cost type information for additional
supported ALTO Cost types, detailing the name for each supported supported ALTO Cost types, detailing the name for each supported
additional type. [[Comment.5: Need to discuss IANA implications additional type. [[Comment.1: Need to discuss IANA implications
or alternate approaches. Note that current definition assumes the or alternate approaches. Note that current definition assumes the
unit for a cost type is fixed.]] unit for a cost type is fixed.]]
o cost_constraints: Indicates if the ALTO Server supports cost o cost_constraints: Indicates if the ALTO Server supports cost
constraints. The value 'false' is implied if this member is not constraints. The value 'false' is implied if this member is not
present. present.
o service_id: UUID [5] indicating an set of ALTO Servers (possibly o service_id: UUID [5] indicating an set of ALTO Servers (possibly
just a single ALTO Server) serving equivalent ALTO Information just a single ALTO Server) serving equivalent ALTO Information
(see Section 7.8). (see Section 7.8).
o certificate: PEM-encoded X.509 certificate used by the ALTO Server o certificate: PEM-encoded X.509 certificate used by the ALTO Server
to sign distributed information (see Section 7.8). to sign distributed information (see Section 7.8).
7.7.1.2.3. Example 7.7.1.2.3. Example
GET /capability HTTP/1.1 GET /info/capability HTTP/1.1
Host: alto.example.com:6671 Host: alto.example.com:6671
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: [TODO] Content-Length: [TODO]
Content-Type: application/alto Content-Type: application/alto
{ {
"meta" : { "meta" : {
"version" : 1, "version" : 1,
"status" : { "status" : {
"code" : 1 "code" : 1
} }
}, },
"type" : "capability", "type" : "capability",
"data" : { "data" : {
"services" : [ "map", "map-filtering" ], "services" : [ "map", "map-filtering" ],
"cost_types": [ "cost_types": [
"routingcost", "routingcost",
"latency", "hopcount"
"pDistance",
"bandwidth"
], ],
"cost_constraints": false "cost_constraints": false
} }
} }
7.7.2. Map Service 7.7.2. Map Service
The Map Service provides batch information to ALTO Clients in the The Map Service provides batch information to ALTO Clients in the
form of two maps: a Network Map and Cost Map. form of two maps: a Network Map and Cost Map.
skipping to change at page 40, line 48 skipping to change at page 40, line 48
deployed to serve equivalent ALTO Information. In such a scenario, deployed to serve equivalent ALTO Information. In such a scenario,
ALTO Responses from any such redundant server should be seen as ALTO Responses from any such redundant server should be seen as
equivalent for the purposes of redistribution. For example, if two equivalent for the purposes of redistribution. For example, if two
ALTO Servers A and B are deployed by the service provider to ALTO Servers A and B are deployed by the service provider to
distribute equivalent ALTO Information, then clients contacting distribute equivalent ALTO Information, then clients contacting
Server A should be able to redistribute ALTO Responses to Server B. Server A should be able to redistribute ALTO Responses to Server B.
One technique for doing this would be to rely on the server's DNS One technique for doing this would be to rely on the server's DNS
name. However, such an approach would mandate that all ALTO Servers name. However, such an approach would mandate that all ALTO Servers
resolved by a particular DNS name would need to provide equivalent resolved by a particular DNS name would need to provide equivalent
ALTO information, which may be unneccessarily restrictive to ALTO information, which may be unneccessarily restrictive. Another
deployment scenarios within large network providers. Another
technique would be to rely on the server's IP adddress. However, technique would be to rely on the server's IP adddress. However,
this suffers similar problems as the DNS name in scenarios in which this suffers similar problems as the DNS name in deployment scenarios
IP Anycast is used. using IP Anycast.
Instead, the ALTO Protocol uses an approach in which a service To avoid such restrictions, the ALTO Protocol allows an ALTO Service
provider explicitly denotes ALTO Servers that provide equivalent ALTO Provider to explicitly denote ALTO Servers that provide equivalent
Information by giving them identical Service IDs. [[Comment.6: TODO: ALTO Information by giving them identical Service IDs.
Define how ALTO Clients distinguish between network regions to
prevent a network provider from 'hijacking' a Service ID of another
provider. Bootstreap on DNS name such as 'ServiceID.example.com'?]]
If an ALTO Server generates redistributable responses, the Server If an ALTO Server generates redistributable responses, the Server
Capability response's 'service_id' field MUST be set to the ALTO Capability response's 'service_id' field MUST be set to the ALTO
Server's Service ID. Server's Service ID.
To help prevent ALTO Servers from mistakenly claiming to distribute To help prevent ALTO Servers from mistakenly claiming to distribute
equivalent ALTO Information, ALTO Server Implementations SHOULD by equivalent ALTO Information, ALTO Server Implementations SHOULD by
default generate a new UUID at installation time. The default, default generate a new UUID at installation time. The default,
generated UUID may be overridden by the service provider. generated UUID may be overridden by the service provider.
skipping to change at page 42, line 39 skipping to change at page 42, line 36
Response. Response.
To reduce requirements on the underlying transport (i.e., requiring To reduce requirements on the underlying transport (i.e., requiring
SSL/TLS), the ALTO Protocol uses the latter option. This SSL/TLS), the ALTO Protocol uses the latter option. This
specification makes the following requirements of the X.509 specification makes the following requirements of the X.509
certificates: certificates:
o The certificate's corresponding private key MUST be used to sign o The certificate's corresponding private key MUST be used to sign
redistributable responses. redistributable responses.
o The certificate for each ALTO Server with an identical Service ID. o The certificate for each ALTO Server with an identical Service ID
[[NOTE: Comment Comment.6 has implications here]] MUST be identical.
ALTO Clients SHOULD verify that the certificate satisfies any local ALTO Clients SHOULD verify that the certificate satisfies any local
policies (e.g., Issuer, expiration date, etc). policies (e.g., Issuer, expiration date, etc).
The ALTO Server may include the Hash Algorithm, Signature Algorithm, The ALTO Server may include the Hash Algorithm, Signature Algorithm,
and Signature in either HTTP Headers or Trailers. Headers may be and Signature in either HTTP Headers or Trailers. Headers may be
useful if Responses are pre-generated, while Trailers may be useful useful if Responses are pre-generated, while Trailers may be useful
if Responses are dynamically generated (e.g., to avoid buffering if Responses are dynamically generated (e.g., to avoid buffering
large responses in memory while the hash value is computed). large responses in memory while the hash value is computed).
The following HTTP Headers (the ALTO Server MAY specify them as HTTP The following HTTP Headers (the ALTO Server MAY specify them as HTTP
Trailers) MUST be used to encode the Signature parameters for Trailers) MUST be used to encode the Signature parameters for
redistributable ALTO Responses: redistributable ALTO Responses:
X-ALTO-HashAlgorithm: <HashAlgorithm> ALTO-HashAlgorithm: <HashAlgorithm>
X-ALTO-SignatureAlgorithm: <SignatureAlgorithm> ALTO-SignatureAlgorithm: <SignatureAlgorithm>
X-ALTO-SignatureDigest: <Signature> ALTO-SignatureDigest: <Signature>
where <HashAlgorithm> and <SignatureAlgorithm> are an integer values where <HashAlgorithm> and <SignatureAlgorithm> are an integer values
from the IANA TLS HashAlgorithm and SignatureAlgorithm registries, from the IANA TLS HashAlgorithm and SignatureAlgorithm registries,
and <Signature> is the corresponding PEM-encoded signature. and <Signature> is the corresponding PEM-encoded signature.
ALTO Clients SHOULD verify the signature on any ALTO information
received via redistribution before adjusting application behavior
based on it.
If an ALTO Client consumes ALTO Information from multiple ALTO
Servers, it can locally maintain a map of the corresponding
certificate for each ALTO Server. Upon receiving redistributed
information, it may lookup the appropriate certificate to use for
signature verification based on the Service ID contained in the
redistributed ALTO Response. Note that verifying the signature also
protects against hijacking of a Service ID as long as the initial
certificate retrieval (via the Server Capability Response) is secure
from hijacking.
ALTO Clients SHOULD pass the ALTO Server Certificate, Signature, and ALTO Clients SHOULD pass the ALTO Server Certificate, Signature, and
Signature Algorithm along with the body of the ALTO Response. The Signature Algorithm along with the body of the ALTO Response. The
mechanism for redistributing such information is not specified by the mechanism for redistributing such information is not specified by the
ALTO Protocol, but one possibility is to add additional messages or ALTO Protocol, but one possibility is to add additional messages or
fields to the application's native protocol. fields to the application's native protocol.
8. Use Cases 8. Use Cases
The sections below depict typical use cases. The sections below depict typical use cases.
skipping to change at page 47, line 8 skipping to change at page 47, line 8
the ranking of the candidate peers. the ranking of the candidate peers.
3. The P2P Client connects to the peers in the order specified in 3. The P2P Client connects to the peers in the order specified in
the ranking. the ranking.
9. Discussions 9. Discussions
9.1. Discovery 9.1. Discovery
The particular mechanism by which an ALTO Client discovers its ALTO The particular mechanism by which an ALTO Client discovers its ALTO
Server is an important component to the ALTO architecture and Server is an important component to the ALTO architecture and
numerous techniques have been discussed [17] [18]. However, the numerous techniques have been discussed [19]. However, the discovery
discovery mechanism is out of scope for this document. mechanism is out of scope for this document. This document assumes
that an ALTO Client can discover an appropriate ALTO Server. Note
that the Server List query in the Server Information Service is
intended to aid an ALTO Client in selecting an available ALTO Server
with the capabilities necessary for its application.
Some ISPs have proposed the possibility of delegation, in which an Some ISPs have proposed the possibility of delegation, in which an
ISP provides information for customer networks which do not wish to ISP provides information for customer networks which do not wish to
run ALTO Servers themselves. A consideration for delegation is that run ALTO Servers themselves. A consideration for delegation is that
customer networks may wish to explicitly configure such delegation. customer networks may wish to explicitly configure such delegation.
9.2. Hosts with Multiple Endpoint Addresses 9.2. Hosts with Multiple Endpoint Addresses
In practical deployments, especially during the transition from IPv4 In practical deployments, especially during the transition from IPv4
to IPv6, a particular host may be reachable using multiple addresses. to IPv6, a particular host may be reachable using multiple addresses.
skipping to change at page 47, line 33 skipping to change at page 47, line 37
have a NAT64 middlebox). An additional consideration may be how to have a NAT64 middlebox). An additional consideration may be how to
handle private address spaces (e.g., behind carrier-grade NATs). handle private address spaces (e.g., behind carrier-grade NATs).
Note that to support such behavior, Endpoints must be associated with Note that to support such behavior, Endpoints must be associated with
a particular address type (e.g., IPv4 or IPv6). One simple a particular address type (e.g., IPv4 or IPv6). One simple
possibility may be to prefix each endpoint address with its type possibility may be to prefix each endpoint address with its type
(e.g., "ipv4:198.51.100.128/25"). However, we may want to discuss if (e.g., "ipv4:198.51.100.128/25"). However, we may want to discuss if
a more efficient/compact encoding is possible in some cases (e.g., a more efficient/compact encoding is possible in some cases (e.g.,
all addresses in the same PID are IPv6). all addresses in the same PID are IPv6).
There are limitations as to what information ALTO can provide in this
regard. In particular, a particular ALTO Service provider may not be
able to determine if connectivity with a particular endhost will
succeed over IPv4 or IPv6, as this may depend upon information
unknown to the ISP such as particular application implementations.
Exploration of these issues is being considered in a separate Exploration of these issues is being considered in a separate
Internet Draft, [CITE REINALDO'S DRAFT], at the current time. Once a Internet Draft [20]. Once a suitable solution emerges, it will be
reasonable solution is ready, it will be included in this document. included in this document.
9.3. Network Address Translation Considerations 9.3. Network Address Translation Considerations
At this day and age of NAT v4<->v4, v4<->v6 [19], and possibly At this day and age of NAT v4<->v4, v4<->v6 [21], and possibly
v6<->v6[20], a protocol should strive to be NAT friendly and minimize v6<->v6[22], a protocol should strive to be NAT friendly and minimize
carrying IP addresses in the payload, or provide a mode of operation carrying IP addresses in the payload, or provide a mode of operation
where the source IP address provide the information necessary to the where the source IP address provide the information necessary to the
server. server.
The protocol specified in this document provides a mode of operation The protocol specified in this document provides a mode of operation
where the source network location is computed by the ALTO Server (via where the source network location is computed by the ALTO Server (via
the Endpoint Property Lookup interface) from the source IP address the Endpoint Property Lookup interface) from the source IP address
found in the ALTO Client query packets. This is similar to how some found in the ALTO Client query packets. This is similar to how some
P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS P2P Trackers (e.g., BitTorrent Trackers - see "Tracker HTTP/HTTPS
Protocol" in [21]) operate. Protocol" in [23]) operate.
The ALTO client SHOULD use the Session Traversal Utilities for NAT The ALTO client SHOULD use the Session Traversal Utilities for NAT
(STUN) [7] to determine a public IP address to use as a source (STUN) [7] to determine a public IP address to use as a source
Endpoint address. If using this method, the host MUST use the Endpoint address. If using this method, the host MUST use the
"Binding Request" message and the resulting "XOR-MAPPED-ADDRESS" "Binding Request" message and the resulting "XOR-MAPPED-ADDRESS"
parameter that is returned in the response. Using STUN requires parameter that is returned in the response. Using STUN requires
cooperation from a publicly accessible STUN server. Thus, the ALTO cooperation from a publicly accessible STUN server. Thus, the ALTO
client also requires configuration information that identifies the client also requires configuration information that identifies the
STUN server, or a domain name that can be used for STUN server STUN server, or a domain name that can be used for STUN server
discovery. To be selected for this purpose, the STUN server needs to discovery. To be selected for this purpose, the STUN server needs to
skipping to change at page 49, line 10 skipping to change at page 49, line 20
from an ALTO Server. Specifically, the application must select which from an ALTO Server. Specifically, the application must select which
peers to use based on this and other sources of information. With peers to use based on this and other sources of information. With
this in mind, the usage of ALTO Costs is intentionally flexible, this in mind, the usage of ALTO Costs is intentionally flexible,
because: because:
Different applications may use the information differently. For Different applications may use the information differently. For
example, an application that connects to just one address may have example, an application that connects to just one address may have
a different algorithm for selecting it than an application that a different algorithm for selecting it than an application that
connects to many. connects to many.
Though initial experiments have been conducted [22], more Though initial experiments have been conducted [24], more
investigation is needed to identify other methods. investigation is needed to identify other methods.
In addition, the application might account for robustness, perhaps In addition, the application might account for robustness, perhaps
using randomized exploration to determine if it performs better using randomized exploration to determine if it performs better
without ALTO information. without ALTO information.
9.6.1. Client-based Peer Selection 9.6.1. Client-based Peer Selection
One possibility is for peer selection using ALTO costs to be done One possibility is for peer selection using ALTO costs to be done
entirely by a P2P client. The following are some techniques have entirely by a P2P client. The following are some techniques have
skipping to change at page 49, line 37 skipping to change at page 49, line 47
[11]. [11].
9.6.2. Server-based Peer Selection 9.6.2. Server-based Peer Selection
Another possibility is for ALTO costs to be used by an Application Another possibility is for ALTO costs to be used by an Application
Tracker (e.g., BitTorrent Tracker) when returning peer lists. The Tracker (e.g., BitTorrent Tracker) when returning peer lists. The
following are techniques that have been proposed and/or used: following are techniques that have been proposed and/or used:
o Using bandwidth matching (e.g., at an Application Tracker) and o Using bandwidth matching (e.g., at an Application Tracker) and
choosing solution (within bound of optimal) with minimal network choosing solution (within bound of optimal) with minimal network
cost [22]. cost [24].
9.6.3. Protocol Extension: 'Location-Only' Peer Selection
This section discusses a promising peer selection algorithm that was
recently used in experiments with a P2P live streaming application.
However, to support it, a small protocol extension would be required,
but the protocol extension is general and may be applicable in other
contexts as well. Feedback from the WG is greatly encouraged.
Experiments in the context of live streaming have shown significant
benefits of a simple "location-only" algorithm that primarily makes
use of the Network Map. A benefit of this algorithm is that it can
provide a simple integration path for applications wishing to utilize
ALTO.
In particular, the algorithm proceeds as follows to select an ordered
list of peers for a particular incoming (or existing peer):
1. Insert into the result list a number (up to a threshold) of peers
from the same PID as the incoming peer.
2. Insert into the result list a number (up to a threshold) of peers
from the same ISP as the incoming peer.
3. Insert into the result list a number (up to a threshold) of peers
from different ISPs than the incoming peer.
In the experiments, this algorithm was implemented at a tracker and
executed for peer selection when peers initially join and when
requesting new peers.
This algorithm makes two assumptions about the preferences
communicated by the Network Map:
o The ISP prefers peers within the same PID to peer with each other
(see Section 4); and
o The ALTO Server can indicate which PIDs describe network locations
within the same ISP.
The second assumption is currently not satisfied by the ALTO
protocol, but could be accomplished by including a PID attribute.
For example, a boolean attribute name "Intra-Region" with value
'true' could be added to PIDs within the ALTO Server's Network
Region.
10. IANA Considerations 10. IANA Considerations
This document request the registration of a new media type: This document request the registration of a new media type:
"application/alto" "application/alto"
11. Security Considerations 11. Security Considerations
11.1. Privacy Considerations for ISPs 11.1. Privacy Considerations for ISPs
skipping to change at page 51, line 34 skipping to change at page 52, line 46
received ALTO information to ensure that it was actually generated by received ALTO information to ensure that it was actually generated by
the correct ALTO Server. Further, to prevent the ALTO Server from the correct ALTO Server. Further, to prevent the ALTO Server from
being a target of attack, the verification scheme must not require being a target of attack, the verification scheme must not require
ALTO Clients to contact the ALTO Server to validate every set of ALTO Clients to contact the ALTO Server to validate every set of
information. Note that in any case, contacting the originating ALTO information. Note that in any case, contacting the originating ALTO
server for information validation would undermine the intended effect server for information validation would undermine the intended effect
of redistribution and is therefore not desirable. of redistribution and is therefore not desirable.
Note that the redistribution scheme must additionally handle details Note that the redistribution scheme must additionally handle details
such as ensuring ALTO Clients retrieve ALTO information from the such as ensuring ALTO Clients retrieve ALTO information from the
correct ALTO Server. See [23] and [24] for further discussion. correct ALTO Server. See [18] for further discussion. Details of a
Details of a particular redistribution scheme are outside the scope particular redistribution scheme are outside the scope of this
of this document. document.
To fulfill these requirements, ALTO Information meant to be To fulfill these requirements, ALTO Information meant to be
redistributable contains a digital signature which includes a hash of redistributable contains a digital signature which includes a hash of
the ALTO information signed by the ALTO Server with its private key. the ALTO information signed by the ALTO Server with its private key.
The corresponding public key should either be part of the ALTO The corresponding public key should either be part of the ALTO
information itself, or it could be included in the server capability information itself, or it could be included in the server capability
response. The public key SHOULD include the hostname of the ALTO response. The public key SHOULD include the hostname of the ALTO
Server and it SHOULD be signed by a trusted authority (i.e., in a Server and it SHOULD be signed by a trusted authority (i.e., in a
certificate). This an ALTO client retrieving redistributed ALTO certificate). This enables an ALTO client retrieving redistributed
information to verify the correctness of the ALTO Server's signature, ALTO information to verify the correctness of the ALTO Server's
given that it trusts the authority which signed the ALTO Server's signature, given that it trusts the authority which signed the ALTO
certificate. Note that in some cases this requires that the Server's certificate. Note that in some cases this requires that the
retrieving ALTO Client must be able to derive a transitive retrieving ALTO Client must be able to derive a transitive
certificate chain (including a Root-CA) to the trusted authority certificate chain (including a Root-CA) to the trusted authority
which signed the ALTO Server's certificate. This requirement may not which signed the ALTO Server's certificate. This requirement may not
be possible to fulfill between every ALTO Client / ALTO Server be possible to fulfill between every ALTO Client / ALTO Server
combination on the Internet due to the lack of a world-wide public combination on the Internet due to the lack of a world-wide public
key infrastructure. key infrastructure.
11.5. Denial of Service 11.5. Denial of Service
ISPs should be cognizant of the workload at the ALTO Server generated ISPs should be cognizant of the workload at the ALTO Server generated
skipping to change at page 54, line 12 skipping to change at page 55, line 25
Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00 Saucez, "The PROXIDOR Service", draft-akonjang-alto-proxidor-00
(work in progress), March 2009. (work in progress), March 2009.
[15] Seedorf, J. and E. Burger, "Application-Layer Traffic [15] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693, October 2009. Optimization (ALTO) Problem Statement", RFC 5693, October 2009.
[16] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An [16] Yang, Y., Popkin, L., Penno, R., and S. Shalunov, "An
Architecture of ALTO for P2P Applications", Architecture of ALTO for P2P Applications",
draft-yang-alto-architecture-00 (work in progress), March 2009. draft-yang-alto-architecture-00 (work in progress), March 2009.
[17] Garcia, G., Tomsu, M., and Y. Wang, "ALTO Discovery Protocols", [17] Zyp, K., "A JSON Media Type for Describing the Structure and
draft-wang-alto-discovery-00 (work in progress), March 2009. Meaning of JSON Documents", draft-zyp-json-schema-02 (work in
progress), March 2010.
[18] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application- [18] Yingjie, G., Alimi, R., and R. Even, "ALTO Information
Redistribution", draft-gu-alto-redistribution-03 (work in
progress), July 2010.
[19] Song, H., Even, R., Pascual, V., and Y. Zhang, "Application-
Layer Traffic Optimization (ALTO): Discover ALTO Servers", Layer Traffic Optimization (ALTO): Discover ALTO Servers",
draft-song-alto-server-discovery-00 (work in progress), draft-song-alto-server-discovery-00 (work in progress),
March 2009. March 2009.
[19] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6 [20] Penno, R. and J. Medved, "ALTO and IPv4/IPv6 Co-existence and
Transition", draft-penno-alto-ipv4v6-00 (work in progress),
June 2010.
[21] Baker, F., Li, X., and C. Bao, "Framework for IPv4/IPv6
Translation", draft-baker-behave-v4v6-framework-02 (work in Translation", draft-baker-behave-v4v6-framework-02 (work in
progress), February 2009. progress), February 2009.
[20] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address [22] Wasserman, M. and F. Baker, "IPv6-to-IPv6 Network Address
Translation (NAT66)", draft-mrw-behave-nat66-02 (work in Translation (NAT66)", draft-mrw-behave-nat66-02 (work in
progress), March 2009. progress), March 2009.
[21] "Bittorrent Protocol Specification v1.0", [23] "Bittorrent Protocol Specification v1.0",
http://wiki.theory.org/BitTorrentSpecification, 2009. http://wiki.theory.org/BitTorrentSpecification, 2009.
[22] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A. [24] H. Xie, YR. Yang, A. Krishnamurthy, Y. Liu, and A.
Silberschatz., "P4P: Provider Portal for (P2P) Applications", Silberschatz., "P4P: Provider Portal for (P2P) Applications",
In SIGCOMM 2008. In SIGCOMM 2008.
[23] Yingjie, G., Alimi, R., and R. Even, "ALTO Information
Redistribution", draft-gu-alto-redistribution-02 (work in
progress), March 2010.
[24] Stiemerling, M., "ALTO Information Redistribution Considered
Harmful", draft-stiemerling-alto-info-redist-00 (work in
progress), August 2009.
[25] Jennings, C., "Computational Puzzles for SPAM Reduction in [25] Jennings, C., "Computational Puzzles for SPAM Reduction in
SIP", draft-jennings-sip-hashcash-06 (work in progress), SIP", draft-jennings-sip-hashcash-06 (work in progress),
July 2007. July 2007.
[26] Stiemerling, M. and S. Kiesel, "ALTO Deployment [26] Stiemerling, M. and S. Kiesel, "ALTO Deployment
Considerations", draft-stiemerling-alto-deployments-02 (work in Considerations", draft-stiemerling-alto-deployments-04 (work in
progress), March 2010. progress), July 2010.
Appendix A. 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.
TODO
Appendix B. Acknowledgments Appendix A. Acknowledgments
Thank you to Jan Seedorf for contributions to the Security Thank you to Jan Seedorf for contributions to the Security
Considerations section. Considerations section. We would like to thank Yingjie Gu and Roni
Even for helpful input and design concerning ALTO Information
redistribution.
We would like to thank the following people whose input and We would like to thank the following people whose input and
involvement was indispensable in achieving this merged proposal: involvement was indispensable in achieving this merged proposal:
Obi Akonjang (DT Labs/TU Berlin), Obi Akonjang (DT Labs/TU Berlin),
Saumitra M. Das (Qualcomm Inc.), Saumitra M. Das (Qualcomm Inc.),
Syon Ding (China Telecom), Syon Ding (China Telecom),
skipping to change at page 56, line 13 skipping to change at page 57, line 13
Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace Lafferty (DCIA), Erran Li (Bell Labs), Jin Li (Microsoft), Y. Grace
Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T), Liu (IBM Watson), Jason Livingood (Comcast), Michael Merritt (AT&T),
Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks), Ingmar Poese (DT Labs/TU Berlin), James Royalty (Pando Networks),
Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda Damien Saucez (UCL) Thomas Scholl (AT&T), Emilio Sepulveda
(Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell (Telefonica), Avi Silberschatz (Yale University), Hassan Sipra (Bell
Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song Canada), Georgios Smaragdakis (DT Labs/TU Berlin), Haibin Song
(Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia (Huawei), Oliver Spatscheck (AT&T), See-Mong Tang (Microsoft), Jia
Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University), Wang (AT&T), Hao Wang (Yale University), Ye Wang (Yale University),
Haiyong Xie (Yale University). Haiyong Xie (Yale University).
Appendix C. Authors Appendix B. Authors
[[Comment.7: RFC Editor: Please move information in this section to [[Comment.2: RFC Editor: Please move information in this section to
the Authors' Addresses section at publication time.]] the Authors' Addresses section at publication time.]]
Stefano Previdi Stefano Previdi
Cisco Cisco
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
Stanislav Shalunov Stanislav Shalunov
BitTorrent BitTorrent
 End of changes. 47 change blocks. 
130 lines changed or deleted 199 lines changed or added

This html diff was produced by rfcdiff 1.48. The latest version is available from http://tools.ietf.org/tools/rfcdiff/