idnits 2.17.1 draft-kiesel-alto-3pdisc-01.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- ** The document seems to lack a License Notice according IETF Trust Provisions of 28 Dec 2009, Section 6.b.ii or Provisions of 12 Sep 2009 Section 6.b -- however, there's a paragraph with a matching beginning. Boilerplate error? (You're using the IETF Trust Provisions' Section 6.b License Notice from 12 Feb 2009 rather than one of the newer Notices. See https://trustee.ietf.org/license-info/.) Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 26, 2009) is 5293 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Informational ---------------------------------------------------------------------------- == Outdated reference: A later version (-04) exists of draft-ietf-alto-problem-statement-02 == Outdated reference: A later version (-16) exists of draft-ietf-alto-reqs-01 == Outdated reference: A later version (-04) exists of draft-penno-alto-protocol-03 == Outdated reference: A later version (-03) exists of draft-song-alto-server-discovery-01 Summary: 1 error (**), 0 flaws (~~), 5 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO S. Kiesel 3 Internet-Draft NEC Europe Ltd. 4 Intended status: Informational M. Tomsu 5 Expires: April 29, 2010 Alcatel-Lucent Bell Labs 6 October 26, 2009 8 Third-party ALTO server discovery 9 draft-kiesel-alto-3pdisc-01 11 Status of this Memo 13 This Internet-Draft is submitted to IETF in full conformance with the 14 provisions of BCP 78 and BCP 79. 16 Internet-Drafts are working documents of the Internet Engineering 17 Task Force (IETF), its areas, and its working groups. Note that 18 other groups may also distribute working documents as Internet- 19 Drafts. 21 Internet-Drafts are draft documents valid for a maximum of six months 22 and may be updated, replaced, or obsoleted by other documents at any 23 time. It is inappropriate to use Internet-Drafts as reference 24 material or to cite them other than as "work in progress." 26 The list of current Internet-Drafts can be accessed at 27 http://www.ietf.org/ietf/1id-abstracts.txt. 29 The list of Internet-Draft Shadow Directories can be accessed at 30 http://www.ietf.org/shadow.html. 32 This Internet-Draft will expire on April 29, 2010. 34 Copyright Notice 36 Copyright (c) 2009 IETF Trust and the persons identified as the 37 document authors. All rights reserved. 39 This document is subject to BCP 78 and the IETF Trust's Legal 40 Provisions Relating to IETF Documents in effect on the date of 41 publication of this document (http://trustee.ietf.org/license-info). 42 Please review these documents carefully, as they describe your rights 43 and restrictions with respect to this document. 45 Abstract 47 The goal of Application-Layer Traffic Optimization (ALTO) is to 48 provide guidance to applications, which have to select one or several 49 hosts from a set of candidates, that are able to provide a desired 50 resource. 52 This document describes why a third-party ALTO server discovery 53 mechanism is required for an important class of applications, namely 54 tracker-based P2P applications. Several solution approaches are 55 classified and evaluated. The conclusion is that further work is 56 required to standardize a protocol and procedures that follow one 57 specific approach. 59 Table of Contents 61 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 62 2. Problem statement . . . . . . . . . . . . . . . . . . . . . . 4 63 2.1. The need for third-party ALTO queries . . . . . . . . . . 4 64 2.2. The need for third-party ALTO server discovery . . . . . . 4 65 3. Peer-to-peer application scenario . . . . . . . . . . . . . . 6 66 4. Classification of solution approaches . . . . . . . . . . . . 8 67 4.1. Solutions that do not require an update of the 68 application protocol . . . . . . . . . . . . . . . . . . . 8 69 4.2. Solutions that do require an update of the application 70 protocol . . . . . . . . . . . . . . . . . . . . . . . . . 10 71 5. Discussion . . . . . . . . . . . . . . . . . . . . . . . . . . 14 72 5.1. Approach #1 . . . . . . . . . . . . . . . . . . . . . . . 14 73 5.2. Approach #2 . . . . . . . . . . . . . . . . . . . . . . . 14 74 5.3. Approach #3 . . . . . . . . . . . . . . . . . . . . . . . 14 75 5.4. Approach #4 . . . . . . . . . . . . . . . . . . . . . . . 15 76 5.5. Approach #5 . . . . . . . . . . . . . . . . . . . . . . . 15 77 5.6. Approach #6 . . . . . . . . . . . . . . . . . . . . . . . 15 78 6. Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 18 80 8. Security Considerations . . . . . . . . . . . . . . . . . . . 19 81 9. Informative References . . . . . . . . . . . . . . . . . . . . 20 82 Appendix A. Acknowledgments . . . . . . . . . . . . . . . . . . . 21 83 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22 85 1. Introduction 87 The goal of Application-Layer Traffic Optimization (ALTO) is to 88 provide guidance to applications, which have to select one or several 89 hosts from a set of candidates, that are able to provide a desired 90 resource. ALTO is realized by a client-server protocol. ALTO 91 clients send queries to ALTO servers, in order to solicit guidance. 92 The ALTO client can be embedded in the resource consumer, which will 93 eventually access the desired resource. As an alternative, the ALTO 94 client can be embedded in a resource directory, which assists 95 resource consumers in finding appropriate resource providers. ALTO 96 queries in the latter case will be referred to as third-party ALTO 97 queries. 99 The challenge for third-party ALTO queries is that they have to be 100 answered by the "right" ALTO server, i.e., the ALTO server which has 101 the knowledge to give guidance to the resource consumer on behalf of 102 which the query is sent. 104 This document uses the terminology introduced in 105 [I-D.ietf-alto-problem-statement] and it investigates solution 106 approaches that fulfill the requirements for ALTO server discovery 107 documented in [I-D.ietf-alto-reqs]. 109 Comments and discussions about this document should be directed to 110 the ALTO working group: alto@ietf.org. 112 2. Problem statement 114 2.1. The need for third-party ALTO queries 116 The scope of this document is the interaction of peer-to-peer 117 applications, that use a centralized resource directory ("tracker"), 118 with the ALTO service. In this scenario, the resource consumer asks 119 the resource directory for a list of potential resource providers, 120 which can provide the desired resource. Usually, only a subset of 121 all resource providers known to the resource directory will 122 eventually be contacted by the resource consumer for accessing the 123 resource. The purpose of ALTO is giving guidance on this peer 124 selection, which is supposed to yield better-than-random results. 126 There are two possibilities where to apply the ALTO guidance, in the 127 resource consumer or in the resource directory: 129 In the first scenario, the resource directory returns a list of 130 potential resource providers without considering ALTO. It is then 131 the duty of the resource consumer to invoke ALTO, in order to solicit 132 guidance regarding this list. The problem with this approach is, 133 that while the resource directory might know thousands of peers 134 taking part in a swarm, the list returned to the resource consumer is 135 usually shortened for efficiency reasons. Therefore, the "best" (in 136 the sense of ALTO) potential resource providers might not be 137 contained in that list anymore, even before ALTO can consider them. 139 In the second scenario, the resource directory has an embedded ALTO 140 client, which we will refer to as RDAC in this document. The 141 resource directory invokes the RDAC to evaluate all resource 142 providers it knows. Then it returns a, possibly shortened, list 143 containing the "best" resource providers to the resource consumer. 144 From an overall optimization perspective, this scenario is 145 advantageous, because it is ensured that the addresses of the "best" 146 resource providers are actually delivered to the resource consumer. 148 2.2. The need for third-party ALTO server discovery 150 The previous section has shown why it is advantageous that entities 151 such as resource directories can perform ALTO queries on behalf of 152 resource consumers. We will refer to this kind of ALTO query as 153 "third-party ALTO query". 155 ALTO queries are sent to ALTO servers, which have knowledge of 156 network topology and other information on which the ALTO guidance is 157 based. One deployment scenario for ALTO is to establish a group of 158 centralized ALTO servers which have complete knowledge and therefore 159 can evaluate any pair of resource consumers and providers, 160 respectively. 162 However, it is likely that there will be deployment scenarios with 163 many ALTO servers, each having only partial knowledge and therefore 164 being able to give guidance regarding only a defined group of 165 resource consumers (e.g., those in its topological vicinity, or those 166 connected to the same network operator). The reasons for 167 partitioning the overall knowledge include scalability and separate 168 administrative responsibilities. For the remainder of this document, 169 we assume that the second scenario has to be supported. The first 170 scenario can be seen as special case of it, i.e., a solution that 171 supports the second scenario will support the first scenario as well. 173 The challenge for third-party ALTO queries is that they have to be 174 answered by the "right" ALTO server, i.e, the ALTO server which has 175 the knowledge to give guidance to the resource consumer on behalf of 176 which the query is sent. 178 3. Peer-to-peer application scenario 180 For illustration purposes the following chapters provide several 181 examples, which all refer to the scenario presented in Figure 1. 182 However, the evaluations and conclusions presented in this document 183 do not only consider this scenario, but they are much more general. 185 +------+ +---------+ 186 | ALTO |---+---| Tracker | 187 | Srv3 | | +---------+ 188 +------+ | 189 |RTR| ISP 3 190 | 191 **** | *********** 192 *** ********************** ******* 193 * Internet Backbone Networks * 194 *************** ****************** 195 | ****** ** | 196 |RTR| ISP 1 ****** |RTR| ISP 2 197 | | +------+ 198 +-------+ | +------+ +--------| ALTO | 199 |Peer 1a|----+---| ALTO | | | Srv2 | 200 +-------+ | | Srv1 | |NAT| +------+ 201 | +------+ | 202 +-------+ | +-------+ | +---------+ 203 |Peer 1b|----+ |Peer 2a|----+------|ConfigSrv| 204 +-------+ | +-------+ | +---------+ 205 |RTR| | 206 +-------+ | +-------+ | +-------+ 207 |Peer 1c|----+ |Peer 2b|----+-|RTR|--|Peer 2c| 208 +-------+ +-------+ +-------+ 210 Figure 1: ALTO scenario 212 Figure 1 shows three networks with connected end hosts, which are 213 operated by different Internet Service Provides, identified as ISP1, 214 ISP2, and ISP3, respectively. These networks are interconnected by 215 Internet backbone networks. 217 ISP1's network connects to (amongst others) three hosts that run the 218 peers of a P2P application, identified as peers 1a, 1b, and 1c, 219 respectively. Peers 1a and 1b are in topological vicinity, while 1c 220 is more distant from them, because of the additional router (RTR) in 221 between. ISP1 operates an ALTO server, identified as ALTO Srv1, 222 which can give guidance to resource consumers in ISP1's network, 223 i.e., to peers 1a, 1b, and 1c. 225 ISP2's network has a very similar structure as described above, and 226 it contains peers 2a, 2b, and 2c, as well as ALTO Srv2. The main 227 difference to ISP1's network is that ISP2 uses a carrier grade NAT 228 device, in order to masquerade peers 2a, 2b, and 2c "behind" one 229 single "external" (globally unique) IPv4 address. ALTO server 2 is 230 assumed to have a globally unique IPv4 address, i.e., it can be 231 queried from other hosts in the Internet without any special NAT 232 traversal mechanisms. 234 ISP3's network contains a resource directory ("tracker") for a 235 tracker-based P2P application. ISP3 operates ALTO Srv3, which is 236 populated with information that could be used for giving guidance to 237 resource consumers in ISP3's network. 239 We assume that the tracker already knows that peers 1b, 1c, 2b, and 240 2c are taking part in a specific P2P overlay. If peer 1a wishes to 241 join the overlay, it sends an application protocol specific message 242 to the tracker, asking for other peer's addresses. Because of the 243 reasons outlined in Section 2.1 the tracker should ask ALTO for 244 guidance prior to replying. More specifically, it should query ALTO 245 server 1, because this ALTO server can give guidance to peer 1a. 246 Analogical to that, if peer 2a sends a query to the tracker, the 247 tracker needs to ask ALTO server 2 for guidance. The procedures for 248 identifying this ALTO server and conveying the guiding information to 249 the tracker are the scope of this document. 251 4. Classification of solution approaches 253 There are several approaches for directing a third-party ALTO query 254 from the RDAC to the "right" ALTO server. The selection of the 255 "right" ALTO server needs to consider the resource consumer, on 256 behalf of which the query will be performed. The set of available 257 options therefore depends on the available information about the 258 resource consumer, 260 The primary criterion in the following classification is whether ALTO 261 must work together with all existing (P2P) application protocols, or 262 whether we can assume that these protocols can be augmented with new 263 ALTO-specific information fields. 265 4.1. Solutions that do not require an update of the application 266 protocol 268 If we do not want to make specific assumptions on the (P2P) 269 application protocol, we cannot assume that there are any other peer 270 identifiers apart from IP addresses. Therefore, we assume that the 271 only information identifying the resource consumer is the source IP 272 address of messages sent from the resource consumer to the resource 273 directory. This address may be the (public) IP address of the 274 resource consumer, or it may be the external address of the last NAT 275 on the path between resource consumer and resource directory. 277 The RDAC that wants to perform the third-party ALTO query has two 278 options: 280 o Approach #1: The RDAC invokes a discovery mechanism external to 281 the ALTO client protocol, in order to map from the resource 282 consumer's IP address to the "right" ALTO server. The ALTO query 283 will then be sent there directly (see Figure 2). 285 o Approach #2: Independent of the resource consumer's identity, the 286 RDAC uses the ALTO client protocol to send the ALTO query to one 287 preconfigured ALTO server. The resource consumer's IP address is 288 included in the query message. Based on this IP address and using 289 mechanisms of the ALTO client protocol the first ALTO server 290 forwards (see Figure 3) or redirects (see Figure 4) the query to 291 the "right" ALTO server. This implies that ALTO servers must know 292 each other, based on some discovery mechanism or manual 293 configuration. 295 Peer 1a Tracker ALTO Srv1 DNS 296 ----+---- ----+---- ----+---- ----+---- 297 | | | | 298 | F1 Tracker Q | | | 299 |==============>| F2 ALTO disc. Q (peer1a) | 300 | |******************************>| 301 | | F3 ALTO disc. R: ALTO Srv1 | 302 | |<******************************| 303 | | F4 ALTO cp Q | | 304 | |-------------->| | 305 | | F5 ALTO cp R | | 306 | F6 Tracker R |<--------------| | 307 |<==============| | | 308 | | | | 310 ==== Application protocol (i.e., tracker-based P2P app protocol) 311 ---- ALTO client protocol 312 **** ALTO discovery protocol (e.g., based on DNS queries) 314 Figure 2: Message sequence chart for Approach 1 316 Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3 317 ----+---- ----+---- ----+---- ----+---- ----+---- 318 | | | F1/2 HELLO | | 319 | | |<###########>| F3/4 HELLO | 320 | | | F5/6 HELLO |<###########>| 321 | | |<#########################>| 322 | F7 Tracker Q | | | | 323 |==============>| | | | 324 | | F8 ALTO cp Q | | | 325 | |------------------------------------------>| 326 | | | F9 ALTO cp Q | 327 | | |<--------------------------| 328 | | | F10 ALTO cp R | 329 | | |-------------------------->| 330 | | F11 ALTO cp R | | | 331 | F12 Tracker R |<------------------------------------------| 332 |<==============| | | | 333 | | | | | 335 ==== Application protocol (i.e., tracker-based P2P app protocol) 336 ---- ALTO client protocol 337 #### Inter-ALTO server protocol 339 Figure 3: Message sequence chart for Approach 2 (query forwarding) 340 Peer 1a Tracker ALTO Srv1 ALTO Srv2 ALTO Srv3 341 ----+---- ----+---- ----+---- ----+---- ----+---- 342 | | | F1/2 HELLO | | 343 | | |<###########>| F3/4 HELLO | 344 | | | F5/6 HELLO |<###########>| 345 | | |<#########################>| 346 | F7 Tracker Q | | | | 347 |==============>| | | | 348 | | F8 ALTO cp Q | | | 349 | |------------------------------------------>| 350 | | F9 ALTO cp redirect | | 351 | |<------------------------------------------| 352 | | F10 ALTO cp Q | | | 353 | |-------------->| | | 354 | | F11 ALTO cp R | | | 355 | F12 Tracker R |<--------------| | | 356 |<==============| | | | 357 | | | | | 359 ==== Application protocol (i.e., tracker-based P2P app protocol) 360 ---- ALTO client protocol 361 #### Inter-ALTO server protocol 363 Figure 4: Message sequence chart for Approach 2 (query redirection) 365 4.2. Solutions that do require an update of the application protocol 367 If we assume that applications can be upgraded in order to support 368 ALTO, the resource consumer can provide additional information to the 369 RDAC in order to assist the process of ALTO server discovery. 371 o Approach #3: Using the extended application protocol, the resource 372 consumer sends an additional peer-ID, which can be understood by 373 ALTO, to the resource directory. This peer-ID could be used to 374 uniquely identify resource consumers and providers located behind 375 NATs. The RDAC uses this peer-ID in addition to or instead of the 376 resource consumer's IP address (see Figure 5). In all other 377 aspects this approach is identical to approach #1. 379 o Approach #4: This approach is identical to approach #2, except 380 that the peer-ID is used instead of the IP address, as described 381 in approach #3. 383 o Approach #5: The resource consumer discovers its ALTO server on 384 its own (i.e., not a third-party discovery). Using the extended 385 application protocol it sends the ALTO server's address to the 386 RDAC. The RDAC can use it for sending third-party ALTO queries 387 there. 389 o Approach #6: The resource consumer retrieves guiding information 390 on its own, e.g., by discovering and querying an ALTO server or by 391 doing measurements. Using the extended application protocol it 392 sends this information to the tracker, which can perform peer 393 selection based on it. 395 Peer 2a ConfigSrv Tracker ALTO Srv2 DNS 396 ----+---- ----+---- ----+---- ----+---- ----+--- 397 | F1 Config Q | | | | 398 |;;;;;;;;;;;;;;>| | | | 399 | | | | | 400 | F2 Config R | | | | 401 | + LocalID LID | | | | 402 |<;;;;;;;;;;;;;;| | | | 403 | | | | | 404 | F3 Tracker Q (LID) | | | 405 |===========================>| F4 ALTO disc. Q (ext.IP+LID) | 406 | | |******************************>| 407 | | | F5 ALTO disc. R: ALTO Srv2 | 408 | | |<******************************| 409 | | | F6 ALTO cp Q | | 410 | | |-------------->| | 411 | | | F7 ALTO cp R | | 412 | F8 Tracker R | |<--------------| | 413 |<===========================| | | 414 | | | | | 416 ;;;; Configuration protocol (e.g., DHCP) 417 ==== Application protocol (i.e., tracker-based P2P app protocol) 418 ---- ALTO client protocol 419 **** ALTO discovery protocol (e.g., based on DNS queries) 421 Figure 5: Message sequence chart for Approach 3 423 Peer 2a ConfigSrv Tracker ALTO Srv2 424 ----+---- ----+---- ----+---- ----+---- 425 | F1 Config Q | | | 426 |;;;;;;;;;;;;;;>| | | 427 | | | | 428 | F2 Config R | | | 429 | + Addr. of ALTO Srv2 | | 430 |<;;;;;;;;;;;;;;| | | 431 | | | | 432 | F3 Tracker Q (Addr. of ALTO Srv2) | 433 |==============================>| | 434 | | | F4 ALTO cp Q | 435 | | |-------------->| 436 | | | F5 ALTO cp R | 437 | F6 Tracker R | |<--------------| 438 |<==============================| | 439 | | | | 441 ;;;; Configuration protocol (e.g., DHCP) 442 ==== Application protocol (i.e., tracker-based P2P app protocol) 443 ---- ALTO client protocol 445 Figure 6: Message sequence chart for Approach 5 447 Peer 2a ConfigSrv Tracker ALTO Srv2 448 ----+---- ----+---- ----+---- ----+---- 449 | F1 Config Q | | | 450 |;;;;;;;;;;;;;;>| | | 451 | | | | 452 | F2 Config R | | | 453 | + Addr. of ALTO Srv2 | | 454 |<;;;;;;;;;;;;;;| | | 455 | | | | 456 | F3 ALTO cp Q | | | 457 |---------------------------------------------->| 458 | F4 ALTO cp R | | | 459 |<----------------------------------------------| 460 optional: perform | | | 461 measurements | | | 462 | | | | 463 | F5 Tracker Q (Info from ALTO reply + meas'mt.)| 464 |==============================>| | 465 | F6 Tracker R | | | 466 |<==============================| | 467 | | | | 469 ;;;; Configuration protocol (e.g., DHCP) 470 ==== Application protocol (i.e., tracker-based P2P app protocol) 471 ---- ALTO client protocol 473 Figure 7: Message sequence chart for Approach 6 475 5. Discussion 477 This section assesses and compares the different approaches 478 introduced above, regarding trust, scalability, integration into 479 existing ISP infrastructure and management processes, modification of 480 existing applications, and ongoing ALTO architecture specification 481 works. 483 5.1. Approach #1 485 The existence of a mechanism according to approach #1 is assumed by 486 [I-D.penno-alto-protocol]. 488 This approach does not require any changes of existing (P2P) 489 application protocols. However, the RDAC needs to implement an 490 additional protocol for performing third-party ALTO server discovery. 492 One possible way of implementing this approach would be based on DNS, 493 providing a mapping from the resource consumer's IP address to the IP 494 address of the corresponding "right" ALTO server. DNS is proven to 495 be scalable and has well-understood mechanisms for delegating 496 authority. Network operators are used to DNS management. 498 This approach does not support intra-domain traffic optimization for 499 large domains behind a NAT. 501 5.2. Approach #2 503 This approach does not require any changes of existing (P2P) 504 application protocols. 506 Furthermore, the RDAC does not need to implement an additional 507 protocol besides the ALTO client protocol. However, this approach 508 relocates the discovery problem from the RDAC to the first ALTO 509 server. 511 This first ALTO server, when preconfigured in the RDAC of a large 512 resource directory, would raise serious concerns about scalability 513 and trust/security issues. 515 This approach does not support intra-domain traffic optimization for 516 large domains behind a NAT. 518 5.3. Approach #3 520 This approach requires changes to all existing (P2P) application 521 protocols that want to benefit from ALTO. 523 This approach supports intra-domain traffic optimization for large 524 domains behind a NAT. 526 Except for the above mentioned statements, the same results as for 527 approach #1 apply. 529 5.4. Approach #4 531 This approach requires changes to all existing (P2P) application 532 protocols that want to benefit from ALTO. 534 This approach supports intra-domain traffic optimization for large 535 domains behind a NAT. 537 Except for the above mentioned statements, the same results as for 538 approach #2 apply. 540 5.5. Approach #5 542 This approach requires changes to all existing (P2P) application 543 protocols that want to benefit from ALTO. 545 This approach does not need a mechanism for third-party ALTO server 546 discovery, as the ALTO server is discovered by the resource consumer. 547 However, a mechanism for this kind of discovery is needed, see, e.g., 548 [I-D.song-alto-server-discovery]. 550 Unlike approaches #1 .. #4 this approach supports scenarios, in which 551 there is not exactly one "right" ALTO server for any given resource 552 consumer. Instead of sending the address of the ALTO server 553 provisioned by the ISP, the resource consumer can also send the 554 address of another ALTO server of its choice to the RDAC. 556 5.6. Approach #6 558 This approach requires changes to all existing (P2P) application 559 protocols that want to benefit from ALTO. 561 This approach does not need a mechanism for third-party ALTO server 562 discovery, as the ALTO server is discovered by the resource consumer. 563 However, a mechanism for this kind of discovery is needed, see, e.g., 564 [I-D.song-alto-server-discovery]. 566 Unlike approaches #1 .. #4 this approach supports scenarios, in which 567 there is not exactly one "right" ALTO server for any given resource 568 consumer. Instead of querying the ALTO server provisioned by the ISP 569 and forwarding that information to the resource directory, the 570 resource consumer can also query any other ALTO server of its choice. 572 This approach allows the resource consumer to augment the ALTO 573 server's reply with local preferences (e.g., from measurements). It 574 is also possible not to query an ALTO server at all. 576 6. Conclusion 578 This document describes why a third-party ALTO server discovery 579 mechanism is required for an important class of applications, namely 580 tracker-based P2P applications. Several solution approaches are 581 classified and evaluated. Assuming that ALTO should work together 582 with already deployed application protocols, "Approach #1" seems to 583 be most promising. In this approach, the resource directory invokes 584 a discovery mechanism external to the ALTO client protocol, in order 585 to map from the resource consumer's IP address to the "right" ALTO 586 server. 588 The existence of such a mechanism according to "Approach #1" is 589 assumed by [I-D.penno-alto-protocol]. 591 Further action is required to standardize a protocol and procedures 592 according to "Approach #1". 594 7. IANA Considerations 596 This document does not mandate any immediate IANA actions. However, 597 such IANA considerations may arise from future ALTO discovery 598 specification documents which try to meet the requirements given 599 here. 601 8. Security Considerations 603 This early version of this memo does not yet have any security 604 considerations, but they will be added in future revision. 606 9. Informative References 608 [I-D.ietf-alto-problem-statement] 609 Seedorf, J. and E. Burger, "Application-Layer Traffic 610 Optimization (ALTO) Problem Statement", 611 draft-ietf-alto-problem-statement-02 (work in progress), 612 July 2009. 614 [I-D.ietf-alto-reqs] 615 Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y. 616 Yang, "Application-Layer Traffic Optimization (ALTO) 617 Requirements", draft-ietf-alto-reqs-01 (work in progress), 618 July 2009. 620 [I-D.penno-alto-protocol] 621 Penno, R. and Y. Yang, "ALTO Protocol", 622 draft-penno-alto-protocol-03 (work in progress), 623 July 2009. 625 [I-D.song-alto-server-discovery] 626 Song, H., Tomsu, M., Garcia, G., Wang, Y., and V. Pascual, 627 "ALTO Service Discovery", 628 draft-song-alto-server-discovery-01 (work in progress), 629 July 2009. 631 Appendix A. Acknowledgments 633 The authors would like to thank Haibin Song, Richard Alimi, and Roni 634 Even for fruitful discussions during the 75th IETF meeting. 636 Sebastian Kiesel is partially supported by the NAPA-WINE project 637 (Network-Aware P2P-TV Application over Wise Networks, 638 http://www.napa-wine.org), a research project supported by the 639 European Commission under its 7th Framework Program (contract no. 640 214412). The views and conclusions contained herein are those of the 641 authors and should not be interpreted as necessarily representing the 642 official policies or endorsements, either expressed or implied, of 643 the NAPA-WINE project or the European Commission. 645 Marco Tomsu is partially supported by the 4WARD project 646 (http://www.4ward-project.eu), a research project supported by the 647 European Commission under its 7th Framework Program (contract no. 648 216041). The views and conclusions contained herein are those of the 649 authors and should not be interpreted as necessarily representing the 650 official policies or endorsements, either expressed or implied, of 651 the 4WARD project or the European Commission. 653 Authors' Addresses 655 Sebastian Kiesel 656 NEC Laboratories Europe 657 Kurfuerstenanlage 36 658 Heidelberg 69115 659 Germany 661 Email: kiesel@nw.neclab.eu 662 URI: http://www.nw.neclab.eu/ 664 Marco Tomsu 665 Alcatel-Lucent Bell Labs 666 Lorenzstrasse 10 667 Stuttgart 70435 668 Germany 670 Email: marco.tomsu@alcatel-lucent.com 671 URI: www.alcatel-lucent.com/bell-labs