ALTO WG                                                       G. Garcia
Internet Draft                                           Telefonica I+D
Intended status: Informational                                 M. Tomsu
Expires: September 2009                        Alcatel-Lucent Bell Labs
                                                                Y. Wang
                                                          March 3, 2009

                         ALTO Discovery Protocols

Status of this Memo

   This Internet-Draft is submitted to IETF in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF), its areas, and its working groups.  Note that
   other groups may also distribute working documents as Internet-

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   The list of current Internet-Drafts can be accessed at

   The list of Internet-Draft Shadow Directories can be accessed at

   This Internet-Draft will expire on September 3, 2009.

Copyright Notice

   Copyright (c) 2009 IETF Trust and the persons identified as the
   document authors. All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   ( in effect on the date of
   publication of this document. Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.


Garcia, Tomsu, Wang   Expires September 3, 2009                [Page 1]

Internet-Draft         ALTO Discovery Protocols              March 2009

   The Application-Layer Traffic Optimization service aims to provide
   applications with information to perform better-than-random initial
   peer selection when multiple peers in the network are available to
   provide a resource or service. This document discusses the discovery
   protocols for the service.

Table of Contents

   1. Introduction...................................................2
      1.1. Status of this Memo.......................................2
   2. Conventions used in this document..............................3
   3. Scenarios for ALTO Service Discovery...........................3
      3.1. ALTO Service Provider.....................................4
      3.2. ALTO Service Location.....................................4
      3.3. ALTO Service Clients......................................5
      3.4. When is ALTO Service Discovered and Accessed..............5
   4. Options for ALTO Service Discovery.............................5
      4.1. Manual....................................................5
      4.2. DHCP......................................................5
      4.3. DNS.......................................................6
      4.4. Multicast (IP)............................................7
      4.5. XRDS......................................................8
      4.6. IP and Domain discovery...................................9
   5. Security Considerations.......................................10
   6. IANA Considerations...........................................10
   7. Conclusions...................................................10
   8. References....................................................11
      8.1. Normative References.....................................11
      8.2. Informative References...................................11
   9. Acknowledgments...............................................13

1. Introduction

   Application-Layer Traffic Optimization (ALTO) service aims to provide
   distributed network applications with information to perform better-
   than-random initial peer selection when multiple peers in the network
   are available to provide a resource or service. A discovery mechanism
   is needed for the applications to find a suitable entity that
   provides the ALTO service. This document discusses various scenarios
   of ALTO discovery, provides a survey of available options, and
   addresses potential issues and consideration for each.

1.1. Status of this Memo

   The ALTO service architecture and protocol are currently under
   discussion and development within the IETF ALTO working group.

Garcia, Tomsu, Wang   Expires September 3, 2009                [Page 2]

Internet-Draft         ALTO Discovery Protocols              March 2009

   Although it is identified in the charter that a discovery mechanism
   is needed, the preference is to adopt one or more existing mechanisms
   for ALTO discovery rather than designing a new one. Note though
   certain design decisions of the final ALTO framework will affect the
   selection of discovery mechanisms. As a result, this document makes
   minimum assumptions of the ALTO framework, and presents different
   scenarios and available options based on prior and related discovery
   mechanisms. This document will be updated to track the progress of
   the ALTO requirements and solution.

2. Conventions used in this document

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   document are to be interpreted as described in RFC-2119 [RFC2119].

3. Scenarios for ALTO Service Discovery

   This section explores the various dimensions of the ALTO service
   deployment and access scenarios, and briefly discusses their
   implications to the discovery mechanisms. Figure 1 below shows a
   generic ALTO framework diagram with discovery. The terminology is
   defined in [ALTO-PS].

                                           +-----+  |  Peers
            +-----+      +------+    +=====|     |--+-oo
            |     |......|      |====+   oo+--*--+     o
            +-----+      +------+    |   o    *  ooooooo
          Source of       ALTO       |   o    *
          Topological     Service    |   o +--*--+
          information     Provider   +===o=|     | Tracker
                                         o +-----+ (Super-peer,
                          ALTO Discovery o    o     proxy)
                              Server     o    o
                             +------+    o    o
                             |      |oooooooooo


           === ALTO protocol
           ooo ALTO discovery protocol
           *** Application protocol (out of scope)
           ... Provisioning or initialization (out of scope)

                      Figure 1 ALTO Discovery Diagram

Garcia, Tomsu, Wang   Expires September 3, 2009                [Page 3]

Internet-Draft         ALTO Discovery Protocols              March 2009

   In addition to the generic ALTO descriptions, the following terms are
   used to describe the discovery mechanisms in this document:

   o  ALTO Discovery Client: The logical entity discovering the ALTO
      Service. Depending on the scenario, this could be a Peer or a

   o  ALTO Discovery Server: The logical entity providing information to
      locate the ALTO Service. Depending on the discovery mechanism,
      this could be another Peer or a dedicated entity in the network.

   o  ALTO Discovery Domain: The scope of the network handled by a
      particular ALTO Discovery Server.

3.1. ALTO Service Provider

   The ALTO service could be provided in a distributed and cooperative
   fashion by the Peers in an overlay, or it can be provided by a
   centralized entity (the ALTO Server) for a given scope. In the former
   case, a DHT-style key-based routing algorithm is commonly used to
   locate the peers with the target network information in this type of
   distributed environment. For the latter case, where a centralized
   ALTO Server is implicitly or explicitly assigned to a specific
   network scope, an out-of-band discovery mechanism is often required.
   All current ALTO solution proposals, ([Infoexp], [P4P]), fall into
   the second category.

3.2. ALTO Service Location

   The ALTO Server for a Peer could be in the same Local Area Network
   (LAN), within the same ISP Network but not on the same LAN, or in the
   Global Internet outside the ISP Network. Different network scopes
   place different constraints on the discovery mechanisms. Multicast
   discovery generally works within a single LAN only, whereas DNS-based
   or DHCP-based discovery can span multiple subnets within a single ISP
   or a single network administrative domain. Internet scope discovery
   usually requires cross-domain indexing or directory services. Note
   that peers participating in a single P2P application may reside on
   the same or different ISP networks. Scenarios like this may require
   hybrid discovery solutions that can adapt to multiple network scopes
   at the same time. The discovery mechanisms listed in this document
   should take into account possible limitations of the ALTO service
   deployment in those network scopes.

   [Open -NAT traversal discussion]

Garcia, Tomsu, Wang   Expires September 3, 2009                [Page 4]

Internet-Draft         ALTO Discovery Protocols              March 2009

3.3. ALTO Service Clients

   The ALTO Client can be the Peer in the end-user host or an external
   entity like a Super-peer or Resource Directory on behalf of the Peer.
   [ALTO-PS] If a Super-Peers acts as an ALTO Client, it needs to know
   and select the suitable ALTO Service for the Peer being served. The
   location of the ALTO Server could be communicated from the Peer to
   the Super-Peer using the application protocol. It could also be
   discovered by the Super-Peer from other Peer information received
   implicitly (like the Peer public IP address) or received explicitly.
   There could be scenarios where only the Peer is able to access to the
   ALTO Service, for example if the ALTO Server is located in a private
   network or in case the ALTO Server requires to receive the ALTO
   Queries from the Peer which network information is being queried.

3.4. When is ALTO Service Discovered and Accessed

   The discovery process takes place before the first access to the ALTO
   server. This discovery process could be done at host network
   initialization time, at application initialization time or just
   before the first ALTO query is sent.

4. Options for ALTO Service Discovery

4.1. Manual

   Manual configuration of the ALTO service location(s) could work in a
   single ISP network scope, but is not scalable when multiple ISPs or
   cross-domain ALTO services are required. P2P applications often
   connect peers from ISPs that they may not have contacted before, and
   manual configuration will not work without any prior knowledge of the
   ALTO servers.

4.2. DHCP

   In environments where the access network itself either deploys an
   ALTO server or knows a third party that operates an ALTO server, DHCP
   [RFC2131] can provide the end host with a domain name. This domain
   name can then used as input to a DNS-based resolution mechanism
   described in Section 4.3.

   The DHCP mechanism seems adequate for an ALTO Service Discovery as it
   defines the delivery of host-specific configuration from a DHCP
   server to a host. Also the placement close to the end host is
   advantageous as local knowledge is important for the ALTO Service.
   Commonly a DHCP procedure is executed by hosts (Peers) each time they
   connect to an access network and thus to a new ALTO discovery domain.

Garcia, Tomsu, Wang   Expires September 3, 2009                [Page 5]

Internet-Draft         ALTO Discovery Protocols              March 2009

   Network providers who are interested in providing an ALTO Service can
   introduce and enable this mechanism in their DHCP servers.

   The DHCP based ALTO Discovery mechanism needs to define the IANA
   registration of IPv4 and IPv6 options [RFC2939] for the delivery of
   the host-specific of the ALTO service configuration.

   As DHCP is limited to a broadcast domain, DHCP relaying must be

   Examples of DHCP based mechanisms are the discovery of a Location-to-
   Service Translation LoST Service [RFC5223] or the configuration of a
   Session Initiation Protocol (SIP) Server [RFC3361]

4.3. DNS

   DNS infrastructure can be used to discover the location of entities
   providing the ALTO service.  The DNS discovery methods described in
   this section require a domain name as input that can be determined
   making use of the mechanisms discussed in Section 4.6.

   NAPTR [RFC3402] and SRV [RFC2782] DNS resource records are
   appropriate to provide service discovery mechanisms.   The concrete
   application of these resource records depends on the final ALTO
   requests/response protocol, but S-NAPTR [RFC3958] and U-NAPTR
   [RFC4848] provides a generic standardized solution that could be used
   for the ALTO discovery use case. S-NAPTR and U-NAPTR mechanisms
   provide a Dynamic Delegation Discovery System (DDDS) Application to
   map domain name, service name and protocol name to a target host and
   port or to a target URI.

   An ALTO service discovery mechanism could be defined just using NAPTR
   records or just using SRV records, but the combination of both
   provides and additional indirection level and more flexibility as
   described in [RFC3958] Section 5.

   The use of NAPTR records for ALTO discovery requires the definition
   of an Application Service tag and an Application Protocol tag that
   must be IANA-registered.

   The next example shows a NAPTR record for the ALTO service in the domain. This record references the HTTP URI where the
   ALTO service using the PROTOCOL_A is located:

Garcia, Tomsu, Wang   Expires September 3, 2009                [Page 6]

Internet-Draft         ALTO Discovery Protocols              March 2009
    ;; order pref flags
    IN NAPTR 100 10 "u" "ALTO:PROTOCOL_A" ( ; service
    "!*.!!" ; regex
    . ; replacement

   The next example shows a NAPTR record for the ALTO service in the domain. This NAPTR record references a SRV domain name
   for the ALTO service using the PROTOCOL_B.  This SRV record could be
   dereferenced to obtain the target host and port where the service can
   be located:
    ;; order pref flags
    IN NAPTR 100 10 "s" "ALTO:PROTOCOL_B" ( ; service
    "" ; regex ; replacement
    ;; prior weight port target
   IN SRV 10 0 8888

   There are some advantages of using DNS-based discovery:

   o  DNS infrastructure is widely deployed, probed and available.

   o  Most of the end user equipment already include DNS protocol

   DNS service discovery is used in IETF protocols for example to locate
   SIP servers [RFC3263] or to locate LIS servers [GeoprivDisc] and also
   in other protocols like bittorrent to discover local trackers [BEP-

4.4. Multicast (IP)

   IP-multicast-based discovery generally works in two ways:

   1. Clients send out multicast discovery requests and listen for
      responses (usually unicast) from available servers or service

   2. Servers or service providers send out multicast announcements when
      they become available or periodically, and clients waits for the
      next available multicast announcement to identify the servers or
      service providers.

Garcia, Tomsu, Wang   Expires September 3, 2009                [Page 7]

Internet-Draft         ALTO Discovery Protocols              March 2009

   The on-demand requests and periodic announcements are not mutually
   exclusive. An implementation can choose to utilize both
   simultaneously. The configuration effort of multicast discovery is
   fairly straightforward, only the multicast address and port are
   needed. Service types and additional information are often encoded in
   the requests or announcements messages, enabling the same multicast
   channel to support discovery of different resources or services.
   There are two main constraints of multicast-based discovery - scopes
   and flooding messages. Routers disable multicast forwarding by
   default, making it practically a single-subnet solution. Some forms
   of discovery proxies are needed to extend the scope of multicast
   discovery to multiple subnets. The second issue is the flooding of
   multicast messages to all hosts on the same subnet. The total
   bandwidth consumed by multicast depends on the arrival rate the
   client application requests, and/or the frequency of the service
   announcements. Older generations of 802.11-based wireless access
   points often slow down the transmission of multicast messages or
   generally have a higher packet loss rate for those, causing some
   multicast discovery implementation to automatically re-send multicast
   requests or announcements by default. This mitigation further
   increases the amount of flooding messages on the LAN. Examples of
   multicast-based discovery include [mDNS], [SSDP], [WSD], SLP
   [RFC2165], and LLMNR [RFC4795].

4.5. XRDS

   [XRDS] (eXtensible Resource Descriptor Sequence), and its simplified
   profile [XRDS-Simple], specifies an XML format to describe resources
   associated with a URI, and the protocol to retrieve that XML
   document.   One of the purposes of this XRDS document is to enumerate
   and describe the service endpoints associated with the resource,
   including the URI to access the service and a a type of service
   and/or media-type identifying the service being discovered.

   The use of XRDS for ALTO Service Discovery requires using a URI to
   retrieve the XRDS document and the specification of a type of service
   and/or media-type identifying the ALTO Service.  This is an example
   of a XRDS document including a possible the description of the ALTO

Garcia, Tomsu, Wang   Expires September 3, 2009                [Page 8]

Internet-Draft         ALTO Discovery Protocols              March 2009

     <XRDS xmlns="xri://$xrds">
       <XRD xmlns="xri://$XRD*($v*2.0)" version="2.0">

   The necessity of an initial URI to retrieve the XRDS document
   requires an additional pre-discovery mechanism similar to the
   discovery of the ALTO service itself.  This extra complexity and
   roundtrip seems to make XRDS not especially appropriate for the ALTO
   discovery use case.

4.6. IP and Domain discovery

   Some of the mechanisms described in the previous sections require the
   knowledge of the domain name representing the entity providing the
   ALTO service for this endpoint or the knowledge of the endpoint IP

   The domain name associated with the entity providing the ALTO service
   could be manually configured in the end user application or extracted
   automatically from the endpoint domain name obtained through a
   reverse DNS lookup process (using DNS PTR records) or from a DHCP
   server ([RFC4702] for DHCPv4, [RFC4704] for DHCPv6). In case the
   endpoint domain name is used, the application tries to get the ALTO
   service for that domain name; if this request fails it removes
   iteratively the labels from the left of the domain name until an
   answer to the service location request is successful. The process
   ends notifying an error when the only label in the domain name is the
   top level domain.

   For example in case of an endpoint with a public address,
   it requests the DNS PTR record at obtaining a
   domain name like The application requests
   the ALTO service for that domain making a DNS SRV request for  In case that request fails, the
   application makes a new request for
   and then for stopping when a successful answer
   is returned.

   To discover the domain name using reverse DNS lookups, the
   application requires first the knowledge of the endpoint IP address.

Garcia, Tomsu, Wang   Expires September 3, 2009                [Page 9]

Internet-Draft         ALTO Discovery Protocols              March 2009

   In presence of Network Address Translation (NAT) this could be done
   using mechanisms specific of the application (for example asking an
   application server using the application specific protocol like [BEP-
   24] in case of a Bittorrent protocol) or using additional standard
   protocols like STUN, UPnP or NAT-PMP that require additional servers
   in the network or impose additional requirements in the routers
   implementing the NATs.

   Similar Domain Name and IP resolution mechanisms have been described
   in other discovery mechanisms like the BitTorrent Local Tracker
   Discovery Protocol [BEP-22].

5. Security Considerations

   The security considerations for the ALTO discovery protocol will be
   detailed in further versions of this document after the final
   discovery mechanism will be selected.

   In case of DHCP security consideration needs to be taken into account
   as a client accepts configuration responses from any server.

   The security considerations for the DNS discovery mechanisms depend
   on the Resource Records in use.  U-NAPTR security considerations are
   detailed in [RFC4848] and those for SRV in [RFC2782].  The security
   of the IP and Domain discovery described in 4.6.  must also be

   Each multicast discovery mechanism has specific security
   considerations that will be addressed if any of them is used in the
   final ALTO discovery protocol.

6. IANA Considerations

   This version of the draft presents a survey of possible discovery
   mechanisms for ALTO service discovery. There is no formal
   recommendation on the discovery mechanisms at this point. As such,
   there is no IANA consideration on any forms of assignment.

7. Conclusions

   The document intends to start the discussion about ALTO discovery in
   the ALTO WG. It discusses various scenarios of ALTO discovery,
   provides a survey of available options, and addresses potential
   issues and consideration for each.

Garcia, Tomsu, Wang   Expires September 3, 2009               [Page 10]

Internet-Draft         ALTO Discovery Protocols              March 2009

8. References

8.1. Normative References

   [ALTO-PS] Seedorf, J., Burger, E., "Application-Layer Traffic
             Optimization (ALTO) Problem Statement," draft-marocco-alto-
             problem-statement-04, (work in progress), February 2009.

   [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
             Requirement Levels", BCP 14, RFC 2119, March 1997.

8.2. Informative References

   [BEP-22] Harrison, D., Shalunov, S., and G. Hazel  "BitTorrent Local
             Tracker Discovery Protocol,"
   , October 2008.

   [Infoexp] Shalunov, S., Penno, and R., Woundy, "ALTO Information
             Export Service," draft-shalunov-alto-infoexport-00, (work
             in progress), October 2008.

   [GeoprivDisc] Thomson, M., Winterbottom, J., "Discovering the Local
             Location Information Server (LIS)," draft-ietf-geopriv-lis-
             discovery-07, (work in progress), February, 2009.

   [mDNS] Cheshire, S., Krochmal, M, "Multicast DNS," draft-cheshire-
             dnsext-multicastdns-07, (work in progress), September 2008.

   [P4P] Alimi, R., Pasko, D., Popkin, L., Wang, Y., and Y. Yang, "P4P:
             Provider Portal for P2P Applications", draft-p4p-framework-
             00 (work in progress), November 2008.

   [RFC2131] Droms, R., "Dynamic Host Configuration Protocol", RFC 2131,
             March 1997

   [RFC2165] Veizades, J., Guttman, E., Perkins, C. and S. Kaplan,
             "Service Location Protocol", RFC 2165, July 1997.

   [RFC2782] Gulbrandsen, A, Vixie, P., Esibov, L., "A DNS RR for
             specifying the location of services (DNS SRV)," RFC 2782,
             February 2000.

   [RFC2939] Droms, R., "Procedures and IANA Guidelines for Definition
             of New DHCP Options and Message Types", September 2000

   [RFC3263] Rosenberg, J., Schulzrinne, H., "Session Initiation
             Protocol (SIP): Locating SIP Servers," RFC 3263, June 2002.

Garcia, Tomsu, Wang   Expires September 3, 2009               [Page 11]

Internet-Draft         ALTO Discovery Protocols              March 2009

   [RFC3361] Schulzrinne, H., "Dynamic Host Configuration Protocol
             (DHCP-for-IPv4) Option for Session Initiation Protocol
             (SIP) Servers", RFC 3361, August 2002

   [RFC3402] Mealling, M., "Dynamic Delegation Discovery System (DDDS):
             Part Two: The Algorithm," RFC 3402, October 2002.

   [RFC3958] Daigle, L., Newton, A., "Domain-Based Application Service
             Location Using SRV RRs and the Dynamic Delegation Discovery
             Service (DDDS)," RFC 3958, Janurary 2005.

   [RFC4702] Stapp, M., Volz, B., and Y. Rekhter, "The Dynamic Host
             Configuration Protocol (DHCP) Client Fully Qualified Domain
             Name (FQDN) Option," RFC 4702, October 2006.

   [RFC4704] Volz, B., "The Dynamic Host Configuration Protocol for IPv6
             (DHCPv6) Client Fully Qualified Domain Name (FQDN) Option,"
             RFC 4704, October 2006.

   [RFC4795] Aboba, B., Thaler, D., and L. Esibov, "Link-Local Multicast
             Name Resolution (LLMNR)," RFC 4795, January 2007.

   [RFC4848] Daigle, L., "Domain-Based Application Service Location
             Using URIs and the Dynamic Delegation Discovery Service
             (DDDS)," RFC 4848, April 2007.

   [RFC5223] Schulzrinne, H., Polk, J., Tschofenig, H., "Discovering
             Location-to-Service Translation (LoST) Servers Using the
             Dynamic Host Configuration Protocol (DHCP)", RFC 5223,
             August 2008

   [SSDP] Goland, Y., Cai, T., Leach, P., Gu, Y., and S. Albright,
             "Simple Service Discovery Protocol/1.0: Operating without
             an Arbiter," draft-cai-ssdp-v1-03, (work in progress),
             October 1999.

   [WSD] Beatty, J., et al., "Web Services Dynamic Discovery (WS-
             Discovery)", April 2005,



Garcia, Tomsu, Wang   Expires September 3, 2009               [Page 12]

Internet-Draft         ALTO Discovery Protocols              March 2009

9. Acknowledgments

   This document was prepared using

Authors' Addresses

   Gustavo Garcia
   Telefonica I+D
   Emilio Vargas
   Madrid, Madrid

   Phone: +34 913129826

   Marco Tomsu
   Alcatel-lucent Bell Labs
   Lorenzstrasse 10
   70435 Stuttgart


   Yu-Shun Wang
   Microsoft Corp.
   One Microsoft Way
   Redmond, WA 98052


Garcia, Tomsu, Wang   Expires September 3, 2009               [Page 13]