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]