Skip to main content

Third-Party ALTO Server Discovery (3pdisc)
draft-kist-alto-3pdisc-01

The information below is for an old version of the document.
Document Type
This is an older version of an Internet-Draft whose latest revision state is "Expired".
Authors Sebastian Kiesel , Martin Stiemerling
Last updated 2012-10-22
RFC stream (None)
Formats
Additional resources
Stream Stream state (No stream defined)
Consensus boilerplate Unknown
RFC Editor Note (None)
IESG IESG state I-D Exists
Telechat date (None)
Responsible AD (None)
Send notices to (None)
draft-kist-alto-3pdisc-01
ALTO                                                           S. Kiesel
Internet-Draft                                   University of Stuttgart
Intended status: Experimental                             M. Stiemerling
Expires: April 25, 2013                                  NEC Europe Ltd.
                                                        October 22, 2012

               Third-Party ALTO Server Discovery (3pdisc)
                       draft-kist-alto-3pdisc-01

Abstract

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications that have to select one or several
   hosts from a set of candidates capable of providing a desired
   resource.  ALTO is realized by a client-server protocol.  Before an
   ALTO client can ask for guidance it needs to discover one or more
   ALTO servers that can provide suitable guidance.

   This document specifies a procedure for third-party ALTO server
   discovery, which can be used if the ALTO client is not co-located
   with the actual resource consumer, but instead embedded in a third
   party such as a peer-to-peer tracker.

Kiesel & Stiemerling     Expires April 25, 2013                 [Page 1]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

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 April 25, 2013.

Copyright Notice

   Copyright (c) 2012 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
   (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.

Kiesel & Stiemerling     Expires April 25, 2013                 [Page 2]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Third-Party ALTO Server Discovery Procedure Overview . . . . .  5
   3.  Third-party ALTO Server  Discovery Procedure Specification . .  6
     3.1.  Step 1: Retrieving the Domain Name . . . . . . . . . . . .  7
     3.2.  Step 2: U-NAPTR Resolution . . . . . . . . . . . . . . . .  7
   4.  Deployment Considerations  . . . . . . . . . . . . . . . . . .  8
     4.1.  IPv4 PTR lookup  . . . . . . . . . . . . . . . . . . . . .  8
       4.1.1.  Private customers or very small businesses . . . . . .  8
       4.1.2.  Medium-size customer networks  . . . . . . . . . . . .  8
       4.1.3.  Large Customers  . . . . . . . . . . . . . . . . . . .  9
     4.2.  IPv6 PTR lookup  . . . . . . . . . . . . . . . . . . . . .  9
   5.  Operational Considerations . . . . . . . . . . . . . . . . . . 10
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 11
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 12
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 13
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 13
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 13
   Appendix A.  Contributors List and Acknowledgments . . . . . . . . 14
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 15

Kiesel & Stiemerling     Expires April 25, 2013                 [Page 3]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

1.  Introduction

   The goal of Application-Layer Traffic Optimization (ALTO) is to
   provide guidance to applications that have to select one or several
   hosts from a set of candidates capable of providing a desired
   resource [RFC5693].  ALTO is realized by a client-server protocol,
   see requirement AR-1 in [RFC6708].  Before an ALTO client can ask for
   guidance it needs to discover one or more ALTO servers that can
   provide suitable guidance.

   For applications that use a centralized resource directory, such as
   tracker-based P2P applications, the efficiency of ALTO is
   significantly improved if the ALTO client is embedded in said
   resource directory instead of the resource consumer (see Section 4.1
   of [I-D.ietf-alto-deployments]).  The ALTO client embedded into the
   resource directory asks for guidance on behalf of the resource
   consumers.  To that end, it needs to discover ALTO servers that can
   give guidance suitable for these resource consumers, respectively.
   This is called third-party party ALTO server discovery.

   This document specifies a procedure for third-party ALTO server
   discovery.  In other words, this document tries to meet requirement
   AR-33 in [RFC6708].  To some extent, AR-32, i.e., resource consumer
   initiated ALTO server discovery, can be seen as a special case of
   third-party ALTO server discovery.  For that matter, an ALTO client
   embedded in a ressouce consumer would have to figure out its own
   "public" IP address (e.g., using STUN [RFC5389]), and then perform
   the procedures described in this document.  However, note that a less
   flexible yet simpler approach for resource consumer initiated ALTO
   server discovery is specified in [I-D.ietf-alto-server-discovery].

   The ALTO protocol specification [I-D.ietf-alto-protocol] is based on
   HTTP and expects the discovery procedure to yield an HTTP(S) URI.
   Therefore, this procedure is based on U-NAPTR [RFC4848].  It tries to
   directly find one or more ALTO server(s) that can give suitable
   guidance to the ALTO client.  Other schemes, such as discovering an
   arbitrary ALTO server (which might not be able to give suitable
   guidance to the client in question) and asking it to redirect the
   client to a better server, are not considered in this document.

   A more detailed discussion of various options where to place the
   funcional entities comprising the overall ALTO architecture can be
   found in [I-D.ietf-alto-deployments].

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

Kiesel & Stiemerling     Expires April 25, 2013                 [Page 4]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

2.  Third-Party ALTO Server Discovery Procedure Overview

   The third-party ALTO server discovery procedure is performed in two
   steps:

   1.  A DNS suffix is yieleded, by means of a DNS PTR lookup on the
       resouce consumer's IP address (or the "public" IP address of the
       outermost NAT in front of the resource consumer).  This IP
       address is the source address of application protocol messages
       arriving at the resource directory.

   2.  This DNS suffix is used for an U-NAPTR lookup yielding the URI.
       Further DNS lookups may be neccessary to determine the ALTO
       server's IP address(es).

   Typically, but not neccessarily, the DNS suffix is the domain name in
   which the client is located, i.e., a PTR lookup on the client's IP
   address would yield a similar name.  However, due to the widespread
   use of network address translation (NAT), trying to determine the DNS
   suffix through a PTR lookup on the client's IP address is not
   recommended.

   Note: Step 1 could be merged with Step 1 of
   [I-D.ietf-alto-server-discovery] in order to yield a combined draft.

