[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 03 04 05

ALTO                                                           S. Kiesel
Internet-Draft                                   University of Stuttgart
Intended status: Informational                                  M. Tomsu
Expires: January 10, 2011                                      N. Schwan
                                                               M. Scharf
                                                Alcatel-Lucent Bell Labs
                                                          M. Stiemerling
                                                         NEC Europe Ltd.
                                                            July 9, 2010


                   Third-party ALTO server discovery
                      draft-kiesel-alto-3pdisc-03

Abstract

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications, which have to select one or several
   hosts from a set of candidates that are able to provide a desired
   resource.

   Entities seeking guidance need to discover and possibly select an
   ALTO server to ask.  This is called ALTO server discovery.  This memo
   describes an ALTO server discovery mechanism based on DNS SRV
   records.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   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."

   This Internet-Draft will expire on January 10, 2011.

Copyright Notice

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




Kiesel, et al.          Expires January 10, 2011                [Page 1]


Internet-Draft      Third-party ALTO server discovery          July 2010


   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) 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.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  DNS-based ALTO Server Discovery  . . . . . . . . . . . . . . .  5
     2.1.  DNS SRV record definition  . . . . . . . . . . . . . . . .  5
     2.2.  DNS SRV record lookup procedure  . . . . . . . . . . . . .  6
       2.2.1.  Step 1: Finding the IP address . . . . . . . . . . . .  6
       2.2.2.  Step 2: Determining the DNS suffix . . . . . . . . . .  6
       2.2.3.  Step 3: Lookup SRV record  . . . . . . . . . . . . . .  7
       2.2.4.  Step 4: Final lookup . . . . . . . . . . . . . . . . .  8
   3.  Applicability  . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.1.  Applicability for third party server discovery . . . . . .  9
     3.2.  Applicability for resource consumer server discovery . . .  9
   4.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 11
   5.  Security Considerations  . . . . . . . . . . . . . . . . . . . 12
   6.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 14
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 14
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 14
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17



















Kiesel, et al.          Expires January 10, 2011                [Page 2]


Internet-Draft      Third-party ALTO server discovery          July 2010


1.  Introduction

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications, which have to select one or several
   hosts from a set of candidates, that are able to provide a desired
   resource[RFC5693].  The requirements for ALTO are itemized in
   [I-D.ietf-alto-reqs].  ALTO is realized by a client-server protocol.
   ALTO clients send queries to ALTO servers, in order to solicit
   guidance.

   ALTO clients have to discover suitable ALTO servers.  Therefore the
   ALTO discovery client tells the ALTO client which ALTO servers to
   send the queries to.  The ALTO discovery client and the ALTO client
   can be embedded in the resource consumer, which will eventually
   access the desired resource.  As an alternative, they can be embedded
   in a resource directory, which assists resource consumers in finding
   appropriate resource providers.  In some specific peer-to-peer
   application protocols these resource directories are called
   "trackers".  Finally the ALTO discovery client can be embedded in the
   resource consumer, whereas the ALTO client is embedded in the
   resource directory.  ALTO queries, which are issued by a resource
   directory on behalf of a resource consumer, are referred to as third-
   party ALTO queries.  The various possibilities to place ALTO servers
   and the placement of ALTO clients is discussed in
   [I-D.stiemerling-alto-deployments].

   No matter where ALTO server and client are located, clients have to
   first find out if there is an ALTO server deployed that is in charge
   for them and second to get the contact information of that server,
   i.e., the IP address, port number, and probably transport protocol
   (which defaults to TCP for [I-D.ietf-alto-protocol]).

   There exists a number of service location protocols, such as SLP
   [RFC2608] or DHCP [RFC2131][RFC3315], which could in principle be
   used for ALTO discovery.  However, SLP is not widely deployed or used
   within the Internet.  DHCP is widely deployed but has several
   limitations:

   o  Though widely deployed DHCP is not in use everywhere.  For
      important scenarios, such as PPPoE based DSL access networks one
      would have to specify another mechanism.

   o  A DHCP-based discovery mechanism will always yield the addresses
      of the ALTO servers that are provided by the network operator.
      The user cannot influence the discovery and, e.g., select an
      alternative ALTO service from an "independent" ALTO operator.





Kiesel, et al.          Expires January 10, 2011                [Page 3]


