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

Versions: 00 01 02 03 04 05 06

ALTO                                                      M. Stiemerling
Internet-Draft                                           NEC Europe Ltd.
Intended status: Standards Track                               S. Kiesel
Expires: December 11, 2010                       University of Stuttgart
                                                            June 9, 2010


                     ALTO Deployment Considerations
                 draft-stiemerling-alto-deployments-03

Abstract

   Many Internet applications are used to access resources, such as
   pieces of information or server processes, which are available in
   several equivalent replicas on different hosts.  This includes, but
   is not limited to, peer-to-peer file sharing applications.  The goal
   of Application-Layer Traffic Optimization (ALTO) is to provide
   guidance to these applications, which have to select one or several
   hosts from a set of candidates, that are able to provide a desired
   resource.  The protocol is under specification in the ALTO working
   group.  However, this document discusses the deployment
   considerations of ALTO and also some preliminary security
   considerations.

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 December 11, 2010.

Copyright Notice

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



Stiemerling & Kiesel    Expires December 11, 2010               [Page 1]

Internet-Draft          Deployment Considerations              June 2010


   (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.  Overview . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Placement of ALTO Server for P2P . . . . . . . . . . . . . . .  8
   4.  Placement of ALTO Server for CDNs  . . . . . . . . . . . . . . 11
   5.  Cascading ALTO Servers . . . . . . . . . . . . . . . . . . . . 12
   6.  API between ALTO Client and Application  . . . . . . . . . . . 14
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
     7.1.  Information Leakage from the ALTO Server . . . . . . . . . 15
     7.2.  ALTO Server Access . . . . . . . . . . . . . . . . . . . . 15
     7.3.  Faking ALTO Guidance . . . . . . . . . . . . . . . . . . . 16
   8.  Conclusion . . . . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Appendix A.  Acknowledgments . . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21
























Stiemerling & Kiesel    Expires December 11, 2010               [Page 2]

Internet-Draft          Deployment Considerations              June 2010


1.  Introduction

   Many Internet applications are used to access resources, such as
   pieces of information or server processes, which are available in
   several equivalent replicas on different hosts.  This includes, but
   is not limited to, peer-to-peer file sharing applications.  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.  The basic ideas of ALTO are described in the problem space
   of ALTO is described in [RFC5693] and the set of requirements is
   discussed in [I-D.kiesel-alto-reqs].

   However, there are no considerations about what issues are to be
   expected once ALTO will be deployed.  This includes, but is not
   limited to, location of the ALTO server, imposed load to the ALTO
   server, or from whom the queries are performed.

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































Stiemerling & Kiesel    Expires December 11, 2010               [Page 3]

Internet-Draft          Deployment Considerations              June 2010


2.  Overview

   The ALTO protocol is a client/server protocol, operating between a
   number of ALTO clients and an ALTO server, as sketched in Figure 1.

   The ALTO working groups defines the ALTO protocol based on the P4P
   proposal [I-D.ietf-alto-protocol], but there are also other past and
   current protocol proposals, such as, H12 [I-D.kiesel-alto-h12], or
   the oracle approach [I-D.akonjang-alto-proxidor] the infoexport
   approach [I-D.shalunov-alto-infoexport].  Irrespectively of all
   mentioned protocols, the common set is always where the ALTO server
   is located an who is actually the querying entity to that ALTO
   server.

                 +----------+
                 |  ALTO    |
                 |  Server  |
                 +----------+
                       ^
                _.-----|------.
            ,-''       |       `--.
          ,'           |           `.
         (     Network |             )
          `.           |           ,'
            `--.       |       _.-'
                `------|-----''
                       v
    +----------+  +----------+   +----------+
    |  ALTO    |  |  ALTO    |...|  ALTO    |
    |  Client  |  |  Client  |   |  Client  |
    +----------+  +----------+   +----------+

                Figure 1: Network Overview of ALTO Protocol

   An ALTO server stores information about preferences (e.g., a list of
   preferred autonomous systems, IP ranges, etc) and ALTO clients can
   retrieve these preferences.  However, there are basically two
   different approaches on where the preferences are actually processed:

   1.  The ALTO server has a list of preferences and clients can
       retrieve this list via the ALTO protocol.  This preference list
       can be partially updated by the server.  The actual processing of
       the data is done on the client and thus there is no data of the
       client's operation revealed to the ALTO server .  This approach
       has been proposed by [I-D.shalunov-alto-infoexport].

   2.  The ALTO server has a list of preferences or preferences
       calculated during runtime and the ALTO client is sending



Stiemerling & Kiesel    Expires December 11, 2010               [Page 4]

Internet-Draft          Deployment Considerations              June 2010


       information of its operation (e.g., a list of IP addresses) to
       the server.  The server is using this operational information to
       determine its preferences and returns these preferences (e.g., a
       sorted list of the IP addresses) back to the ALTO client.  This
       approach has been initially described in [ACM.ispp2p], but never
       been described on the protocol level.

   Approach 1 (we call it H1) has the advantage (seen from the client)
   that all operational information stays within the client and is not
   revealed to the provider of the server.  On the other hand, does
   approach 1 require that the provider of the ALTO server, i.e., the
   network operator, reveals information about its network structure
   (e.g., AS numbers, IP ranges, topology information in general) to the
   ALTO client.

   Approach 2 (we call it H2) has the advantage (seen from the operator)
   that all operational information stays with the ALTO server and is
   not revealed to the ALTO client.  On the other hand, does approach 2
   require that the clients send their operational information to the
   server.

   Both approaches have their pros and cons and are extensively
   discussed on the ALTO mailing list.  But there is basically a
   dilemma: Approach 1 is seen as the only working solution by peer-to-
   peer software vendors and approach 2 is seen as the only working by
   the network operators.  But neither the software vendors nor the
   operators seem to willing to change their position.  However, there
   is the need to get both sides on board, to come to a solution.























Stiemerling & Kiesel    Expires December 11, 2010               [Page 5]

Internet-Draft          Deployment Considerations              June 2010


                                                  +-----+
                                                **|     |**
                                              **  +-----+  *
                                            **       *     *
                                          **         *     *
        +-----+     +------+     +-----+**        +-----+  *
        |     |.....|      |=====|     |**********|     |  *
        +-----+     +------+     +-----+**        +-----+  *
      Source of      ALTO        Resource **         *     *
      topological    service     directory  **       *     *
      information               ("tracker")   **  +-----+  *
                                                **|     |**
                                                  +-----+
                                                   Peers
      Legend:
      === ALTO client protocol
      *** Application protocol
      ... Provisioning protocol

     Figure 2: Overview of protocol interaction between ALTO elements,
                           scenario with tracker

   However, Figure 2 does not denote where the ALTO elements are
   actually located, i.e., if the tracker and the ALTO server are in the
   same ISP's domain, or if the tracker and the ALTO server are managed/
   owned/located in different domains.  The latter is the typical use
   case, e.g., taking Pirate Bay as example that serves Bittorrent users
   world-wide.























Stiemerling & Kiesel    Expires December 11, 2010               [Page 6]

Internet-Draft          Deployment Considerations              June 2010


                                                  +-----+
                                             =====|     |**
                                         ====     +-----+  *
                                     ====            *     *
                                 ====                *     *
        +-----+     +------+=====                 +-----+  *
        |     |.....|      |======================|     |  *
        +-----+     +------+=====                 +-----+  *
      Source of      ALTO        ====                *     *
      topological    service         ====            *     *
      information                        ====     +-----+  *
                                             =====|     |**
                                                  +-----+
      Legend:
      === ALTO client protocol
      *** Application protocol
      ... Provisioning protocol

          Figure 3: Overview of protocol interaction between ALTO
                     elements,scenario without tracker

   Figure 3 shows the operational model for applications that do not use
   a tracker, such as, edonky, or in if the tracker should be the
   querying party.  This use case also holds true for CDNs.  The ALTO
   server can also be queried by CDNs to get a guidance about where the
   a particular client accessing data in the CDN is exactly located in
   the ISP's network.
























Stiemerling & Kiesel    Expires December 11, 2010               [Page 7]

Internet-Draft          Deployment Considerations              June 2010


3.  Placement of ALTO Server for P2P

   This section discuss where the ALTO server can be placed and which
   entities are querying the ALTO server from what ALTO client.  The
   section assumes a P2P system relying a tracker to initially find
   other peers.  However, the tracker can be replaced by any other
   database that provides a rendezvous point for an application.  The
   limitation to a tracker is made for educational purpose, i.e. to ease
   the general understanding.
                                 ,-------.
          ,---.               ,-'         `-.   +-----------+
       ,-'     `-.           /     ISP 1     \  |   Peer 1  |*****
      /           \         / +-------------+ \ |           |    *
     /    ISP X    \   +=====>+ ALTO Server |  )+-----------+    *
    /               \  =    \ +-------------+ / +-----------+    *
   ; +-----------+   : =     \               /  |   Peer 2  |    *
   | |  Tracker  |<====+      `-.         ,-'   |           |*****
   | |ALTO Client|<====+         `-------'      +-----------+   **
   | +-----------+   | =         ,-------.                      **
   :        *        ; =      ,-'         `-.   +-----------+   **
    \       *       /  =     /     ISP 2     \  |   Peer 3  |   **
     \      *      /   =    / +-------------+ \ |           |*****
      \     *     /    +=====>| ALTO Server |  )+-----------+  ***
       `-.  *  ,-'          \ +-------------+ / +-----------+  ***
          `-*-'              \               /  |   Peer 4  |*****
            *                 `-.         ,-'   |           | ****
            *                    `-------'      +-----------+ ****
            *                                                 ****
            *                                                 ****
            ***********************************************<******
       Legend:
       === ALTO client protocol
       *** Application protocol

      Figure 4: Global tracker accessing ALTO server at various ISPs

   Figure 4 depicts a tracker-based system, where the tracker embeds the
   ALTO client.  The tracker itself is hosted and operated by an entity
   different than the ISP hosting and operating the ALTO server.
   Initially, the tracker has to look-up the ALTO server in charge for
   each peer where it receives a ALTO query for.  Therefore, the ALTO
   server has to discover the handling ALTO server, as described in
   [I-D.kiesel-alto-3pdisc].  However, the peers do not have any way to
   query the server themselves.  This setting allows to give the peers a
   better selection of candidate peers for their operation at an initial
   time, but does not consider peers learned through direct peer-to-peer
   knowledge exchange, AKA peer exchange in various peer-to-peer
   protocols.