Kiesel & Stiemerling     Expires April 25, 2013                 [Page 5]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

3.  Third-party ALTO Server  Discovery Procedure Specification

   A already outlined in Section 2 the ALTO server discovery procedure
   is performed in two steps, which will be specified in Section 3.1 and
   Section 3.2, respectively.  The following figure gives an overview:

         IPv4 address    IPv6 address
               |              |
               v              v
           PTR lookup     PTR lookup
           |        |     |        |
           v        v     v        v
   no result        result1       no result
        |             |             |
        v             |             V
       FAIL           |     PTR lookup on (addr/64)
                      |      |                   |
                      |      v                   v
                      \     result1          no result
                       \   /                     |
                        \ /                      v
                         +                      FAIL
                         |
                         v
               NAPTR lookup on result1
                 |              |
                 v              v
               result2        no result
                  \             |
                   \            v
                    \         shorten result1 by one component
                     \        from the left, including first dot
                      \         |
                       \        v
                        \     second NAPTR lookup on shortened name
                         \      |               |
                          \     v               v
                           \  result2           no result
                            \ /                 |
                             +                  v
                             |                  FAIL
                             v
     Third-party ALTO server discovery procedure's output is: result2

Kiesel & Stiemerling     Expires April 25, 2013                 [Page 6]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

3.1.  Step 1: Retrieving the Domain Name

   Textual specification TBD.  See figure above.

   Somewhere in the figure, we do a lookup on addr/64, which is the
   "network part" of the IPv6 address computed as follows: addr/64 :=
   addr & 0xFFFF:FFFF:FFFF:FFFF:0000:0000:0000:0000.

   Note that the algorithm at some point tries to chop one component
   from the DNS name, but there is no recursion, i.e., no DNS tree
   walking.

3.2.  Step 2: U-NAPTR Resolution

   See Step 2 in [I-D.ietf-alto-server-discovery].

Kiesel & Stiemerling     Expires April 25, 2013                 [Page 7]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

4.  Deployment Considerations

   The mechanism specified in this document needs some configuration
   effort in order to work properly.

4.1.  IPv4 PTR lookup

   Especially the domain name retrieved through the reverse DNS lookup
   (PTR records) and the U-NAPTR entry need to be coordinated.  In this
   section we discuss this configuration for different scenarios.