Internet-Draft      Third-party ALTO server discovery          July 2010


   o  There are problems with residential gateways or broadband routers
      with NAT.  If the network operator gives information about ALTO
      serves to the residential gateway via DHCP, the residential
      gateway would have to forward this information to the hosts with
      the (P2P) applications within the local network.  This is not
      supported by any of the already deployed residential gateways.

   o  DHCP poorly supports third-party ALTO server discovery, i.e., in
      scenarios where the ALTO client is co-located with a resource
      directory ("tracker"), which is located in a different
      administrative domain than the client which will eventually access
      the ressource.

   The goal of this memo is to propose a uniform mechanism for all types
   of ALTO client deployments that is implementable and deployable at a
   fast pace, i.e., without creating other deployment dependecies for
   ALTO.  One way of fulfilling the previous mentioned requirements is
   using the Service Records (SRV) of the Domain Name System (DNS), as
   described in [RFC2782].  DNS SRVs have been defined and are used for
   a number of protocols, such as SIP and XMPP.

   Comments and discussions about this memo should be directed to the
   ALTO working group: alto@ietf.org.




























Kiesel, et al.          Expires January 10, 2011                [Page 4]


Internet-Draft      Third-party ALTO server discovery          July 2010


2.  DNS-based ALTO Server Discovery

2.1.  DNS SRV record definition

   We define a new service record for ALTO servers according to
   [RFC2782].  The general format of the SRV RR, whose DNS type code is
   33, is

      _Service._Proto.Name TTL Class SRV Priority Weight Port Target

   Where for the ALTO server discovery, we define:

   Service  alto

   Proto  tcp

   Name  "The domain this RR refers to.  The SRV RR is unique in that
      the name one searches for is not this name; the example near the
      end shows this clearly."[RFC2782]

   TTL  Standard DNS meaning [RFC2782]

   Class  Standard DNS meaning[RFC2782]

   Priority   "The priority of this target host.  A client MUST attempt
      to contact the target host with the lowest-numbered priority it
      can reach; target hosts with the same priority SHOULD be tried in
      an order defined by the weight field.  The range is 0-65535.  This
      is a 16 bit unsigned integer in network byte order."  [RFC2782]

   Weight   "A server selection mechanism.  The weight field specifies a
      relative weight for entries with the same priority.  Larger
      weights SHOULD be given a proportionately higher probability of
      being selected.  The range of this number is 0-65535.  This is a
      16 bit unsigned integer in network byte order.  Domain
      administrators SHOULD use Weight 0 when there isn't any server
      selection to do, to make the RR easier to read for humans (less
      noisy).  In the presence of records containing weights greater
      than 0, records with weight 0 should have a very small chance of
      being selected.[...]"  [RFC2782]

   Port  "The port on this target host of this service.  The range is 0-
      65535.  This is a 16 bit unsigned integer in network byte order.
      This is often as specified in Assigned Numbers but need not
      be."[RFC2782] It will be set to 80, if the standard TCP port for
      HTTP is used, but this also allows to run the service on any other
      port.




Kiesel, et al.          Expires January 10, 2011                [Page 5]


Internet-Draft      Third-party ALTO server discovery          July 2010


   Target   "The domain name of the target host.  There MUST be one or
      more address records for this name, the name MUST NOT be an alias
      (in the sense of RFC 1034 or RFC 2181).  Implementors are urged,
      but not required, to return the address record(s) in the
      Additional Data section.  Unless and until permitted by future
      standards action, name compression is not to be used for this
      field.  A Target of "." means that the service is decidedly not
      available at this domain.  "[RFC2782]

   An example for querying for such an ALTO service record running in
   the domain myisp.net:

      _alto._tcp.example.com IN SRV 1 0 80 alto-srv01.myisp.net

2.2.  DNS SRV record lookup procedure

   This section describes the algorithm that is applied to discover the
   ALTO server.  We differentiate between two use cases: In use case (a)
   the user has no specific wish which ALTO service instance to use.
   Here the ALTO service instance is provided by default by the user's
   access network provider, thus the ALTO discovery client needs to
   determine the correct domain name automatically.  In case (b) the
   user configures a specific ALTO service instance that he wants to
   use.  Here the ALTO discovery client already has the information
   about which DNS suffix to use.

