idnits 2.17.1 draft-song-alto-server-discovery-00.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 : ---------------------------------------------------------------------------- ** There are 2 instances of too long lines in the document, the longest one being 8 characters in excess of 72. == There are 1 instance of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == The document doesn't use any RFC 2119 keywords, yet has text resembling RFC 2119 boilerplate text. -- The document date (March 2, 2009) is 5533 days in the past. Is this intentional? Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Unused Reference: 'RFC2782' is defined on line 510, but no explicit reference was found in the text == Unused Reference: 'RFC2629' is defined on line 527, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 530, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 534, but no explicit reference was found in the text == Outdated reference: A later version (-05) exists of draft-marocco-alto-problem-statement-04 ** Downref: Normative reference to an Informational draft: draft-marocco-alto-problem-statement (ref. 'I-D.marocco-alto-problem-statement') == Outdated reference: A later version (-07) exists of draft-ietf-dhc-container-opt-04 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) Summary: 3 errors (**), 0 flaws (~~), 9 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 ALTO H. Song, Ed. 3 Internet-Draft Huawei 4 Intended status: Standards Track R. Even 5 Expires: September 3, 2009 Gesher Erove 6 V. Pascual 7 Tekelec 8 Y. Zhang 9 China Mobile 10 March 2, 2009 12 Application-Layer Traffic Optimization (ALTO): Discover ALTO Servers 13 draft-song-alto-server-discovery-00 15 Status of this Memo 17 This Internet-Draft is submitted to IETF in full conformance with the 18 provisions of BCP 78 and BCP 79. 20 Internet-Drafts are working documents of the Internet Engineering 21 Task Force (IETF), its areas, and its working groups. Note that 22 other groups may also distribute working documents as Internet- 23 Drafts. 25 Internet-Drafts are draft documents valid for a maximum of six months 26 and may be updated, replaced, or obsoleted by other documents at any 27 time. It is inappropriate to use Internet-Drafts as reference 28 material or to cite them other than as "work in progress." 30 The list of current Internet-Drafts can be accessed at 31 http://www.ietf.org/ietf/1id-abstracts.txt. 33 The list of Internet-Draft Shadow Directories can be accessed at 34 http://www.ietf.org/shadow.html. 36 This Internet-Draft will expire on September 3, 2009. 38 Copyright Notice 40 Copyright (c) 2009 IETF Trust and the persons identified as the 41 document authors. All rights reserved. 43 This document is subject to BCP 78 and the IETF Trust's Legal 44 Provisions Relating to IETF Documents in effect on the date of 45 publication of this document (http://trustee.ietf.org/license-info). 46 Please review these documents carefully, as they describe your rights 47 and restrictions with respect to this document. 49 Abstract 51 A set of mechanisms are required to discover an Application-Layer 52 Traffic Optimization (ALTO) Server. These mechanisms enable 53 applications to find a reliable information source which provides 54 them with information regarding the underlying network. By providing 55 this information it would be possible to greatly increase application 56 performance, reduce congestion and optimize the overall traffic 57 across different networks. This document specifies the use of 58 general means such as DHCP, DNS or static configuration for ALTO 59 server discovery. 61 Table of Contents 63 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 3 64 1.1. Background . . . . . . . . . . . . . . . . . . . . . . . . 3 65 1.2. ALTO server distribution . . . . . . . . . . . . . . . . . 3 66 1.3. Concerns of ALTO server discovery . . . . . . . . . . . . 4 67 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 3. ALTO server discovery using Domain Name System (DNS) . . . . . 5 69 3.1. ALTO servers providing service to overall network . . . . 5 70 3.2. ALTO servers providing service to local networks . . . . . 6 71 3.2.1. ALTO server discovery by end terminals . . . . . . . . 6 72 3.2.2. ALTO server discovery by application trackers . . . . 9 73 4. Other ALTO server discovery mechanisms . . . . . . . . . . . . 11 74 4.1. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 11 75 4.2. Manual Configuration . . . . . . . . . . . . . . . . . . . 11 76 4.3. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 12 77 4.4. ALTO server discovery using DHCP . . . . . . . . . . . . . 12 78 5. Security Considerations . . . . . . . . . . . . . . . . . . . 12 79 6. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 12 80 7. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 81 8. References . . . . . . . . . . . . . . . . . . . . . . . . . . 12 82 8.1. Normative References . . . . . . . . . . . . . . . . . . . 12 83 8.2. Informative References . . . . . . . . . . . . . . . . . . 13 84 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 86 1. Introduction 88 1.1. Background 90 The ALTO problem statement draft [I-D.marocco-alto-problem-statement] 91 describes that in P2P applications or client/server applications, 92 resources are often available through multiple replicas and each of 93 those are sometimes provided by different service providers. ALTO 94 service gives guidance to a resource consumer or resource directory, 95 like p2p tracker or ALTO service proxy, about which resource 96 provider(s) to select, in order to optimize the client's performance 97 or quality of experience while optimizing resource consumption in the 98 underlying network infrastructure. 100 1.2. ALTO server distribution 102 An ALTO server is a logical entity that provides interfaces to query 103 the alto service. ALTO servers can be deployed by : 105 (1) A network operator which wants to optimize its traffic, e.g. 106 reduce its transit traffic across the network boundaries; 108 (2) A third party on behalf of one or more ISPs; 110 (3) user communities which run distributed algorithms, however, in 111 this case, the user community may not know the policy of network 112 operators, so with high probability it will also cause the 113 suboptimal result for the network operator while benefiting the 114 applications; 116 So there may be different ALTO servers distributed in different 117 operator's networks. 119 For (1), each network operator may provide the ALTO service using 120 their own ALTO servers. Each network operator may have its own 121 traffic optimization policy based on his network topology, however it 122 may not know other network operator's policies, nor be clear of other 123 network operator's topologies (e.g. topology hiding). The 124 application client must choose the ALTO service from the ALTO server 125 that has information about its local network topology and policy. So 126 in this case, each ALTO server must only provide service to the 127 clients in its own network. A request from a client to an ALTO 128 server not in its own operator's network may cause suboptimal result, 129 because that ALTO server does not observe the network from the 130 client's point of view. So each network operator deploys one or more 131 ALTO servers for clients in its own network. If it is a large ISP, 132 it may also deploy one or more ALTO servers for its sub networks, 133 such as autonomous systems (AS). 135 For (2), if a third party provides ALTO service on behalf of only one 136 ISP, it is similar to (1). 138 If a third party provides ALTO service on behalf of many ISPs, or a 139 user community which measures the overall network through some 140 mechanisms and provides ALTO service to numerous application clients 141 located in different network operators, the case is equal to a 142 conventional internet application server providing service to 143 application clients. 145 This document describes the ALTO server discovery mechanisms for both 146 environments where an ALTO server provides service to the overall 147 network or an ALTO server provides service only to its local network 149 1.3. Concerns of ALTO server discovery 151 The following issues should be considered when designing the ALTO 152 server discovery mechanism. 154 Load Balance: When more than one ALTO server provide identical 155 service for the same area, we must find a mechanism to balance the 156 processing load between the ALTO servers; 158 Well known port: If ALTO server provides service through a well 159 known port, then the discovery mechanism only needs to discover 160 the IP address of an ALTO server that can provide service for a 161 client, otherwise, the discovery mechanism must discover both IP 162 address and port number through which the ALTO server provides the 163 service. 165 IP address change: The IP address of the ALTO server may change in 166 some circumstances. The ALTO server discovery mechanism must be 167 well adaptable to this case when necessary. 169 Mobile Scenarios: When the end terminals are mobile equipments, 170 the data traffic may route via a roaming client's home agent's 171 router to the client, or route to the client directly. Which ALTO 172 server to choose should depend on the routing optimization mode 173 adopted for mobility. If the data traffic routes via the client's 174 home agent, it should choose the ALTO server that serves its home 175 area network, otherwise, it should choose the ALTO server that 176 serves its current network. 178 2. Terminology 180 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 181 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 182 document are to be interpreted in BCP 14, RFC 2119 [RFC2119] and 183 indicate requirement levels for compliant implementations. 185 Other terms used in this document are compatible with the definitions 186 in "ALTO problem statement" draft 187 [I-D.marocco-alto-problem-statement]. 189 3. ALTO server discovery using Domain Name System (DNS) 191 ALTO service is a conventional client/server mode service. The ALTO 192 server discovery scenarios are classified into two types: one is the 193 ALTO server providing service to overall network, and the other is 194 ALTO server providing service to the local network. 196 3.1. ALTO servers providing service to overall network 198 The ALTO servers providing service to overall network include the 199 ALTO servers provided by p2p application community and the ALTO 200 servers provided by third party for multiple network operators. 202 As shown in Figure 1. A simple ALTO server discovery mechanism is 203 used for this type of ALTO server. A DNS SRV query 204 [RFC2782]mechanism is used. The server must register its SRV 205 resource record with a well known service name (e.g. 206 _ALTO._TCP.example.com) in the DNS system. The service name in this 207 document refers to the name used for DNS SRV query, which includes 208 the service label, protocol name (TCP or UDP) and domain name. Any 209 ALTO client that wants to get the IP address and port of the ALTO 210 server sends a DNS SRV query to the DNS server in that domain . 212 +-------------------------------------+ 213 | | 214 | DNS | 215 | | 216 +-------------------------------------+ 217 ^ ^ 218 | | 219 | | 220 |DNS configuration |DNS queries 221 |or dynamic update |and responses 222 | | 223 v v 224 +-------------+ +-------------+ 225 | | | | 226 | | | | 227 | ALTO Server | | ALTO Client | 228 | | | | 229 +-------------+ +-------------+ 231 Figure 1: DNS query for well known ALTO servers 233 3.2. ALTO servers providing service to local networks 235 In this environment, one or several ALTO servers provide service to 236 their own network or autonomous system. There will be multiple ALTO 237 servers in the overall network. Each of the ALTO server may have a 238 FQDN. However, an end terminal can't easily determine its ALTO 239 server automatically. 241 3.2.1. ALTO server discovery by end terminals 243 In p2p applications without a tracker like DHTs and other 244 conventional client/server applications, an end user needs to 245 discover the ALTO server by itself. It should follow these steps: 247 (1) Through DHCP configuration, an end terminal retrieves the DNS 248 SRV service name for local ALTO servers which includes the service 249 provider's domain information, e.g. _ALTO._TCP.MyISP.com. A new 250 DHCP Option for the ALTO server discovery is needed. 252 The DHCPv4 ALTO_SRV_Name option has the following format: 254 0 1 2 3 255 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 256 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 257 | Code | len | | 258 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ . 259 . DNS SRV service name for local ALTO servers . 260 . . 261 . . 262 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 264 Code ALTO_SRV_Name_V4 (TBDv4) 266 len Length of DNS SRV service name for ALTO server, in octets 268 The DHCPv6 ALTO_SRV_Name option has the following format: 270 0 1 2 3 271 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 272 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 273 | OPTION_ALTO_SRV_Name_V6 | option-len | 274 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 275 | DNS SRV service name for local ALTO servers | 276 . . 277 . . 278 . . 279 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+ 281 option-code OPTION_ALTO_SRV_Name_V6 (TBDv6). 283 option-len Length of DNS SRV service name for ALTO server, in octets 285 Once the ALTO server's service name is retrieved, the end terminal 286 should cache this service name for later use. 288 It should be noticed that there are many residential gateways (RG) 289 which can act as DHCP servers themselves. RG becomes a hindrance 290 between the end terminals and the ALTO service provider's DHCP 291 server if we use DHCP. It should not depend on the update of all 292 these RGs to support this new DHCP Option for ALTO server 293 discovery. A DHCP Container Option [I-D.ietf-dhc-container-opt] 294 for server configuration must be used here. With the Container 295 Option, the DHCP server for the consumer domain (e.g. RGs) can 296 just pass the server configuration to the end terminals without 297 explicit knowledge of the DHCP options contained in the Container. 298 The DHCP Option for the ALTO service name should be contained in 299 the Container Option. 301 (2) The end terminal sends an SRV query to the DNS server with the 302 service name. It will retrieve the SRV RR with ALTO server 303 instance name and port information, maybe together with a TXT 304 description RR and an A RR with the IP address of the ALTO server. 305 However, an additional A query is needed if the A RR corresponding 306 to the ALTO server instance is not retrieved at the same time. 307 Eventually the end terminal will get the IP address and port of 308 the ALTO server. If there are more than one ALTO servers in the 309 domain, the DNS server must balance the load between the ALTO 310 servers according to the "priority" and "weight" value in the 311 corresponding SRV RRs. Once the transport address of the ALTO 312 server is retrieved, the end terminal should cache it for later 313 use. 315 (3) The end terminal than accesses the ALTO server to get service; 317 Here DHCP protocol is used to retrieve the service name instead of 318 the IP address because the IP address may change and the 319 configuration for the DHCP server is very troublesome. Besides that, 320 with the DNS SRV query, its existing load balance mechanism can be 321 used, instead of introducing a new load balance mechanism in DHCP 322 server. 324 The following Figure 2 and Figure 3 depicts the first and second step 325 of the ALTO server discovery for end terminals. 327 +-------------+ 328 | | 329 | DHCP Server | 330 | | 331 +-------------+ 332 ^ 333 | 334 | 335 |use DHCP to 336 |retrieve local ALTO 337 |service name 338 v 339 +-------------+ 340 | | 341 | Client | 342 | | 343 +-------------+ 345 Step 1: retrieving service name 346 Figure 2: retrieving service name with DHCP 348 +-------------+ 349 | | 350 | DNS Server | Load Balance 351 | | 352 +-------------+ 353 ^ 354 |SRV and other queries 355 |to retrieve ALTO 356 |server address info 357 | 358 | 359 v 360 +-------------+ 361 | | 362 | Client | 363 | | 364 +-------------+ 365 Step 2: DNS query for ALTO server address info 367 Figure 3: retrieving ALTO server address with DNS 369 3.2.2. ALTO server discovery by application trackers 371 Some p2p applications have trackers, and these applications don't 372 need to have their clients looking for the ALTO server guidance. 373 Trackers query the ALTO servers for guidance, and then return the 374 final ranked result to the application clients. However, application 375 clients are distributed among different network operators and 376 autonomous systems. Trackers must find different ALTO servers for 377 the clients located in different network operators or autonomous 378 systems. 380 Here are the steps for ALTO server discovery in this type of 381 scenarios: 383 (1) The tracker should determine to which physical location the 384 corresponding application client belongs to, i.e. which network 385 operator and/or autonomous system the application client belongs 386 to. The subsidiary organizations (e.g. APNIC) of IANA have the 387 information database for the mapping between IP range to ISP/AS or 388 other organizations. The WHOIS service [WWW.WHOIS] on the 389 Internet is also available for this purpose. However, the mapping 390 information may be changed due to the business deals and network 391 adjustment. DHCP can also be used to retrieve the ISP/AS 392 information to the end user, and the tracker can collect the 393 information from its clients. 395 (2) The tracker must determine the ALTO server for the 396 corresponding network operator and or/ autonomous system. The 397 tracker should maintain a complete mapping table between (a) the 398 identities of network operators and/or autonomous systems and (b) 399 ALTO server service names. The tracker sends a SRV query to the 400 DNS server (an additional A query is needed when SRV query only 401 responds with ALTO server instance name) to retrieve the ALTO 402 server address information for its application client. From the 403 perspective of efficiency, the tracker should cache the mapping 404 information between network operators and ALTO server addresses 405 for later use. 407 (3) The tracker contacts with the ALTO server for guidance on 408 behalf of the application client; and sends the final ranked peer 409 list to the application client. 411 Figure 4 shows an example for tracker's ALTO server discovery. For 412 client 1, the tracker has not cached yet the mapping between client 413 1's network operator and its ALTO server address, so it queries the 414 DNS server for the ALTO server address in that operator's domain. 415 And then the tracker interacts with the ALTO server on behalf of 416 client 1, finally, the ranked list is sent back to client 1. For 417 client 2, the tracker has cached the mapping between client 2's 418 network operator and its ALTO server address, so it does not need to 419 query the DNS for the address of ALTO server 2. 421 +-------------+ +-------------+ 422 | | | | 423 | ALTO Server1| | ALTO Server2| 424 | | | | 425 +-------------+ +-------------+ 426 ^ | ^ | 427 | | | | 428 3| 4| b| |c 429 | | | | 430 | | | | 431 v /---------------+-\ v 432 +------+ ////// \\\\\\ 433 | | ||| ||| 434 | |<----->| || 435 | DNS | 2 | Application Tracker | 436 | | ||| ||| 437 | | \\\\\\ ////// 438 +------+ ^ | \-----------------/ | 439 | | ^ | 440 | |5 | |d 441 1| | a| | 442 | | | | 443 | v | v 444 +-+-----------+ +---+---------+ 445 | | | | 446 |Application | |Application | 447 |client1 | |client2 | 448 +-------------+ +-------------+ 450 Figure 4: Example for tracker's ALTO discovery 452 4. Other ALTO server discovery mechanisms 454 4.1. Provisioning 456 A network operator can simply provide a configuration file that 457 contains the ALTO server address for its clients, provided that there 458 are only one or a few ALTO servers which provide identical service 459 for its network. An application can also provide such a 460 configuration file containing the ALTO server address if an existing 461 ALTO server provides identical service to the overall network. 463 4.2. Manual Configuration 465 ALTO server information could also be configured on the ALTO client 466 by a user or service provider manually. 468 4.3. Caching 470 Once a client has located an ALTO server for the first time, it can 471 cache it for use as future ALTO server. 473 4.4. ALTO server discovery using DHCP 475 An ALTO client can discover an ALTO server through auto-configuration 476 protocols. A new option could be defined in DHCP protocol to 477 retrieve the IP address of local ALTO servers directly. However, it 478 has drawbacks as described in Section 3.2.1. 480 5. Security Considerations 482 As this document mainly proposes to use DNS and DHCP for ALTO service 483 discovery, it will depend on the DHCP security and DNS security for 484 this service discovery. 486 6. IANA Considerations 488 The service label for the ALTO service will depend on the final 489 protocol name for application-layer traffic optimization(TBD). 491 This document requests IANA to assign an option tag from the "BOOTP 492 Vendor Extensions and DHCP Options" registry for ALTO_SRV_Name_V4 493 (TBDv4). 495 This document requests IANA to assign an option code from the "DHCPv6 496 Option Codes" registry for OPTION_ALTO_SRV_Name_V6 (TBDv6). 498 7. Acknowledgements 500 The authors thank the review and valuable comments from Y. Richard 501 Yang, Xingfeng Jiang, Jay Gu and Ning Zong. 503 8. References 505 8.1. Normative References 507 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 508 Requirement Levels", BCP 14, RFC 2119, March 1997. 510 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 511 specifying the location of services (DNS SRV)", RFC 2782, 512 February 2000. 514 [I-D.marocco-alto-problem-statement] 515 Seedorf, J. and E. Burger, "Application-Layer Traffic 516 Optimization (ALTO) Problem Statement", 517 draft-marocco-alto-problem-statement-04 (work in 518 progress), February 2009. 520 [I-D.ietf-dhc-container-opt] 521 Droms, R., "Container Option for Server Configuration", 522 draft-ietf-dhc-container-opt-04 (work in progress), 523 November 2008. 525 8.2. Informative References 527 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 528 June 1999. 530 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 531 Text on Security Considerations", BCP 72, RFC 3552, 532 July 2003. 534 [I-D.narten-iana-considerations-rfc2434bis] 535 Narten, T. and H. Alvestrand, "Guidelines for Writing an 536 IANA Considerations Section in RFCs", 537 draft-narten-iana-considerations-rfc2434bis-09 (work in 538 progress), March 2008. 540 [WWW.WHOIS] 541 "http://www.whois.net". 543 Authors' Addresses 545 Song Haibin (editor) 546 Huawei 547 Baixia Road No. 91 548 Nanjing, Jiangsu Province 210001 549 P.R.China 551 Phone: +86-25-84565867 552 Fax: +86-25-84565888 553 Email: melodysong@huawei.com 554 Roni Even 555 Gesher Erove 556 14 David Hamelech 557 Tel Aviv 64953 558 Israel 560 Email: ron.even.tlv@gmail.com 562 Victor Pascual 563 Tekelec 564 Am Borsigturm 11 565 Berlin D-13507 566 Germany 568 Phone: +49 30 32 51 32 12 569 Email: victor@iptel.org 571 Yunfei Zhang 572 China Mobile 574 Phone: +86 10 66006688 575 Email: zhangyunfei@chinamobile.com