Stiemerling & Kiesel    Expires December 11, 2010               [Page 8]

Internet-Draft          Deployment Considerations              June 2010


                            ,-------.         +-----------+
          ,---.          ,-'         `-.  +==>|   Peer 1  |*****
       ,-'     `-.      /     ISP 1     \ =   |ALTO Client|    *
      /           \    / +-------------+<=+   +-----------+    *
     /    ISP X    \   | + ALTO Server |<=+   +-----------+    *
    /               \  \ +-------------+ /=   |   Peer 2  |    *
   ;   +---------+   :  \               / +==>|ALTO Client|*****
   |   | Global  |   |   `-.         ,-'      +-----------+   **
   |   | Tracker |   |      `-------'                         **
   |   +---------+   |      ,-------.         +-----------+   **
   :        *        ;   ,-'         `-.  +==>|   Peer 3  |   **
    \       *       /   /     ISP 2     \ =   |ALTO Client|*****
     \      *      /   / +-------------+<=+   +-----------+  ***
      \     *     /    | | ALTO Server |<=+   +-----------+  ***
       `-.  *  ,-'     \ +-------------+ /=   |   Peer 4  |*****
          `-*-'         \               / +==>|ALTO Client| ****
            *            `-.         ,-'      +-----------+ ****
            *               `-------'                       ****
            *                                               ****
            ***********************************************<****
       Legend:
       === ALTO client protocol
       *** Application protocol



               Figure 5: Global Tracker - Local ALTO Servers

   The scenario in Figure 5 lets the peers directly communicate with
   their ISP's ALTO server (i.e., ALTO client embedded in the peers),
   giving thus the peers the most control on which information they
   query for, as they can integrate information received from trackers
   and through direct peer-to-peer knowledge exchange.


