2.2.1.  Step 1: Finding the IP address

   The first step for the ALTO discovery client is to determine the IP
   address or IP addresses of the resource consumer.  The resource
   consumer may have private IP addresses and public IP addresses and
   depending on the deployment it might be necessary to determine for
   all IP addresses the ALTO server in charge of.  To determine its
   public IP address the resource consumer may need to use STUN[RFC5389]
   or BEP24[bep24].  For the following example we assume that the IP
   address of the resource consumer is a.b.c.d

2.2.2.  Step 2: Determining the DNS suffix

   To get the DNS suffix in case (a) the ALTO discovery uses a DNS PTR
   query for the IP address of the resource consumer as determined in
   step 1.  The local DNS server resolves the IP address to the FQDN
   that also contains the DNS suffix for the respective IP address.  A
   possible answer for a PTR lookup for d.c.b.a.in-addr.apra might be,
   for example:






Kiesel, et al.          Expires January 10, 2011                [Page 6]


Internet-Draft      Third-party ALTO server discovery          July 2010


      d-c-b-a.dsl.westcoast.myisp.net

   In case (b) The user specifies the DNS suffix on its own, for example
   in a config file option.  Here the user wants to use an ALTO service
   instance which is operated by a third party as for example the
   tracker operator.  A possible DNS suffix entered by the user may be:

      myaltoprovider.org

2.2.3.  Step 3: Lookup SRV record

   In step 3 the ALTO discovery client uses the information that has
   been determined in the previous steps to composes the domain name
   that is used for the SRV queries.  As the suffix part in not obvious
   in all cases e.g., it can be for the above example
   "westcoast.myisp.net" or "myisp.net", the ALTO discovery client might
   need to perform multiple SRV lookups until it gets a PTR reply.

   In case (a) the ALTO discovery client composes the domain name as
   described in Section 2.  If there is no response to the lookup the
   DNS suffix is shortened by one part for the succeeding lookup.  The
   domain names used for the example as described above are:

      _alto._tcp.d-c-b-a.dsl.westcoast.myisp.net.

      _alto._tcp.dsl.westcoast.myisp.net.

      _alto._tcp.westcoast.myisp.net.

      _alto._tcp.myisp.net.

   For case (b) the ALTO discovery client extends the DNS suffix by the
   IP address of the resource consumer in reverse order to compose the
   domain name.  This is needed for the third party ALTO service
   instance to direct the ALTO client to the ALTO server closest to the
   client in case there are multiple ALTO servers deployed.  The suffix
   is then shortened as described before until a lookup is successful,
   as for example

      _alto._tcp.d.c.b.a.myaltoprovider.org.

      _alto._tcp.c.b.a.myaltoprovider.org.

      _alto._tcp.b.a.myaltoprovider.org.







Kiesel, et al.          Expires January 10, 2011                [Page 7]


Internet-Draft      Third-party ALTO server discovery          July 2010


      _alto._tcp.a.myaltoprovider.org.

      _alto._tcp.myaltoprovider.org.

2.2.4.  Step 4: Final lookup

   After step 3 has been completed the ALTO discovery client processes
   the PTR records and performs the final DNS lookup on the A record.
   It then forwards the contact information to the ALTO client, which
   can now contact the ALTO server to perform ALTO queries.









































Kiesel, et al.          Expires January 10, 2011                [Page 8]


Internet-Draft      Third-party ALTO server discovery          July 2010


3.  Applicability

   This section discusses the applicability of the proposed solution
   with respect to the third party and the resource consumer server
   discovery deployment scenarios.  Each section discusses the proposed
   steps that are needed to create the right domain name for the final
   DNS lookup.