4.1.1.  Private customers or very small businesses

   For private customers and very small businesses that are DSL or cable
   customers often a dynamically assigned IP address is provisioned.
   Here, the reverse DNS lookup (PTR records) are controlled by the ISP
   and they point to the ISP's domain, e.g.:

      d-c-b-a.dsl.westcoast.my-isp.net

   In this case, it would be the responsibility of the respective ISP to
   provide U-NAPTR entries for the DNS suffix without the endhost part,
   e.g.:

      westcoast.my-isp.net

4.1.2.  Medium-size customer networks

   The second class of customers have their own DNS domain but only one
   single upstream ISP, e.g.:

   (1)  ISP my-isp.net assigns an IP address a.b.c.d to its customer

   (2)  The customer decides that reverse mapping for a.b.c.d should be
        whatever.customerdomain.com

   (3)  If the customer wants to support ALTO, he has to ask the ISP for
        the URI of the ISP's ALTO server which can give guidance to
        a.b.c.d.  Assume that ISP replies it is
        http://altoserver.my-isp.net

   (4)  The customer establishes a U-NAPTR entry for his domain

       customerdomain.com.   IN NAPTR 200  10   "u"    "ALTO:http"
            "!.*!http://altoserver.my-isp.net!"  ""

Kiesel & Stiemerling     Expires April 25, 2013                 [Page 8]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

4.1.3.  Large Customers

   For very large customers with multiple upstream connections we assume
   that they have their very own traffic optimization policies and thus
   run their own ALTO server anyway.  In this case they need to manage
   their DNS entries accordingly.

4.2.  IPv6 PTR lookup

   The IPv6 address space per subnet is much larger than with IPv4 and
   mechanisms such as privacy extensions allow a host to randomly pick
   an IP address.  Establishing static PTR records for all IPv6
   addresses in a /64 prefix is a cumbersome task and unlikely to
   happen.  One alternative is the use of dynamic DNS.  Another option
   is to do without PTR records for individual IP addresses and just
   have a PTR record for the "network address".  The algorithm presented
   in the figure above can deal with that situation due to the second
   PTR lookup on (addr/64) if the direct PTR lookup fails.

Kiesel & Stiemerling     Expires April 25, 2013                 [Page 9]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

5.  Operational Considerations

   TBD.

Kiesel & Stiemerling     Expires April 25, 2013                [Page 10]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

6.  Security Considerations

   TBD.  See also [I-D.ietf-alto-server-discovery].

Kiesel & Stiemerling     Expires April 25, 2013                [Page 11]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

7.  IANA Considerations

   None.

Kiesel & Stiemerling     Expires April 25, 2013                [Page 12]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

8.  References

8.1.  Normative References

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

8.2.  Informative References

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

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

   [I-D.ietf-alto-server-discovery]
              Kiesel, S., Stiemerling, M., Schwan, N., Scharf, M., and
              S. Yongchao, "ALTO Server Discovery",
              draft-ietf-alto-server-discovery-04 (work in progress),
              July 2012.

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

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

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

   [RFC6708]  Kiesel, S., Previdi, S., Stiemerling, M., Woundy, R., and
              Y. Yang, "Application-Layer Traffic Optimization (ALTO)
              Requirements", RFC 6708, September 2012.

Kiesel & Stiemerling     Expires April 25, 2013                [Page 13]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

Appendix A.  Contributors List and Acknowledgments

   The initial version of this document was co-authored by Marco Tomsu
   <marco.tomsu@alcatel-lucent.com>.

   Hannes Tschofenig provided the initial input to the U-NAPTR solution
   part.  Hannes and Martin Thomson provided excellent feedback and
   input to the server discovery.

   This memo borrows a lot of text from
   [I-D.ietf-alto-server-discovery], as the 3pdisc was historically part
   of this memo.  Special thanks to Michael Scharf and Nico Schwan.

   Martin Stiemerling is partially supported by the CHANGE project (
   http://www.change-project.eu), a research project supported by the
   European Commission under its 7th Framework Program (contract no.
   257422).  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 CHANGE project or the European Commission.

Kiesel & Stiemerling     Expires April 25, 2013                [Page 14]
Internet-Draft      Third-Party ALTO Server Discovery       October 2012

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/

   Martin Stiemerling
   NEC Laboratories Europe
   Kurfuerstenanlage 36
   Heidelberg  69115
   Germany

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

Kiesel & Stiemerling     Expires April 25, 2013                [Page 15]