ALTO S. Kiesel Internet-Draft NEC Europe Ltd. Intended status: Informational M. Tomsu Expires: April 29, 2010 Alcatel-Lucent Bell Labs October 26, 2009 Third-party ALTO server discovery draft-kiesel-alto-3pdisc-01 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 April 29, 2010. 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. Kiesel & Tomsu Expires April 29, 2010 [Page 1] Internet-Draft Third-party ALTO server discovery October 2009 Abstract The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. This document describes why a third-party ALTO server discovery mechanism is required for an important class of applications, namely tracker-based P2P applications. Several solution approaches are classified and evaluated. The conclusion is that further work is required to standardize a protocol and procedures that follow one specific approach. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 2.1. The need for third-party ALTO queries . . . . . . . . . . 4 2.2. The need for third-party ALTO server discovery . . . . . . 4 3. Peer-to-peer application scenario . . . . . . . . . . . . . . 6 4. Classification of solution approaches . . . . . . . . . . . . 8 4.1. Solutions that do not require an update of the application protocol . . . . . . . . . . . . . . . . . . . 8 4.2. Solutions that do require an update of the application protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 5.1. Approach #1 . . . . . . . . . . . . . . . . . . . . . . . 14 5.2. Approach #2 . . . . . . . . . . . . . . . . . . . . . . . 14 5.3. Approach #3 . . . . . . . . . . . . . . . . . . . . . . . 14 5.4. Approach #4 . . . . . . . . . . . . . . . . . . . . . . . 15 5.5. Approach #5 . . . . . . . . . . . . . . . . . . . . . . . 15 5.6. Approach #6 . . . . . . . . . . . . . . . . . . . . . . . 15 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 9. Informative References . . . . . . . . . . . . . . . . . . . . 20 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 Kiesel & Tomsu Expires April 29, 2010 [Page 2] Internet-Draft Third-party ALTO server discovery October 2009 1. Introduction The goal of Application-Layer Traffic Optimization (ALTO) is to provide guidance to applications, which have to select one or several hosts from a set of candidates, that are able to provide a desired resource. ALTO is realized by a client-server protocol. ALTO clients send queries to ALTO servers, in order to solicit guidance. The ALTO client can be embedded in the resource consumer, which will eventually access the desired resource. As an alternative, the ALTO client can be embedded in a resource directory, which assists resource consumers in finding appropriate resource providers. ALTO queries in the latter case will be referred to as third-party ALTO queries. The challenge for third-party ALTO queries is that they have to be answered by the "right" ALTO server, i.e., the ALTO server which has the knowledge to give guidance to the resource consumer on behalf of which the query is sent. This document uses the terminology introduced in [I-D.ietf-alto-problem-statement] and it investigates solution approaches that fulfill the requirements for ALTO server discovery documented in [I-D.ietf-alto-reqs]. Comments and discussions about this document should be directed to the ALTO working group: alto@ietf.org. Kiesel & Tomsu Expires April 29, 2010 [Page 3] Internet-Draft Third-party ALTO server discovery October 2009 2. Problem statement 2.1. The need for third-party ALTO queries The scope of this document is the interaction of peer-to-peer applications, that use a centralized resource directory ("tracker"), with the ALTO service. In this scenario, the resource consumer asks the resource directory for a list of potential resource providers, which can provide the desired resource. Usually, only a subset of all resource providers known to the resource directory will eventually be contacted by the resource consumer for accessing the resource. The purpose of ALTO is giving guidance on this peer selection, which is supposed to yield better-than-random results. There are two possibilities where to apply the ALTO guidance, in the resource consumer or in the resource directory: In the first scenario, the resource directory returns a list of potential resource providers without considering ALTO. It is then the duty of the resource consumer to invoke ALTO, in order to solicit guidance regarding this list. The problem with this approach is, that while the resource directory might know thousands of peers taking part in a swarm, the list returned to the resource consumer is usually shortened for efficiency reasons. Therefore, the "best" (in the sense of ALTO) potential resource providers might not be contained in that list anymore, even before ALTO can consider them. In the second scenario, the resource directory has an embedded ALTO client, which we will refer to as RDAC in this document. The resource directory invokes the RDAC to evaluate all resource providers it knows. Then it returns a, possibly shortened, list containing the "best" resource providers to the resource consumer. From an overall optimization perspective, this scenario is advantageous, because it is ensured that the addresses of the "best" resource providers are actually delivered to the resource consumer. 2.2. The need for third-party ALTO server discovery The previous section has shown why it is advantageous that entities such as resource directories can perform ALTO queries on behalf of resource consumers. We will refer to this kind of ALTO query as "third-party ALTO query". ALTO queries are sent to ALTO servers, which have knowledge of network topology and other information on which the ALTO guidance is based. One deployment scenario for ALTO is to establish a group of centralized ALTO servers which have complete knowledge and therefore can evaluate any pair of resource consumers and providers, Kiesel & Tomsu Expires April 29, 2010 [Page 4] Internet-Draft Third-party ALTO server discovery October 2009 respectively. However, it is likely that there will be deployment scenarios with many ALTO servers, each having only partial knowledge and therefore being able to give guidance regarding only a defined group of resource consumers (e.g., those in its topological vicinity, or those connected to the same network operator). The reasons for partitioning the overall knowledge include scalability and separate administrative responsibilities. For the remainder of this document, we assume that the second scenario has to be supported. The first scenario can be seen as special case of it, i.e., a solution that supports the second scenario will support the first scenario as well. The challenge for third-party ALTO queries is that they have to be answered by the "right" ALTO server, i.e, the ALTO server which has the knowledge to give guidance to the resource consumer on behalf of which the query is sent. Kiesel & Tomsu Expires April 29, 2010 [Page 5] Internet-Draft Third-party ALTO server discovery October 2009 3. Peer-to-peer application scenario For illustration purposes the following chapters provide several examples, which all refer to the scenario presented in Figure 1. However, the evaluations and conclusions presented in this document do not only consider this scenario, but they are much more general. +------+ +---------+ | ALTO |---+---| Tracker | | Srv3 | | +---------+ +------+ | |RTR| ISP 3 | **** | *********** *** ********************** ******* * Internet Backbone Networks * *************** ****************** | ****** ** | |RTR| ISP 1 ****** |RTR| ISP 2 | | +------+ +-------+ | +------+ +--------| ALTO | |Peer 1a|----+---| ALTO | | | Srv2 | +-------+ | | Srv1 | |NAT| +------+ | +------+ | +-------+ | +-------+ | +---------+ |Peer 1b|----+ |Peer 2a|----+------|ConfigSrv| +-------+ | +-------+ | +---------+ |RTR| | +-------+ | +-------+ | +-------+ |Peer 1c|----+ |Peer 2b|----+-|RTR|--|Peer 2c| +-------+ +-------+ +-------+ Figure 1: ALTO scenario Figure 1 shows three networks with connected end hosts, which are operated by different Internet Service Provides, identified as ISP1, ISP2, and ISP3, respectively. These networks are interconnected by Internet backbone networks. ISP1's network connects to (amongst others) three hosts that run the peers of a P2P application, identified as peers 1a, 1b, and 1c, respectively. Peers 1a and 1b are in topological vicinity, while 1c is more distant from them, because of the additional router (RTR) in between. ISP1 operates an ALTO server, identified as ALTO Srv1, which can give guidance to resource consumers in ISP1's network, i.e., to peers 1a, 1b, and 1c. Kiesel & Tomsu Expires April 29, 2010 [Page 6] Internet-Draft Third-party ALTO server discovery October 2009 ISP2's network has a very similar structure as described above, and it contains peers 2a, 2b, and 2c, as well as ALTO Srv2. The main difference to ISP1's network is that ISP2 uses a carrier grade NAT device, in order to masquerade peers 2a, 2b, and 2c "behind" one single "external" (globally unique) IPv4 address. ALTO server 2 is assumed to have a globally unique IPv4 address, i.e., it can be queried from other hosts in the Internet without any special NAT traversal mechanisms. ISP3's network contains a resource directory ("tracker") for a tracker-based P2P application. ISP3 operates ALTO Srv3, which is populated with information that could be used for giving guidance to resource consumers in ISP3's network. We assume that the tracker already knows that peers 1b, 1c, 2b, and 2c are taking part in a specific P2P overlay. If peer 1a wishes to join the overlay, it sends an application protocol specific message to the tracker, asking for other peer's addresses. Because of the reasons outlined in Section 2.1 the tracker should ask ALTO for guidance prior to replying. More specifically, it should query ALTO server 1, because this ALTO server can give guidance to peer 1a. Analogical to that, if peer 2a sends a query to the tracker, the tracker needs to ask ALTO server 2 for guidance. The procedures for identifying this ALTO server and conveying the guiding information to the tracker are the scope of this document. Kiesel & Tomsu Expires April 29, 2010 [Page 7] Internet-Draft Third-party ALTO server discovery October 2009 4. Classification of solution approaches There are several approaches for directing a third-party ALTO query from the RDAC to the "right" ALTO server. The selection of the "right" ALTO server needs to consider the resource consumer, on behalf of which the query will be performed. The set of available options therefore depends on the available information about the resource consumer, The primary criterion in the following classification is whether ALTO must work together with all existing (P2P) application protocols, or whether we can assume that these protocols can be augmented with new ALTO-specific information fields. 4.1. Solutions that do not require an update of the application protocol If we do not want to make specific assumptions on the (P2P) application protocol, we cannot assume that there are any other peer identifiers apart from IP addresses. Therefore, we assume that the only information identifying the resource consumer is the source IP address of messages sent from the resource consumer to the resource directory. This address may be the (public) IP address of the resource consumer, or it may be the external address of the last NAT on the path between resource consumer and resource directory. The RDAC that wants to perform the third-party ALTO query has two options: o Approach #1: The RDAC invokes a discovery mechanism external to the ALTO client protocol, in order to map from the resource consumer's IP address to the "right" ALTO server. The ALTO query will then be sent there directly (see Figure 2). o Approach #2: Independent of the resource consumer's identity, the RDAC uses the ALTO client protocol to send the ALTO query to one preconfigured ALTO server. The resource consumer's IP address is included in the query message. Based on this IP address and using mechanisms of the ALTO client protocol the first ALTO server forwards (see Figure 3) or redirects (see Figure 4) the query to the "right" ALTO server. This implies that ALTO servers must know each other, based on some discovery mechanism or manual configuration. Kiesel & Tomsu Expires April 29, 2010 [Page 8] Internet-Draft Third-party ALTO server discovery October 2009 Peer 1a Tracker ALTO Srv1 DNS ----+---- ----+---- ----+---- ----+---- | | | | | F1 Tracker Q | | | |==============>| F2 ALTO disc. Q (peer1a) | | |******************************>| | | F3 ALTO disc. R: ALTO Srv1 | | |<******************************| | | F4 ALTO cp Q | | | |-------------->| | | | F5 ALTO cp R | | | F6 Tracker R |<--------------| | |<==============| | | | | | | ==== Application protocol (i.e., tracker-based P2P app protocol) ---- ALTO client protocol **** ALTO discovery protocol (e.g., based on DNS queries) Figure 2: Message sequence chart for Approach 1 Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3 ----+---- ----+---- ----+---- ----+---- ----+---- | | | F1/2 HELLO | | | | |<###########>| F3/4 HELLO | | | | F5/6 HELLO |<###########>| | | |<#########################>| | F7 Tracker Q | | | | |==============>| | | | | | F8 ALTO cp Q | | | | |------------------------------------------>| | | | F9 ALTO cp Q | | | |<--------------------------| | | | F10 ALTO cp R | | | |-------------------------->| | | F11 ALTO cp R | | | | F12 Tracker R |<------------------------------------------| |<==============| | | | | | | | | ==== Application protocol (i.e., tracker-based P2P app protocol) ---- ALTO client protocol #### Inter-ALTO server protocol Figure 3: Message sequence chart for Approach 2 (query forwarding) Kiesel & Tomsu Expires April 29, 2010 [Page 9] Internet-Draft Third-party ALTO server discovery October 2009 Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3 ----+---- ----+---- ----+---- ----+---- ----+---- | | | F1/2 HELLO | | | | |<###########>| F3/4 HELLO | | | | F5/6 HELLO |<###########>| | | |<#########################>| | F7 Tracker Q | | | | |==============>| | | | | | F8 ALTO cp Q | | | | |------------------------------------------>| | | F9 ALTO cp redirect | | | |<------------------------------------------| | | F10 ALTO cp Q | | | | |-------------->| | | | | F11 ALTO cp R | | | | F12 Tracker R |<--------------| | | |<==============| | | | | | | | | ==== Application protocol (i.e., tracker-based P2P app protocol) ---- ALTO client protocol #### Inter-ALTO server protocol Figure 4: Message sequence chart for Approach 2 (query redirection) 4.2. Solutions that do require an update of the application protocol If we assume that applications can be upgraded in order to support ALTO, the resource consumer can provide additional information to the RDAC in order to assist the process of ALTO server discovery. o Approach #3: Using the extended application protocol, the resource consumer sends an additional peer-ID, which can be understood by ALTO, to the resource directory. This peer-ID could be used to uniquely identify resource consumers and providers located behind NATs. The RDAC uses this peer-ID in addition to or instead of the resource consumer's IP address (see Figure 5). In all other aspects this approach is identical to approach #1. o Approach #4: This approach is identical to approach #2, except that the peer-ID is used instead of the IP address, as described in approach #3. o Approach #5: The resource consumer discovers its ALTO server on its own (i.e., not a third-party discovery). Using the extended application protocol it sends the ALTO server's address to the RDAC. The RDAC can use it for sending third-party ALTO queries Kiesel & Tomsu Expires April 29, 2010 [Page 10] Internet-Draft Third-party ALTO server discovery October 2009 there. o Approach #6: The resource consumer retrieves guiding information on its own, e.g., by discovering and querying an ALTO server or by doing measurements. Using the extended application protocol it sends this information to the tracker, which can perform peer selection based on it. Peer 2a ConfigSrv Tracker ALTO Srv2 DNS ----+---- ----+---- ----+---- ----+---- ----+--- | F1 Config Q | | | | |;;;;;;;;;;;;;;>| | | | | | | | | | F2 Config R | | | | | + LocalID LID | | | | |<;;;;;;;;;;;;;;| | | | | | | | | | F3 Tracker Q (LID) | | | |===========================>| F4 ALTO disc. Q (ext.IP+LID) | | | |******************************>| | | | F5 ALTO disc. R: ALTO Srv2 | | | |<******************************| | | | F6 ALTO cp Q | | | | |-------------->| | | | | F7 ALTO cp R | | | F8 Tracker R | |<--------------| | |<===========================| | | | | | | | ;;;; Configuration protocol (e.g., DHCP) ==== Application protocol (i.e., tracker-based P2P app protocol) ---- ALTO client protocol **** ALTO discovery protocol (e.g., based on DNS queries) Figure 5: Message sequence chart for Approach 3 Kiesel & Tomsu Expires April 29, 2010 [Page 11] Internet-Draft Third-party ALTO server discovery October 2009 Peer 2a ConfigSrv Tracker ALTO Srv2 ----+---- ----+---- ----+---- ----+---- | F1 Config Q | | | |;;;;;;;;;;;;;;>| | | | | | | | F2 Config R | | | | + Addr. of ALTO Srv2 | | |<;;;;;;;;;;;;;;| | | | | | | | F3 Tracker Q (Addr. of ALTO Srv2) | |==============================>| | | | | F4 ALTO cp Q | | | |-------------->| | | | F5 ALTO cp R | | F6 Tracker R | |<--------------| |<==============================| | | | | | ;;;; Configuration protocol (e.g., DHCP) ==== Application protocol (i.e., tracker-based P2P app protocol) ---- ALTO client protocol Figure 6: Message sequence chart for Approach 5 Kiesel & Tomsu Expires April 29, 2010 [Page 12] Internet-Draft Third-party ALTO server discovery October 2009 Peer 2a ConfigSrv Tracker ALTO Srv2 ----+---- ----+---- ----+---- ----+---- | F1 Config Q | | | |;;;;;;;;;;;;;;>| | | | | | | | F2 Config R | | | | + Addr. of ALTO Srv2 | | |<;;;;;;;;;;;;;;| | | | | | | | F3 ALTO cp Q | | | |---------------------------------------------->| | F4 ALTO cp R | | | |<----------------------------------------------| optional: perform | | | measurements | | | | | | | | F5 Tracker Q (Info from ALTO reply + meas'mt.)| |==============================>| | | F6 Tracker R | | | |<==============================| | | | | | ;;;; Configuration protocol (e.g., DHCP) ==== Application protocol (i.e., tracker-based P2P app protocol) ---- ALTO client protocol Figure 7: Message sequence chart for Approach 6 Kiesel & Tomsu Expires April 29, 2010 [Page 13] Internet-Draft Third-party ALTO server discovery October 2009 5. Discussion This section assesses and compares the different approaches introduced above, regarding trust, scalability, integration into existing ISP infrastructure and management processes, modification of existing applications, and ongoing ALTO architecture specification works. 5.1. Approach #1 The existence of a mechanism according to approach #1 is assumed by [I-D.penno-alto-protocol]. This approach does not require any changes of existing (P2P) application protocols. However, the RDAC needs to implement an additional protocol for performing third-party ALTO server discovery. One possible way of implementing this approach would be based on DNS, providing a mapping from the resource consumer's IP address to the IP address of the corresponding "right" ALTO server. DNS is proven to be scalable and has well-understood mechanisms for delegating authority. Network operators are used to DNS management. This approach does not support intra-domain traffic optimization for large domains behind a NAT. 5.2. Approach #2 This approach does not require any changes of existing (P2P) application protocols. Furthermore, the RDAC does not need to implement an additional protocol besides the ALTO client protocol. However, this approach relocates the discovery problem from the RDAC to the first ALTO server. This first ALTO server, when preconfigured in the RDAC of a large resource directory, would raise serious concerns about scalability and trust/security issues. This approach does not support intra-domain traffic optimization for large domains behind a NAT. 5.3. Approach #3 This approach requires changes to all existing (P2P) application protocols that want to benefit from ALTO. Kiesel & Tomsu Expires April 29, 2010 [Page 14] Internet-Draft Third-party ALTO server discovery October 2009 This approach supports intra-domain traffic optimization for large domains behind a NAT. Except for the above mentioned statements, the same results as for approach #1 apply. 5.4. Approach #4 This approach requires changes to all existing (P2P) application protocols that want to benefit from ALTO. This approach supports intra-domain traffic optimization for large domains behind a NAT. Except for the above mentioned statements, the same results as for approach #2 apply. 5.5. Approach #5 This approach requires changes to all existing (P2P) application protocols that want to benefit from ALTO. This approach does not need a mechanism for third-party ALTO server discovery, as the ALTO server is discovered by the resource consumer. However, a mechanism for this kind of discovery is needed, see, e.g., [I-D.song-alto-server-discovery]. Unlike approaches #1 .. #4 this approach supports scenarios, in which there is not exactly one "right" ALTO server for any given resource consumer. Instead of sending the address of the ALTO server provisioned by the ISP, the resource consumer can also send the address of another ALTO server of its choice to the RDAC. 5.6. Approach #6 This approach requires changes to all existing (P2P) application protocols that want to benefit from ALTO. This approach does not need a mechanism for third-party ALTO server discovery, as the ALTO server is discovered by the resource consumer. However, a mechanism for this kind of discovery is needed, see, e.g., [I-D.song-alto-server-discovery]. Unlike approaches #1 .. #4 this approach supports scenarios, in which there is not exactly one "right" ALTO server for any given resource consumer. Instead of querying the ALTO server provisioned by the ISP and forwarding that information to the resource directory, the resource consumer can also query any other ALTO server of its choice. Kiesel & Tomsu Expires April 29, 2010 [Page 15] Internet-Draft Third-party ALTO server discovery October 2009 This approach allows the resource consumer to augment the ALTO server's reply with local preferences (e.g., from measurements). It is also possible not to query an ALTO server at all. Kiesel & Tomsu Expires April 29, 2010 [Page 16] Internet-Draft Third-party ALTO server discovery October 2009 6. Conclusion This document describes why a third-party ALTO server discovery mechanism is required for an important class of applications, namely tracker-based P2P applications. Several solution approaches are classified and evaluated. Assuming that ALTO should work together with already deployed application protocols, "Approach #1" seems to be most promising. In this approach, the resource directory invokes a discovery mechanism external to the ALTO client protocol, in order to map from the resource consumer's IP address to the "right" ALTO server. The existence of such a mechanism according to "Approach #1" is assumed by [I-D.penno-alto-protocol]. Further action is required to standardize a protocol and procedures according to "Approach #1". Kiesel & Tomsu Expires April 29, 2010 [Page 17] Internet-Draft Third-party ALTO server discovery October 2009 7. IANA Considerations This document does not mandate any immediate IANA actions. However, such IANA considerations may arise from future ALTO discovery specification documents which try to meet the requirements given here. Kiesel & Tomsu Expires April 29, 2010 [Page 18] Internet-Draft Third-party ALTO server discovery October 2009 8. Security Considerations This early version of this memo does not yet have any security considerations, but they will be added in future revision. Kiesel & Tomsu Expires April 29, 2010 [Page 19] Internet-Draft Third-party ALTO server discovery October 2009 9. Informative References [I-D.ietf-alto-problem-statement] Seedorf, J. and E. Burger, "Application-Layer Traffic Optimization (ALTO) Problem Statement", draft-ietf-alto-problem-statement-02 (work in progress), July 2009. [I-D.ietf-alto-reqs] Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. Yang, "Application-Layer Traffic Optimization (ALTO) Requirements", draft-ietf-alto-reqs-01 (work in progress), July 2009. [I-D.penno-alto-protocol] Penno, R. and Y. Yang, "ALTO Protocol", draft-penno-alto-protocol-03 (work in progress), July 2009. [I-D.song-alto-server-discovery] Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual, "ALTO Service Discovery", draft-song-alto-server-discovery-01 (work in progress), July 2009. Kiesel & Tomsu Expires April 29, 2010 [Page 20] Internet-Draft Third-party ALTO server discovery October 2009 Appendix A. Acknowledgments The authors would like to thank Haibin Song, Richard Alimi, and Roni Even for fruitful discussions during the 75th IETF meeting. Sebastian Kiesel is partially supported by the NAPA-WINE project (Network-Aware P2P-TV Application over Wise Networks, http://www.napa-wine.org), a research project supported by the European Commission under its 7th Framework Program (contract no. 214412). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the NAPA-WINE project or the European Commission. Marco Tomsu is partially supported by the 4WARD project (http://www.4ward-project.eu), a research project supported by the European Commission under its 7th Framework Program (contract no. 216041). The views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the 4WARD project or the European Commission. Kiesel & Tomsu Expires April 29, 2010 [Page 21] Internet-Draft Third-party ALTO server discovery October 2009 Authors' Addresses Sebastian Kiesel NEC Laboratories Europe Kurfuerstenanlage 36 Heidelberg 69115 Germany Email: kiesel@nw.neclab.eu URI: http://www.nw.neclab.eu/ Marco Tomsu Alcatel-Lucent Bell Labs Lorenzstrasse 10 Stuttgart 70435 Germany Email: marco.tomsu@alcatel-lucent.com URI: www.alcatel-lucent.com/bell-labs Kiesel & Tomsu Expires April 29, 2010 [Page 22]