3.1.  Applicability for third party server discovery

   In case of the third party server discovery deployment scenario the
   ALTO discovery client is a different entity than the resource
   consumer.  Typically the resource consumer is a peer wehereas the
   ALTO (discovery) client is a resource directory which seeks for ALTO
   guidance on behalf of the peer.  Another use case for the third party
   discovery is an application that looks for ALTO guidance
   transparently to the resource consumer, for example a CDN.

   Here the ALTO discovery client already knows the IP address of the
   resource consumer which was used to establish the initial connection.
   In general this IP address is a public address, either of the
   resource consumer or of the last NAT on the path to the ALTO client.
   This makes the IP address a good candidate for the next steps.  In
   case the resource consumer needs guidance for a different IP address,
   for example one from a private network, we propose that the resource
   consumer does the server discovery by itself and forwards the ALTO
   server contact information directly to the ALTO client which in turn
   can then do the third party ALTO query.

   To determine the DNS suffix the ALTO discovery client uses a DNS PTR
   query.  As here the IP address is public we expect that the DNS query
   will be successfully resolved to the FQDN of the domain where the
   resource consumer is registered in.

   To compose the right domain name from the FQDN the ALTO discovery
   client follows the mechansims as described in Section 2.2.3.
   Additionally the ALTO discovery client can cache domain names and
   contact details of already discovered ALTO servers and compare them
   with the FQDN by a longest suffix matching.  If successful the client
   can use the contact information and skip the final discovery step.

   The fourth step of the procedure can be applied as described.

3.2.  Applicability for resource consumer server discovery

   In this scenario the ALTO discovery client that performs the
   discovery is also the resource consumer, for example a peer in a P2P
   system.  After the discovery the peer does the ALTO query on its own,



Kiesel, et al.          Expires January 10, 2011                [Page 9]


Internet-Draft      Third-party ALTO server discovery          July 2010


   or it might share the ALTO server contact information with a third
   party, for example a tracker, which then does the ALTO query on
   behalf of the peer.

   DNS SRV records can be used for resource consumer discovery, too.
   Depending on the deployment scenario the resource consumer will have
   multiple IP addresses which are possible candidates for a reverse
   lookup to determine the FQDN in step 2.  Usually the ALTO server is
   responsible for a set of public IP addresses, thus in case the
   resource consumer is behind a NAT or a residential gateway it needs
   to determine the public IP address assigned to it.  As discussed in
   Section 2.2.1 this can be done by the use of STUN[RFC5389] or
   BEP24[bep24].

   In other deployment scenarios where internal guidance for a large
   private domain is desired the ALTO server might be inside the same
   private domain as the resource consumer.  In this case the resource
   consumer can either use a private IP address or it needs to find a
   STUN server that is also inside the private domain in order to find
   the right IP address.

   To determine the DNS suffix for a public IP address the procedure is
   as described in the respective section.  In case of a private IP
   address it has to be ensured that the DNS server that is used by the
   discovery client is a local one that is capable of resolving the
   private IP address.

   The third and fourth step of the procedure can be applied as
   described.






















Kiesel, et al.          Expires January 10, 2011               [Page 10]


Internet-Draft      Third-party ALTO server discovery          July 2010


4.  IANA Considerations

   This document does not mandate any immediate IANA actions.  However,
   such IANA considerations may arise from future ALTO discovery
   specification documents which try to meet the requirements given
   here.













































Kiesel, et al.          Expires January 10, 2011               [Page 11]


Internet-Draft      Third-party ALTO server discovery          July 2010


5.  Security Considerations

   This early version of this memo does not yet have any security
   considerations, but they will be added in future revision.















































Kiesel, et al.          Expires January 10, 2011               [Page 12]


Internet-Draft      Third-party ALTO server discovery          July 2010


6.  Conclusion

   This document describes a general DNS SRV queries based ALTO server
   discovery mechanism and discusses how ALTO discovery clients can find
   the right domain name which has to be used for the query.  In
   addition this document discusses the applicability of the described
   mechanism for the third party as well as the resource consumer
   discovery.











































Kiesel, et al.          Expires January 10, 2011               [Page 13]


Internet-Draft      Third-party ALTO server discovery          July 2010


7.  References

7.1.  Normative References

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

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

   [RFC5389]  Rosenberg, J., Mahy, R., Matthews, P., and D. Wing,
              "Session Traversal Utilities for NAT (STUN)", RFC 5389,
              October 2008.

