< draft-gu-alto-redistribution-01.txt   draft-gu-alto-redistribution-02.txt >
ALTO Y. Gu ALTO Y. Gu
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Informational R. Alimi Intended status: BCP R. Alimi
Expires: April 29, 2010 Yale University Expires: September 9, 2010 Yale University
R. Even R. Even
Huawei Huawei
October 26, 2009 March 8, 2010
ALTO Information Redistribution ALTO Information Redistribution
draft-gu-alto-redistribution-01 draft-gu-alto-redistribution-02
Abstract
The ALTO protocol proposes several mechanisms to increase
scalability. One of the proposed mechanisms is ALTO information
redistribution. This document concretely defines ALTO Information
Redistribution, indicates suggested extensions to the ALTO Protocol
to support redistribution, and shows how redistribution could be used
in practice.
Status of this Memo Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet- other groups may also distribute working documents as Internet-
Drafts. Drafts.
skipping to change at page 1, line 35 skipping to change at page 1, line 44
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 April 29, 2010. This Internet-Draft will expire on September 9, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2009 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 in effect on the date of Provisions Relating to IETF Documents
publication of this document (http://trustee.ietf.org/license-info). (http://trustee.ietf.org/license-info) in effect on the date of
Please review these documents carefully, as they describe your rights publication of this document. Please review these documents
and restrictions with respect to this document. carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must
Abstract include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as
The ALTO protocol proposes several mechanisms to increase described in the BSD License.
scalability. One of the proposed mechanisms is ALTO information
redistribution. This document concretely defines ALTO Information
Redistribution, indicates suggested extensions to the ALTO Protocol
to support redistribution, and shows how redistribution could be used
in practice.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 4 2. Terminologies and concepts . . . . . . . . . . . . . . . . . . 4
3. Redistribution Framework . . . . . . . . . . . . . . . . . . . 4 3. Redistribution Framework . . . . . . . . . . . . . . . . . . . 4
3.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 5 3.1. Basic Requirements . . . . . . . . . . . . . . . . . . . . 5
3.2. ALTO Information Types . . . . . . . . . . . . . . . . . . 5 3.2. ALTO Information Types . . . . . . . . . . . . . . . . . . 5
3.3. Redistribution Scheme Design . . . . . . . . . . . . . . . 6 3.3. Redistribution Scheme Design . . . . . . . . . . . . . . . 6
4. ALTO Protocol Requirements . . . . . . . . . . . . . . . . . . 6 4. ALTO Protocol Requirements . . . . . . . . . . . . . . . . . . 6
4.1. Signature and Authentication . . . . . . . . . . . . . . . 6 4.1. Signature and Verification . . . . . . . . . . . . . . . . 6
4.2. Redistributable Indication and Expiration Time . . . . . . 6
5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7 5. Use Cases . . . . . . . . . . . . . . . . . . . . . . . . . . 7
5.1. Tracker-based redistribution . . . . . . . . . . . . . . . 7 5.1. Tracker-based redistribution . . . . . . . . . . . . . . . 7
5.2. Trackerless redistribution . . . . . . . . . . . . . . . . 9 5.2. Trackerless redistribution . . . . . . . . . . . . . . . . 8
5.2.1. Lookup in DHT . . . . . . . . . . . . . . . . . . . . 9 5.2.1. Lookup in DHT . . . . . . . . . . . . . . . . . . . . 9
6. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 10 6. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 10
6.1. Updating . . . . . . . . . . . . . . . . . . . . . . . . . 10 7. References . . . . . . . . . . . . . . . . . . . . . . . . . . 10
7. Security Considerations . . . . . . . . . . . . . . . . . . . 11 7.1. Normative References . . . . . . . . . . . . . . . . . . . 10
8. Acknowledgments . . . . . . . . . . . . . . . . . . . . . . . 11 7.2. Informative References . . . . . . . . . . . . . . . . . . 10
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 11 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 11
9.1. Normative References . . . . . . . . . . . . . . . . . . . 11
9.2. Informative References . . . . . . . . . . . . . . . . . . 12
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 12
1. Introduction 1. Introduction
When providing an ALTO service, Network Providers offer information When providing an ALTO service, Network Providers offer information
to clients with the goal of helping P2P applications to perform to clients with the goal of helping P2P applications to perform
better peer selection and improving network efficiency. The ALTO better peer selection and improving network efficiency. The ALTO
Service becomes a distribution point of network information for ALTO Service becomes a distribution point of network information for ALTO
Clients within its network. A Network Provider may deploy an ALTO Clients within its network. A Network Provider may deploy an ALTO
Service using techniques such as load balancing and caching to handle Service using techniques such as load balancing and caching to handle
a large number of subscribers. In this document, we discuss an a large number of subscribers. In this document, we discuss an
skipping to change at page 3, line 49 skipping to change at page 3, line 49
1) Defines basic requirements for redistributing ALTO information, 1) Defines basic requirements for redistributing ALTO information,
and considerations for developing a redistribution scheme. and considerations for developing a redistribution scheme.
2) Propose extensions to the ALTO Protocol to support ALTO 2) Propose extensions to the ALTO Protocol to support ALTO
Information redistribution to meet the defined requirements. Information redistribution to meet the defined requirements.
3) Provide use cases showing how redistribution may be applied in 3) Provide use cases showing how redistribution may be applied in
practice. practice.
This document contains informational content. We envision that We envision that multiple redistribution schemes are possible, and
multiple redistribution schemes are possible, and the design may the design may depend on the particular setting, such as scalability
depend on the particular setting, such as scalability requirements requirements and existing application protocols. Thus,
and existing application protocols. Thus, standardization of a standardization of a redistribution scheme for all kinds of scenario
redistribution scheme is not currently an objective. is not an object. This BCP intends to extract the fundamental for
real-world practice, and to provide use cases for most common
scenario of ALTO Redistribution.
Note that certain design changes during the development of the ALTO Note that certain design changes during the development of the ALTO
Protocol may affect ALTO information redistribution. This document Protocol may affect ALTO information redistribution. This document
will be updated to track the progress of the ALTO Protocol. will be updated to track the progress of the ALTO Protocol.
2. Terminologies and concepts 2. Terminologies and concepts
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in[RFC2119]. document are to be interpreted as described in[RFC2119].
skipping to change at page 5, line 18 skipping to change at page 5, line 20
order to successfully redistribute an ALTO Server's response to a set order to successfully redistribute an ALTO Server's response to a set
of ALTO Client. of ALTO Client.
1. The ALTO Client should be able to identify the desired 1. The ALTO Client should be able to identify the desired
redistributed data based only on the ALTO Server hostname and redistributed data based only on the ALTO Server hostname and
port, and the input parameters. port, and the input parameters.
2. The ALTO Client should be able to check the validity of the 2. The ALTO Client should be able to check the validity of the
information once it is retrieved. That is, the ALTO Client information once it is retrieved. That is, the ALTO Client
should be able to determine if the retrieved information was should be able to determine if the retrieved information was
indeed generated by its ALTO Server. indeed generated by its ALTO Server, , and is generated based on
the particular input parameters.
3.2. ALTO Information Types 3.2. ALTO Information Types
In general, it should be possible to redistribute the response from a In general, it should be possible to redistribute the response from a
particular ALTO Server that does not depend on anything except query particular ALTO Server that does not depend on anything except query
input parameters. However, redistribution may only be worthwhile for input parameters. However, redistribution may only be worthwhile for
queries that are made by a large number of ALTO Clients. In the queries that are made by a large number of ALTO Clients. In the
context of [I-D.penno-alto-protocol], we provide an example list of context of [I-D.penno-alto-protocol], we provide an example list of
information types that may be commonly used across many ALTO Clients, information types that may be commonly used across many ALTO Clients,
and hence benefit from redistribution. The example list the most and hence benefit from redistribution. The example list the most
skipping to change at page 6, line 8 skipping to change at page 6, line 8
Path Costs (i.e., a ranked list) for a set of individual endpoint Path Costs (i.e., a ranked list) for a set of individual endpoint
addresses (i.e., Resource Providers), the response may not be useful addresses (i.e., Resource Providers), the response may not be useful
to other ALTO Clients. This is because other ALTO Clients may be to other ALTO Clients. This is because other ALTO Clients may be
running different applications or have a different set of available running different applications or have a different set of available
peers (e.g., participating in a different swarm, or be in contact peers (e.g., participating in a different swarm, or be in contact
with a different set of peers within the same swarm). with a different set of peers within the same swarm).
3.3. Redistribution Scheme Design 3.3. Redistribution Scheme Design
While this document does not fully specify a particular While this document does not fully specify a particular
redistribution scheme, it provides a set of decisions that should be redistribution scheme, we provide a sampling of decisions that should
considered when implementing a redistribution scheme. This list can be considered when designing an implementing a redistribution scheme.
be used as a guide for implementers when designing a redistribution This list can be used as a guide for implementers when designing a
scheme for a particular setting. Considerations for a redistribution redistribution scheme for a particular setting. Considerations for a
scheme include: redistribution scheme include:Which ALTO Client(s) directly query the
ALTO Server?
o Which ALTO Client(s) directly query the ALTO Server?
o What method is used for locating redistributed ALTO information? o What method is used for locating redistributed ALTO information?
o What naming scheme is used to specify the ALTO Server hostname, o What naming scheme is used to specify the ALTO Server hostname,
port, and input parameters in the protocol for locating port, and input parameters in the protocol for locating
redistributed ALTO information? For example, the naming scheme redistributed ALTO information? For example, the naming scheme
could define how to compute the 'key' in a DHT. could define how to compute the 'key' in a DHT.
o What protocol is used for retrieving redistributed ALTO o What protocol is used for retrieving redistributed ALTO
information? information?
skipping to change at page 6, line 37 skipping to change at page 6, line 36
original response from the ALTO Service may be reformatted (e.g., original response from the ALTO Service may be reformatted (e.g.,
compressed) for redistribution. Note that if this approach is compressed) for redistribution. Note that if this approach is
taken and ALTO Clients still wish to verify received information, taken and ALTO Clients still wish to verify received information,
ALTO Clients should be able to reconstruct the ALTO Service's ALTO Clients should be able to reconstruct the ALTO Service's
original response (e.g., via decompression). If a lossy original response (e.g., via decompression). If a lossy
transformation is used (e.g., filtering), ALTO Clients may not be transformation is used (e.g., filtering), ALTO Clients may not be
able to verify the received information. able to verify the received information.
4. ALTO Protocol Requirements 4. ALTO Protocol Requirements
4.1. Signature and Authentication 4.1. Signature and Verification
For some redistribution schemes (e.g., posting a ".torrent" file on a
website), any ALTO Client could provide the redistributed ALTO
information. A malicious ALTO Client could modify the information
before it is redistributed. Thus, the ALTO server should sign the
information to allow ALTO Clients to verify the information before it
is utilized.
This section proposes a scheme through which ALTO clients can verify
redistributed ALTO information. The signature for a particular piece
of ALTO information (query response) is generated by ALTO Server that
provides the information. The signature is composed of at least two
parts: (1) the input parameters for generating the information (e.g.,
the full request URL used by an ALTO Client), and (2) hash of the
returned ALTO information (i.e., the ALTO Server's response). The
concatenation of the two parts is signed by ALTO server's Private
Key.
+-------------------------------------------+
( | Input parameters | Hash(ALTO information) | ) AS_PrivateKey
+-------------------------------------------+
Signature format
To check the signature, an ALTO client requires ALTO server's Public
Key. There are several methods to get the Public Key:
1. Get the public key from the ALTO server. The public key can be We proposed to consider signature mechanism to ensure that an ALTO
stored locally (until it is changed) by the ALTO Client and used client can verify that a redistributed information is generated from
regardless of how often ALTO information is updated. Thus, while the right ALTO server and is based on the correct input parameters in
this is a query to the ALTO Server, it is only done once (e.g., -01 version. The basic idea has been accepted in [I-D.penno-alto-
the first time the ALTO Server is queried). protocol] and is described in section 7.5.3. [I-D.penno-alto-
protocol] also introduces how public key is obtained.
2. Get the public key from the discovery system where ALTO clients 4.2. Redistributable Indication and Expiration Time
get their AS_n and AS_p. DNS or DHCP is extensible to carry some
additional information.
3. Get the public key from a Global Trusted Certificate Authority In -01 version, we proposed that ALTO server should using HTTP
(GTCA). This GTCA can be a hierarchical system. The pair of Caching directives to indicate whether a response could be
<Public Key, Private Key> and the certificate of the ALTO server redistributed and when a redistributed information should be updated.
are generated by the GTCA. Though this possibility may not be In the lastest version of [I-D.penno-alto-protocol], An ALTO server
widely deployable on the public Internet (currently), we present MAY indicate that a response is suitable fore redistribution by
it for completeness. including a "redistribution" JSON object and the Expiration time is
also indicated as JSON object.
5. Use Cases 5. Use Cases
The architecture of a particular P2P application will affect the The architecture of a particular P2P application will affect the
redistribution mechanism. Generally speaking, there are two kinds of redistribution mechanism. Generally speaking, there are two kinds of
P2P applications: trackerless, and those using a tracker. In P2P applications: trackerless, and those using a tracker. In
Tracker-based applications, a resource directory is maintained on a Tracker-based applications, a resource directory is maintained on a
tracker, and peers contact the tracker to learn about new peers. In tracker, and peers contact the tracker to learn about new peers. In
a Trackerless overlay, peers are organized through a particular a Trackerless overlay, peers are organized through a particular
algorithm, e.g. DHT, and they publish or find resources by routing algorithm, e.g. DHT, and they publish or find resources by routing
skipping to change at page 8, line 17 skipping to change at page 7, line 37
learned from other sources (e.g., Peer Exchange and/or DHT). learned from other sources (e.g., Peer Exchange and/or DHT).
2. A peer asks for a Resource and Tracker replies without any ALTO 2. A peer asks for a Resource and Tracker replies without any ALTO
information. The peer queries the ALTO server for ALTO information. The peer queries the ALTO server for ALTO
information, and selects peers. In order to help lessen the information, and selects peers. In order to help lessen the
burden on ALTO server, as well as to help other peers who want burden on ALTO server, as well as to help other peers who want
the same ALTO information, the peer publishes the ALTO the same ALTO information, the peer publishes the ALTO
information on the Tracker (if the Tracker allows this behavior). information on the Tracker (if the Tracker allows this behavior).
Peers may then distribute the ALTO information just as any other Peers may then distribute the ALTO information just as any other
Resource. The method introduced here can be regard as a Resource. The method introduced here can be regard as a
complementary process to the first one. complementary process to (1).
+-------------+ +-------------+
| | | |
| ALTO | | ALTO |
| Server | | Server |
| | | |
+-------------+ +-------------+
| |
| (1) Query | (1) Query
| and | and
skipping to change at page 10, line 34 skipping to change at page 10, line 25
hash("alto:http://alto.example.com:80/capability"). hash("alto:http://alto.example.com:80/capability").
2) Full Network Map. 2) Full Network Map.
hash("alto:http://alto.example.com:80/prop/pid/map"). hash("alto:http://alto.example.com:80/prop/pid/map").
3) Full Path Cost among all PIDs 3) Full Path Cost among all PIDs
hash("alto:http://alto.example.com:80/cost/pid/map"). hash("alto:http://alto.example.com:80/cost/pid/map").
6. Discussion 6. Acknowledgments
6.1. Updating
A Network Provider may update the ALTO information provided by the
ALTO Server. It should be possible for ALTO Clients using
redistribution to obtain updated information within a reasonable
time.
[I-D.penno-alto-protocol] indicates that HTTP Caching directives
should be used by an ALTO Server to indicate the lifetime for
retrieved ALTO information. ALTO Clients contacting the ALTO Server
directly (and providing it for redistribution) should refresh
redistributed information when updated information is retrieved. If
the HTTP Caching directives indicate that the information should not
be cached, then the information should not be provided for
redistribution.
Operators of an ALTO Server should be cognizant that ALTO Information
that is distributed may not be able to be "revoked" and replaced
immediately at all ALTO Clients. If the distributed information
includes caching parameters, these parameters may cause the
information to be returned to ALTO Clients by HTTP Caches or via
redistribution mechanisms until the cache parameters indicate that
the data has expired.
7. Security Considerations
ALTO Clients should be able to verify redistributed ALTO Information,
as documented in Section 4.2. Additional support is required in
[I-D.penno-alto-protocol] to support this verification mechanism.
A redistribution mechanism may suffer from a Denial of Service attack
if malicious (or faulty) ALTO Clients are in charge of fetching
updated content from an ALTO Server. In such a case, ALTO Clients
relying on redistributed information may not receive any information
at all, or the received information may not pass the signature
verification process. These ALTO Clients may contact the original
ALTO Service to retrieve ALTO information, or they may continue with
their default behavior without ALTO information.
8. Acknowledgments
The authors would like to give special thanks to Jan Seedorf and many The authors would like to give special thanks to Jan Seedorf and many
others for the illuminative discussion in the mailing list. The others for the illuminative discussion in the mailing list. The
authors also thank David Bryan for providing comments on preliminary authors also thank David Bryan for providing comments on preliminary
versions of the draft. versions of the draft.
9. References 7. References
9.1. Normative References 7.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[I-D.ietf-alto-problem-statement] [I-D.ietf-alto-problem-statement]
Seedorf, J. and E. Burger, "Application-Layer Traffic Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", Optimization (ALTO) Problem Statement",
draft-ietf-alto-problem-statement-04 (work in progress), draft-ietf-alto-problem-statement-04 (work in progress),
September 2009. September 2009.
9.2. Informative References 7.2. Informative References
[I-D.penno-alto-protocol] [I-D.penno-alto-protocol]
Penno, R. and Y. Yang, "ALTO Protocol", Penno, R. and Y. Yang, "ALTO Protocol",
draft-penno-alto-protocol-03 (work in progress), draft-penno-alto-protocol-04 (work in progress),
July 2009. October 2009.
[I-D.kiesel-alto-3pdisc] [I-D.kiesel-alto-3pdisc]
Kiesel, S. and M. Tomsu, "Third-party ALTO server Kiesel, S. and M. Tomsu, "Third-party ALTO server
discovery", draft-kiesel-alto-3pdisc-00 (work in discovery", draft-kiesel-alto-3pdisc-01 (work in
progress), August 2009. progress), October 2009.
[I-D.song-alto-server-discovery] [I-D.song-alto-server-discovery]
Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual, Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual,
"ALTO Service Discovery", "ALTO Service Discovery",
draft-song-alto-server-discovery-01 (work in progress), draft-song-alto-server-discovery-01 (work in progress),
July 2009. July 2009.
Authors' Addresses Authors' Addresses
Gu Yingjie Gu Yingjie
 End of changes. 23 change blocks. 
133 lines changed or deleted 70 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/