ALTO H. Song, Ed.
Internet-Draft Huawei
Intended status: Standards Track R. Even
Expires: September 3, 2009 Gesher Erove
V. Pascual
Tekelec
Y. Zhang
China Mobile
March 2, 2009
Application-Layer Traffic Optimization (ALTO): Discover ALTO Servers
draft-song-alto-server-discovery-00
Status of this Memo
This Internet-Draft is submitted to IETF in full conformance with the
provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF), its areas, and its working groups. Note that
other groups may also distribute working documents as Internet-
Drafts.
Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress."
The list of current Internet-Drafts can be accessed at
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 September 3, 2009.
Copyright Notice
Copyright (c) 2009 IETF Trust and the persons identified as the
document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents in effect on the date of
publication of this document (http://trustee.ietf.org/license-info).
Please review these documents carefully, as they describe your rights
and restrictions with respect to this document.
Song, et al. Expires September 3, 2009 [Page 1]
Internet-Draft ALTO Server Discovery March 2009
Abstract
A set of mechanisms are required to discover an Application-Layer
Traffic Optimization (ALTO) Server. These mechanisms enable
applications to find a reliable information source which provides
them with information regarding the underlying network. By providing
this information it would be possible to greatly increase application
performance, reduce congestion and optimize the overall traffic
across different networks. This document specifies the use of
general means such as DHCP, DNS or static configuration for ALTO
server discovery.
Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3
1.2. ALTO server distribution . . . . . . . . . . . . . . . . . 3
1.3. Concerns of ALTO server discovery . . . . . . . . . . . . 4
2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4
3. ALTO server discovery using Domain Name System (DNS) . . . . . 5
3.1. ALTO servers providing service to overall network . . . . 5
3.2. ALTO servers providing service to local networks . . . . . 6
3.2.1. ALTO server discovery by end terminals . . . . . . . . 6
3.2.2. ALTO server discovery by application trackers . . . . 9
4. Other ALTO server discovery mechanisms . . . . . . . . . . . . 11
4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 11
4.2. Manual Configuration . . . . . . . . . . . . . . . . . . . 11
4.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 12
4.4. ALTO server discovery using DHCP . . . . . . . . . . . . . 12
5. Security Considerations . . . . . . . . . . . . . . . . . . . 12
6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12
7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12
8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12
8.1. Normative References . . . . . . . . . . . . . . . . . . . 12
8.2. Informative References . . . . . . . . . . . . . . . . . . 13
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13
Song, et al. Expires September 3, 2009 [Page 2]
Internet-Draft ALTO Server Discovery March 2009
1. Introduction
1.1. Background
The ALTO problem statement draft [I-D.marocco-alto-problem-statement]
describes that in P2P applications or client/server applications,
resources are often available through multiple replicas and each of
those are sometimes provided by different service providers. ALTO
service gives guidance to a resource consumer or resource directory,
like p2p tracker or ALTO service proxy, about which resource
provider(s) to select, in order to optimize the client's performance
or quality of experience while optimizing resource consumption in the
underlying network infrastructure.
1.2. ALTO server distribution
An ALTO server is a logical entity that provides interfaces to query
the alto service. ALTO servers can be deployed by :
(1) A network operator which wants to optimize its traffic, e.g.
reduce its transit traffic across the network boundaries;
(2) A third party on behalf of one or more ISPs;
(3) user communities which run distributed algorithms, however, in
this case, the user community may not know the policy of network
operators, so with high probability it will also cause the
suboptimal result for the network operator while benefiting the
applications;
So there may be different ALTO servers distributed in different
operator's networks.
For (1), each network operator may provide the ALTO service using
their own ALTO servers. Each network operator may have its own
traffic optimization policy based on his network topology, however it
may not know other network operator's policies, nor be clear of other
network operator's topologies (e.g. topology hiding). The
application client must choose the ALTO service from the ALTO server
that has information about its local network topology and policy. So
in this case, each ALTO server must only provide service to the
clients in its own network. A request from a client to an ALTO
server not in its own operator's network may cause suboptimal result,
because that ALTO server does not observe the network from the
client's point of view. So each network operator deploys one or more
ALTO servers for clients in its own network. If it is a large ISP,
it may also deploy one or more ALTO servers for its sub networks,
such as autonomous systems (AS).
Song, et al. Expires September 3, 2009 [Page 3]
Internet-Draft ALTO Server Discovery March 2009
For (2), if a third party provides ALTO service on behalf of only one
ISP, it is similar to (1).
If a third party provides ALTO service on behalf of many ISPs, or a
user community which measures the overall network through some
mechanisms and provides ALTO service to numerous application clients
located in different network operators, the case is equal to a
conventional internet application server providing service to
application clients.
This document describes the ALTO server discovery mechanisms for both
environments where an ALTO server provides service to the overall
network or an ALTO server provides service only to its local network
1.3. Concerns of ALTO server discovery
The following issues should be considered when designing the ALTO
server discovery mechanism.
Load Balance: When more than one ALTO server provide identical
service for the same area, we must find a mechanism to balance the
processing load between the ALTO servers;
Well known port: If ALTO server provides service through a well
known port, then the discovery mechanism only needs to discover
the IP address of an ALTO server that can provide service for a
client, otherwise, the discovery mechanism must discover both IP
address and port number through which the ALTO server provides the
service.
IP address change: The IP address of the ALTO server may change in
some circumstances. The ALTO server discovery mechanism must be
well adaptable to this case when necessary.
Mobile Scenarios: When the end terminals are mobile equipments,
the data traffic may route via a roaming client's home agent's
router to the client, or route to the client directly. Which ALTO
server to choose should depend on the routing optimization mode
adopted for mobility. If the data traffic routes via the client's
home agent, it should choose the ALTO server that serves its home
area network, otherwise, it should choose the ALTO server that
serves its current network.
2. Terminology
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
Song, et al. Expires September 3, 2009 [Page 4]
Internet-Draft ALTO Server Discovery March 2009
document are to be interpreted in BCP 14, RFC 2119 [RFC2119] and
indicate requirement levels for compliant implementations.
Other terms used in this document are compatible with the definitions
in "ALTO problem statement" draft
[I-D.marocco-alto-problem-statement].
3. ALTO server discovery using Domain Name System (DNS)
ALTO service is a conventional client/server mode service. The ALTO
server discovery scenarios are classified into two types: one is the
ALTO server providing service to overall network, and the other is
ALTO server providing service to the local network.
3.1. ALTO servers providing service to overall network
The ALTO servers providing service to overall network include the
ALTO servers provided by p2p application community and the ALTO
servers provided by third party for multiple network operators.
As shown in Figure 1. A simple ALTO server discovery mechanism is
used for this type of ALTO server. A DNS SRV query
[RFC2782]mechanism is used. The 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 in this
document refers to the name used for DNS SRV 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 port of the ALTO
server sends a DNS SRV query to the DNS server in that domain .
Song, et al. Expires September 3, 2009 [Page 5]
Internet-Draft ALTO Server Discovery March 2009
+-------------------------------------+
| |
| DNS |
| |
+-------------------------------------+
^ ^
| |
| |
|DNS configuration |DNS queries
|or dynamic update |and responses
| |
v v
+-------------+ +-------------+
| | | |
| | | |
| ALTO Server | | ALTO Client |
| | | |
+-------------+ +-------------+
Figure 1: DNS query for well known ALTO servers
3.2. ALTO servers providing service to local networks
In this environment, one or several ALTO servers provide service to
their own network or autonomous system. There will be multiple ALTO
servers in the overall network. Each of the ALTO server may have a
FQDN. However, an end terminal can't easily determine its ALTO
server automatically.
3.2.1. ALTO server discovery by end terminals
In p2p applications without a tracker like DHTs and other
conventional client/server applications, an end user needs to
discover the ALTO server by itself. It should follow these steps:
(1) Through DHCP configuration, an end terminal retrieves the DNS
SRV service name for local ALTO servers which includes the service
provider's domain information, e.g. _ALTO._TCP.MyISP.com. A new
DHCP Option for the ALTO server discovery is needed.
Song, et al. Expires September 3, 2009 [Page 6]
Internet-Draft ALTO Server Discovery March 2009
The DHCPv4 ALTO_SRV_Name option has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Code | len | |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ .
. DNS SRV service name for local ALTO servers .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Code ALTO_SRV_Name_V4 (TBDv4)
len Length of DNS SRV service name for ALTO server, in octets
The DHCPv6 ALTO_SRV_Name option has the following format:
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| OPTION_ALTO_SRV_Name_V6 | option-len |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| DNS SRV service name for local ALTO servers |
. .
. .
. .
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
option-code OPTION_ALTO_SRV_Name_V6 (TBDv6).
option-len Length of DNS SRV service name for ALTO server, in octets
Once the ALTO server's service name is retrieved, the end terminal
should cache this service name for later use.
It should be noticed that there are many residential gateways (RG)
which can act as DHCP servers themselves. RG becomes a hindrance
between the end terminals and the ALTO service provider's DHCP
server if we use DHCP. It should not depend on the update of all
these RGs to support this new DHCP Option for ALTO server
discovery. A DHCP Container Option [I-D.ietf-dhc-container-opt]
for server configuration must be used here. With the Container
Option, the DHCP server for the consumer domain (e.g. RGs) can
just pass the server configuration to the end terminals without
explicit knowledge of the DHCP options contained in the Container.
The DHCP Option for the ALTO service name should be contained in
Song, et al. Expires September 3, 2009 [Page 7]
Internet-Draft ALTO Server Discovery March 2009
the Container Option.
(2) The end terminal sends an SRV query to the DNS server with the
service name. It will retrieve the SRV RR with ALTO server
instance name and port information, maybe together with a TXT
description RR and an A RR with the IP address of the ALTO server.
However, an additional A query is needed if the A RR corresponding
to the ALTO server instance is not retrieved at the same time.
Eventually the end terminal will get the IP address and port of
the ALTO server. If there are more than one ALTO servers in the
domain, the DNS server must balance the load between the ALTO
servers according to the "priority" and "weight" value in the
corresponding SRV RRs. Once the transport address of the ALTO
server is retrieved, the end terminal should cache it for later
use.
(3) The end terminal than accesses the ALTO server to get service;
Here DHCP protocol is used to retrieve the service name instead of
the IP address because the IP address may change and the
configuration for the DHCP server is very troublesome. Besides that,
with the DNS SRV query, its existing load balance mechanism can be
used, instead of introducing a new load balance mechanism in DHCP
server.
The following Figure 2 and Figure 3 depicts the first and second step
of the ALTO server discovery for end terminals.
+-------------+
| |
| DHCP Server |
| |
+-------------+
^
|
|
|use DHCP to
|retrieve local ALTO
|service name
v
+-------------+
| |
| Client |
| |
+-------------+
Step 1: retrieving service name
Song, et al. Expires September 3, 2009 [Page 8]
Internet-Draft ALTO Server Discovery March 2009
Figure 2: retrieving service name with DHCP
+-------------+
| |
| DNS Server | Load Balance
| |
+-------------+
^
|SRV and other queries
|to retrieve ALTO
|server address info
|
|
v
+-------------+
| |
| Client |
| |
+-------------+
Step 2: DNS query for ALTO server address info
Figure 3: retrieving ALTO server address with DNS
3.2.2. ALTO server discovery by application trackers
Some p2p applications have trackers, and these applications don't
need to have their clients looking for the ALTO server guidance.
Trackers query the ALTO servers for guidance, and then return the
final ranked result to the application clients. However, application
clients are distributed among different network operators and
autonomous systems. Trackers must find different ALTO servers for
the clients located in different network operators or autonomous
systems.
Here are the steps for ALTO server discovery in this type of
scenarios:
(1) The tracker should determine to which physical location the
corresponding application client belongs to, i.e. which network
operator and/or autonomous system the application client belongs
to. The subsidiary organizations (e.g. APNIC) of IANA have the
information database for the mapping between IP range to ISP/AS or
other organizations. The WHOIS service [WWW.WHOIS] on the
Internet is also available for this purpose. However, the mapping
information may be changed due to the business deals and network
adjustment. DHCP can also be used to retrieve the ISP/AS
information to the end user, and the tracker can collect the
Song, et al. Expires September 3, 2009 [Page 9]
Internet-Draft ALTO Server Discovery March 2009
information from its clients.
(2) The tracker must determine the ALTO server for the
corresponding network operator and or/ autonomous system. The
tracker should maintain a complete mapping table between (a) the
identities of network operators and/or autonomous systems and (b)
ALTO server service names. The tracker sends a SRV query to the
DNS server (an additional A query is needed when SRV query only
responds with ALTO server instance name) to retrieve the ALTO
server address information for its application client. From the
perspective of efficiency, the tracker should cache the mapping
information between network operators and ALTO server addresses
for later use.
(3) The tracker contacts with the ALTO server for guidance on
behalf of the application client; and sends the final ranked peer
list to the application client.
Figure 4 shows an example for tracker's ALTO server discovery. For
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
DNS server for the ALTO server address in that operator's domain.
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 2, the tracker has cached the mapping between client 2's
network operator and its ALTO server address, so it does not need to
query the DNS for the address of ALTO server 2.
Song, et al. Expires September 3, 2009 [Page 10]
Internet-Draft ALTO Server Discovery March 2009
+-------------+ +-------------+
| | | |
| ALTO Server1| | ALTO Server2|
| | | |
+-------------+ +-------------+
^ | ^ |
| | | |
3| 4| b| |c
| | | |
| | | |
v /---------------+-\ v
+------+ ////// \\\\\\
| | ||| |||
| |<----->| ||
| DNS | 2 | Application Tracker |
| | ||| |||
| | \\\\\\ //////
+------+ ^ | \-----------------/ |
| | ^ |
| |5 | |d
1| | a| |
| | | |
| v | v
+-+-----------+ +---+---------+
| | | |
|Application | |Application |
|client1 | |client2 |
+-------------+ +-------------+
Figure 4: Example for tracker's ALTO discovery
4. Other ALTO server discovery mechanisms
4.1. Provisioning
A network operator can simply provide a configuration file that
contains the ALTO server address for its clients, provided that there
are only one or a few ALTO servers which provide identical service
for its network. An application can also provide such a
configuration file containing the ALTO server address if an existing
ALTO server provides identical service to the overall network.
4.2. Manual Configuration
ALTO server information could also be configured on the ALTO client
by a user or service provider manually.
Song, et al. Expires September 3, 2009 [Page 11]
Internet-Draft ALTO Server Discovery March 2009
4.3. Caching
Once a client has located an ALTO server for the first time, it can
cache it for use as future ALTO server.
4.4. ALTO server discovery using DHCP
An ALTO client can discover an ALTO server through auto-configuration
protocols. A new option could be defined in DHCP protocol to
retrieve the IP address of local ALTO servers directly. However, it
has drawbacks as described in Section 3.2.1.
5. Security Considerations
As this document mainly proposes to use DNS and DHCP for ALTO service
discovery, it will depend on the DHCP security and DNS security for
this service discovery.
6. IANA Considerations
The service label for the ALTO service will depend on the final
protocol name for application-layer traffic optimization(TBD).
This document requests IANA to assign an option tag from the "BOOTP
Vendor Extensions and DHCP Options" registry for ALTO_SRV_Name_V4
(TBDv4).
This document requests IANA to assign an option code from the "DHCPv6
Option Codes" registry for OPTION_ALTO_SRV_Name_V6 (TBDv6).
7. Acknowledgements
The authors thank the review and valuable comments from Y. Richard
Yang, Xingfeng Jiang, Jay Gu and Ning Zong.
8. References
8.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for
specifying the location of services (DNS SRV)", RFC 2782,
Song, et al. Expires September 3, 2009 [Page 12]
Internet-Draft ALTO Server Discovery March 2009
February 2000.
[I-D.marocco-alto-problem-statement]
Seedorf, J. and E. Burger, "Application-Layer Traffic
Optimization (ALTO) Problem Statement",
draft-marocco-alto-problem-statement-04 (work in
progress), February 2009.
[I-D.ietf-dhc-container-opt]
Droms, R., "Container Option for Server Configuration",
draft-ietf-dhc-container-opt-04 (work in progress),
November 2008.
8.2. Informative References
[RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629,
June 1999.
[RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC
Text on Security Considerations", BCP 72, RFC 3552,
July 2003.
[I-D.narten-iana-considerations-rfc2434bis]
Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs",
draft-narten-iana-considerations-rfc2434bis-09 (work in
progress), March 2008.
[WWW.WHOIS]
"http://www.whois.net".
Authors' Addresses
Song Haibin (editor)
Huawei
Baixia Road No. 91
Nanjing, Jiangsu Province 210001
P.R.China
Phone: +86-25-84565867
Fax: +86-25-84565888
Email: melodysong@huawei.com
Song, et al. Expires September 3, 2009 [Page 13]
Internet-Draft ALTO Server Discovery March 2009
Roni Even
Gesher Erove
14 David Hamelech
Tel Aviv 64953
Israel
Email: ron.even.tlv@gmail.com
Victor Pascual
Tekelec
Am Borsigturm 11
Berlin D-13507
Germany
Phone: +49 30 32 51 32 12
Email: victor@iptel.org
Yunfei Zhang
China Mobile
Phone: +86 10 66006688
Email: zhangyunfei@chinamobile.com
Song, et al. Expires September 3, 2009 [Page 14]