< draft-song-alto-server-discovery-01.txt   draft-song-alto-server-discovery-03.txt >
ALTO H. Song, Ed. ALTO H. Song
Internet-Draft Huawei Internet-Draft Huawei
Intended status: Standards Track M. Tomsu, Ed. Intended status: Standards Track M. Tomsu
Expires: January 12, 2010 Alcatel-lucent Bell Labs Expires: January 13, 2011 Alcatel-lucent Bell Labs
G. Garcia G. Garcia
Telefonica I+D Telefonica I+D
Y. Wang Y. Wang
Microsoft Corp. Microsoft Corp.
V. Pascual V. Pascual
Tekelec Consultant
July 11, 2009 July 12, 2010
ALTO Service Discovery ALTO Service Discovery
draft-song-alto-server-discovery-01 draft-song-alto-server-discovery-03
Abstract
Application-Layer Traffic Optimization (ALTO) service aims to provide
distributed applications with information to perform better-than-
random initial peer selection when multiple peers in the network are
available to provide a resource or service. In order to discover an
Application-Layer Traffic Optimization (ALTO) Server, a set of
mechanisms are required. These mechanisms enable applications to
find an information source which provides them with information
regarding the underlying network. This document discusses various
scenarios of ALTO discovery and specifies the use of several
available options such as DHCP or DNS.
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 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). Note that other groups may also distribute
other groups may also distribute working documents as Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts. 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."
The list of current Internet-Drafts can be accessed at This Internet-Draft will expire on January 13, 2011.
http://www.ietf.org/ietf/1id-abstracts.txt.
The list of Internet-Draft Shadow Directories can be accessed at
http://www.ietf.org/shadow.html.
This Internet-Draft will expire on January 12, 2010.
Copyright Notice Copyright Notice
Copyright (c) 2010 IETF Trust and the persons identified as the
Copyright (c) 2009 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
Application-Layer Traffic Optimization (ALTO) service aims to provide described in the Simplified BSD License.
distributed applications with information to perform better-than-
random initial peer selection when multiple peers in the network are
available to provide a resource or service. In order to discover an
Application-Layer Traffic Optimization (ALTO) Server, a set of
mechanisms are required. These mechanisms enable applications to
find an information source which provides them with information
regarding the underlying network. This document discusses various
scenarios of ALTO discovery and specifies the use of several
available options such as DHCP or DNS.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4
1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ALTO Service Deployment . . . . . . . . . . . . . . . . . . . 5 3. ALTO Service Deployment . . . . . . . . . . . . . . . . . . . 5
3.1. ISP-Centric vs. Application-Specific ALTO Service 3.1. ISP-Centric ALTO Service Deployments . . . . . . . . . . . 6
Deployments . . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Cross-domain vs. Localized ALTO Server Discovery . . . . . 7
3.2. Cross-domain vs. Localized ALTO Server Discovery . . . . . 8 4. ALTO Service Discovery Scenarios . . . . . . . . . . . . . . . 7
4. ALTO Service Discovery Scenarios . . . . . . . . . . . . . . . 8 4.1. Discovery Metrics . . . . . . . . . . . . . . . . . . . . 7
4.1. Discovery Metrics . . . . . . . . . . . . . . . . . . . . 8 4.1.1. Discovery Clients . . . . . . . . . . . . . . . . . . 7
4.1.1. Discovery Clients . . . . . . . . . . . . . . . . . . 8 4.1.2. Service Location . . . . . . . . . . . . . . . . . . . 8
4.1.2. Service Location . . . . . . . . . . . . . . . . . . . 9 4.1.3. Layering Perspective . . . . . . . . . . . . . . . . . 8
4.1.3. Layering Perspective . . . . . . . . . . . . . . . . . 9
4.2. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 9 4.2. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 9
4.2.1. Local ALTO service discovery by end terminals . . . . 9 4.2.1. Local ALTO service discovery by end terminals . . . . 9
4.2.2. Local ALTO service discovery by application 4.2.2. Local ALTO service discovery by application
trackers . . . . . . . . . . . . . . . . . . . . . . . 10 trackers . . . . . . . . . . . . . . . . . . . . . . . 10
5. ALTO Service Discovery Mechanisms . . . . . . . . . . . . . . 11 5. ALTO Service Discovery Mechanisms . . . . . . . . . . . . . . 11
5.1. ALTO service discovery using Domain Name System (DNS) . . 12 5.1. ALTO service discovery using Domain Name System (DNS) . . 11
5.1.1. DNS-based ALTO discovery . . . . . . . . . . . . . . . 12 5.1.1. DNS-based ALTO discovery . . . . . . . . . . . . . . . 12
5.1.2. Determine Service Name of Local ALTO servers . . . . . 13 5.1.2. Determine Service Name of Local ALTO servers . . . . . 12
5.1.2.1. Using DHCP option for access domain name . . . . . 13 5.1.2.1. Using DHCP option for access domain name . . . . . 13
5.1.2.2. Use IANA Database . . . . . . . . . . . . . . . . 14 5.1.2.2. Use IANA Database . . . . . . . . . . . . . . . . 13
5.1.2.3. Reverse DNS lookup . . . . . . . . . . . . . . . . 14 5.1.2.3. Reverse DNS lookup . . . . . . . . . . . . . . . . 14
5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.3. XRD . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 5.3. XRD . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
5.4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 15 5.4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 15
5.5. Manual Configuration . . . . . . . . . . . . . . . . . . . 15 5.5. Manual Configuration . . . . . . . . . . . . . . . . . . . 15
5.6. Multicast and broadcast . . . . . . . . . . . . . . . . . 15 5.6. Multicast and broadcast . . . . . . . . . . . . . . . . . 15
5.7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 16 5.7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 16
6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 16
8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17
9.2. Informative References . . . . . . . . . . . . . . . . . . 18 9.2. Informative References . . . . . . . . . . . . . . . . . . 18
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19
1. Introduction 1. Introduction
1.1. History 1.1. History
This document represents a merge of features from two previous This document represents a merge of features from two previous
skipping to change at page 4, line 21 skipping to change at page 4, line 21
(1). draft-wang-alto-discovery-00 (1). draft-wang-alto-discovery-00
(2). draft-song-alto-server-discovery-00 (2). draft-song-alto-server-discovery-00
The ALTO service architecture and protocol are currently under The ALTO service architecture and protocol are currently under
discussion and development within the IETF ALTO working group. discussion and development within the IETF ALTO working group.
Although it is identified in the charter that a discovery mechanism Although it is identified in the charter that a discovery mechanism
is needed, the preference is to adopt one or more existing mechanisms is needed, the preference is to adopt one or more existing mechanisms
for ALTO discovery rather than designing a new one. Note though for ALTO discovery rather than designing a new one. This document is
certain design decisions of the final ALTO framework will affect the consistent with the ALTO framework[I-D.ietf-alto-protocol], and
selection of discovery mechanisms. As a result, this document makes presents different scenarios and available options based on prior and
minimum assumptions of the ALTO framework, and presents different related discovery mechanisms. This document will be updated to track
scenarios and available options based on prior and related discovery the progress of the ALTO requirements and solution.
mechanisms. This document will be updated to track the progress of
the ALTO requirements and solution.
1.2. Overview 1.2. Overview
The ALTO problem statement draft [I-D.ietf-alto-problem-statement] The ALTO problem statement [RFC5693] describes that in P2P
describes that in P2P applications or client/server applications, applications or client/server applications, resources or services are
resources or services are often available through multiple replicas often available through multiple replicas and each of those are
and each of those are sometimes provided by different providers. sometimes provided by different providers. ALTO service gives
ALTO service gives guidance to a consumer or directory about which guidance to a consumer or directory about which resource provider(s)
resource provider(s) to select, in order to optimize the client's to select, in order to optimize the client's performance or quality
performance or quality of experience while optimizing resource of experience while optimizing resource consumption in the underlying
consumption in the underlying network infrastructure. network infrastructure.
In order to query the ALTO server, clients must first know one or In order to query the ALTO server, clients must first know one or
more ALTO servers that might provide useful information. The purpose more ALTO servers that might provide useful information. The purpose
of the ALTO discovery mechanism is to find those servers in different of the ALTO discovery mechanism is to find those servers in different
network and application scenarios. network and application scenarios.
Section 3 and Section 4 discuss various scenarios of ALTO service Section 3 and Section 4 discuss various scenarios of ALTO service
deployment and discovery. Section 5 provides a description of deployment and discovery. Section 5 provides a description of
available discovery mechanisms and its application to the ALTO available discovery mechanisms and its application to the ALTO
service discovery use case addressing potential issues and service discovery use case addressing potential issues and
consideration for each. consideration for each.
2. Terminology 2. Terminology
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].
The document uses terms defined in [I-D.ietf-alto-problem-statement]. The document uses terms defined in [RFC5693].
In addition to the generic ALTO descriptions, the following terms are In addition to the generic ALTO descriptions, the following terms are
used to describe the discovery mechanisms in this document: used to describe the discovery mechanisms in this document:
o ALTO Discovery Client: The logical entity discovering the ALTO o ALTO Discovery Client: The logical entity discovering the ALTO
Service. Depending on the scenario, this could be a Peer or a Super- Service. Depending on the scenario, this could be a Peer or a Super-
peer/Tracker. peer/Tracker.
o ALTO Discovery Server: The logical entity providing information to o ALTO Discovery Server: The logical entity providing information to
locate the ALTO Service. Depending on the discovery mechanism, this locate the ALTO Service. Depending on the discovery mechanism, this
skipping to change at page 6, line 29 skipping to change at page 6, line 29
Legend: Legend:
=== ALTO query protocol === ALTO query protocol
ooo ALTO service discovery protocol ooo ALTO service discovery protocol
*** Application protocol (out of scope) *** Application protocol (out of scope)
... Provisioning or initialization (out of scope) ... Provisioning or initialization (out of scope)
Figure 1 ALTO Discovery Diagram Figure 1 ALTO Discovery Diagram
3.1. ISP-Centric vs. Application-Specific ALTO Service Deployments 3.1. ISP-Centric ALTO Service Deployments
(Haibin: we delete the application-centric ALTO servcie deployment
scenario as to keep consistent with the ALTO framework in the working
group)
An ALTO Server is the logical entity that provides query interfaces An ALTO Server is the logical entity that provides query interfaces
for ALTO Clients. ALTO servers can be deployed in an ISP-centric for ALTO Clients. ALTO servers are deployed in an ISP-centric
deployment or on the application level by application providers or deployment.
other trusted third parties:
1. A network operator which wants to optimize its traffic, e.g. to A network operator which wants to optimize its traffic, e.g. to
reduce its transit traffic volume across the network boundaries; a reduce its transit traffic volume across the network boundaries; a
third party on behalf of one or even several ISPs. third party on behalf of one or even several ISPs.
+-----------+ +-----------+ +---------+ +-----------+ +-----------+ +---------+
|ALTO Server| |ALTO Server| |ALTO | |ALTO Server| |ALTO Server| |ALTO |
| A | | B | |Service | | A | | B | |Service |
+-----------+ +-----------+ |Discovery| +-----------+ +-----------+ |Discovery|
^ ^ +---------+ ^ ^ +---------+
+---+--+ +---+--+ o o +---+--+ +---+--+ o o
+|------|-------------------|------|-+ o o +|------|-------------------|------|-+ o o
skipping to change at page 7, line 23 skipping to change at page 7, line 23
++------+-------------------+------+-+ o ++------+-------------------+------+-+ o
| | | | o | | | | o
++------+-------------------+------+-+ o ++------+-------------------+------+-+ o
|| | P2P Applcation B | | |oooooooo || | P2P Applcation B | | |oooooooo
++------+-------------------+------+-+ ++------+-------------------+------+-+
|ISP A | .............. | ISP B| |ISP A | .............. | ISP B|
+------+ +------+ +------+ +------+
Figure 2: ISP-centric ALTO service deployment example Figure 2: ISP-centric ALTO service deployment example
2. The application provider itself, a trusted third party or a user
community: acting on the application level and spanning different
networks. They run distributed algorithms to measure the overall
network through some mechanisms and provide an ALTO service to
numerous application clients. However in this case, the application
level service may not know the policy of network operators, so with
high probability it will also cause suboptimal result for the network
operator while benefitting the applications.
+---------+
+-----------+ |ALTO |
|ALTO Server| |Service |
+-----------+ |Discovery|
^ ^ +---------+
+------+ | | +------+ o o
+|------|--+---------|------|------|-+ o o
|| | P2P Appication A | | |ooo o
++------+------------+------+------+-+ o
| | | | | o
++------+------------|------+------+-+ o
|| | P2P Applcation B | | |oooooooo
++------+-------------------+------+-+
|ISP A | .............. | ISP B|
+------+ +------+
Figure 3: Application-centric ALTO service deployment example
3.2. Cross-domain vs. Localized ALTO Server Discovery 3.2. Cross-domain vs. Localized ALTO Server Discovery
For cross domain scenarios, the ALTO service includes the ALTO For cross domain scenarios, the ALTO client is embeded in the
servers provided by p2p application community as well as the ALTO application tracker or Resource Directory.
servers provided by a third party on behalf of multiple cooperating
network operators.
So there may be several ALTO servers distributed in different
operator's networks.
Each operator may provide the ALTO service using their own ALTO There may be several ALTO servers distributed in different operator's
servers. Each network operator may have its own traffic optimization networks. Each operator may provide the ALTO service using their own
policy based on his network topology, however it may not know other ALTO servers. Each network operator may have its own traffic
network operator's policies, nor be clear of other network operator's optimization policy based on his network topology, however it may not
topologies (e.g. topology hiding). Each of the ALTO servers may have know other network operator's policies, nor be clear of other network
a FQDN. operator's topologies (e.g. topology hiding). Each of the ALTO
servers may have a FQDN.
The ALTO client (e.g. the Tracker) must be able to discover and The ALTO client (e.g. the Tracker) must be able to discover and
choose the ALTO server that has the information that is specific to choose the ALTO server that has the information that is specific to
those clients located within that network. those clients located within that network.
In localized discovery deployments one or several ALTO servers In localized discovery deployments one or several ALTO servers
provide the service only to clients in their own network or provide the service only to clients in their own network or
autonomous system. autonomous system.
4. ALTO Service Discovery Scenarios 4. ALTO Service Discovery Scenarios
4.1. Discovery Metrics 4.1. Discovery Metrics
4.1.1. Discovery Clients 4.1.1. Discovery Clients
The ALTO Client can be the Peer in the end-user host or an external The ALTO Client can be the Peer in the end-user host or an external
entity like a Super-peer or Resource Directory (aka Tracker) on entity like a Super-peer or Resource Directory (aka Tracker) on
behalf of the Peer [I-D.ietf-alto-problem-statement]. If a Super- behalf of the Peer [RFC5693]. If a Super-Peer or Tracker acts as an
Peer or Tracker acts as an ALTO Client it needs to know and select ALTO Client it needs to know and select the suitable ALTO Service for
the suitable ALTO Service for the Peer being served. the Peer being served. Possible mechanisms for third party ALTO
discovery have been proposed in[I-D.kiesel-alto-3pdisc]
In a hybrid model the location of the ALTO Server could be In a hybrid model the address info of the ALTO Server could be
communicated from the Peer to the Super-Peer using the application communicated from the Peer to the Super-Peer using the application
protocol. It could also be discovered by the Super-Peer from other protocol. It could also be discovered by the Super-Peer from other
Peer information received implicitly (like the Peer public IP Peer information received implicitly (like the Peer public IP
address) or received explicitly. address) or received explicitly.
There could be scenarios where only the Peer (and not the Super-Peer/ There could be scenarios where only the Peer (and not the Super-Peer/
Tracker) is able to access the ALTO Service, for example if the ALTO Tracker) is able to access the ALTO Service, for example if the ALTO
Server is located in a private network. Server is located in a private network. Also the ALTO server might
not allow requests from the IP addresses that are out of its
administrative domain.
4.1.2. Service Location 4.1.2. Service Location
The ALTO service could be provided in a distributed and cooperative The ALTO service is provided by a centralized entity (the ALTO
fashion by the Peers in an overlay, or it can be provided by a Server) for a given scope. A centralized ALTO Server is implicitly
centralized entity (the ALTO Server) for a given scope. In the or explicitly assigned to a specific network scope, an out-of-band
former case, a DHT-style key-based routing algorithm could be used to discovery mechanism is often required.
locate the peers with the target network information in this type of
distributed environment. For the latter case, where a centralized
ALTO Server is implicitly or explicitly assigned to a specific
network scope, an out-of-band discovery mechanism is often required.
All current ALTO solution proposals, ([Infoexp],
[I-D.wang-alto-p4p-specification]), fall into the second category.
The ALTO Server for a Peer could be in the same Local Area Network The ALTO Server for a Peer could be in the same Local Area Network
(LAN), within the same ISP Network but not on the same LAN, or in the (LAN), within the same ISP Network but not on the same LAN, or in the
Global Internet outside the ISP Network. Different network scopes Global Internet outside the ISP Network. Different network scopes
place different constraints on the discovery mechanisms. Multicast place different constraints on the discovery mechanisms. Multicast
discovery generally works within a single LAN only, whereas DNS-based discovery generally works within a single LAN only, whereas DNS-based
or DHCP-based discovery can span multiple subnets within a single ISP or DHCP-aabased discovery can span multiple subnets within a single
or a single network administrative domain. Internet scope discovery ISP or a single network administrative domain. Internet scope
usually requires cross-domain indexing or directory services. Note discovery usually requires cross-domain indexing or directory
that peers participating in a single P2P application may reside on services. Note that peers participating in a single P2P application
the same or different ISP networks. Scenarios like this may require may reside on the same or different ISP networks. Scenarios like
hybrid discovery solutions that can adapt to multiple network scopes this may require hybrid discovery solutions that can adapt to
at the same time. The discovery mechanisms listed in this document multiple network scopes at the same time. The discovery mechanisms
should take into account possible limitations of the ALTO service listed in this document should take into account possible limitations
deployment in those network scopes. of the ALTO service deployment in those network scopes.
4.1.3. Layering Perspective 4.1.3. Layering Perspective
The discovery process takes place before the first access to the ALTO The discovery process takes place before the first access to the ALTO
server. This discovery process could be done at host network server. This discovery process could be done at host network
initialization time, at application initialization time or just initialization time, at application initialization time or just
before the first ALTO query is sent. before the first ALTO query is sent.
4.2. Discovery Scenarios 4.2. Discovery Scenarios
The ALTO service discovery scenarios are classified into two types: The ALTO service discovery scenarios are classified into two types:
one is the ALTO server providing service to the overall network, and one is the ALTO server discovery by end terminals, and the other is
the other is where the ALTO server is providing service to the local the ALTO server discovery by application trackers.
network.
4.2.1. Local ALTO service discovery by end terminals 4.2.1. Local ALTO service discovery by end terminals
In p2p applications without a tracker like DHTs and other In p2p applications without a tracker like DHTs and other
conventional client/server applications, an end device needs to conventional client/server applications, an end device needs to
discover the local ALTO server by itself. discover the local ALTO server by itself.
P2P application which has tracker(s) may also embed the ALTO client
within the peers . And the peers can do the remote peer selection
after retrieving peer list from the application tracker. Or the peer
can send its ALTO server address information to the application
tracker, and the application tracker will contact the specific ALTO
server and do the peer selection for peers.
After the discovery of an ALTO server, the p2p client can get After the discovery of an ALTO server, the p2p client can get
guidance from the ALTO server directly or through its application guidance from the ALTO server directly or through its application
tracker. tracker.
+---------------+ +---------------+
| ALTO Server | | ALTO Server |
+---------------+ +---------------+
^ ^ +-----------+ ^ ^ +-----------+
| | | ALTO | | | | ALTO |
| +---+---+ | Service | | +---+---+ | Service |
skipping to change at page 10, line 28 skipping to change at page 9, line 47
+------------+--+ | o o +------------+--+ | o o
|P2P Application|ooooo|oooooooooooo o |P2P Application|ooooo|oooooooooooo o
| Client A | | o | Client A | | o
+---------------+ | o +---------------+ | o
| o | o
+--+-------------+ o +--+-------------+ o
| P2P Application|oooooo | P2P Application|oooooo
| Client B | | Client B |
+----------------+ +----------------+
Figure 4: Local ALTO service discovery by end terminals (Example) Figure 3: Local ALTO service discovery by end terminals (Example)
4.2.2. Local ALTO service discovery by application trackers 4.2.2. Local ALTO service discovery by application trackers
Some p2p applications have trackers, and these applications don't Some p2p applications have trackers, and these applications might not
need to have their clients looking for the ALTO server guidance. need to have their clients looking for the ALTO server guidance.
Trackers query the ALTO servers for guidance, and then return the Trackers query the ALTO servers for guidance, and then return the
final ranked result to the application clients. However, application final ranked result to the application clients. However, application
clients are distributed among different network operators and clients are distributed among different network operators and
autonomous systems. Trackers must find different ALTO servers for autonomous systems. Trackers must find different ALTO servers for
the clients located in different network operators or autonomous the clients located in different network operators or autonomous
systems. systems.
Figure 5 shows an example for a tracker's ALTO server discovery. For Figure 4 shows an example for a tracker's ALTO server discovery. For
client 1, the tracker has not cached yet the mapping between client client 1, the tracker has not cached yet the mapping between client
1's network operator and its ALTO server address, so it queries the 1's network operator and its ALTO server address, so it queries the
DNS server for the ALTO server address in that operator's domain. DNS server for the ALTO server address in that operator's domain.
And then the tracker interacts with the ALTO server on behalf of And then the tracker interacts with the ALTO server on behalf of
client 1, finally, the ranked list is sent back to client 1. For client 1(to get the network map and cost map), finally, the ranked
client 2, the tracker has cached the mapping between client 2's list is sent back to client 1. For client 2, the tracker has cached
network operator and its ALTO server address, so it does not need to the mapping between client 2's network operator and its ALTO server
query the DNS for the address of ALTO server 2. address, so it does not need to query the DNS for the address of ALTO
server 2. If the Application tracker already has the network map and
cost map from ALTO Server2, then it does not to query the ALTO Server
for network map and cost map frequently.
+-------------+ +-------------+ +-------------+ +-------------+
| ALTO Server1| | ALTO Server2| | ALTO Server1| | ALTO Server2|
+-------------+ +-------------+ +-------------+ +-------------+
^ | ^ | ^ | ^ |
3| 4| b| |c 3| 4| b| |c
| | | | | | | |
v /----------+-\ v v /----------+-\ v
+---+ ////// \\\\\ +---+ ////// \\\\\
| | ||| ||| | | ||| |||
skipping to change at page 11, line 27 skipping to change at page 10, line 51
| | \\\\\\ ///// | | \\\\\\ /////
+---+ ^ | \------------/ | +---+ ^ | \------------/ |
| |5 ^ |d | |5 ^ |d
1| | a| | 1| | a| |
| v | v | v | v
+-+---------+ +---+--------+ +-+---------+ +---+--------+
|Application| |Application | |Application| |Application |
|client1 | |client2 | |client1 | |client2 |
+-----------+ +------------+ +-----------+ +------------+
Figure 5: Local ALTO service discovery by application trackers (Example) Figure 4: Local ALTO service discovery by application trackers (Example)
5. ALTO Service Discovery Mechanisms 5. ALTO Service Discovery Mechanisms
One ALTO client should use one or several of the introduced discovery One ALTO client should use one or several of the introduced discovery
mechanisms according to its application scenario until it finally mechanisms according to its application scenario until it finally
finds an appropriate ALTO server. finds an appropriate ALTO server.
The following issues should be considered when designing the ALTO The following issues should be considered when designing the ALTO
service discovery mechanism. service discovery mechanism.
skipping to change at page 12, line 37 skipping to change at page 12, line 12
application of these resource records depends on the final ALTO application of these resource records depends on the final ALTO
requests/response protocol. The use of NAPTR or SRV records is a requests/response protocol. The use of NAPTR or SRV records is a
trade-off between flexibility and simplicity. S-NAPTR [RFC3958] and trade-off between flexibility and simplicity. S-NAPTR [RFC3958] and
U-NAPTR [RFC4848] mechanisms provide a Dynamic Delegation Discovery U-NAPTR [RFC4848] mechanisms provide a Dynamic Delegation Discovery
System (DDDS) Application to map domain name, service name and System (DDDS) Application to map domain name, service name and
protocol name to a target host and port or to a target URI. SRV protocol name to a target host and port or to a target URI. SRV
records provide a mechanism to map domain name, service name and records provide a mechanism to map domain name, service name and
transport protocol name to a target host and port. The use of a transport protocol name to a target host and port. The use of a
NAPTR or SRV solution is open to discussion and depends on the NAPTR or SRV solution is open to discussion and depends on the
requirements of the ALTO protocol. Next section will asume the use requirements of the ALTO protocol. Next section will asume the use
use of SRV records in the next sections are based on SRV. of SRV records.
5.1.1. DNS-based ALTO discovery 5.1.1. DNS-based ALTO discovery
Figure 6. shows a general DNS ALTO server discovery mechanism. A Figure 5. shows a general DNS ALTO server discovery mechanism. A
server must register its SRV resource record with a well known server must register its SRV resource record with a well known
service name (e.g. _ALTO._TCP.example.com) in the DNS system. The service name (e.g. _ALTO._TCP.example.com) in the DNS system. The
service name in this document refers to the name used for DNS SRV service name in this document refers to the name used for DNS SRV
query, which includes the service label, protocol name (TCP or UDP) query, which includes the service label, protocol name (TCP or UDP)
and domain name. Any ALTO client that wants to get the IP address and domain name. Any ALTO client that wants to get the IP address
and port of the ALTO server sends a DNS SRV query to the DNS server and port of the ALTO server sends a DNS SRV query to the DNS server
in that domain . in that domain .
+-------------------------------------+ +-------------------------------------+
| DNS | | DNS |
skipping to change at page 13, line 21 skipping to change at page 12, line 41
|DNS configuration |DNS queries |DNS configuration |DNS queries
|or dynamic update |and responses |or dynamic update |and responses
| | | |
v v v v
+-------------+ +-------------+ +-------------+ +-------------+
| | | ALTO | | | | ALTO |
| ALTO Server | | Discovery | | ALTO Server | | Discovery |
| | | Client | | | | Client |
+-------------+ +-------------+ +-------------+ +-------------+
Figure 6: DNS query for well known ALTO servers Figure 5: DNS query for well known ALTO servers
5.1.2. Determine Service Name of Local ALTO servers 5.1.2. Determine Service Name of Local ALTO servers
An ALTO discovery client must know its ALTO service name for it An ALTO discovery client must know its ALTO service name for it
before sending a query to the DNS system. Some ALTO servers may before sending a query to the DNS system. Some ALTO servers may
provide service to the overall network, they may have well-known provide service to the overall network, they may have well-known
service name. But in most cases, one ALTO server will only provide service name. But in most cases, one ALTO server will only provide
service to its own local access network or autonomous system. There service to its own local access network or autonomous system. There
will be multiple ALTO servers in the overall network. An ALTO will be multiple ALTO servers in the overall network. An ALTO
discovery client needs to find the service name of its local ALTO discovery client needs to find the service name of its local ALTO
skipping to change at page 15, line 19 skipping to change at page 14, line 42
port information directly. New DHCP options are needed for this port information directly. New DHCP options are needed for this
purpose. The residential gateways consideration for DHCP option must purpose. The residential gateways consideration for DHCP option must
be considered as described in . (Section 5.1.2.1) be considered as described in . (Section 5.1.2.1)
With this mechanism, the DHCP server needs to support load balance if With this mechanism, the DHCP server needs to support load balance if
there are more than one ALTO servers for this access domain. The there are more than one ALTO servers for this access domain. The
maintenance is costly when the address of ALTO server changes. maintenance is costly when the address of ALTO server changes.
5.3. XRD 5.3. XRD
XRD is described in [XRD-1.0]. In order to begin the XRD discovery XRD is described in [XEP-1.0]. In order to begin the XRD discovery
you need the URL (or XRI) of the resource you want to discover links/ you need the URL (or XRI) of the resource you want to discover links/
services related to. In other XRD use cases like OpenId or services related to. In other XRD use cases like OpenId or
OpenSocial, it is clear that you know that URL (the OpenId url of the OpenSocial, it is clear that you know that URL (the OpenId url of the
user, or the url of the OS container). But in case of ALTO Server user, or the url of the OS container). But in case of ALTO Server
Discovery, the obtainment of this initial URL also needs to use some Discovery, the obtainment of this initial URL also needs to use some
discovery framework. discovery framework.
5.4. Provisioning 5.4. Provisioning
A network operator can simply provide a configuration file that A network operator can simply provide a configuration file that
skipping to change at page 17, line 15 skipping to change at page 16, line 37
7. IANA Considerations 7. IANA Considerations
The service label for the ALTO service will depend on the final The service label for the ALTO service will depend on the final
protocol name for application-layer traffic optimization(TBD). protocol name for application-layer traffic optimization(TBD).
8. Acknowledgements 8. Acknowledgements
The authors would like to give special thanks to Roni Even for his The authors would like to give special thanks to Roni Even for his
continuous contribution to this document. continuous contribution to this document.
We would also like to thank the following experts for their review We would also like to thank the following experts for their
and valuable comments. contribution.
Sebastian Kiesel
Yunfei Zhang
Y. Richard Yang Y. Richard Yang
Xingfeng Jiang Xingfeng Jiang
Jay Gu Jay Gu
Ning Zong Ning Zong
(To be added) David Bryan
Enrico Marocco
9. References 9. References
9.1. Normative References 9.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.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782, specifying the location of services (DNS SRV)", RFC 2782,
February 2000. February 2000.
[RFC3958] Daigle, L. and A. Newton, "Domain-Based Application [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application
Service Location Using SRV RRs and the Dynamic Delegation Service Location Using SRV RRs and the Dynamic Delegation
Discovery Service (DDDS)", RFC 3958, January 2005. Discovery Service (DDDS)", RFC 3958, January 2005.
[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
Optimization (ALTO) Problem Statement", RFC 5693,
October 2009.
[RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer
(NAPTR) DNS Resource Record", RFC 2915, September 2000. (NAPTR) DNS Resource Record", RFC 2915, September 2000.
[I-D.ietf-alto-problem-statement] [I-D.ietf-alto-protocol]
Seedorf, J. and E. Burger, "Application-Layer Traffic Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
Optimization (ALTO) Problem Statement", draft-ietf-alto-protocol-04 (work in progress), May 2010.
draft-ietf-alto-problem-statement-02 (work in progress),
July 2009.
[I-D.ietf-geopriv-lis-discovery] [I-D.ietf-geopriv-lis-discovery]
Thomson, M. and J. Winterbottom, "Discovering the Local Thomson, M. and J. Winterbottom, "Discovering the Local
Location Information Server (LIS)", Location Information Server (LIS)",
draft-ietf-geopriv-lis-discovery-11 (work in progress), draft-ietf-geopriv-lis-discovery-15 (work in progress),
May 2009. March 2010.
[I-D.ietf-dhc-container-opt] [I-D.ietf-dhc-container-opt]
Droms, R., "Container Option for Server Configuration", Droms, R., "Container Option for Server Configuration",
draft-ietf-dhc-container-opt-05 (work in progress), draft-ietf-dhc-container-opt-05 (work in progress),
March 2009. March 2009.
9.2. Informative References 9.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999. June 1999.
skipping to change at page 18, line 36 skipping to change at page 18, line 22
Text on Security Considerations", BCP 72, RFC 3552, Text on Security Considerations", BCP 72, RFC 3552,
July 2003. July 2003.
[RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan, [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan,
"Service Location Protocol", RFC 2165, June 1997. "Service Location Protocol", RFC 2165, June 1997.
[RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local
Multicast Name Resolution (LLMNR)", RFC 4795, Multicast Name Resolution (LLMNR)", RFC 4795,
January 2007. January 2007.
[I-D.kiesel-alto-3pdisc]
Kiesel, S., Tomsu, M., Schwan, N., Scharf, M., and M.
Stiemerling, "Third-party ALTO server discovery",
draft-kiesel-alto-3pdisc-03 (work in progress), July 2010.
[I-D.cheshire-dnsext-multicastdns] [I-D.cheshire-dnsext-multicastdns]
Cheshire, S. and M. Krochmal, "Multicast DNS", Cheshire, S. and M. Krochmal, "Multicast DNS",
draft-cheshire-dnsext-multicastdns-07 (work in progress), draft-cheshire-dnsext-multicastdns-11 (work in progress),
September 2008. March 2010.
[I-D.wang-alto-p4p-specification] [I-D.wang-alto-p4p-specification]
Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang,
"P4P Protocol Specification", "P4P Protocol Specification",
draft-wang-alto-p4p-specification-00 (work in progress), draft-wang-alto-p4p-specification-00 (work in progress),
March 2009. March 2009.
[I-D.narten-iana-considerations-rfc2434bis] [I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", IANA Considerations Section in RFCs",
skipping to change at page 19, line 27 skipping to change at page 19, line 19
[XEP-1.0] Hammer-Lahav, E., "Extensible Resource Descriptor (XRD) [XEP-1.0] Hammer-Lahav, E., "Extensible Resource Descriptor (XRD)
Version 1.0", May 2009, <http://www.oasis-open.org/ Version 1.0", May 2009, <http://www.oasis-open.org/
committees/download.php/32686/xrd-1.0-wd01.html>. committees/download.php/32686/xrd-1.0-wd01.html>.
[WSD] Beatty, J., "Web Services Dynamic Discovery (WS- [WSD] Beatty, J., "Web Services Dynamic Discovery (WS-
Discovery)", April 2005, <http://specs.xmlsoap.org/ws/ Discovery)", April 2005, <http://specs.xmlsoap.org/ws/
2005/04/discovery/ws-discovery.pdf>. 2005/04/discovery/ws-discovery.pdf>.
Authors' Addresses Authors' Addresses
Song Haibin (editor) Haibin Song
Huawei Huawei
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
P.R.China
Email: melodysong@huawei.com Email: melodysong@huawei.com
Marco Tomsu (editor) Marco Tomsu
Alcatel-lucent Bell Labs Alcatel-lucent Bell Labs
Lorenzstrasse 10 Lorenzstrasse 10
70435 Stuttgart 70435 Stuttgart
Germany Germany
Email: marco.tomsu@alcatel-lucent.com Email: marco.tomsu@alcatel-lucent.com
URI: www.alcatel-lucent.com/bell-labs URI: www.alcatel-lucent.com/bell-labs
Gustavo Garcia Gustavo Garcia
Telefonica I+D Telefonica I+D
Emilio Vargas Emilio Vargas
Madrid, Madrid Madrid, Madrid
Spain Spain
Phone: +34 913129826 Phone: +34 913129826
Email: ggb@tid.es Email: ggb@tid.es
Yu-Shun Wang Yu-Shun Wang
Microsoft Corp. Microsoft Corp.
One Microsoft Way One Microsoft Way
Redmond, WA 98052 Redmond, WA 98052
USA USA
Email: yu-shun.wang@microsoft.com Email: yu-shun.wang@microsoft.com
Victor Pascual Victor Pascual
Tekelec Consultant
Am Borsigturm 11
Berlin D-13507
Germany
Phone: +49 30 32 51 32 12 Email: victor.pascual.avila@gmail.com
Email: victor@iptel.org
 End of changes. 56 change blocks. 
176 lines changed or deleted 153 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/