< draft-ietf-alto-server-discovery-01.txt   draft-ietf-alto-server-discovery-02.txt >
ALTO S. Kiesel ALTO S. Kiesel
Internet-Draft University of Stuttgart Internet-Draft University of Stuttgart
Intended status: Standards Track M. Stiemerling Intended status: Standards Track M. Stiemerling
Expires: January 12, 2012 NEC Europe Ltd. Expires: March 17, 2012 NEC Europe Ltd.
N. Schwan N. Schwan
M. Scharf M. Scharf
Alcatel-Lucent Bell Labs Alcatel-Lucent Bell Labs
H. Song H. Song
Huawei Huawei
July 11, 2011 September 14, 2011
ALTO Server Discovery ALTO Server Discovery
draft-ietf-alto-server-discovery-01 draft-ietf-alto-server-discovery-02
Abstract Abstract
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications, which have to select one or several provide guidance to applications, which have to select one or several
hosts from a set of candidates that are able to provide a desired hosts from a set of candidates that are able to provide a desired
resource. resource.
Entities seeking guidance need to discover and possibly select an Entities seeking guidance need to discover and possibly select an
ALTO server to ask. This is called ALTO server discovery. This memo ALTO server to ask. This is called ALTO server discovery. This memo
describes an ALTO server discovery mechanism based on several describes an ALTO server discovery mechanism based on several
alternative mechanisms that are applicable in a diverse set of ALTO alternative mechanisms that are applicable in a diverse set of ALTO
deployments. deployment scenarios.
Status of this Memo Status of this Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted 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). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
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."
This Internet-Draft will expire on January 12, 2012. This Internet-Draft will expire on March 17, 2012.
Copyright Notice Copyright Notice
Copyright (c) 2011 IETF Trust and the persons identified as the Copyright (c) 2011 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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 4
1.2. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 4 1.1.1. ALTO Server Discovery by Resource Consumers . . . . . 5
1.2.1. ALTO Server Discovery by Resource Consumers . . . . . 5 1.1.2. ALTO Server Discovery by a Third Party . . . . . . . . 6
1.2.2. ALTO Server Discovery by a Third Party . . . . . . . . 5 1.2. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . . 7
1.3. Pre-Conditions . . . . . . . . . . . . . . . . . . . . . . 6
2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8 2. Protocol Overview . . . . . . . . . . . . . . . . . . . . . . 8
3. Retrieving the URI by U-NAPTR . . . . . . . . . . . . . . . . 10 3. Retrieving the URI by U-NAPTR . . . . . . . . . . . . . . . . 10
3.1. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 10 3.1. Retrieving the Domain Name . . . . . . . . . . . . . . . . 10
3.2. Retrieving the Domain Name . . . . . . . . . . . . . . . . 10 3.1.1. Option 1: User input . . . . . . . . . . . . . . . . . 10
3.2.1. Option 1: User input . . . . . . . . . . . . . . . . . 11 3.1.2. Option 2: DHCP . . . . . . . . . . . . . . . . . . . . 11
3.2.2. Option 2: DHCP . . . . . . . . . . . . . . . . . . . . 11 3.1.3. Option 3: Reverse DNS Lookup . . . . . . . . . . . . . 11
3.2.3. Option 3: Reverse DNS Lookup . . . . . . . . . . . . . 12 3.2. U-NAPTR Resolution . . . . . . . . . . . . . . . . . . . . 12
4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13 4. Applicability . . . . . . . . . . . . . . . . . . . . . . . . 13
4.1. Applicability for Resource Consumer Server Discovery . . . 13 4.1. Applicability for Resource Consumer Server Discovery . . . 13
4.2. Applicability for Third Party Server Discovery . . . . . . 14 4.2. Applicability for Third Party Server Discovery . . . . . . 14
5. Deployment Considerations . . . . . . . . . . . . . . . . . . 15 5. Deployment Considerations . . . . . . . . . . . . . . . . . . 15
5.1. Reverse DNS Lookup . . . . . . . . . . . . . . . . . . . . 15 5.1. Reverse DNS Lookup . . . . . . . . . . . . . . . . . . . . 15
5.1.1. Private customers or very small businesses . . . . . . 15 5.1.1. Private customers or very small businesses . . . . . . 15
5.1.2. Medium-size customer networks . . . . . . . . . . . . 15 5.1.2. Medium-size customer networks . . . . . . . . . . . . 15
5.1.3. Large Customers . . . . . . . . . . . . . . . . . . . 16 5.1.3. Large Customers . . . . . . . . . . . . . . . . . . . 16
5.2. DHCP option for DNS Suffix . . . . . . . . . . . . . . . . 16 5.2. DHCP option for DNS Suffix . . . . . . . . . . . . . . . . 16
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17
skipping to change at page 3, line 11 skipping to change at page 3, line 11
10.2. Informative References . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 22
Appendix A. Contributors List and Acknowledgments . . . . . . . . 24 Appendix A. Contributors List and Acknowledgments . . . . . . . . 24
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 25
1. Introduction 1. Introduction
The goal of Application-Layer Traffic Optimization (ALTO) is to The goal of Application-Layer Traffic Optimization (ALTO) is to
provide guidance to applications, which have to select one or several provide guidance to applications, which have to select one or several
hosts from a set of candidates, that are able to provide a desired hosts from a set of candidates, that are able to provide a desired
resource [RFC5693]. The requirements for ALTO are itemized in resource [RFC5693]. The requirements for ALTO are itemized in
[I-D.ietf-alto-reqs]. ALTO is realized by a client-server protocol. [I-D.ietf-alto-reqs].
ALTO clients send queries to ALTO servers, in order to solicit
guidance.
ALTO clients have to discover suitable ALTO servers. Therefore the ALTO is realized by a client-server protocol. ALTO clients send
output of the herein defined ALTO discovery procedure tells the ALTO queries to ALTO servers, in order to solicit guidance. Hence, ALTO
client which ALTO servers to send the queries to. The ALTO discovery clients need to know the contact information of ALTO servers, which
procedure, as part of the ALTO client, can be embedded in the can provide appropriate guidance for a given resource consumer. This
resource consumer, which will eventually access the desired resource. information can be retrieved by invoking the ALTO discovery procedure
As an alternative, they can be embedded in a resource directory, defined in this document.
which assists resource consumers in finding appropriate resource
providers. In some specific peer-to-peer application protocols these
resource directories are called "trackers". Finally the ALTO server
discovery procedure can be embedded in the resource consumer, whereas
the ALTO client is embedded in the resource directory. ALTO queries,
which are issued by a resource directory on behalf of a resource
consumer, are referred to as third-party ALTO queries. The various
possibilities to place ALTO servers and the placement of ALTO clients
is discussed in [I-D.ietf-alto-deployments].
No matter where ALTO server and client are located, clients have to The ALTO protocol specification [I-D.ietf-alto-protocol] is based on
first find out if there is an ALTO server deployed that is in charge HTTP. Therefore, it expects that the ALTO discovery procedure yields
for them, and second they have to get the contact information of that the HTTP(S) URI of the ALTO server's Information Resource Directory,
server, i.e., the IP address, port number, and probably transport which gives further information about the capabilities and services
protocol (which defaults to TCP for the ALTO protocol specification provided by that ALTO server. Further (DNS) lookups may be necessary
[I-D.ietf-alto-protocol]). in order to find out the ALTO server's IP address.
There are various architectural options where to place the ALTO
client and the ALTO server discovery procedure:
o One option is that the ALTO client and the ALTO server discovery
procedure are embedded directly in the resource consumer, i.e.,
the application protocol entity that will eventually initiate data
transmission to/from the selected resource provider(s). In this
case, the ALTO server discovery procedure might be able to
interact with the user (i.e., prompt for a host name).
Furthermore, it may use services such as DHCP, which are only
available within the access network to which the resource consumer
is connected.
o Another option is to integrate the ALTO client and the ALTO server
discovery procedure into a third party such as a resource
directory ("peer-to-peer tracker"), which issues ALTO queries on
behalf of various resource consumers. This third party may reside
in a different part of the network (administrative domain) than
the resource consumer. It may occur that said third party whishes
to issue ALTO queries on behalf of a resouce consumer, but all it
knows about the resource consumer is the source IP address of
messages originating from it (i.e., the resource consumer's IP
address or the "public" IP address of the outermost NAT in front
of the resource consumer). This IP address will be the only input
parameter to the ALTO server discovery procedure, which will have
to find an ALTO server that can give appropriate guidance for that
resource consumer.
A more detailed discussion of various options where to place the
funcional entities comprising the overall ALTO architecture can be
found in [I-D.ietf-alto-deployments].
The goal of this memo is to propose a uniform mechanism for all types The goal of this memo is to propose a uniform mechanism for all types
of ALTO client deployments that is implementable and deployable at a of ALTO client deployments that is implementable and deployable at a
fast pace, i.e., without creating other deployment dependencies for fast pace, i.e., without creating other deployment dependencies for
ALTO. We propose a schema which employs the UNAPTR mechanism ALTO. We propose a schema which employs the UNAPTR mechanism
[RFC4848] to determine the URI of the ALTO server and where mutliple [RFC4848] to determine the URI of the ALTO server and where mutliple
input methods to the UNAPTR process can be used. input methods to the UNAPTR process can be used.
Comments and discussions about this memo should be directed to the Comments and discussions about this memo should be directed to the
ALTO working group: alto@ietf.org. ALTO working group: alto@ietf.org.
1.1. History 1.1. Discovery Scenarios
[RFC editor's note: Please remove this section before publication.]
This document represents a merge of features from two previous
drafts:
o draft-kiesel-alto-3pdisc-04
o draft-song-alto-server-discovery-03
1.2. Discovery Scenarios
Figure 1 below shows an overview on the different entities of a Figure 1 below shows an overview on the different entities of a
generic ALTO framework. The ALTO Server discovery mechanism is used generic ALTO framework. The ALTO Server discovery mechanism is used
by the peer-to-peer (P2P) application in order retrieve the point of by the peer-to-peer (P2P) application in order retrieve the point of
contact of the ALTO Service. contact of the ALTO Service.
+------+ +------+
+-----+ | Peers +-----+ | Peers
+-----+ +------+ +=====| |--+-oo +-----+ +------+ +=====| |--+-oo
| |......| |====+ oo+--*--+ o | |......| |====+ oo+--*--+ o
skipping to change at page 5, line 5 skipping to change at page 5, line 12
Figure 1: ALTO Discovery Overview Figure 1: ALTO Discovery Overview
Hereby the ALTO service discovery scenarios are classified into two Hereby the ALTO service discovery scenarios are classified into two
types: one is the ALTO server discovery by the resource consumer, and types: one is the ALTO server discovery by the resource consumer, and
the other is the ALTO server discovery by a third party, such as the other is the ALTO server discovery by a third party, such as
application trackers. Before the specification of the discovery application trackers. Before the specification of the discovery
mechanism the following section illustrates and discusses both mechanism the following section illustrates and discusses both
scenarios. scenarios.
1.2.1. ALTO Server Discovery by Resource Consumers 1.1.1. ALTO Server Discovery by Resource Consumers
The ALTO service discovery in some scenarios needs to be performed by The ALTO service discovery in some scenarios needs to be performed by
the resource consumer itself. In particular in P2P applications the resource consumer itself. In particular in P2P applications
without a tracker like DHTs and other conventional client/server without a tracker like DHTs and other conventional client/server
applications. applications.
In addition also P2P application which are tracker based may embed In addition also P2P application which are tracker based may embed
the ALTO client into the resource consumer to allow peers a selection the ALTO client into the resource consumer to allow peers a selection
of peers after retrieving the peer list from the application tracker. of peers after retrieving the peer list from the application tracker.
Another option is that the resource consumer peer sends its ALTO Another option is that the resource consumer peer sends its ALTO
skipping to change at page 5, line 45 skipping to change at page 6, line 5
| Client A | | o | Client A | | o
+---------------+ | o +---------------+ | o
| o | o
+--+-------------+ o +--+-------------+ o
| P2P Application|oooooo | P2P Application|oooooo
| Client B | | Client B |
+----------------+ +----------------+
Figure 2: Resource Consumer ALTO Server Discovery (Example) Figure 2: Resource Consumer ALTO Server Discovery (Example)
1.2.2. ALTO Server Discovery by a Third Party 1.1.2. ALTO Server Discovery by a Third Party
Some P2P applications have trackers, and these applications might not Some P2P applications have trackers, and these applications might not
need to have their clients looking for the ALTO server guidance. In need to have their clients looking for the ALTO server guidance. In
these scenarios trackers query the ALTO servers for guidance these scenarios trackers query the ALTO servers for guidance
themselves, and then return the final ranked result to the themselves, and then return the final ranked result to the
application clients. However, application clients are distributed application clients. However, application clients are distributed
among different network operators and autonomous systems. Trackers among different network operators and autonomous systems. Trackers
thus need to find different ALTO servers for the clients located in thus need to find different ALTO servers for the clients located in
different operator networks or autonomous systems. In such scenarios different operator networks or autonomous systems. In such scenarios
the discovery is thus not performed by the resource consumer, but a the discovery is thus not performed by the resource consumer, but a
skipping to change at page 6, line 47 skipping to change at page 7, line 29
| |5 ^ |d | |5 ^ |d
1| | a| | 1| | a| |
| v | v | v | v
+-+---------+ +---+--------+ +-+---------+ +---+--------+
|Application| |Application | |Application| |Application |
| Client1 | | Client2 | | Client1 | | Client2 |
+-----------+ +------------+ +-----------+ +------------+
Figure 3: Third Party ALTO Server Discovery (Example) Figure 3: Third Party ALTO Server Discovery (Example)
1.3. Pre-Conditions 1.2. Pre-Conditions
The whole document assumes certain pre-conditions, such as: The whole document assumes certain pre-conditions, in particular:
o The ALTO server discovery procedure is executed on a per IP o The ALTO server discovery procedure is executed on a per IP
address base. Multiple IP addresses per interface or multiple IP address base. Multiple IP addresses per interface or multiple IP
addresses assigned to different IP interfaces require to repeat addresses assigned to different IP interfaces require to repeat
the procedure for every IP address. It may be fine to group IP the procedure for every IP address. It may be fine to group IP
addresses according their domain suffixes and to perfom the addresses according their domain suffixes and to perfom the
procedure for such a group. However, this is out of scope of this procedure for such a group. However, this is out of scope of this
document.[Editor's note: this may relate to the work of the MIF document.[Editor's note: this may relate to the work of the MIF
WG] WG]
skipping to change at page 8, line 21 skipping to change at page 8, line 21
deployments where the ALTO server in charge for ALTO client is deployments where the ALTO server in charge for ALTO client is
provisioned by the network operator and communicated to the ALTO provisioned by the network operator and communicated to the ALTO
client's host via a DHCP option, while in other deployments no such client's host via a DHCP option, while in other deployments no such
means may exist. It should be noted that there is no silver bullet means may exist. It should be noted that there is no silver bullet
solution to the ALTO server discovery, as there too many deployment solution to the ALTO server discovery, as there too many deployment
scenarios in the server discovery space. scenarios in the server discovery space.
The following figure illustrates the different protocols that are The following figure illustrates the different protocols that are
used to find the URI of a suitable ALTO server. used to find the URI of a suitable ALTO server.
Descending Order of Preference Descending Order of Preference
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~> ~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~>
-------------- -------- --------------- -------------- -------------- ---------------------
| User Input | | DHCP | | Reverse DNS | | User Input | | DHCP query | | DNS PTR lookup on |
-------------- -------- --------------- | in res.c. | | by res.c. | | res.c's IP addr. |
| | | -------------- -------------- ---------------------
\ | / | | |
Retrieving the DNS suffix \ | /
\ | / \--------+----------/
--------+---------- |
| V
----------- DNS suffix
| U-NAPTR | |
----------- V
| ------------------
Retrieving ALTO Server URI | U-NAPTR lookup |
| ------------------
| |
Final DNS lookup V
ALTO Server's Information Resource Directory URI
Figure 4: Protocol Overview Figure 4: Protocol Overview
Figure 4 illustrates the U-NAPTR based resolution process to retrieve Figure 4 illustrates the U-NAPTR based resolution process to retrieve
the ALTO Server URL. As a precondition for resolution the U-NAPTR the ALTO Server URL. As a precondition for resolution the U-NAPTR
process needs the right domain name as input. This domain name is process needs the right domain name as input. This domain name is
determined by the IP address of the client and the DNS suffix of the determined by the IP address of the client and the DNS suffix of the
access network where the client is registered in. In order to access network where the client is registered in. In order to
retrieve the DNS suffix we specify three options, as are listed in retrieve the DNS suffix we specify three options, as are listed in
descending order of preference: descending order of preference:
skipping to change at page 10, line 9 skipping to change at page 10, line 9
option. option.
Reverse DNS: the DNS system can be used to retrieve the DNS suffix Reverse DNS: the DNS system can be used to retrieve the DNS suffix
through reverse lookup of an FQDN associated with an IP address. through reverse lookup of an FQDN associated with an IP address.
This is the last resort if all other options failed. This is the last resort if all other options failed.
3. Retrieving the URI by U-NAPTR 3. Retrieving the URI by U-NAPTR
This section specifies the U-NAPTR based resolution process. To This section specifies the U-NAPTR based resolution process. To
start the U-NAPTR resolution process a domain name is required as start the U-NAPTR resolution process a domain name is required as
input. Thus the section is devided into two parts: Section 3.1 input. Thus the section is devided into two parts: Section 3.2
describes the U-NAPTR resolution process itself. How the client describes the U-NAPTR resolution process itself. How the client
identifies this DNS suffix of the access network where the resource identifies this DNS suffix of the access network where the resource
consumer is registered in is described in Section 3.2. consumer is registered in is described in Section 3.1.
3.1. U-NAPTR Resolution
ALTO servers are identified by U-NAPTR/DDDS (URI-Enabled NAPTR/
Dynamic Delegation Discovery Service) [RFC4848] application unique
strings, in the form of a DNS name. An example is
'altoserver.example.com'.
Clients need to use the U-NAPTR [RFC4848] specification described
below to obtain a URI (indicating host and protocol) for the
applicable ALTO service. In this document, only the HTTP and HTTPS
URL schemes are defined, as the ALTO protocol specification defines
the access over both protocols, but no other
[I-D.ietf-alto-protocol]. Note that the HTTP URL can be any valid
HTTP(s) URL, including those containing path elements.
The following two DNS entries show the U-NAPTR resolution for
"example.com" to the HTTPS URL https://altoserver.example.com/secure
or the HTTP URL http://altoserver.example.com, with the former being
preferred.
example.com.
IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://altoserver.example.com/secure!" ""
IN NAPTR 200 10 "u" "ALTO:http"
"!.*!http://altoserver.example.com!" ""
3.2. Retrieving the Domain Name 3.1. Retrieving the Domain Name
The U-NAPTR resolution process requires a domain name as input. The The U-NAPTR resolution process requires a domain name as input. The
algorithm that is applied to determine this domain name is described algorithm that is applied to determine this domain name is described
in this section. We specify three different options. In option 1 in this section. We specify three different options. In option 1
the user manually configures a specific ALTO service instance that he the user manually configures a specific ALTO service instance that he
wants to use. Option 2 defines a DHCP option to allow the network wants to use. Option 2 defines a DHCP option to allow the network
service provider a remote configuration of the client. In option 3 service provider a remote configuration of the client. In option 3
the client tries to get the domain name by performing a reverse DNS the client tries to get the domain name by performing a reverse DNS
lookup on its IP address. lookup on its IP address.
The resource consumer may have private IP addresses and public IP The resource consumer may have private IP addresses and public IP
addresses and depending on the deployment it might be necessary to addresses and depending on the deployment it might be necessary to
determine for all IP addresses the ALTO server in charge of. To determine for all IP addresses the ALTO server in charge of. To
determine its public IP address the resource consumer may need to use determine its public IP address the resource consumer may need to use
STUN[RFC5389] or BEP24[bep24]. For the following examples we assume STUN[RFC5389] or BEP24[bep24]. For the following examples we assume
that the IP address of the resource consumer is a.b.c.d. that the IP address of the resource consumer is a.b.c.d.
3.2.1. Option 1: User input 3.1.1. Option 1: User input
A user may want to use a third party ALTO service instance. A user may want to use a third party ALTO service instance.
Therefore we allow the user to specify a DNS suffix on its own, for Therefore we allow the user to specify a DNS suffix on its own, for
example in a config file option. The DNS suffix given by the user is example in a config file option. The DNS suffix given by the user is
combined with the IP address of the resource consumer to allow the combined with the IP address of the resource consumer to allow the
third party ALTO service to direct the client to a suitable ALTO third party ALTO service to direct the client to a suitable ALTO
server based on the location of the client. A possible DNS suffix server based on the location of the client. A possible DNS suffix
entered by the user may be: entered by the user may be:
myaltoprovider.org myaltoprovider.org
This DNS suffix is prepended with the IP address of the resource This DNS suffix is prepended with the IP address of the resource
consumer in reverse order to compose the domain name used for the consumer in reverse order to compose the domain name used for the
final U-NAPTR lookup Section 3.1. In case there are multiple ALTO final U-NAPTR lookup Section 3.2. In case there are multiple ALTO
servers deployed, the third party ALTO service instance can direct servers deployed, the third party ALTO service instance can direct
the ALTO client to the ALTO server closest to the client based on the the ALTO client to the ALTO server closest to the client based on the
IP address. IP address.
Multiple lookups with different domain names might be necessary to Multiple lookups with different domain names might be necessary to
complete the U-NAPTR resolution process. If there is no response for complete the U-NAPTR resolution process. If there is no response for
a lookup the domain name is shortened by one part for the succeeding a lookup the domain name is shortened by one part for the succeeding
lookup, until a lookup is successful, as for example lookup, until a lookup is successful, as for example
d.c.b.a.myaltoprovider.org. d.c.b.a.myaltoprovider.org.
c.b.a.myaltoprovider.org. c.b.a.myaltoprovider.org.
b.a.myaltoprovider.org. b.a.myaltoprovider.org.
a.myaltoprovider.org. a.myaltoprovider.org.
myaltoprovider.org. myaltoprovider.org.
3.2.2. Option 2: DHCP 3.1.2. Option 2: DHCP
As a second option network operators can configure the domain name to As a second option network operators can configure the domain name to
be used for service discovery within an access network. RFC be used for service discovery within an access network. RFC
5986[RFC5986] defines DHCP IPv4 and IPv6 access network domain name 5986[RFC5986] defines DHCP IPv4 and IPv6 access network domain name
options that identify a domain name that is suitable for service options that identify a domain name that is suitable for service
discovery within the access network. The ALTO server discovery discovery within the access network. The ALTO server discovery
procedure uses these DHCP options to retrieve the domain name as an procedure uses these DHCP options to retrieve the domain name as an
input for the U-NAPTR resolution. One example could be: input for the U-NAPTR resolution. One example could be:
example.com example.com
3.2.3. Option 3: Reverse DNS Lookup 3.1.3. Option 3: Reverse DNS Lookup
The last option to get the domain name is to use a DNS PTR query for The last option to get the domain name is to use a DNS PTR query for
the IP address of the resource consumer. The local DNS server the IP address of the resource consumer. The local DNS server
resolves the IP address to the FQDN that also contains the DNS suffix resolves the IP address to the FQDN that also contains the DNS suffix
for the respective IP address. A possible answer for a PTR lookup for the respective IP address. A possible answer for a PTR lookup
for d.c.b.a.in-addr.apra might be, for example: for d.c.b.a.in-addr.apra might be, for example:
d-c-b-a.dsl.westcoast.myisp.net d-c-b-a.dsl.westcoast.myisp.net
This domain name can be used for the final U-NAPTR lookup This domain name can be used for the final U-NAPTR lookup
Section 3.1. If there is no response to the lookup the domain name Section 3.2. If there is no response to the lookup the domain name
is shortened by one part for one succeeding lookup. If there is is shortened by one part for one succeeding lookup. If there is
still no response we consider the reverse lookup being failed. The still no response we consider the reverse lookup being failed. The
domain names used for the example as described above are: domain names used for the example as described above are:
d-c-b-a.dsl.westcoast.myisp.net. d-c-b-a.dsl.westcoast.myisp.net.
dsl.westcoast.myisp.net. dsl.westcoast.myisp.net.
3.2. U-NAPTR Resolution
The ALTO protocol specification [I-D.ietf-alto-protocol] , it expects
that the ALTO discovery procedure yields the HTTP(S) URI of the ALTO
server's Information Resource Directory, which gives further
information about the capabilities and services provided by that ALTO
server. The first step of the ALTO server discovery procedure (see
Section 3.1) yielded an U-NAPTR/DDDS (URI-Enabled NAPTR/Dynamic
Delegation Discovery Service) [RFC4848] application unique strings,
in the form of a DNS name. An example is "example.com".
In the second step, the ALTO Server discovery procedure needs to use
the U-NAPTR [RFC4848] specification described below to obtain a URI
(indicating host and protocol) for the ALTO server's Information
Resource Directory. In this document, only the HTTP and HTTPS URL
schemes are defined, as the ALTO protocol specification defines the
access over both protocols, but no other [I-D.ietf-alto-protocol].
Note that the HTTP URL can be any valid HTTP(s) URL, including those
containing path elements.
The following two DNS entries show the U-NAPTR resolution for
"example.com" to the HTTPS URL
https://altoserver.example.com/secure/directory or the HTTP URL
http://altoserver.example.com/directory, with the former being
preferred.
example.com.
IN NAPTR 100 10 "u" "ALTO:https"
"!.*!https://altoserver.example.com/secure/directory!" ""
IN NAPTR 200 10 "u" "ALTO:http"
"!.*!http://altoserver.example.com/directory!" ""
4. Applicability 4. Applicability
This section discusses the applicability of the proposed solution This section discusses the applicability of the proposed solution
with respect to the resource consumer server discovery and the third with respect to the resource consumer server discovery and the third
party deployment scenarios. Each section discusses the proposed party deployment scenarios. Each section discusses the proposed
steps that are needed to determine the ALTO Server URI. steps that are needed to determine the ALTO Server URI.
4.1. Applicability for Resource Consumer Server Discovery 4.1. Applicability for Resource Consumer Server Discovery
In this scenario the ALTO server discovery procedure is performed by In this scenario the ALTO server discovery procedure is performed by
the resource consumer, for example a peer in a P2P system. After the the resource consumer, for example a peer in a P2P system. After the
discovery the peer does the ALTO query on its own, or it might share discovery the peer does the ALTO query on its own, or it might share
the ALTO server contact information with a third party, for example a the ALTO server contact information with a third party, for example a
tracker, which then executes the ALTO query on behalf of the peer. tracker, which then executes the ALTO query on behalf of the peer.
To complete the ALTO server discovery process the resource consumer To complete the ALTO server discovery process the resource consumer
first SHOULD check whether the user has provider the domain name first SHOULD check whether the user has provider the domain name
through manual configuration. If this is not the case the next step through manual configuration. If this is not the case the next step
SHOULD be to check for the access network domain name DHCP option SHOULD be to check for the access network domain name DHCP option
(Section 3.2.2). Finally the client SHOULD try to retrieve the (Section 3.1.2). Finally the client SHOULD try to retrieve the
domain name by the last option, the DNS reverse lookup on its IP domain name by the last option, the DNS reverse lookup on its IP
address as described in Section 3.2.3. address as described in Section 3.1.3.
A client can have several candidate IP addresses that it may use for A client can have several candidate IP addresses that it may use for
the discovery process. For example if it is located behind a NAT, a the discovery process. For example if it is located behind a NAT, a
private and a public IP address may be used for the discovery private and a public IP address may be used for the discovery
process. It depends on the deployment scenario which of the IP process. It depends on the deployment scenario which of the IP
addresses is the correct one. Thus it is out-of-scope of this addresses is the correct one. Thus it is out-of-scope of this
document to specify how exactly the client finds the right IP document to specify how exactly the client finds the right IP
address. However in the following we list methods that may be used address. However in the following we list methods that may be used
in order to determine these candidate IP addresses. Generally in P2P in order to determine these candidate IP addresses. Generally in P2P
environments peers already have implemented mechanisms for NAT- environments peers already have implemented mechanisms for NAT-
skipping to change at page 13, line 48 skipping to change at page 13, line 48
public IP address, for example by asking a neighbour peer about its public IP address, for example by asking a neighbour peer about its
record of the own IP address. Non-proprietary solutions that are record of the own IP address. Non-proprietary solutions that are
favorable include the Session Traversal Utilities for NAT (STUN) favorable include the Session Traversal Utilities for NAT (STUN)
[RFC5986] protocol to determine the public address. If the client is [RFC5986] protocol to determine the public address. If the client is
behind a residential gateway another option may be to use Universal behind a residential gateway another option may be to use Universal
Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] or the NAT Port Plug and Play (UPnP) [UPnP-IGD-WANIPConnection1] or the NAT Port
Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp]. Mapping Protocol (NAT-PMP) [I-D.cheshire-nat-pmp].
In case the ALTO discovery client has determined the domain name In case the ALTO discovery client has determined the domain name
through one of the described options it proceedes with the U-NAPTR through one of the described options it proceedes with the U-NAPTR
lookup as described in Section 3.1. lookup as described in Section 3.2.
4.2. Applicability for Third Party Server Discovery 4.2. Applicability for Third Party Server Discovery
In case of the third party server discovery deployment scenario the In case of the third party server discovery deployment scenario the
entity performing the ALTO server discovery process is different from entity performing the ALTO server discovery process is different from
the resource consumer. Typically the resource consumer is a peer the resource consumer. Typically the resource consumer is a peer
whereas the ALTO client is a resource directory which seeks for ALTO whereas the ALTO client is a resource directory which seeks for ALTO
guidance on behalf of the peer. Another use case for the third party guidance on behalf of the peer. Another use case for the third party
discovery is an application that looks for ALTO guidance discovery is an application that looks for ALTO guidance
transparently for the resource consumer, for example a CDN. transparently for the resource consumer, for example a CDN.
skipping to change at page 14, line 26 skipping to change at page 14, line 26
through the DHCP option or manual user configuration, but only if the through the DHCP option or manual user configuration, but only if the
provided discovery information is forwarded by the resource consumer provided discovery information is forwarded by the resource consumer
to the third party entity. In this case, additional mechanisms for to the third party entity. In this case, additional mechanisms for
the forwarding of this discovery information need to be specified. the forwarding of this discovery information need to be specified.
However these mechanisms are out of scope of this doument. However these mechanisms are out of scope of this doument.
If the third party entity cannot obtain this discovery information, If the third party entity cannot obtain this discovery information,
the ALTO server discovery process relies on retrieving the domain the ALTO server discovery process relies on retrieving the domain
name used as input to the U-NAPTR lookup through reverse DNS lookup name used as input to the U-NAPTR lookup through reverse DNS lookup
of the IP address of the resource consumer as described in of the IP address of the resource consumer as described in
Section 3.2.3. Usually the third party entity already knows the IP Section 3.1.3. Usually the third party entity already knows the IP
address of the resource consumer which was used to establish the address of the resource consumer which was used to establish the
initial connection. In general this IP address is a public address, initial connection. In general this IP address is a public address,
either of the resource consumer or of the last NAT on the path to the either of the resource consumer or of the last NAT on the path to the
ALTO client. This makes the IP address a good candidate for the DNS ALTO client. This makes the IP address a good candidate for the DNS
PTR query. Thus, we expect that the DNS query will be successfully PTR query. Thus, we expect that the DNS query will be successfully
resolved to the FQDN of the domain where the resource consumer is resolved to the FQDN of the domain where the resource consumer is
registered in. registered in.
In case the resource consumer needs guidance for a different IP In case the resource consumer needs guidance for a different IP
address, for example one from a private network, we recommend that address, for example one from a private network, we recommend that
skipping to change at page 16, line 29 skipping to change at page 16, line 29
5.1.3. Large Customers 5.1.3. Large Customers
For very large customers with multiple upstream connections we assume For very large customers with multiple upstream connections we assume
that they have their very own traffic optimization policies and thus that they have their very own traffic optimization policies and thus
run their own ALTO server anyway. In this case they need to manage run their own ALTO server anyway. In this case they need to manage
their DNS entries accordingly. their DNS entries accordingly.
5.2. DHCP option for DNS Suffix 5.2. DHCP option for DNS Suffix
Section 3.2.2 describes the usage of a DHCP option which allows the Section 3.1.2 describes the usage of a DHCP option which allows the
network operator of the network where the ALTO client is attached to, network operator of the network where the ALTO client is attached to,
to provide a DNS suffix. However, this assumes that this particular to provide a DNS suffix. However, this assumes that this particular
DHCP option is correctly passed from the DHCP server to the actual DHCP option is correctly passed from the DHCP server to the actual
host with the ALTO client, and that the particular host understands host with the ALTO client, and that the particular host understands
this DHCP option. This memo assumes the client to be able to this DHCP option. This memo assumes the client to be able to
understand the proposed DHCP option, otherwise there is no further understand the proposed DHCP option, otherwise there is no further
use of the DHCP option, but the client has to use the other proposed use of the DHCP option, but the client has to use the other proposed
mechanisms. mechanisms.
There are well-known issues with the handling of DHCP options in home There are well-known issues with the handling of DHCP options in home
skipping to change at page 22, line 35 skipping to change at page 22, line 35
October 2008. October 2008.
10.2. Informative References 10.2. Informative References
[I-D.cheshire-nat-pmp] [I-D.cheshire-nat-pmp]
Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)", Cheshire, S., "NAT Port Mapping Protocol (NAT-PMP)",
draft-cheshire-nat-pmp-03 (work in progress), April 2008. draft-cheshire-nat-pmp-03 (work in progress), April 2008.
[I-D.ietf-alto-deployments] [I-D.ietf-alto-deployments]
Stiemerling, M. and S. Kiesel, "ALTO Deployment Stiemerling, M. and S. Kiesel, "ALTO Deployment
Considerations", draft-ietf-alto-deployments-01 (work in Considerations", draft-ietf-alto-deployments-02 (work in
progress), March 2011. progress), July 2011.
[I-D.ietf-alto-protocol] [I-D.ietf-alto-protocol]
Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol", Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
draft-ietf-alto-protocol-04 (work in progress), May 2010. draft-ietf-alto-protocol-09 (work in progress), June 2011.
[I-D.ietf-alto-reqs] [I-D.ietf-alto-reqs]
Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
Y. Yang, "Application-Layer Traffic Optimization (ALTO) Y. Yang, "Application-Layer Traffic Optimization (ALTO)
Requirements", draft-ietf-alto-reqs-08 (work in progress), Requirements", draft-ietf-alto-reqs-11 (work in progress),
March 2011. July 2011.
[RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational [RFC4472] Durand, A., Ihren, J., and P. Savola, "Operational
Considerations and Issues with IPv6 DNS", RFC 4472, Considerations and Issues with IPv6 DNS", RFC 4472,
April 2006. April 2006.
[RFC4848] Daigle, L., "Domain-Based Application Service Location [RFC4848] Daigle, L., "Domain-Based Application Service Location
Using URIs and the Dynamic Delegation Discovery Service Using URIs and the Dynamic Delegation Discovery Service
(DDDS)", RFC 4848, April 2007. (DDDS)", RFC 4848, April 2007.
[RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic [RFC5693] Seedorf, J. and E. Burger, "Application-Layer Traffic
 End of changes. 34 change blocks. 
120 lines changed or deleted 136 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/