Stiemerling & Kiesel    Expires December 11, 2010               [Page 9]

Internet-Draft          Deployment Considerations              June 2010


                             ,-------.         +-----------+
           ,---.          ,-'  ISP 1  `-.  ***>|   Peer 1  |
        ,-'     `-.      /+-------------+\ *   |           |
       /           \    / +   Tracker   |<**   +-----------+
      /    ISP X    \   | +-----===-----+<**   +-----------+
     /               \  \ +-----===-----+ /*   |   Peer 2  |
    ;   +---------+   :  \+ ALTO Server |/ ***>|           |
    |   | Global  |   |   +-------------+      +-----------+
    |   | Tracker |   |      `-------'
    |   +---------+   |                        +-----------+
    :          ^      ;      ,-------.         |   Peer 3  |
     \         *     /    ,-'  ISP 2  `-.  ***>|           |
      \        *    /    /+-------------+\ *   +-----------+
       \       *   /    / +   Tracker   |<**   +-----------+
        `-.    *,-'     | +-----===-----+ |    |   Peer 4  |<*
           `---*        \ +-----===-----+ /    |           | *
               *         \+ ALTO Server |/     +-----------+ *
               *          +-------------+                    *
               *             `-------'                       *
               ***********************************************
        Legend:
        === ALTO client protocol
        *** Application protocol

      Figure 6: P4P approach with local tracker and local ALTO server

   There are some attempts to let ISP's to deploy their own trackers, as
   shown in Figure 6.  In this case, the client has no chance to get
   guidance from the ALTO server, other than talking to the ISP's
   tracker.  However, the peers would have still chance the contact
   other trackers, deployed by entities other than the peer's ISP.

   Figure 6 and Figure 4 ostensibly take peers the possibility to
   directly query the ALTO server, if the communication with the ALTO
   server is not permitted for any reason.  However, considering the
   plethora of different applications of ALTO, e.g., multiple tracker
   and non-tracker based P2P systems and or applications searching for
   relays, it seems to be beneficial for all participants to let the
   peers directly query the ALTO server.  The peers are also the single
   point having all operational knowledge to decide whether to use the
   ALTO guidance and how to use the ALTO guidance.  This is a preference
   for the scenario depicted in Figure Figure 5.









Stiemerling & Kiesel    Expires December 11, 2010              [Page 10]

Internet-Draft          Deployment Considerations              June 2010


4.  Placement of ALTO Server for CDNs

   Section 3 discussed the placement and usage of ALTO for P2P systems,
   but not beyond.  This section discuss the usage of ALTO for Content
   Delivery Networks (CDNs).  CDNs are used to bring a service (e.g., a
   web page, videos, etc) closer to location of the user - where close
   refers to shorten the distance between the client and the server in
   the IP topology.  CDNs use several techniques to decide which server
   is closest to a client requesting a service.  One common way to do
   so, is relying on the DNS system, but there are many other ways, see
   [RFC3568], and has some issues as detailed in
   [I-D.vandergaast-edns-client-ip].

   This section refers to [I-D.penno-alto-cdn] as a initial step.





































Stiemerling & Kiesel    Expires December 11, 2010              [Page 11]

Internet-Draft          Deployment Considerations              June 2010


5.  Cascading ALTO Servers

   The main assumptions of ALTO seems to be each ISP operates its own
   ALTO server independently, irrespectively of the ISP's situation.
   This may true for most envisioned deployments of ALTO but there are
   certain deployments that may have different settings.  Figure 7 shows
   such setting, were for example, a university network is connected to
   two upstream providers.  ISP2 if the national research network and
   ISP1 is a commercial upstream provider to this university network.
   The university, as well as ISP1, are operating their own ALTO server.
   The ALTO clients, located on the peers will contact the ALTO server
   located at the university.


         +-----------+
         |   ISP1    |
         |   ALTO    |
         |  Server   |
         +----------=+
            ,-------=            ,------.
         ,-'        =`-.      ,-'         `-.
        /   Upstream=   \    /   Upstream    \
       (       ISP1 =    )  (       ISP2      )
        \           =   /    \               /
         `-.        =,-'      `-.         ,-'
            `---+---=            `+------'
                |   =             |
                |   =======================
                |,-------------.  |       =
              ,-+               `-+    +-----------+
            ,'      University     `.  |University |
           (        Network          ) |   ALTO    |
            `.  =======================|  Server   |
              `-=               +-'    +-----------+
                =`+------------'|
                = |             |
         +--------+-+         +-+--------+
         |   Peer1  |         |   PeerN  |
         +----------+         +----------+

                      Figure 7: Cascaded ALTO Server

   In this setting all "destinations" useful for the peers within ISP2
   are free-of-charge for the peers located in the university network
   (i.e., they are preferred in the rating of the ALTO server).
   However, all traffic that is not towards ISP2 will be handled by the
   ISP1 upstream provider.  Therefore, the ALTO server at the university
   has also to include the guidance given by the ISP1 ALTO server in its



Stiemerling & Kiesel    Expires December 11, 2010              [Page 12]

Internet-Draft          Deployment Considerations              June 2010


   replies to the ALTO clients.  This can be called cascaded ALTO
   servers.

















































Stiemerling & Kiesel    Expires December 11, 2010              [Page 13]

Internet-Draft          Deployment Considerations              June 2010


6.  API between ALTO Client and Application

   This sections gives some informational guidance on how the interface
   between the actual application using the ALTO guidance and the ALTO
   client can look like.

   This is still TBD.












































Stiemerling & Kiesel    Expires December 11, 2010              [Page 14]

Internet-Draft          Deployment Considerations              June 2010


7.  Security Considerations

   The ALTO protocol itself, as well as, the ALTO client and server
   raise new security issues beyond the one mentioned in
   [I-D.ietf-alto-protocol] and issues related to message transport over
   the Internet.  For instance, Denial of Service (DoS) is of interest
   for the ALTO server and also for the ALTO client.  A server can get
   overloaded if too many TCP requests hit the server, or if the query
   load of the server surpasses the maximum computing capacity.  An ALTO
   client can get overloaded if the responses from the sever are, either
   intentionally or due to an implementation mistake, too large to be
   handled by that particular client.

7.1.  Information Leakage from the ALTO Server

   The ALTO server will be provisioned with information about the owning
   ISP's network and very likely also with information about neighboring
   ISPs.  This information (e.g., network topology, business relations,
   etc) is consider to be confidential to the ISP and must not be
   revealed.

   The ALTO server will naturally reveal parts of that information in
   small doses to peers, as the guidance given will depend on the above
   mentioned information.  This is seen beneficial for both parties,
   i.e., the ISP's and the peer's.  However, there is the chance that
   one or multiple peers are querying an ALTO server with the goal to
   gather information about network topology or any other data
   considered confidential or at least sensitive.  It is unclear whether
   this is a real technical security risk or whether this is more a
   perceived security risk.

7.2.  ALTO Server Access

   Depending on the use case of ALTO, several access restrictions to an
   ALTO server may or may not apply.  For an ALTO server that is solely
   accessible by peers from the ISP network (as shown in Figure 5), for
   instance, the source IP address can be used to grant only access from
   that ISP network to the server.  This will "limit" the number of
   peers able to attack the server to the user's of the ISP (however,
   including botnet computers).

   On the other hand, if the ALTO server has to be accessible by parties
   not located in the ISP's network (see Figure Figure 4), e.g., by a
   third-party tracker or by a CDN system outside the ISP's network, the
   access restrictions have to be more loose.  In the extreme case,
   i.e., no access restrictions, each and every host in the Internet can
   access the ALTO server.  This might no the intention of the ISP, as
   the server is not only subject to more possible attacks, but also on



Stiemerling & Kiesel    Expires December 11, 2010              [Page 15]

Internet-Draft          Deployment Considerations              June 2010


   the load imposed to the server, i.e., possibly more ALTO clients to
   serve and thus more work load.

7.3.  Faking ALTO Guidance

   It has not yet been investigated how a faked or wrong ALTO guidance
   by an ALTO server can impact the operation of the network and also
   the peers.

   Here is a list of examples how the ALTO guidance could be faked and
   what possible consequences may arise:

   Sorting  An attacker could change to sorting order of the ALTO
      guidance (given that the order is of importance, otherwise the
      ranking mechanism is of interest), i.e., declaring peers located
      outside the ISP as peers to be preferred.  This will not pose a
      big risk to the network or peers, as it would mimic the "regular"
      peer operation without traffic localization, apart from the
      communication/processing overhead for ALTO.  However, it could
      mean that ALTO is reaching the opposite goal of shuffling more
      data across ISP boundaries, incurring more costs for the ISP.

   Preference of a single peer  A single IP address (thus a peer) could
      be marked as to be preferred all over other peers.  This peer can
      be located within the local ISP or also in other parts of the
      Internet (e.g., a web server).  This could lead to the case that
      quite a number of peers to trying to contact this IP address,
      possibly causing a Denial of Service (DoS) attack.

   This section is solely giving a first shot on security issues related
   to ALTO deployments.




















Stiemerling & Kiesel    Expires December 11, 2010              [Page 16]

Internet-Draft          Deployment Considerations              June 2010


8.  Conclusion

   This is the first version of the deployment considerations and for
   sure the considerations are yet incomplete and imprecise.















































Stiemerling & Kiesel    Expires December 11, 2010              [Page 17]

Internet-Draft          Deployment Considerations              June 2010


9.  References

9.1.  Normative References

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

   [RFC3568]  Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
              Content Network (CN) Request-Routing Mechanisms",
              RFC 3568, July 2003.

9.2.  Informative References

   [ACM.ispp2p]
              Aggarwal, V., Feldmann, A., and C. Scheideler, "Can ISPs
              and P2P systems co-operate for improved performance?",  In
              ACM SIGCOMM Computer Communications Review
              (CCR), 37:3, pp. 29-40.

   [I-D.akonjang-alto-proxidor]
              Akonjang, O., Feldmann, A., Previdi, S., Davie, B., and D.
              Saucez, "The PROXIDOR Service",
              draft-akonjang-alto-proxidor-00 (work in progress),
              March 2009.

   [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.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.kiesel-alto-h12]
              Kiesel, S. and M. Stiemerling, "ALTO H12",
              draft-kiesel-alto-h12-02 (work in progress), March 2010.

   [I-D.kiesel-alto-reqs]
              Kiesel, S., Popkin, L., Previdi, S., Woundy, R., and Y.
              Yang, "Application-Layer Traffic Optimization (ALTO)
              Requirements", draft-kiesel-alto-reqs-02 (work in
              progress), March 2009.

   [I-D.penno-alto-cdn]
              Penno, R., Raghunath, S., Medved, J., Bakshi, M., Alimi,
              R., and S. Previdi, "ALTO and Content Delivery Networks",
              draft-penno-alto-cdn-00 (work in progress), June 2010.



Stiemerling & Kiesel    Expires December 11, 2010              [Page 18]

Internet-Draft          Deployment Considerations              June 2010


   [I-D.penno-alto-protocol]
              Penno, R. and Y. Yang, "ALTO Protocol",
              draft-penno-alto-protocol-04 (work in progress),
              October 2009.

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

   [I-D.stiemerling-alto-h1h2-protocol]
              Stiemerling, M. and S. Kiesel, "ALTO H1/H2 Protocol",
              draft-stiemerling-alto-h1h2-protocol-00 (work in
              progress), March 2009.

   [I-D.vandergaast-edns-client-ip]
              Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
              "Client IP information in DNS requests",
              draft-vandergaast-edns-client-ip-01 (work in progress),
              May 2010.

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



























Stiemerling & Kiesel    Expires December 11, 2010              [Page 19]

Internet-Draft          Deployment Considerations              June 2010


Appendix A.  Acknowledgments

   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.









































Stiemerling & Kiesel    Expires December 11, 2010              [Page 20]

Internet-Draft          Deployment Considerations              June 2010


Authors' Addresses

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

   Phone: +49 6221 4342 113
   Fax:   +49 6221 4342 155
   Email: martin.stiemerling@neclab.eu
   URI:   http://www.nw.neclab.eu/


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

   Email: ietf-alto@skiesel.de






























Stiemerling & Kiesel    Expires December 11, 2010              [Page 21]


Html markup produced by rfcmarkup 1.108, available from http://tools.ietf.org/tools/rfcmarkup/