< draft-ietf-alto-reqs-02.txt   draft-ietf-alto-reqs-04.txt >
Network Working Group S. Kiesel, Ed. Network Working Group S. Kiesel, Ed.
Internet-Draft NEC Internet-Draft University of Stuttgart
Intended status: Informational L. Popkin Intended status: Informational L. Popkin
Expires: April 26, 2010 Pando Networks, Inc. Expires: September 9, 2010 Pando Networks, Inc.
S. Previdi S. Previdi
Cisco Systems, Inc. Cisco Systems, Inc.
R. Woundy R. Woundy
Comcast Corporation Comcast Corporation
Y R. Yang Y R. Yang
Yale University Yale University
October 23, 2009 March 8, 2010
Application-Layer Traffic Optimization (ALTO) Requirements Application-Layer Traffic Optimization (ALTO) Requirements
draft-ietf-alto-reqs-02.txt draft-ietf-alto-reqs-04.txt
Abstract
Many Internet applications are used to access resources, such as
pieces of information or server processes, which are available in
several equivalent replicas on different hosts. This includes, but
is not limited to, peer-to-peer file sharing applications. The goal
of Application-Layer Traffic Optimization (ALTO) is to provide
guidance to applications, which have to select one or several hosts
from a set of candidates, that are able to provide a desired
resource. This guidance shall be based on parameters that affect
performance and efficiency of the data transmission between the
hosts, e.g., the topological distance. The ultimate goal is to
improve performance (or Quality of Experience) in the application
while reducing resource consumption in the underlying network
infrastructure.
This document enumerates requirements for ALTO, which should be
considered when specifying, assessing, or comparing protocols and
implementations, and it solicits feedback and discussion.
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 39 skipping to change at page 2, line 13
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 26, 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
Many Internet applications are used to access resources, such as described in the BSD License.
pieces of information or server processes, which are available in
several equivalent replicas on different hosts. This includes, but
is not limited to, peer-to-peer file sharing applications. The goal
of Application-Layer Traffic Optimization (ALTO) is to provide
guidance to applications, which have to select one or several hosts
from a set of candidates, that are able to provide a desired
resource. This guidance shall be based on parameters that affect
performance and efficiency of the data transmission between the
hosts, e.g., the topological distance. The ultimate goal is to
improve performance (or Quality of Experience) in the application
while reducing resource consumption in the underlying network
infrastructure.
This document enumerates requirements for ALTO, which should be
considered when specifying, assessing, or comparing protocols and
implementations, and it solicits feedback and discussion.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 5 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology and architectural framework . . . . . . . . . . . 6 2. Terminology and architectural framework . . . . . . . . . . . 5
2.1. Requirements notation . . . . . . . . . . . . . . . . . . 6 2.1. Requirements notation . . . . . . . . . . . . . . . . . . 5
2.2. ALTO terminology . . . . . . . . . . . . . . . . . . . . . 6 2.2. ALTO terminology . . . . . . . . . . . . . . . . . . . . . 5
2.3. Architectural framework for ALTO . . . . . . . . . . . . . 7 2.3. Architectural framework for ALTO . . . . . . . . . . . . . 6
2.4. Sample use cases . . . . . . . . . . . . . . . . . . . . . 7 2.4. Sample use cases . . . . . . . . . . . . . . . . . . . . . 6
3. ALTO requirements . . . . . . . . . . . . . . . . . . . . . . 10 3. ALTO requirements . . . . . . . . . . . . . . . . . . . . . . 9
3.1. ALTO client protocol . . . . . . . . . . . . . . . . . . . 10 3.1. ALTO client protocol . . . . . . . . . . . . . . . . . . . 9
3.1.1. General requirements . . . . . . . . . . . . . . . . . 10 3.1.1. General requirements . . . . . . . . . . . . . . . . . 9
3.1.2. Host group descriptor support . . . . . . . . . . . . 10 3.1.2. Host group descriptor support . . . . . . . . . . . . 9
3.1.3. Rating criteria support . . . . . . . . . . . . . . . 11 3.1.3. Rating criteria support . . . . . . . . . . . . . . . 10
3.1.4. Placement of entities and timing of transactions . . . 12 3.1.4. Placement of entities and timing of transactions . . . 11
3.1.5. Protocol extensibility . . . . . . . . . . . . . . . . 13 3.1.5. Protocol extensibility . . . . . . . . . . . . . . . . 12
3.1.6. Error handling and overload protection . . . . . . . . 14 3.1.6. Error handling and overload protection . . . . . . . . 13
3.2. ALTO server discovery . . . . . . . . . . . . . . . . . . 14 3.2. ALTO server discovery . . . . . . . . . . . . . . . . . . 13
3.3. Security and privacy . . . . . . . . . . . . . . . . . . . 15 3.3. Security and privacy . . . . . . . . . . . . . . . . . . . 14
4. Host group descriptors . . . . . . . . . . . . . . . . . . . . 17 4. Host group descriptors . . . . . . . . . . . . . . . . . . . . 16
5. Rating criteria . . . . . . . . . . . . . . . . . . . . . . . 18 5. Rating criteria . . . . . . . . . . . . . . . . . . . . . . . 17
5.1. Distance-related rating criteria . . . . . . . . . . . . . 18 5.1. Distance-related rating criteria . . . . . . . . . . . . . 17
5.2. Charging-related rating criteria . . . . . . . . . . . . . 18 5.2. Charging-related rating criteria . . . . . . . . . . . . . 17
5.3. Performance-related rating criteria . . . . . . . . . . . 19 5.3. Performance-related rating criteria . . . . . . . . . . . 18
5.4. Inappropriate rating criteria . . . . . . . . . . . . . . 20 5.4. Inappropriate rating criteria . . . . . . . . . . . . . . 19
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 21 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20
7. Security Considerations . . . . . . . . . . . . . . . . . . . 22 7. Security Considerations . . . . . . . . . . . . . . . . . . . 21
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23 7.1. High-level security considerations . . . . . . . . . . . . 21
8.1. Normative References . . . . . . . . . . . . . . . . . . . 23 7.2. Classification of information disclosure scenarios . . . . 21
8.2. Informative References . . . . . . . . . . . . . . . . . . 23 7.3. Security requirements . . . . . . . . . . . . . . . . . . 23
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 24 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 25 8.1. Normative References . . . . . . . . . . . . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 26 8.2. Informative References . . . . . . . . . . . . . . . . . . 24
Appendix A. Contributors . . . . . . . . . . . . . . . . . . . . 25
Appendix B. Acknowledgments . . . . . . . . . . . . . . . . . . . 26
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 27
1. Introduction 1. Introduction
The motivation for Application-Layer Traffic Optimization (ALTO) is The motivation for Application-Layer Traffic Optimization (ALTO) is
described in the ALTO problem statement described in the ALTO problem statement [RFC5693].
[I-D.ietf-alto-problem-statement].
The goal of ALTO is to provide information which can help peer-to- The goal of ALTO is to provide information which can help peer-to-
peer (P2P) applications to make better decisions with respect to peer peer (P2P) applications to make better decisions with respect to peer
selection. However, ALTO may be useful for non-P2P applications as selection. However, ALTO may be useful for non-P2P applications as
well. For example, clients of client-server applications may use well. For example, clients of client-server applications may use
information provided by ALTO to select one of several servers or information provided by ALTO to select one of several servers or
information replicas. As another example, ALTO information could be information replicas. As another example, ALTO information could be
used to select a media relay needed for NAT traversal. The goal of used to select a media relay needed for NAT traversal. The goal of
these informed decisions is to improve performance (or Quality of these informed decisions is to improve performance (or Quality of
Experience) in the application while reducing resource consumption in Experience) in the application while reducing resource consumption in
skipping to change at page 6, line 16 skipping to change at page 5, line 16
2.1. Requirements notation 2.1. Requirements notation
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].
2.2. ALTO terminology 2.2. ALTO terminology
This document uses the following ALTO-related terms, which are This document uses the following ALTO-related terms, which are
defined in [I-D.ietf-alto-problem-statement]: defined in [RFC5693]:
Application, Overlay Network, Application protocol, Peer, P2P, Application, Overlay Network, Application protocol, Peer, P2P,
Resource, Resource Identifier, Resource Provider, Resource Consumer, Resource, Resource Identifier, Resource Provider, Resource Consumer,
Resource Directory, Transport Address, ALTO Service, ALTO Server, Resource Directory, Transport Address, ALTO Service, ALTO Server,
ALTO Client, ALTO Client Protocol, ALTO Query, ALTO Reply, ALTO ALTO Client, ALTO Client Protocol, ALTO Query, ALTO Reply, ALTO
Transaction, Provisioning protocol, Inter ALTO-Server Protocol, Local Transaction, Provisioning protocol, Inter ALTO-Server Protocol, Local
Traffic, Peering Traffic, Transit Traffic. Traffic, Peering Traffic, Transit Traffic.
Furthermore, the following additonal terms will be used: Furthermore, the following additonal terms will be used:
skipping to change at page 7, line 13 skipping to change at page 6, line 13
can be described by means of a host group descriptor. can be described by means of a host group descriptor.
2.3. Architectural framework for ALTO 2.3. Architectural framework for ALTO
There are various architectural options how ALTO could be There are various architectural options how ALTO could be
implemented, and specifying or mandating one specific architecture is implemented, and specifying or mandating one specific architecture is
out of the scope of this document. out of the scope of this document.
The ALTO Working Group Charter [ALTO-charter] itemizes several key The ALTO Working Group Charter [ALTO-charter] itemizes several key
components, which shall be elaborated and specified by the ALTO components, which shall be elaborated and specified by the ALTO
Working Group. The ALTO problem statement Working Group. The ALTO problem statement [RFC5693] defines a
[I-D.ietf-alto-problem-statement] defines a terminology (see terminology (see Section 2.2) and presents a figure that gives a
Section 2.2) and presents a figure that gives a high-level overview high-level overview of protocol interaction between ALTO elements.
of protocol interaction between ALTO elements.
This document itemizes requirements for the following components of This document itemizes requirements for the following components of
the abovementioned architecture: the abovementioned architecture:
o The ALTO client protocol, which is used for sending ALTO queries o The ALTO client protocol, which is used for sending ALTO queries
and ALTO replies between ALTO client and ALTO server. and ALTO replies between ALTO client and ALTO server.
o The discovery mechanism, which will be used by ALTO clients in o The discovery mechanism, which will be used by ALTO clients in
order to find out where to send ALTO requests. order to find out where to send ALTO requests.
skipping to change at page 7, line 44 skipping to change at page 6, line 43
a host in the network topology. a host in the network topology.
o Rating criteria, i. e., conditions that shall be evaluated in o Rating criteria, i. e., conditions that shall be evaluated in
order to generate the ALTO guidance. order to generate the ALTO guidance.
Requirements regarding other components are not considered in the Requirements regarding other components are not considered in the
current version of this document, but may be added later. current version of this document, but may be added later.
2.4. Sample use cases 2.4. Sample use cases
The ALTO problem statement [I-D.ietf-alto-problem-statement] presents The ALTO problem statement [RFC5693] presents a figure that gives a
a figure that gives a high-level overview of protocol interaction high-level overview of protocol interaction between ALTO elements.
between ALTO elements. The following figures are somewhat more The following figures are somewhat more elaborated and extended
elaborated and extended versions of it, in order to give some non- versions of it, in order to give some non-normative examples of ALTO
normative examples of ALTO usage. It can also be seen that, in some usage. It can also be seen that, in some use cases, some of the
use cases, some of the requirements presented in later sections are requirements presented in later sections are more relevant than in
more relevant than in others. others.
Figure 1 shows an ALTO use case with a DHT-based P2P application. Figure 1 shows an ALTO use case with a DHT-based P2P application.
Using this distributed lookup mechanism, a peer can figure out which Using this distributed lookup mechanism, a peer can figure out which
other peers are candidate resource providers for a desired resource. other peers are candidate resource providers for a desired resource.
Every peer software includes an ALTO client, in order to request and Every peer software includes an ALTO client, in order to request and
receive guidance on peer selection from the ALTO servers. receive guidance on peer selection from the ALTO servers.
From an ALTO perspective this means that the ALTO servers will From an ALTO perspective this means that the ALTO servers will
receive ALTO queries from a rather large number of different ALTO receive ALTO queries from a rather large number of different ALTO
clients. The performance of many clients and their Internet clients. The performance of many clients and their Internet
connectivity may be rather limited and therefore, this puts certain connectivity may be rather limited and therefore, this puts certain
restrictions on the amount of guiding data that can be sent to them. restrictions on the amount of guiding data that can be sent to them.
skipping to change at page 10, line 11 skipping to change at page 9, line 11
Figure 2: Overview of protocol interaction between ALTO elements, Figure 2: Overview of protocol interaction between ALTO elements,
scenario with resource directory scenario with resource directory
3. ALTO requirements 3. ALTO requirements
3.1. ALTO client protocol 3.1. ALTO client protocol
3.1.1. General requirements 3.1.1. General requirements
REQ. ARv02-1: The ALTO service is provided by one or more ALTO REQ. ARv04-1: The ALTO service is provided by one or more ALTO
servers. ALTO servers MUST implement the ALTO client protocol, for servers. ALTO servers MUST implement the ALTO client protocol, for
receiving ALTO queries from ALTO clients and for sending the receiving ALTO queries from ALTO clients and for sending the
corresponding ALTO replies. corresponding ALTO replies.
REQ. ARv02-2: ALTO clients MUST implement the ALTO client protocol, REQ. ARv04-2: ALTO clients MUST implement the ALTO client protocol,
for sending ALTO queries to ALTO servers and for receiving the for sending ALTO queries to ALTO servers and for receiving the
corresponding ALTO replies. corresponding ALTO replies.
REQ. ARv02-3: The format of the ALTO query message MUST allow the REQ. ARv04-3: The format of the ALTO query message MUST allow the
ALTO client to solicit guidance for selecting appropriate resource ALTO client to solicit guidance for selecting appropriate resource
providers. providers.
REQ. ARv02-4: The format of the ALTO reply message MUST allow the REQ. ARv04-4: The format of the ALTO reply message MUST allow the
ALTO server to express its guidance for selecting appropriate ALTO server to express its guidance for selecting appropriate
resource providers. resource providers.
REQ. ARv02-5: The detailed specification of a protocol is out of the REQ. ARv04-5: The detailed specification of a protocol is out of the
scope of this document. However, any protocol specification that scope of this document. However, any protocol specification that
claims to implement the ALTO client protocol MUST be compliant to the claims to implement the ALTO client protocol MUST be compliant to the
requirements itemized in this document. requirements itemized in this document.
3.1.2. Host group descriptor support 3.1.2. Host group descriptor support
The ALTO guidance is based on the evaluation of several resource The ALTO guidance is based on the evaluation of several resource
providers or groups of resource providers, which are characterized by providers or groups of resource providers, which are characterized by
means of host group descriptors, considering one or several rating means of host group descriptors, considering one or several rating
criteria. criteria.
REQ. ARv02-6: The ALTO client protocol MUST support the usage of REQ. ARv04-6: The ALTO client protocol MUST support the usage of
several different host group descriptor types. several different host group descriptor types.
REQ. ARv02-7: The ALTO client protocol specification MUST define a REQ. ARv04-7: The ALTO client protocol specification MUST define a
basic set of host group descriptor types, which MUST be supported by basic set of host group descriptor types, which MUST be supported by
all implementations of the ALTO client protocol. all implementations of the ALTO client protocol.
REQ. ARv02-8: The ALTO client protocol MUST support the host group REQ. ARv04-8: The ALTO client protocol MUST support the host group
descriptor types "IPv4 address prefix" and "IPv6 address prefix." descriptor types "IPv4 address prefix" and "IPv6 address prefix."
They can be used to specify the IP address of one host, or an IP They can be used to specify the IP address of one host, or an IP
address range (in CIDR notation), which contains all hosts in address range (in CIDR notation), which contains all hosts in
question. It is also possible to specify a broader address range question. It is also possible to specify a broader address range
(i.e., a shorter prefix length) than the intended group of hosts (i.e., a shorter prefix length) than the intended group of hosts
actually uses, in order to conceal their exact identity. actually uses, in order to conceal their exact identity.
REQ. ARv02-9: The ALTO client protocol specification MUST define an REQ. ARv04-9: The ALTO client protocol specification MUST define an
appropriate procedure for adding new host group descriptor types, appropriate procedure for adding new host group descriptor types,
e.g., by establishing an IANA registry. e.g., by establishing an IANA registry.
See Section 4 for a discussion of possible other host group See Section 4 for a discussion of possible other host group
descriptor types. descriptor types.
REQ. ARv02-10: ALTO clients and ALTO servers MUST clearly identify REQ. ARv04-10: ALTO clients and ALTO servers MUST clearly identify
the type of each host group descriptor sent in ALTO queries or the type of each host group descriptor sent in ALTO queries or
replies. replies.
REQ. ARv02-11: For host group descriptor types other than "IPv4 REQ. ARv04-11: For host group descriptor types other than "IPv4
address prefix" and "IPv6 address prefix", the host group descriptor address prefix" and "IPv6 address prefix", the host group descriptor
type identification MUST be supplemented by a reference to a type identification MUST be supplemented by a reference to a
facility, which can be used to translate host group descriptors of facility, which can be used to translate host group descriptors of
that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping that type to IPv4/IPv6 address prefixes, e.g., by means of a mapping
table or an algorithm. table or an algorithm.
REQ. ARv02-12: Protocol functions for mapping other host group REQ. ARv04-12: Protocol functions for mapping other host group
descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and descriptor types to IPv4/IPv6 address prefixes SHOULD be designed and
specified as part of the ALTO client protocol, and the corresponding specified as part of the ALTO client protocol, and the corresponding
address mapping information SHOULD be made available by the same address mapping information SHOULD be made available by the same
entity that wants to use these host group descriptors within the ALTO entity that wants to use these host group descriptors within the ALTO
client protocol. However, an ALTO server or an ALTO client MAY also client protocol. However, an ALTO server or an ALTO client MAY also
send a reference to an external mapping facility, e.g., a translation send a reference to an external mapping facility, e.g., a translation
table to be downloaded as file via HTTP. table to be downloaded as file via HTTP.
REQ. ARv02-13: The ALTO client protocol specification MUST define REQ. ARv04-13: The ALTO client protocol specification MUST define
mechanisms, which can be used by the ALTO client and the ALTO server mechanisms, which can be used by the ALTO client and the ALTO server
to indicate that a host group descriptor used by the other party is to indicate that a host group descriptor used by the other party is
of an unsupported type, or that the indicated mapping mechanism could of an unsupported type, or that the indicated mapping mechanism could
not be used. not be used.
3.1.3. Rating criteria support 3.1.3. Rating criteria support
REQ. ARv02-14: The ALTO client protocol MUST support the usage of REQ. ARv04-14: The ALTO client protocol MUST support the usage of
several different rating criteria types. several different rating criteria types.
REQ. ARv02-15: The ALTO client protocol specification MUST define a REQ. ARv04-15: The ALTO client protocol specification MUST define a
basic set of rating criteria types, which MUST be supported by all basic set of rating criteria types, which MUST be supported by all
implementations of the ALTO client protocol. implementations of the ALTO client protocol.
REQ. ARv02-16: The ALTO client protocol specification MUST support REQ. ARv04-16: The ALTO client protocol specification MUST support
the rating criteria type "relative operator's preference." This is a the rating criteria type "relative operator's preference." This is a
relative measure, i.e., it is not associtated with any unit of relative measure, i.e., it is not associtated with any unit of
measurement. A higher rating according to this criterion indicates measurement. A higher rating according to this criterion indicates
that the application should prefer the respective candidate resource that the application should prefer the respective candidate resource
provider over others with lower ratings (if no other reasons speak provider over others with lower ratings (if no other reasons speak
against it, such as transmission attempts suggesting that the path is against it, such as transmission attempts suggesting that the path is
currently congested). The operator of the ALTO server does not have currently congested). The operator of the ALTO server does not have
to disclose how and based on which data the ratings are actually to disclose how and based on which data the ratings are actually
computed. Examples could be: cost for peering or transit traffic, computed. Examples could be: cost for peering or transit traffic,
traffic engineering inside the network, and other policies. traffic engineering inside the network, and other policies.
REQ. ARv02-17: The ALTO client protocol specification MUST define an REQ. ARv04-17: The ALTO client protocol specification MUST define an
appropriate procedure for adding new rating criteria types, e.g., by appropriate procedure for adding new rating criteria types, e.g., by
establishing an IANA registry. establishing an IANA registry.
See Section 5 for a discussion of possible other rating criteria. See Section 5 for a discussion of possible other rating criteria.
REQ. ARv02-18:The ALTO query message SHOULD allow the ALTO client to REQ. ARv04-18:The ALTO query message SHOULD allow the ALTO client to
express which rating criteria should be considered, as well as their express which rating criteria should be considered, as well as their
relative relevance for the specific application that will eventually relative relevance for the specific application that will eventually
make use of the guidance. make use of the guidance.
REQ. ARv02-19:The ALTO reply message SHOULD allow the ALTO server to REQ. ARv04-19:The ALTO reply message SHOULD allow the ALTO server to
express which rating criteria have been considered when generating express which rating criteria have been considered when generating
the reply. the reply.
REQ. ARv02-20: The ALTO client protocol specification MUST define REQ. ARv04-20: The ALTO client protocol specification MUST define
mechanisms, which can be used by the ALTO client and the ALTO server mechanisms, which can be used by the ALTO client and the ALTO server
to indicate that a rating criteria used by the other party is of an to indicate that a rating criteria used by the other party is of an
unsupported type. unsupported type.
3.1.4. Placement of entities and timing of transactions 3.1.4. Placement of entities and timing of transactions
With respect to the placement of ALTO clients, several modes of With respect to the placement of ALTO clients, several modes of
operation exist: operation exist:
o One mode of ALTO operation is that ALTO clients may be embedded o One mode of ALTO operation is that ALTO clients may be embedded
directly in the resource consumer (e.g., peer of a DHT-based P2P directly in the resource consumer (e.g., peer of a DHT-based P2P
application), which wants to access a resource. application), which wants to access a resource.
o Another mode of operation is to perform ALTO queries indirectly, o Another mode of operation is to perform ALTO queries indirectly,
via resource directories (e.g., tracker of a P2P application), via resource directories (e.g., tracker of a P2P application),
which may issue ALTO queries to solicit preference on potential which may issue ALTO queries to solicit preference on potential
resource providers, considering the respective resource consumer. resource providers, considering the respective resource consumer.
REQ. ARv02-21: The ALTO client protocol MUST support the mode of REQ. ARv04-21: The ALTO client protocol MUST support the mode of
operation, in which the ALTO client is directly embedded in the operation, in which the ALTO client is directly embedded in the
resource consumer. resource consumer.
REQ. ARv02-22: The ALTO client protocol MUST support the mode of REQ. ARv04-22: The ALTO client protocol MUST support the mode of
operation, in which the ALTO client is embedded in the resource operation, in which the ALTO client is embedded in the resource
directory. directory.
REQ. ARv02-23: The ALTO client protocol MUST be designed in a way REQ. ARv04-23: The ALTO client protocol MUST be designed in a way
that the ALTO service can be provided by an operator which is not the that the ALTO service can be provided by an operator which is not the
operator of the IP access network. operator of the IP access network.
REQ. ARv02-24: The ALTO client protocol MUST be designed in a way REQ. ARv04-24: The ALTO client protocol MUST be designed in a way
that different instances of the ALTO service operated by different that different instances of the ALTO service operated by different
providers can coexist. providers can coexist.
With respect to the timing of ALTO queries, several modes of With respect to the timing of ALTO queries, several modes of
operation exist: operation exist:
o In target-aware query mode, an ALTO client performs the ALTO query o In target-aware query mode, an ALTO client performs the ALTO query
when the desired resource and a set of candidate resource when the desired resource and a set of candidate resource
providers are already known, i. e., after DHT lookups, queries to providers are already known, i. e., after DHT lookups, queries to
the resource directory, etc. the resource directory, etc.
o In target-independent query mode, ALTO queries are performed in o In target-independent query mode, ALTO queries are performed in
advance or periodically, in order to receive comprehensive, advance or periodically, in order to receive comprehensive,
"target-independent" guidance, which will be cached locally and "target-independent" guidance, which will be cached locally and
evaluated later, when a resource is to be accessed. evaluated later, when a resource is to be accessed.
REQ. ARv02-25: The ALTO client protocol MUST support at least one of REQ. ARv04-25: The ALTO client protocol MUST support at least one of
these two modes, either the target-aware or the target-independent these two modes, either the target-aware or the target-independent
query mode. query mode.
REQ. ARv02-26: The ALTO client protocol SHOULD support both the REQ. ARv04-26: The ALTO client protocol SHOULD support both the
target-aware and the target-independent query mode. target-aware and the target-independent query mode.
REQ. ARv02-27: The ALTO client protocol SHOULD support lifetime REQ. ARv04-27: The ALTO client protocol SHOULD support lifetime
attributes, to enable caching of recommendations at ALTO clients. attributes, to enable caching of recommendations at ALTO clients.
REQ. ARv02-28: The ALTO client protocol SHOULD specify an aging REQ. ARv04-28: The ALTO client protocol SHOULD specify an aging
mechanism, which allows to give newer recommendations precedence over mechanism, which allows to give newer recommendations precedence over
older ones. older ones.
REQ. ARv02-29: The ALTO client protocol MUST support scenarios with REQ. ARv04-29: The ALTO client protocol MUST support scenarios with
the ALTO client located in the private address realm behind a network the ALTO client located in the private address realm behind a network
address translator (NAT). There are different types of NAT, see address translator (NAT). There are different types of NAT, see
[RFC4787] and [RFC5382]. [RFC4787] and [RFC5382].
3.1.5. Protocol extensibility 3.1.5. Protocol extensibility
REQ. ARv02-30: The ALTO client protocol MUST include support for REQ. ARv04-30: The ALTO client protocol MUST include support for
adding protocol extensions in a non-disruptive, backward-compatible adding protocol extensions in a non-disruptive, backward-compatible
way. way.
REQ. ARv02-31: The ALTO client protocol MUST include protocol REQ. ARv04-31: The ALTO client protocol MUST include protocol
versioning support, in order to clearly distinguish between versioning support, in order to clearly distinguish between
incompatible major versions of the protocol. incompatible major versions of the protocol.
3.1.6. Error handling and overload protection 3.1.6. Error handling and overload protection
REQ. ARv02-32: Any application designed to use ALTO MUST also work REQ. ARv04-32: Any application designed to use ALTO MUST also work
if no ALTO servers can be found or if no responses to ALTO queries if no ALTO servers can be found or if no responses to ALTO queries
are received, e.g., due to connectivity problems or overload are received, e.g., due to connectivity problems or overload
situation. situation.
REQ. ARv02-33: The ALTO client protocol MUST use TCP based REQ. ARv04-33: The ALTO client protocol MUST use TCP based
transport. transport.
REQ. ARv02-34: An ALTO server, which is operating close to its REQ. ARv04-34: An ALTO server, which is operating close to its
capacity limit, MUST be able to inform clients about its impending capacity limit, MUST be able to inform clients about its impending
overload situation, and require them to throttle their query rate. overload situation, and require them to throttle their query rate.
REQ. ARv02-35: An ALTO server, which is operating close to its REQ. ARv04-35: An ALTO server, which is operating close to its
capacity limit, MUST be able to inform clients about its impending capacity limit, MUST be able to inform clients about its impending
overload situation, and redirect them to another ALTO server. overload situation, and redirect them to another ALTO server.
REQ. ARv02-36: An ALTO server, which is operating close to its REQ. ARv04-36: An ALTO server, which is operating close to its
capacity limit, MUST be able to inform clients about its impending capacity limit, MUST be able to inform clients about its impending
overload situation, and terminate the conversation with the ALTO overload situation, and terminate the conversation with the ALTO
client. client.
REQ. ARv02-37: An ALTO server, which is operating close to its REQ. ARv04-37: An ALTO server, which is operating close to its
capacity limit, MUST be able to inform clients about its impending capacity limit, MUST be able to inform clients about its impending
overload situation, and reject new conversation attempts. overload situation, and reject new conversation attempts.
3.2. ALTO server discovery 3.2. ALTO server discovery
The ALTO client protocol is supported by one or several ALTO server The ALTO client protocol is supported by one or several ALTO server
discovery mechanisms, which will be used by ALTO clients in order to discovery mechanisms, which will be used by ALTO clients in order to
find out where to send ALTO requests. find out where to send ALTO requests.
REQ. ARv02-38: ALTO clients which are embedded in the resource REQ. ARv04-38: ALTO clients which are embedded in the resource
consumer MUST be able to use the ALTO server discovery mechanism, in consumer MUST be able to use the ALTO server discovery mechanism, in
order to find one or several ALTO servers that can provide ALTO order to find one or several ALTO servers that can provide ALTO
guidance suitable for the resource consumer. This mode of operation guidance suitable for the resource consumer. This mode of operation
is called "resource consumer initiated ALTO server discovery". is called "resource consumer initiated ALTO server discovery".
REQ. ARv02-39: ALTO clients which are embedded in a resource REQ. ARv04-39: ALTO clients which are embedded in a resource
directory and perform third-party ALTO queries on behalf of a remote directory and perform third-party ALTO queries on behalf of a remote
resource consumer MUST be able to use the ALTO server discovery resource consumer MUST be able to use the ALTO server discovery
mechanism, in order to find one or several ALTO servers that can mechanism, in order to find one or several ALTO servers that can
provide ALTO guidance suitable for the respective resource consumer. provide ALTO guidance suitable for the respective resource consumer.
This mode of operation is called "third-party ALTO server discovery". This mode of operation is called "third-party ALTO server discovery".
A classification and evaluation of architectural options for third- A classification and evaluation of architectural options for third-
party ALTO server discovery can be found in [I-D.kiesel-alto-3pdisc]. party ALTO server discovery can be found in [I-D.kiesel-alto-3pdisc].
REQ. ARv02-40: ALTO clients MUST be able to perform resource REQ. ARv04-40: ALTO clients MUST be able to perform resource
consumer initiated ALTO server discovery, even if they are located consumer initiated ALTO server discovery, even if they are located
behind a network address translator (NAT). behind a network address translator (NAT).
REQ. ARv02-41: ALTO clients MUST be able to perform third-party ALTO REQ. ARv04-41: ALTO clients MUST be able to perform third-party ALTO
server discovery, even if they are located behind a network address server discovery, even if they are located behind a network address
translator (NAT). translator (NAT).
REQ. ARv02-42: ALTO clients MUST be able to perform third-party ALTO REQ. ARv04-42: ALTO clients MUST be able to perform third-party ALTO
server discovery, even if the resource consumer, on behalf of which server discovery, even if the resource consumer, on behalf of which
the ALTO query will be sent, is located behind a network address the ALTO query will be sent, is located behind a network address
translator (NAT). translator (NAT).
REQ. ARv02-43: The ALTO server discovery mechanism may be specified REQ. ARv04-43: The ALTO server discovery mechanism may be specified
and provided using an existing protocol or mechanism, such as DNS, and provided using an existing protocol or mechanism, such as DNS,
DHCP, or PPP based automatic configuration, etc. These candidate DHCP, or PPP based automatic configuration, etc. These candidate
"base protocols" differ with respect to their availability in various "base protocols" differ with respect to their availability in various
access network archtitectures and their suitability for third-party access network archtitectures and their suitability for third-party
queries. When evaluating different options this should be taken into queries. When evaluating different options this should be taken into
account, in order to limit the total number of ALTO server discovery account, in order to limit the total number of ALTO server discovery
mechanisms that have to be specified for supporting a reasonably wide mechanisms that have to be specified for supporting a reasonably wide
range of deployment scenarios. range of deployment scenarios.
REQ. ARv02-44: The ALTO server discovery mechanism SHOULD be able to REQ. ARv04-44: The ALTO server discovery mechanism SHOULD be able to
return the respective contact information for several ALTO servers. return the respective contact information for several ALTO servers.
REQ. ARv02-45: The ALTO server discovery mechanism SHOULD be able to REQ. ARv04-45: The ALTO server discovery mechanism SHOULD be able to
indicate preferences for each returned ALTO server contact indicate preferences for each returned ALTO server contact
information. information.
3.3. Security and privacy 3.3. Security and privacy
REQ. ARv02-46: The ALTO client protocol MUST support mechanisms for REQ. ARv04-46: The ALTO client protocol MUST support mechanisms for
the authentication of ALTO servers. the authentication of ALTO servers.
REQ. ARv02-47: The ALTO client protocol MUST support mechanisms for REQ. ARv04-47: The ALTO client protocol MUST support mechanisms for
the authentication of ALTO clients. the authentication of ALTO clients.
REQ. ARv02-48: The ALTO client protocol MUST support different REQ. ARv04-48: The ALTO client protocol MUST support different
levels of detail in queries and responses, in order for the operator levels of detail in queries and responses, in order for the operator
of an ALTO service to be able to control how much information (e.g., of an ALTO service to be able to control how much information (e.g.,
about the network topology) is disclosed. about the network topology) is disclosed.
REQ. ARv02-49: The ALTO client protocol MUST support different REQ. ARv04-49: The operator of an ALTO server MUST NOT assume that
an ALTO client will implement mechanisms or comply with rules that
limit the ALTO client's ability to redistribute information retrieved
from the ALTO server to third parties.
REQ. ARv04-50: The ALTO client protocol MUST support different
levels of detail in queries and responses, in order to protect the levels of detail in queries and responses, in order to protect the
privacy of users, to ensure that the operators of ALTO servers and privacy of users, to ensure that the operators of ALTO servers and
other users of the same application cannot derive sensitive other users of the same application cannot derive sensitive
information. information.
REQ. ARv02-50: The ALTO client protocol SHOULD be defined in a way, REQ. ARv04-51: The ALTO client protocol SHOULD be defined in a way,
that the operator of one ALTO server cannot easily deduce the that the operator of one ALTO server cannot easily deduce the
resource identifier (e.g., file name in P2P file sharing) which the resource identifier (e.g., file name in P2P file sharing) which the
resource consumer seeking ALTO guidance wants to access. resource consumer seeking ALTO guidance wants to access.
REQ. ARv02-51: The ALTO client protocol MUST include appropriate REQ. ARv04-52: The ALTO client protocol MUST include appropriate
mechanisms to protect the ALTO service against DoS attacks. mechanisms to protect the ALTO service against DoS attacks.
4. Host group descriptors 4. Host group descriptors
Host group descriptors are used in the ALTO client protocol to Host group descriptors are used in the ALTO client protocol to
describe the location of a host in the network topology. The ALTO describe the location of a host in the network topology. The ALTO
client protocol specification defines a basic set of host group client protocol specification defines a basic set of host group
descriptor types, which have to be suported by all implementations, descriptor types, which have to be suported by all implementations,
and an extension procedure for adding new descriptor types (see and an extension procedure for adding new descriptor types (see
Section 3.1.2). The following list gives an overview on further host Section 3.1.2). The following list gives an overview on further host
skipping to change at page 22, line 7 skipping to change at page 21, line 7
6. IANA Considerations 6. IANA Considerations
This requirements document does not mandate any immediate IANA This requirements document does not mandate any immediate IANA
actions. However, such IANA considerations may arise from future actions. However, such IANA considerations may arise from future
ALTO specification documents which try to meet the requirements given ALTO specification documents which try to meet the requirements given
here. here.
7. Security Considerations 7. Security Considerations
7.1. High-level security considerations
High-level security considerations for the ALTO service can be found High-level security considerations for the ALTO service can be found
in the "Security Considerations" section of the ALTO problem in the "Security Considerations" section of the ALTO problem
statement [I-D.ietf-alto-problem-statement]. For a set of specific statement document [RFC5693].
security requirements please refer to Section 3.3 of this document.
7.2. Classification of information disclosure scenarios
The unwanted disclosure of information is one key concern related to
ALTO. The following list gives a classification of information
disclosure scenarios, which may be considered more or less critical
by different parties:
o (1) Excess disclosure of ALTO server operator's data to an
authorized ALTO client. The operator of an ALTO server has to
feed information, such as tables mapping host group descriptors to
host characteristics attributes, into the server, thereby enabling
it to give guidance to ALTO clients. Some operators might
consider the full set of this information confidential (e.g., a
detailed map of the operator's network topology), and might want
to disclose only a subset of it or somehow obfuscated information
to an ALTO client.
o (2) Disclosure of the application behavior to the ALTO server.
The operator of an ALTO server could infer the application
behavior (e.g., content identifiers in P2P file sharing
applications, or lists of resource providers that are considered
for establishing a connection) from the ALTO queries sent by an
ALTO client.
o (3) Disclosure of ALTO server operator's data (e.g., network
topology information) to an unauthorized third party. There are a
couple of sub-cases here:
* (3a) An ALTO server sends the information directly to an
unauthorized ALTO client.
* (3b) An unauthorized party snoops on the data transmission from
the ALTO server to an authorized ALTO client.
* (3c) An authorized ALTO client knowingly forwards the
information it had received from the ALTO server to an
unauthorized party.
o (4) Disclosure of the application behavior to an unauthorized
third party.
o (5) Excess retrieval of ALTO server operator's data by
collaborating ALTO clients. Several authorized ALTO clients could
ask an ALTO server for guidance, and redistribute the replies
among each other (see also case 3c). By correlating the ALTO
replies they could find out more information than intended to be
disclosed by the ALTO server operator.
(1) may be addressed by the ALTO server operator choosing the level
of detail of the information to be populated into the ALTO server.
Furhermore, access control mechanisms for filtering ALTO replies
according to the authenticated ALTO client identity might be
installed in the ALTO server, although this might not be effective
given the lack of efficient mechanisms for addressing (3c) and (5),
see below.
(2) is addressed by allowing ALTO clients to use the target-
independent query mode. In this mode of operation, guiding
information (e.g., "maps") is retrieved from the ALTO server and used
entirely locally by the ALTO client, i.e., without sending host
location attributes of candidate resource providers to the ALTO
server. In the target-aware query mode, (2) can be addressed by ALTO
clients by obfuscating the identity of candidate resource consumers,
e.g., by zeroing-out or randomizing the last few bits of the IP
addresses. However, there is the potential side effect of yielding
inaccurate results.
(3a), (3b), and (4) may be addressed by authentication, access
control, and encryption schemes for the ALTO client protocol.
However, deployment of encryption schemes might not be effective
given the lack of efficient mechanisms for addressing (3c) and (5),
see below.
Straightforward authentication and encryption schemes won't help
solving (3c) and (5), and there is no other simple and efficient
mechanism known. The cost of complex approaches, e.g., based on
digital rights management (DRM), might easily outweigh the benefits
of the whole ALTO solution, and therefore they are not considered as
a viable solution. That is, ALTO server operators must be aware that
(3c) and (5) cannot be prevented from happening, and therefore they
should feed only such data into an ALTO server, which they do not
consider sensitive with respect to (3c) and (5).
These insights are reflected by the requirements presented in this
document.
7.3. Security requirements
For a set of specific security requirements please refer to
Section 3.3 of this document.
8. References 8. References
8.1. Normative References 8.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.
8.2. Informative References 8.2. Informative References
[ALTO-charter] [ALTO-charter]
Marocco, E. and V. Gurbani, "Application-Layer Traffic Marocco, E. and V. Gurbani, "Application-Layer Traffic
Optimization (ALTO) Working Group Charter", February 2009. Optimization (ALTO) Working Group Charter", February 2009.
[I-D.ietf-alto-problem-statement]
Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement",
draft-ietf-alto-problem-statement-04 (work in progress),
September 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-00 (work in
progress), August 2009. progress), August 2009.
[RFC4787] Audet, F. and C. Jennings, "Network Address Translation [RFC4787] Audet, F. and C. Jennings, "Network Address Translation
(NAT) Behavioral Requirements for Unicast UDP", BCP 127, (NAT) Behavioral Requirements for Unicast UDP", BCP 127,
RFC 4787, January 2007. RFC 4787, January 2007.
[RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P. [RFC5382] Guha, S., Biswas, K., Ford, B., Sivakumar, S., and P.
Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142, Srisuresh, "NAT Behavioral Requirements for TCP", BCP 142,
RFC 5382, October 2008. RFC 5382, October 2008.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
Appendix A. Contributors Appendix A. Contributors
The authors were supported by the following people, who have The authors were supported by the following people, who have
contributed to this document: contributed to this document:
o Richard Alimi <richard.alimi@yale.edu>
o Zoran Despotovic <despotovic@docomolab-euro.com> o Zoran Despotovic <despotovic@docomolab-euro.com>
o Jason Livingood <Jason_Livingood@cable.comcast.com> o Jason Livingood <Jason_Livingood@cable.comcast.com>
o Saverio Niccolini <saverio.niccolini@nw.neclab.eu> o Saverio Niccolini <saverio.niccolini@nw.neclab.eu>
o Jan Seedorf <jan.seedorf@nw.neclab.eu> o Jan Seedorf <jan.seedorf@nw.neclab.eu>
o Martin Stiemerling <martin.stiemerling@nw.neclab.eu> o Martin Stiemerling <martin.stiemerling@nw.neclab.eu>
skipping to change at page 25, line 16 skipping to change at page 26, line 16
The authors would like to thank The authors would like to thank
o Vijay K. Gurbani <vkg@alcatel-lucent.com> o Vijay K. Gurbani <vkg@alcatel-lucent.com>
o Enrico Marocco <enrico.marocco@telecomitalia.it> o Enrico Marocco <enrico.marocco@telecomitalia.it>
for fostering discussions that lead to the creation of this document, for fostering discussions that lead to the creation of this document,
and for giving valuable comments on it. and for giving valuable comments on it.
Sebastian Kiesel, Saverio Niccolini, Jan Seedorf, and Martin
Stiemerling are partially supported by the NAPA-WINE project
(Network-Aware P2P-TV Application over Wise Networks,
http://www.napa-wine.org), a research project supported by the
European Commission under its 7th Framework Program (contract no.
214412). The views and conclusions contained herein are those of the
authors and should not be interpreted as necessarily representing the
official policies or endorsements, either expressed or implied, of
the NAPA-WINE project or the European Commission.
Laird Popkin and Y. Richard Yang are grateful to the many Laird Popkin and Y. Richard Yang are grateful to the many
contributions made by the members of the P4P working group and Yale contributions made by the members of the P4P working group and Yale
Laboratory of Networked Systems. The P4P working group is hosted by Laboratory of Networked Systems. The P4P working group is hosted by
DCIA. DCIA.
Saverio Niccolini, Jan Seedorf, and Martin Stiemerling were partially
supported by the NAPA-WINE project (Network-Aware P2P-TV Application
over Wise Networks, http://www.napa-wine.org), a research project
supported by the European Commission under its 7th Framework Program
(contract no. 214412). The views and conclusions contained herein
are those of the authors and should not be interpreted as necessarily
representing the official policies or endorsements, either expressed
or implied, of the NAPA-WINE project or the European Commission.
Authors' Addresses Authors' Addresses
Sebastian Kiesel (editor) Sebastian Kiesel (editor)
NEC Europe Ltd., Network Laboratories Europe University of Stuttgart Computing Center
Kurfuersten-Anlage 36 Allmandring 30
Heidelberg 69115 Stuttgart 70550
Germany Germany
Phone: +49 6221 4342 232 Email: ietf-alto@skiesel.de
Email: sebastian.kiesel@nw.neclab.eu URI: http://www.rus.uni-stuttgart.de/nks/
Laird Popkin Laird Popkin
Pando Networks, Inc. Pando Networks, Inc.
Email: laird@pando.com Email: laird@pando.com
Stefano Previdi Stefano Previdi
Cisco Systems, Inc. Cisco Systems, Inc.
Email: sprevidi@cisco.com Email: sprevidi@cisco.com
 End of changes. 73 change blocks. 
149 lines changed or deleted 249 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/