7.2.  Informative References

   [I-D.ietf-alto-protocol]
              Alimi, R., Penno, R., and Y. Yang, "ALTO Protocol",
              draft-ietf-alto-protocol-04 (work in progress), May 2010.

   [I-D.ietf-alto-reqs]
              Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
              Y. Yang, "Application-Layer Traffic Optimization (ALTO)
              Requirements", draft-ietf-alto-reqs-05 (work in progress),
              June 2010.

   [I-D.kiesel-alto-3pdisc]
              Kiesel, S., Tomsu, M., Schwan, N., and M. Scharf, "Third-
              party ALTO server discovery", draft-kiesel-alto-3pdisc-02
              (work in progress), March 2010.

   [I-D.stiemerling-alto-deployments]
              Stiemerling, M. and S. Kiesel, "ALTO Deployment
              Considerations", draft-stiemerling-alto-deployments-03
              (work in progress), June 2010.

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

   [RFC2608]  Guttman, E., Perkins, C., Veizades, J., and M. Day,
              "Service Location Protocol, Version 2", RFC 2608,
              June 1999.

   [RFC3315]  Droms, R., Bound, J., Volz, B., Lemon, T., Perkins, C.,
              and M. Carney, "Dynamic Host Configuration Protocol for
              IPv6 (DHCPv6)", RFC 3315, July 2003.




Kiesel, et al.          Expires January 10, 2011               [Page 14]


Internet-Draft      Third-party ALTO server discovery          July 2010


   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              October 2009.

   [bep22]    Harrison, D., Shalunov, S., and G. Greg Hazel, "BitTorrent
              Local Tracker Discovery Protocol",
              BEP http://bittorrent.org/beps/bep_0022.html.

   [bep24]    Harrison, D., "Tracker Returns External IP",
              BEP http://bittorrent.org/beps/bep_0024.html.









































Kiesel, et al.          Expires January 10, 2011               [Page 15]


Internet-Draft      Third-party ALTO server discovery          July 2010


Appendix A.  Acknowledgments

   The authors would like to thank Haibin Song, Richard Alimi, and Roni
   Even for fruitful discussions during the 75th IETF meeting.

   Marco Tomsu and Nico Schwan are partially supported by the ENVISION
   project (http://www.envision-project.org), a research project
   supported by the European Commission under its 7th Framework Program
   (contract no. 248565).  The views and conclusions contained herein
   are those of the authors and should not be interpreted as necessarily
   representing the official policies or endorsements, either expressed
   or implied, of the ENVISION project or the European Commission.

   Michael Scharf is supported by the German-Lab project
   (http://www.german-lab.de) funded by the German Federal Ministry of
   Education and Research (BMBF).

   Martin Stiemerling is partially supported by the NAPA-WINE project
   (Network-Aware P2P-TV Application over Wise Networks,
   http://www.napa-wine.org), a research project supported by the
   European Commission under its 7th Framework Program (contract no.
   214412).  The views and conclusions contained herein are those of the
   authors and should not be interpreted as necessarily representing the
   official policies or endorsements, either expressed or implied, of
   the NAPA-WINE project or the European Commission.


























Kiesel, et al.          Expires January 10, 2011               [Page 16]


Internet-Draft      Third-party ALTO server discovery          July 2010


Authors' Addresses

   Sebastian Kiesel
   University of Stuttgart Computing Center
   Allmandring 30
   Stuttgart  70550
   Germany

   Email: ietf-alto@skiesel.de
   URI:   http://www.rus.uni-stuttgart.de/nks/


   Marco Tomsu
   Alcatel-Lucent Bell Labs
   Lorenzstrasse 10
   Stuttgart  70435
   Germany

   Email: marco.tomsu@alcatel-lucent.com
   URI:   www.alcatel-lucent.com/bell-labs


   Nico Schwan
   Alcatel-Lucent Bell Labs
   Lorenzstrasse 10
   Stuttgart  70435
   Germany

   Email: nico.schwan@alcatel-lucent.com
   URI:   www.alcatel-lucent.com/bell-labs


   Michael Scharf
   Alcatel-Lucent Bell Labs
   Lorenzstrasse 10
   Stuttgart  70435
   Germany

   Email: michael.scharf@alcatel-lucent.com
   URI:   www.alcatel-lucent.com/bell-labs











Kiesel, et al.          Expires January 10, 2011               [Page 17]


Internet-Draft      Third-party ALTO server discovery          July 2010


   Martin Stiemerling
   NEC Laboratories Europe/University of Goettingen
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

   Phone: +49 6221 4342 113
   Email: martin.stiemerling@neclab.eu
   URI:   http://ietf.stiemerling.org










































Kiesel, et al.          Expires January 10, 2011               [Page 18]


Html markup produced by rfcmarkup 1.129d, available from https://tools.ietf.org/tools/rfcmarkup/