idnits 2.17.1 draft-song-alto-server-discovery-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 : ---------------------------------------------------------------------------- ** There is 1 instance of too long lines in the document, the longest one being 2 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 == Line 189 has weird spacing: '...Service o ...' == Line 221 has weird spacing: '... | |ooo o...' == Line 248 has weird spacing: '... | |ooo o...' -- The document date (July 11, 2009) is 5402 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) == Missing Reference: 'Infoexp' is mentioned on line 317, but not defined == Unused Reference: 'RFC2629' is defined on line 748, but no explicit reference was found in the text == Unused Reference: 'RFC3552' is defined on line 751, but no explicit reference was found in the text == Unused Reference: 'I-D.cheshire-dnsext-multicastdns' is defined on line 762, but no explicit reference was found in the text == Unused Reference: 'I-D.narten-iana-considerations-rfc2434bis' is defined on line 773, but no explicit reference was found in the text ** Obsolete normative reference: RFC 2915 (Obsoleted by RFC 3401, RFC 3402, RFC 3403, RFC 3404) == Outdated reference: A later version (-04) exists of draft-ietf-alto-problem-statement-02 ** Downref: Normative reference to an Informational draft: draft-ietf-alto-problem-statement (ref. 'I-D.ietf-alto-problem-statement') == Outdated reference: A later version (-15) exists of draft-ietf-geopriv-lis-discovery-11 == Outdated reference: A later version (-07) exists of draft-ietf-dhc-container-opt-05 -- Obsolete informational reference (is this intentional?): RFC 2629 (Obsoleted by RFC 7749) == Outdated reference: A later version (-15) exists of draft-cheshire-dnsext-multicastdns-07 Summary: 4 errors (**), 0 flaws (~~), 14 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 M. Tomsu, Ed. 5 Expires: January 12, 2010 Alcatel-lucent Bell Labs 6 G. Garcia 7 Telefonica I+D 8 Y. Wang 9 Microsoft Corp. 10 V. Pascual 11 Tekelec 12 July 11, 2009 14 ALTO Service Discovery 15 draft-song-alto-server-discovery-01 17 Status of this Memo 19 This Internet-Draft is submitted to IETF in full conformance with the 20 provisions of BCP 78 and BCP 79. 22 Internet-Drafts are working documents of the Internet Engineering 23 Task Force (IETF), its areas, and its working groups. Note that 24 other groups may also distribute working documents as Internet- 25 Drafts. 27 Internet-Drafts are draft documents valid for a maximum of six months 28 and may be updated, replaced, or obsoleted by other documents at any 29 time. It is inappropriate to use Internet-Drafts as reference 30 material or to cite them other than as "work in progress." 32 The list of current Internet-Drafts can be accessed at 33 http://www.ietf.org/ietf/1id-abstracts.txt. 35 The list of Internet-Draft Shadow Directories can be accessed at 36 http://www.ietf.org/shadow.html. 38 This Internet-Draft will expire on January 12, 2010. 40 Copyright Notice 42 Copyright (c) 2009 IETF Trust and the persons identified as the 43 document authors. All rights reserved. 45 This document is subject to BCP 78 and the IETF Trust's Legal 46 Provisions Relating to IETF Documents in effect on the date of 47 publication of this document (http://trustee.ietf.org/license-info). 48 Please review these documents carefully, as they describe your rights 49 and restrictions with respect to this document. 51 Abstract 53 Application-Layer Traffic Optimization (ALTO) service aims to provide 54 distributed applications with information to perform better-than- 55 random initial peer selection when multiple peers in the network are 56 available to provide a resource or service. In order to discover an 57 Application-Layer Traffic Optimization (ALTO) Server, a set of 58 mechanisms are required. These mechanisms enable applications to 59 find an information source which provides them with information 60 regarding the underlying network. This document discusses various 61 scenarios of ALTO discovery and specifies the use of several 62 available options such as DHCP or DNS. 64 Table of Contents 66 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 67 1.1. History . . . . . . . . . . . . . . . . . . . . . . . . . 4 68 1.2. Overview . . . . . . . . . . . . . . . . . . . . . . . . . 4 69 2. Terminology . . . . . . . . . . . . . . . . . . . . . . . . . 5 70 3. ALTO Service Deployment . . . . . . . . . . . . . . . . . . . 5 71 3.1. ISP-Centric vs. Application-Specific ALTO Service 72 Deployments . . . . . . . . . . . . . . . . . . . . . . . 6 73 3.2. Cross-domain vs. Localized ALTO Server Discovery . . . . . 8 74 4. ALTO Service Discovery Scenarios . . . . . . . . . . . . . . . 8 75 4.1. Discovery Metrics . . . . . . . . . . . . . . . . . . . . 8 76 4.1.1. Discovery Clients . . . . . . . . . . . . . . . . . . 8 77 4.1.2. Service Location . . . . . . . . . . . . . . . . . . . 9 78 4.1.3. Layering Perspective . . . . . . . . . . . . . . . . . 9 79 4.2. Discovery Scenarios . . . . . . . . . . . . . . . . . . . 9 80 4.2.1. Local ALTO service discovery by end terminals . . . . 9 81 4.2.2. Local ALTO service discovery by application 82 trackers . . . . . . . . . . . . . . . . . . . . . . . 10 83 5. ALTO Service Discovery Mechanisms . . . . . . . . . . . . . . 11 84 5.1. ALTO service discovery using Domain Name System (DNS) . . 12 85 5.1.1. DNS-based ALTO discovery . . . . . . . . . . . . . . . 12 86 5.1.2. Determine Service Name of Local ALTO servers . . . . . 13 87 5.1.2.1. Using DHCP option for access domain name . . . . . 13 88 5.1.2.2. Use IANA Database . . . . . . . . . . . . . . . . 14 89 5.1.2.3. Reverse DNS lookup . . . . . . . . . . . . . . . . 14 90 5.2. DHCP . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 91 5.3. XRD . . . . . . . . . . . . . . . . . . . . . . . . . . . 15 92 5.4. Provisioning . . . . . . . . . . . . . . . . . . . . . . . 15 93 5.5. Manual Configuration . . . . . . . . . . . . . . . . . . . 15 94 5.6. Multicast and broadcast . . . . . . . . . . . . . . . . . 15 95 5.7. Caching . . . . . . . . . . . . . . . . . . . . . . . . . 16 96 6. Security Considerations . . . . . . . . . . . . . . . . . . . 16 97 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 17 98 8. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17 99 9. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17 100 9.1. Normative References . . . . . . . . . . . . . . . . . . . 17 101 9.2. Informative References . . . . . . . . . . . . . . . . . . 18 102 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19 104 1. Introduction 106 1.1. History 108 This document represents a merge of features from two previous 109 drafts: 111 (1). draft-wang-alto-discovery-00 113 (2). draft-song-alto-server-discovery-00 115 The ALTO service architecture and protocol are currently under 116 discussion and development within the IETF ALTO working group. 118 Although it is identified in the charter that a discovery mechanism 119 is needed, the preference is to adopt one or more existing mechanisms 120 for ALTO discovery rather than designing a new one. Note though 121 certain design decisions of the final ALTO framework will affect the 122 selection of discovery mechanisms. As a result, this document makes 123 minimum assumptions of the ALTO framework, and presents different 124 scenarios and available options based on prior and related discovery 125 mechanisms. This document will be updated to track the progress of 126 the ALTO requirements and solution. 128 1.2. Overview 130 The ALTO problem statement draft [I-D.ietf-alto-problem-statement] 131 describes that in P2P applications or client/server applications, 132 resources or services are often available through multiple replicas 133 and each of those are sometimes provided by different providers. 134 ALTO service gives guidance to a consumer or directory about which 135 resource provider(s) to select, in order to optimize the client's 136 performance or quality of experience while optimizing resource 137 consumption in the underlying network infrastructure. 139 In order to query the ALTO server, clients must first know one or 140 more ALTO servers that might provide useful information. The purpose 141 of the ALTO discovery mechanism is to find those servers in different 142 network and application scenarios. 144 Section 3 and Section 4 discuss various scenarios of ALTO service 145 deployment and discovery. Section 5 provides a description of 146 available discovery mechanisms and its application to the ALTO 147 service discovery use case addressing potential issues and 148 consideration for each. 150 2. Terminology 152 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 153 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 154 document are to be interpreted as described in [RFC2119]. 156 The document uses terms defined in [I-D.ietf-alto-problem-statement]. 158 In addition to the generic ALTO descriptions, the following terms are 159 used to describe the discovery mechanisms in this document: 161 o ALTO Discovery Client: The logical entity discovering the ALTO 162 Service. Depending on the scenario, this could be a Peer or a Super- 163 peer/Tracker. 165 o ALTO Discovery Server: The logical entity providing information to 166 locate the ALTO Service. Depending on the discovery mechanism, this 167 could be another Peer or a dedicated entity in the network. 169 o ALTO Discovery Domain: The scope of the network handled by a 170 particular ALTO Discovery Server. 172 3. ALTO Service Deployment 174 This section explores the various dimensions of the ALTO service 175 deployment and access scenarios, and briefly discusses their 176 implications to the discovery mechanisms. Figure 1 below shows a 177 generic ALTO framework diagram with discovery. . 179 +------+ 180 +-----+ | Peers 181 +-----+ +------+ +=====| |--+-oo 182 | |......| |====+ oo+--*--+ o 183 +-----+ +------+ | o * ooooooo 184 Source of ALTO | o * 185 Topological Service | o +--*--+ 186 information +===o=| | Tracker 187 o +-----+ /Super-peer 188 ALTO Discovery o o 189 Service o o 190 +------+ o o 191 | |oooooooooo 192 +------+ 194 Legend: 196 === ALTO query protocol 197 ooo ALTO service discovery protocol 198 *** Application protocol (out of scope) 199 ... Provisioning or initialization (out of scope) 201 Figure 1 ALTO Discovery Diagram 203 3.1. ISP-Centric vs. Application-Specific ALTO Service Deployments 205 An ALTO Server is the logical entity that provides query interfaces 206 for ALTO Clients. ALTO servers can be deployed in an ISP-centric 207 deployment or on the application level by application providers or 208 other trusted third parties: 210 1. A network operator which wants to optimize its traffic, e.g. to 211 reduce its transit traffic volume across the network boundaries; a 212 third party on behalf of one or even several ISPs. 214 +-----------+ +-----------+ +---------+ 215 |ALTO Server| |ALTO Server| |ALTO | 216 | A | | B | |Service | 217 +-----------+ +-----------+ |Discovery| 218 ^ ^ +---------+ 219 +---+--+ +---+--+ o o 220 +|------|-------------------|------|-+ o o 221 || | P2P Appication A | | |ooo o 222 ++------+-------------------+------+-+ o 223 | | | | o 224 ++------+-------------------+------+-+ o 225 || | P2P Applcation B | | |oooooooo 226 ++------+-------------------+------+-+ 227 |ISP A | .............. | ISP B| 228 +------+ +------+ 230 Figure 2: ISP-centric ALTO service deployment example 232 2. The application provider itself, a trusted third party or a user 233 community: acting on the application level and spanning different 234 networks. They run distributed algorithms to measure the overall 235 network through some mechanisms and provide an ALTO service to 236 numerous application clients. However in this case, the application 237 level service may not know the policy of network operators, so with 238 high probability it will also cause suboptimal result for the network 239 operator while benefitting the applications. 241 +---------+ 242 +-----------+ |ALTO | 243 |ALTO Server| |Service | 244 +-----------+ |Discovery| 245 ^ ^ +---------+ 246 +------+ | | +------+ o o 247 +|------|--+---------|------|------|-+ o o 248 || | P2P Appication A | | |ooo o 249 ++------+------------+------+------+-+ o 250 | | | | | o 251 ++------+------------|------+------+-+ o 252 || | P2P Applcation B | | |oooooooo 253 ++------+-------------------+------+-+ 254 |ISP A | .............. | ISP B| 255 +------+ +------+ 257 Figure 3: Application-centric ALTO service deployment example 259 3.2. Cross-domain vs. Localized ALTO Server Discovery 261 For cross domain scenarios, the ALTO service includes the ALTO 262 servers provided by p2p application community as well as the ALTO 263 servers provided by a third party on behalf of multiple cooperating 264 network operators. 266 So there may be several ALTO servers distributed in different 267 operator's networks. 269 Each operator may provide the ALTO service using their own ALTO 270 servers. Each network operator may have its own traffic optimization 271 policy based on his network topology, however it may not know other 272 network operator's policies, nor be clear of other network operator's 273 topologies (e.g. topology hiding). Each of the ALTO servers may have 274 a FQDN. 276 The ALTO client (e.g. the Tracker) must be able to discover and 277 choose the ALTO server that has the information that is specific to 278 those clients located within that network. 280 In localized discovery deployments one or several ALTO servers 281 provide the service only to clients in their own network or 282 autonomous system. 284 4. ALTO Service Discovery Scenarios 286 4.1. Discovery Metrics 288 4.1.1. Discovery Clients 290 The ALTO Client can be the Peer in the end-user host or an external 291 entity like a Super-peer or Resource Directory (aka Tracker) on 292 behalf of the Peer [I-D.ietf-alto-problem-statement]. If a Super- 293 Peer or Tracker acts as an ALTO Client it needs to know and select 294 the suitable ALTO Service for the Peer being served. 296 In a hybrid model the location of the ALTO Server could be 297 communicated from the Peer to the Super-Peer using the application 298 protocol. It could also be discovered by the Super-Peer from other 299 Peer information received implicitly (like the Peer public IP 300 address) or received explicitly. 302 There could be scenarios where only the Peer (and not the Super-Peer/ 303 Tracker) is able to access the ALTO Service, for example if the ALTO 304 Server is located in a private network. 306 4.1.2. Service Location 308 The ALTO service could be provided in a distributed and cooperative 309 fashion by the Peers in an overlay, or it can be provided by a 310 centralized entity (the ALTO Server) for a given scope. In the 311 former case, a DHT-style key-based routing algorithm could be used to 312 locate the peers with the target network information in this type of 313 distributed environment. For the latter case, where a centralized 314 ALTO Server is implicitly or explicitly assigned to a specific 315 network scope, an out-of-band discovery mechanism is often required. 317 All current ALTO solution proposals, ([Infoexp], 318 [I-D.wang-alto-p4p-specification]), fall into the second category. 320 The ALTO Server for a Peer could be in the same Local Area Network 321 (LAN), within the same ISP Network but not on the same LAN, or in the 322 Global Internet outside the ISP Network. Different network scopes 323 place different constraints on the discovery mechanisms. Multicast 324 discovery generally works within a single LAN only, whereas DNS-based 325 or DHCP-based discovery can span multiple subnets within a single ISP 326 or a single network administrative domain. Internet scope discovery 327 usually requires cross-domain indexing or directory services. Note 328 that peers participating in a single P2P application may reside on 329 the same or different ISP networks. Scenarios like this may require 330 hybrid discovery solutions that can adapt to multiple network scopes 331 at the same time. The discovery mechanisms listed in this document 332 should take into account possible limitations of the ALTO service 333 deployment in those network scopes. 335 4.1.3. Layering Perspective 337 The discovery process takes place before the first access to the ALTO 338 server. This discovery process could be done at host network 339 initialization time, at application initialization time or just 340 before the first ALTO query is sent. 342 4.2. Discovery Scenarios 344 The ALTO service discovery scenarios are classified into two types: 345 one is the ALTO server providing service to the overall network, and 346 the other is where the ALTO server is providing service to the local 347 network. 349 4.2.1. Local ALTO service discovery by end terminals 351 In p2p applications without a tracker like DHTs and other 352 conventional client/server applications, an end device needs to 353 discover the local ALTO server by itself. 355 After the discovery of an ALTO server, the p2p client can get 356 guidance from the ALTO server directly or through its application 357 tracker. 359 +---------------+ 360 | ALTO Server | 361 +---------------+ 362 ^ ^ +-----------+ 363 | | | ALTO | 364 | +---+---+ | Service | 365 | |tracker| | Discovery | 366 | +-------+ +---------+-+ 367 | | o o 368 +------------+--+ | o o 369 |P2P Application|ooooo|oooooooooooo o 370 | Client A | | o 371 +---------------+ | o 372 | o 373 +--+-------------+ o 374 | P2P Application|oooooo 375 | Client B | 376 +----------------+ 378 Figure 4: Local ALTO service discovery by end terminals (Example) 380 4.2.2. Local ALTO service discovery by application trackers 382 Some p2p applications have trackers, and these applications don't 383 need to have their clients looking for the ALTO server guidance. 384 Trackers query the ALTO servers for guidance, and then return the 385 final ranked result to the application clients. However, application 386 clients are distributed among different network operators and 387 autonomous systems. Trackers must find different ALTO servers for 388 the clients located in different network operators or autonomous 389 systems. 391 Figure 5 shows an example for a tracker's ALTO server discovery. For 392 client 1, the tracker has not cached yet the mapping between client 393 1's network operator and its ALTO server address, so it queries the 394 DNS server for the ALTO server address in that operator's domain. 395 And then the tracker interacts with the ALTO server on behalf of 396 client 1, finally, the ranked list is sent back to client 1. For 397 client 2, the tracker has cached the mapping between client 2's 398 network operator and its ALTO server address, so it does not need to 399 query the DNS for the address of ALTO server 2. 401 +-------------+ +-------------+ 402 | ALTO Server1| | ALTO Server2| 403 +-------------+ +-------------+ 404 ^ | ^ | 405 3| 4| b| |c 406 | | | | 407 v /----------+-\ v 408 +---+ ////// \\\\\ 409 | | ||| ||| 410 | |<--->| | 411 |DNS| 2 | Application Tracker | 412 | | ||| ||| 413 | | \\\\\\ ///// 414 +---+ ^ | \------------/ | 415 | |5 ^ |d 416 1| | a| | 417 | v | v 418 +-+---------+ +---+--------+ 419 |Application| |Application | 420 |client1 | |client2 | 421 +-----------+ +------------+ 423 Figure 5: Local ALTO service discovery by application trackers (Example) 425 5. ALTO Service Discovery Mechanisms 427 One ALTO client should use one or several of the introduced discovery 428 mechanisms according to its application scenario until it finally 429 finds an appropriate ALTO server. 431 The following issues should be considered when designing the ALTO 432 service discovery mechanism. 434 Load Balance: When more than one ALTO server provide identical 435 service for the same area, we must find a mechanism to balance the 436 processing load between the ALTO servers; 438 Well known port: If ALTO server provides service through a well 439 known port, then the discovery mechanism only needs to discover 440 the IP address of an ALTO server that can provide service for a 441 client, otherwise, the discovery mechanism must discover both IP 442 address and port number through which the ALTO server provides the 443 service. 445 Note:It will depend on the ALTO protocol whether a well know 446 port is used for the ALTO server. If there is no well known 447 port for the ALTO server, we need to discover the port 448 information with the discovery process. 450 IP address change: The IP address of the ALTO server may change in 451 some circumstances. The ALTO service discovery mechanism must be 452 well adaptable to this case when necessary. 454 Mobile Scenarios: When the end terminals are mobile equipments, 455 the data traffic may route via a roaming client's home agent's 456 router to the client, or route to the client directly. Which ALTO 457 server to choose should depend on the routing optimization mode 458 adopted for mobility. If the data traffic routes via the client's 459 home agent, it should choose the ALTO server that serves its home 460 area network, otherwise, it should choose the ALTO server that 461 serves its current network. 463 5.1. ALTO service discovery using Domain Name System (DNS) 465 DNS is widely used on the Internet to discover the server address for 466 applications. ALTO service is a conventional client/server mode 467 service, which can use DNS lookup for its service discovery. 469 NAPTR [RFC2915] and SRV [RFC2782] DNS resource records are 470 appropriate to provide service discovery mechanisms. The concrete 471 application of these resource records depends on the final ALTO 472 requests/response protocol. The use of NAPTR or SRV records is a 473 trade-off between flexibility and simplicity. S-NAPTR [RFC3958] and 474 U-NAPTR [RFC4848] mechanisms provide a Dynamic Delegation Discovery 475 System (DDDS) Application to map domain name, service name and 476 protocol name to a target host and port or to a target URI. SRV 477 records provide a mechanism to map domain name, service name and 478 transport protocol name to a target host and port. The use of a 479 NAPTR or SRV solution is open to discussion and depends on the 480 requirements of the ALTO protocol. Next section will asume the use 481 use of SRV records in the next sections are based on SRV. 483 5.1.1. DNS-based ALTO discovery 485 Figure 6. shows a general DNS ALTO server discovery mechanism. A 486 server must register its SRV resource record with a well known 487 service name (e.g. _ALTO._TCP.example.com) in the DNS system. The 488 service name in this document refers to the name used for DNS SRV 489 query, which includes the service label, protocol name (TCP or UDP) 490 and domain name. Any ALTO client that wants to get the IP address 491 and port of the ALTO server sends a DNS SRV query to the DNS server 492 in that domain . 494 +-------------------------------------+ 495 | DNS | 496 +-------------------------------------+ 497 ^ ^ 498 | | 499 | | 500 |DNS configuration |DNS queries 501 |or dynamic update |and responses 502 | | 503 v v 504 +-------------+ +-------------+ 505 | | | ALTO | 506 | ALTO Server | | Discovery | 507 | | | Client | 508 +-------------+ +-------------+ 510 Figure 6: DNS query for well known ALTO servers 512 5.1.2. Determine Service Name of Local ALTO servers 514 An ALTO discovery client must know its ALTO service name for it 515 before sending a query to the DNS system. Some ALTO servers may 516 provide service to the overall network, they may have well-known 517 service name. But in most cases, one ALTO server will only provide 518 service to its own local access network or autonomous system. There 519 will be multiple ALTO servers in the overall network. An ALTO 520 discovery client needs to find the service name of its local ALTO 521 server. 523 5.1.2.1. Using DHCP option for access domain name 525 There are DHCP options (OPTION_V4_ACCESS_DOMAIN and 526 OPTION_V6_ACCESS_DOMAIN) proposed in [I-D.ietf-geopriv-lis-discovery] 527 to discover the local access domain names. The retrieved access 528 domain name can be used to form a SRV name by prefixing the ALTO 529 service label to the access domain name. If it failed with the SRV 530 lookup with this service name, then it will remove one tag from the 531 left hand of the access domain name and prefix the ALTO service label 532 to form a new SRV name. It will iterate the process until it 533 succeeds in getting an ATLO server information or failed. 535 It should be noticed that there are many residential gateways (RG) 536 which can act as DHCP servers themselves. RG becomes a hindrance 537 between the end terminals and the ALTO service provider's DHCP server 538 if we use DHCP. It should not depend on the update of all these RGs 539 to support this new DHCP Option for ALTO server discovery. A DHCP 540 Container Option [I-D.ietf-dhc-container-opt] for server 541 configuration should be used here. With the Container Option, the 542 DHCP server for the consumer domain (e.g. RGs) can just pass the 543 server configuration to the end terminals without explicit knowledge 544 of the DHCP options contained in the Container. The DHCP Option for 545 the access domain name could be contained in the Container Option. 547 5.1.2.2. Use IANA Database 549 The service name of a client's local ALTO server could be formed by 550 adding the service and protocol label before its domain information. 551 IANA and its subsidiary organizations (e.g. APNIC) database can be 552 used to lookup the physical domain of a client through its public IP 553 address, i.e. which network operator and/or autonomous system the 554 client belongs to. The WHOIS service [WWW.WHOIS] on the Internet is 555 also available for this purpose. This mechanism requires ISPs assign 556 the domain names to their ALTO servers according to the AS and ISP 557 information (e.g. they have a rule to format the domain name, 558 AS.ISP.COM), then you can rebuid the domain name with the information 559 retrieved from WHOIS. Otherwise, you can't. 561 However, the mapping information may be changed due to the business 562 deals and network adjustment. For example, an ISP could sell some 563 part of its network (include all equipments, IP addresses, AS number, 564 and so on) to another ISP, and the ISP does not have the 565 responsibility to notify the IANA, and then the information in the 566 IANA database is wrong. 568 5.1.2.3. Reverse DNS lookup 570 BEP 22 [BEP-22] framework uses reverse DNS lookup to determine the 571 domain name of a client through its public address. And then use 572 service label and the domain name to lookup the local server in DNS. 573 The following limitations should be considered when use this 574 mechanism. 576 (1) This method assumes that the access network provider also 577 provides the reverse DNS record and they control the domain that is 578 indicated in the "PTR" record. (In most cases it is true, but not 579 always) 581 (2) Furthermore, this method might not apply where a host is given a 582 domain name that is different from the domain name of the access 583 network. 585 (3) In case of NAT and a public ALTO server, it requires the ALTO 586 client to know its public IP address. 588 The advantage is that it doesn't require any update/configuration/ 589 change in the DHCP servers of any residential gateway. 591 5.2. DHCP 593 There are other ways using DHCP to locate an ALTO server. One 594 suggestion is to use DHCP to obtain the ALTO server IP address and 595 port information directly. New DHCP options are needed for this 596 purpose. The residential gateways consideration for DHCP option must 597 be considered as described in . (Section 5.1.2.1) 599 With this mechanism, the DHCP server needs to support load balance if 600 there are more than one ALTO servers for this access domain. The 601 maintenance is costly when the address of ALTO server changes. 603 5.3. XRD 605 XRD is described in [XRD-1.0]. In order to begin the XRD discovery 606 you need the URL (or XRI) of the resource you want to discover links/ 607 services related to. In other XRD use cases like OpenId or 608 OpenSocial, it is clear that you know that URL (the OpenId url of the 609 user, or the url of the OS container). But in case of ALTO Server 610 Discovery, the obtainment of this initial URL also needs to use some 611 discovery framework. 613 5.4. Provisioning 615 A network operator can simply provide a configuration file that 616 contains the ALTO server address for its clients, provided that there 617 are only one or a few ALTO servers which provide identical service 618 for its network. An application can also provide such a 619 configuration file containing the ALTO server address if an existing 620 ALTO server provides identical service to the overall network. 622 5.5. Manual Configuration 624 Manual configuration of the ALTO service location(s) could work in a 625 single ISP network scope, but is not scalable when multiple ISPs or 626 cross-domain ALTO services are required. P2P applications often 627 connect peers from ISPs that they may not have contacted before, and 628 manual configuration will not work without any prior knowledge of the 629 ALTO servers. 631 5.6. Multicast and broadcast 633 Multicast or broadcast MAY be used in some scenarios for ALTO 634 discovery. 636 IP-multicast-based discovery generally works in two ways: 638 1. Clients send out multicast discovery requests and listen for 639 responses (usually unicast) from available servers or service 640 providers. 642 2. Servers or service providers send out multicast announcements 643 when they become available or periodically, and clients waits for the 644 next available multicast announcement to identify the servers or 645 service providers. 647 The on-demand requests and periodic announcements are not mutually 648 exclusive. An implementation can choose to utilize both 649 simultaneously. The configuration effort of multicast discovery is 650 fairly straightforward, only the multicast address and port are 651 needed. Service types and additional information are often encoded 652 in the requests or announcements messages, enabling the same 653 multicast channel to support discovery of different resources or 654 services. There are two main constraints of multicast-based 655 discovery - scopes and flooding messages. Routers disable multicast 656 forwarding by default, making it practically a single-subnet 657 solution. Some forms of discovery proxies are needed to extend the 658 scope of multicast discovery to multiple subnets. The second issue 659 is the flooding of multicast messages to all hosts on the same 660 subnet. The total bandwidth consumed by multicast depends on the 661 arrival rate the client application requests, and/or the frequency of 662 the service announcements. Older generations of 802.11-based 663 wireless access points often slow down the transmission of multicast 664 messages or generally have a higher packet loss rate for those, 665 causing some multicast discovery implementation to automatically re- 666 send multicast requests or announcements by default. This mitigation 667 further increases the amount of flooding messages on the LAN. 668 Examples of multicast-based discovery include [I-D.cheshire-dnsext- 669 multicastdns], [I-D.cai-ssdp-v1], [WSD], SLP [RFC2165], and LLMNR 670 [RFC4795]. 672 5.7. Caching 674 Once a client has located an ALTO server for the first time, it can 675 cache it for use as future ALTO server. There are implications in 676 case of mobility of devices. 678 6. Security Considerations 680 As this document mainly proposes to use DNS and DHCP for ALTO service 681 discovery, it will depend on the DHCP security and DNS security for 682 this service discovery. 684 7. IANA Considerations 686 The service label for the ALTO service will depend on the final 687 protocol name for application-layer traffic optimization(TBD). 689 8. Acknowledgements 691 The authors would like to give special thanks to Roni Even for his 692 continuous contribution to this document. 694 We would also like to thank the following experts for their review 695 and valuable comments. 697 Y. Richard Yang 699 Xingfeng Jiang 701 Jay Gu 703 Ning Zong 705 (To be added) 707 9. References 709 9.1. Normative References 711 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 712 Requirement Levels", BCP 14, RFC 2119, March 1997. 714 [RFC2782] Gulbrandsen, A., Vixie, P., and L. Esibov, "A DNS RR for 715 specifying the location of services (DNS SRV)", RFC 2782, 716 February 2000. 718 [RFC3958] Daigle, L. and A. Newton, "Domain-Based Application 719 Service Location Using SRV RRs and the Dynamic Delegation 720 Discovery Service (DDDS)", RFC 3958, January 2005. 722 [RFC4848] Daigle, L., "Domain-Based Application Service Location 723 Using URIs and the Dynamic Delegation Discovery Service 724 (DDDS)", RFC 4848, April 2007. 726 [RFC2915] Mealling, M. and R. Daniel, "The Naming Authority Pointer 727 (NAPTR) DNS Resource Record", RFC 2915, September 2000. 729 [I-D.ietf-alto-problem-statement] 730 Seedorf, J. and E. Burger, "Application-Layer Traffic 731 Optimization (ALTO) Problem Statement", 732 draft-ietf-alto-problem-statement-02 (work in progress), 733 July 2009. 735 [I-D.ietf-geopriv-lis-discovery] 736 Thomson, M. and J. Winterbottom, "Discovering the Local 737 Location Information Server (LIS)", 738 draft-ietf-geopriv-lis-discovery-11 (work in progress), 739 May 2009. 741 [I-D.ietf-dhc-container-opt] 742 Droms, R., "Container Option for Server Configuration", 743 draft-ietf-dhc-container-opt-05 (work in progress), 744 March 2009. 746 9.2. Informative References 748 [RFC2629] Rose, M., "Writing I-Ds and RFCs using XML", RFC 2629, 749 June 1999. 751 [RFC3552] Rescorla, E. and B. Korver, "Guidelines for Writing RFC 752 Text on Security Considerations", BCP 72, RFC 3552, 753 July 2003. 755 [RFC2165] Veizades, J., Guttman, E., Perkins, C., and S. Kaplan, 756 "Service Location Protocol", RFC 2165, June 1997. 758 [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-local 759 Multicast Name Resolution (LLMNR)", RFC 4795, 760 January 2007. 762 [I-D.cheshire-dnsext-multicastdns] 763 Cheshire, S. and M. Krochmal, "Multicast DNS", 764 draft-cheshire-dnsext-multicastdns-07 (work in progress), 765 September 2008. 767 [I-D.wang-alto-p4p-specification] 768 Wang, Y., Alimi, R., Pasko, D., Popkin, L., and Y. Yang, 769 "P4P Protocol Specification", 770 draft-wang-alto-p4p-specification-00 (work in progress), 771 March 2009. 773 [I-D.narten-iana-considerations-rfc2434bis] 774 Narten, T. and H. Alvestrand, "Guidelines for Writing an 775 IANA Considerations Section in RFCs", 776 draft-narten-iana-considerations-rfc2434bis-09 (work in 777 progress), March 2008. 779 [I-D.cai-ssdp-v1] 780 Goland, Y., Cai, T., Leach, P., Gu, Y., and S. Albright, 781 "Simple Service Discovery Protocol/1.0 Operating without 782 an Arbiter", October 1999, . 784 [WWW.WHOIS] 785 "http://www.whois.net". 787 [BEP-22] Harrison, D., Shalunov, S., and G. Hazel, "BitTorrent 788 Local Tracker Discovery Protocol", October 2008, 789 . 791 [XEP-1.0] Hammer-Lahav, E., "Extensible Resource Descriptor (XRD) 792 Version 1.0", May 2009, . 795 [WSD] Beatty, J., "Web Services Dynamic Discovery (WS- 796 Discovery)", April 2005, . 799 Authors' Addresses 801 Song Haibin (editor) 802 Huawei 803 Baixia Road No. 91 804 Nanjing, Jiangsu Province 210001 805 P.R.China 807 Email: melodysong@huawei.com 809 Marco Tomsu (editor) 810 Alcatel-lucent Bell Labs 811 Lorenzstrasse 10 812 70435 Stuttgart 813 Germany 815 Email: marco.tomsu@alcatel-lucent.com 816 URI: www.alcatel-lucent.com/bell-labs 817 Gustavo Garcia 818 Telefonica I+D 819 Emilio Vargas 820 Madrid, Madrid 821 Spain 823 Phone: +34 913129826 824 Email: ggb@tid.es 826 Yu-Shun Wang 827 Microsoft Corp. 828 One Microsoft Way 829 Redmond, WA 98052 830 USA 832 Email: yu-shun.wang@microsoft.com 834 Victor Pascual 835 Tekelec 836 Am Borsigturm 11 837 Berlin D-13507 838 Germany 840 Phone: +49 30 32 51 32 12 841 Email: victor@iptel.org