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

Versions: 00 01 02 03

Network Working Group                                           R. Penno
Internet-Draft                                              S. Raghunath
Intended status: Experimental                                  J. Medved
Expires: December 6, 2010                                      M. Bakshi
                                                        Juniper Networks
                                                                R. Alimi
                                                         Yale University
                                                              S. Previdi
                                                           Cisco Systems
                                                           June 04, 2010


                   ALTO and Content Delivery Networks
                        draft-penno-alto-cdn-00

Abstract

   Networking applications can request through the ALTO protocol
   information about the underlying network topology from the ISP or
   Content Provider (henceforth referred as Provider) point of view.  In
   other words, what a Provider prefers in terms of traffic optimization
   -- and a way to distribute it.  The ALTO Service provides information
   such as preferences of network resources with the goal of modifying
   network resource consumption patterns while maintaining or improving
   application performance.

   A main use case of the ALTO Service is its integration with of
   Content Delivery Networks (CDN).  In this document we describe the
   deployment scenarios and considerations for a ALTO Service in the
   case of CDNs.

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



Penno, et al.           Expires December 6, 2010                [Page 1]


Internet-Draft              Abbreviated-Title                  June 2010


   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 6, 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
   (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.































Penno, et al.           Expires December 6, 2010                [Page 2]


Internet-Draft              Abbreviated-Title                  June 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  Scope  . . . . . . . . . . . . . . . . . . . . . . . . . . . .  4
   3.  Terminology  . . . . . . . . . . . . . . . . . . . . . . . . .  4
   4.  HTTP Redirect  . . . . . . . . . . . . . . . . . . . . . . . .  5
     4.1.  ALTO Server Discovery  . . . . . . . . . . . . . . . . . .  7
     4.2.  CDN Node Discovery and Status  . . . . . . . . . . . . . .  7
     4.3.  CDN Node Status Updates received by HTTP Redirector  . . .  7
     4.4.  CDN Node Status Updates received by ALTO Server  . . . . .  8
   5.  DNS Integration  . . . . . . . . . . . . . . . . . . . . . . . 10
   6.  Administrative domains and ALTO  . . . . . . . . . . . . . . . 11
     6.1.  CDN nodes in the ISP administrative domain . . . . . . . . 11
     6.2.  CDN nodes in a separate administrative domain from
           that of ISP  . . . . . . . . . . . . . . . . . . . . . . . 12
     6.3.  Integrating with managed DNS service . . . . . . . . . . . 14
       6.3.1.  Managed DNS resolver used to redirect to local
               cache  . . . . . . . . . . . . . . . . . . . . . . . . 14
       6.3.2.  Managed DNS resolver used with multiple CDN vendors  . 16
   7.  Tracker Integration  . . . . . . . . . . . . . . . . . . . . . 16
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 16
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 17
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 17
     11.2. Informative References . . . . . . . . . . . . . . . . . . 17
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17
























Penno, et al.           Expires December 6, 2010                [Page 3]


Internet-Draft              Abbreviated-Title                  June 2010


1.  Introduction

   Content Delivery Networks are becoming increasingly important in the
   Internet [ARBOR] and many CDNs today already use some form of
   application proximity through geolocation.  But in many cases the
   content provider and the Service Provider are disjoint and even if
   content servers are co-located into the ISP's networks, there is no
   standardized way to share information.  Therefore a natural step
   forward would be to use ALTO for full integration.

   Another key aspect of ALTO in the context of CDNs deployments is that
   there is an expectation that no changes to the hosts are needed (or
   would be transparent to the user).  In other words, a traditional web
   browser is all there is needed to take advantage of ALTO information.
   This is significant difference from the P2P file sharing case where a
   special client is needed and ALTO is normally used as a way to reduce
   operational expense.


2.  Scope

   This document discusses how Content Delivery Networks can benefit
   from ALTO through integration of the ALTO Service with the main
   request routing techniques.  Whenever a gap in protocol functionality
   is identified to achieve such integration, it will be enumerated with
   'GAP-<N>'.  Each gap is documented in a section of their own in order
   to foster parallel discussion and possible adoption.


3.  Terminology

      Content-aware Proximity Redirector: The Redirector knows about
      locations and presence of content & media objects in the network.
      Therefore the redirection to a CDN node is made based on
      availability of content or content-type in that CDN node and the
      proximity of the CDN node to the user.

      Service-aware Proximity Redirector: The Redirector knows about
      locations of CDN nodes in the network and redirects user to the
      closest CDN node.  The redirection made irrespective of content
      presence in the CDN Node; if content not present, the cache will
      be populated with the content before or when the content is served
      to the user.

      HTTP Redirector: a Content-Aware or Service Aware Proximity
      Redirector for HTTP.  It embeds an HTTP Server that performs HTTP
      Redirects, an ALTO client that retrieves network mapping from the
      ALTO Server and a Location Database which stores network mappings



Penno, et al.           Expires December 6, 2010                [Page 4]


Internet-Draft              Abbreviated-Title                  June 2010


      received from the ALTO Client.  The HTTP Server consults the
      Location Database when making redirection decisions.


4.  HTTP Redirect

   In this case an HTTP GET request from a host is received by an HTTP
   Redirector which sends back an HTTP responses with Status-Code 302
   (Redirect) informing the host of the best location to fetch the
   content.  The HTTP Redirection method is already commonly used in
   production CDNs as described in RFC3568 [RFC3568].  ALTO integration
   provides localization services where the device that performs the
   redirection becomes an ALTO client.

   The ALTO client embedded in the HTTP Redirector fetches the cost and
   network map from the ALTO Server and provides that information to the
   HTTP Server.  When the HTTP Redirector intercepts an HTTP GET request
   (1), it looks up the source IP address on the GET request, consults
   the Location Database and returns an HTTP redirect with the URL of
   the best CDN node from which to service the host.  The URL in 302
   Redirect may contain the IP address of the selected CDN node or a
   domain name instead of IP address due to virtual hosting.  Therefore
   the IP addresses contained in the cost maps may need to be correlated
   to domain names a priori.



























Penno, et al.           Expires December 6, 2010                [Page 5]


Internet-Draft              Abbreviated-Title                  June 2010


                                 +-----------------+
                                 | HTTP Redirector |
         +------+      1         | +-------------+ |
         |      |--------------> | | HTTP Server | |
         | Host |<-------------- | +-------------+ |
         +------+      2         |        ^        |
                                 |        |        |
                                 | +-------------+ |
                                 | | Location DB | |
                                 | +-------------+ |
                                 |        ^        |
                                 |        |        |
                                 | +-------------+ |
                                 | | ALTO Client | |
                                 | +-------------+ |
                                 +-----------------+
                                        |   ^
                                        |   |  ALTO Protocol
                                        |   |  (Map Service)
                                        v   |
                                 +-----------------+
                                 |   ALTO Server   |
                                 +-----------------+

                         Figure 1: HTTP Redirector

   The Network Maps generated by the ALTO server contain Host PIDs and
   CDN Node PIDs, i.e., Host PIDs contain host subnets; CDN PIDs contain
   IP addresses of available CDN nodes.  Cost Maps contain only cost
   from each host PID to each CDN PID and not the full matrix across all
   PIDs.  The reason is that the HTTP Redirector can only redirect a
   host to a CDN node, not to another host as in the P2P case.
   Moreover, there is no generic way to disambiguate PIDs containing
   only hosts from PIDs containing CDN nodes (GAP).

   The cost for CDN PID to CDN PID and from between host PIDs are
   assumed to be infinity (GAP).  The HTTP Redirector looks up the
   source address on the HTTP GET request, and uses the cost map to
   select the best CDN PID and a CDN node from it.  The CDN node
   selection method can be random, round-robin, or the HTTP Redirector
   can use some level of content awareness (i.e. send requests for the
   same content (URL) to the same CDN node.

      GAP-1 (PID Attributes): In order to disambiguate between PIDs that
      contain endpoints of a specific class, a PID property is needed.
      A PID can be classified as containing "CDN nodes", "Mobile Hosts",
      "Wireline Hosts", etc.




Penno, et al.           Expires December 6, 2010                [Page 6]


Internet-Draft              Abbreviated-Title                  June 2010


      GAP-2 (PID Attributes and Query): PID attributes can be used by
      the Client to select a appropriate host and also passed as a
      constraint in the map filtering service.

      GAP-3 (Default Cost): The issue of default cost if one of
      importance.  Without a default PID with endpoint '0.0.0.0/0', what
      should be the cost between two PIDs?  Moreover, if the default PID
      mandatory in the protocol?

   A future revision will incorporate analysis of ALTO Server - HTTP
   Redirector interaction with Endpoint Cost Service

4.1.  ALTO Server Discovery

4.2.  CDN Node Discovery and Status

   The method of discovering available caches and their locations is not
   specified.  We assume the CDN nodes are discovered in some way.  It
   is desirable that not only CDN node locations, but also real-time
   status (like health, load, cache utilization, CPU, etc.) is
   communicated either to the HTTP Redirector or to the ALTO Server.

   CDN node status can be retrieved from the existing Load Balancer
   infrastructure.  Most Load Balancers today have mechanisms to poll
   caches/servers via ping, HTTP Get, traceroute, etc.  Most LBs have
   SNMP trap capabilities to let other devices know about these
   thresholds.  The HTTP Redirector or the ALTO Server can implement an
   SNMP agent and get to know whatever is needed.  For greenfield
   installations, the ALTO Server could also provide an API (for
   example, a Web Service or XMPP-based API) that could be used by CDN
   nodes to communicate their status to the ALTO server directly.

4.3.  CDN Node Status Updates received by HTTP Redirector

   In this use case the HTTP Redirector receives CDN Status updates.
















Penno, et al.           Expires December 6, 2010                [Page 7]


Internet-Draft              Abbreviated-Title                  June 2010


                                 +-----------------+
                                 | HTTP Redirector |
         +------+      1         | +-------------+ |
         |      |--------------> | | HTTP Server | |
         | Host |<-------------- | +-------------+ |
         +------+      2         |        ^        |
                                 |        |        |
                                 | +-------------+ |
                                 | | Location DB | |<--- Real-time CDN
                                 | +-------------+ |     status updates
                                 |        ^        |
                                 |        |        |
                                 | +-------------+ |
                                 | | ALTO Client | |
                                 | +-------------+ |
                                 +-----------------+
                                        |   ^
                                        |   |  ALTO Protocol
                                        |   |  (Map Service)
                                        v   |
                                 +-----------------+
                                 |   ALTO Server   |
                                 +-----------------+

                Figure 2: RT CDN Updates to HTTP Redirector

4.4.  CDN Node Status Updates received by ALTO Server

   This model generally simplifies the HTTP Redirector.  It allows an
   easier distribution of the HTTP Redirector, and to keep real time CDN
   status data updates in a logically centralized ALTO Server or in an
   ALTO Server Cluster.  It allows for the HTTP Redirector and the ALTO
   Server to be in different administrative domains.  For example, the
   HTTP Redirector can be in a Content Provider's domain, the ALTO
   Server and CDN Nodes in a Network Service Provider's domain.
















Penno, et al.           Expires December 6, 2010                [Page 8]


Internet-Draft              Abbreviated-Title                  June 2010


                                 +-----------------+
                                 | HTTP Redirector |
         +------+      1         | +-------------+ |
         |      |--------------> | | HTTP Server | |
         | Host |<-------------- | +-------------+ |
         +------+      2         |        ^        |
                                 |        |        |
                                 | +-------------+ |
                                 | | Location DB | |
                                 | +-------------+ |
                                 |        ^        |
                                 |        |        |
                                 | +-------------+ |
                                 | | ALTO Client | |
                                 | +-------------+ |
                                 +-----------------+
                                        |   ^
                                        |   |  ALTO Protocol
                                        |   |  (Map Service)
                                        v   |
                                 +-----------------+
                                 |   ALTO Server   |<--- Real-time CDN
                                 +-----------------+     status updates

                  Figure 3: RT CDN Updates to ALTO Server

   In this model it is recommended that a given HTTP Redirector may be
   designated as being responsible for a fixed set of Host PIDs.  This
   information can be made available to the HTTP Redirector before it
   receives requests from clients.  If the set of Host PIDs is not known
   ahead of time, the latency for serving requests will be impacted by
   the capabilities of the ALTO server.  With such information ahead of
   time, the HTTP Redirector may pre-download the network map for the
   interesting Host PIDs and the CDN PIDs.  It can also start
   periodically pulling cost maps for relevant PID 2-tuples.

   The HTTP Redirector can rely on the ALTO Server generated Cache-
   Control headers to decide how often to fetch CDN PID network map and
   Host PID network maps.  In order to better deal with outages of
   caches or changes to CDN PIDs, a push mechanism from ALTO server to
   ALTO client would be needed (GAP-4).  In the general P2P scenario
   this may not make sense, but with content delivery this may be
   important from a service continuity perspective.

   If the maps are large and change often a natural extension to the
   protocol is to allow incremental Map Updates (GAP-5).  This
   requirement becomes more emphasized when the ALTO Server is the
   recipient of CDN nodes' status updates, because their load/status



Penno, et al.           Expires December 6, 2010                [Page 9]


Internet-Draft              Abbreviated-Title                  June 2010


   changes are typically more frequent than topology changes in the
   network.

      GAP-4 (Push Mechanism): It is important for the ALTO Service
      through the ALTO protocol or a companion protocol to provide a
      push mechanism from server to client.  The push mechanism can be a
      notification that new data is vailable or the data itself.

      GAP-5 (Incremental Map Updates): A natural evolution to the
      protocol if maps are large and change often is to allow for
      incremental map updates.  In this sense the map contained in the
      reply would be considered the delta from the previous version.


5.  DNS Integration

   In the case of DNS request routing, the DNS server handling client
   requests is integrated with an ALTO client.  When the host performs a
   DNS query lookup, the IP address contained in the response are
   already optimal for that query.  As in the previous example, no
   changes in the host are needed.

   DNS queries can be either iterative or recursive.  Iterative queries
   can be used with ALTO if the client itself queries the DNS Servers,
   or if the DNS Proxy used by the host is topologically close to the
   host.  If the Host queries the DNS Servers, the authoritative DNS
   Server can see directly the host's IP address.  If the the DNS
   Proxy's is topologically close to the Host, its IP address is a good
   approximation for the host's location.  In recursive queries, the
   authoritative DNS Server sees the IP address of the previous DNS
   Server in the resolution chain, and the IP address of the host is
   unknown.  DNS-based request routing does not work with recursive DNS
   queries.

   In an iterative DNS lookup with DNS Proxy, as shown in examples in
   the next section, the host queries the Proxy, which in turn first
   queries one of the root servers to find the server authoritative for
   the top-level domain (com in our example).  The Proxy then queries
   the obtained top-level-domain DNS server for the address of the DNS
   server authoritative for the cdn domain.  Finally, the Proxy queries
   the DNS server that is authoritative for the cdn.com domain.  The
   authoritative DNS Server for the cdn.com will perform the request
   routing to the most appropriate CDN node, based on the source IP
   address of the requestor.  The client will then request the content
   directly from the CDN Node.






Penno, et al.           Expires December 6, 2010               [Page 10]


Internet-Draft              Abbreviated-Title                  June 2010


6.  Administrative domains and ALTO

   With DNS-based redirection, among others, there are two models that
   are worth further study - one, where the CDN nodes are in the
   administrative domain of the ISP and two, where CDN nodes are part of
   a separate domain from that of the ISP.  In the first use case, the
   Host, the CDN Nodes, the ALTO Server and the Authoritative DNS Server
   for the CDN domain are in the same administrative domain.  In the
   second use case, Hosts and CDN Nodes are in different administrative
   domains.

6.1.  CDN nodes in the ISP administrative domain

   When the CDN nodes are within the ISP's administrative domain, the
   DNS server with the ALTO client is under the ISP's management.  As
   described earlier, the best CDN node is picked by performing an ALTO
   query on the source IP address of the DNS request.


































Penno, et al.           Expires December 6, 2010               [Page 11]


Internet-Draft              Abbreviated-Title                  June 2010


                           2      +----------------+
             +------------------> |       root     |
             | +----------------- |   Name Server  |      +----------+
             | |           3      +----------------+      | Content  |
             | |                                          | Provider |
             | |           4      +----------------+      +----------+
             | |   +------------> |       com      |
             | |   | +----------- |   Name Server  |
             | |   | |     5      +----------------+
      .......|.|...|.|...............................................
      :      | V   | V                                              :
      :     +---------+           +----------------+                :
      :     |   DNS   |---------> |     cdn.com    |                :
      :     |  Proxy  |<--------- |   Name Server  |                :
      :     +---------+    7      |                |                :
      :         ^ |               | +------------+ |                :
      :       1 | | 8             | |ALTO Client | |                :
      :         | V               | +------------+ |                :
      :     +---------+           +----------------+                :
      :     |  Host   |                  |   ^                      :
      :     +---------+                  |   |  ALTO Protocol       :
      :          |                       |   |  (Map Service)       :
      :          |                       V   |                      :
      :          V                +----------------+                :
      :       CDN Node            |   ALTO Server  |                :
      :                           +----------------+                :
      :                                                             :
      :              NSP/CDN Administrative Domain                  :
      :.............................................................:

             Figure 4: DNS Resolution with single admin domain

6.2.  CDN nodes in a separate administrative domain from that of ISP

   In many situations, the CDN nodes are in a separate network managed
   by an entity that is distinct from the ISP.  Consequently, the CDN
   nodes belong to a network with its own ALTO server that is distinct
   from the ALTO server of the ISP where the subscriber belongs.













Penno, et al.           Expires December 6, 2010               [Page 12]


Internet-Draft              Abbreviated-Title                  June 2010


                                       .................................
                                       :      +-----------------+      :
                                       :      |     cdn.com     |      :
                                       :      |   Name Server   |      :
            +----------+               :      |                 |      :
            | Content  |               :      | +-------------+ |      :
            | Provider |               :      | | ALTO Client | |      :
            +----------+               :      | +-------------+ |      :
                                       :      +-----------------+      :
                                       :              ^                :
                                       :              |                :
                                       :      +-----------------+      :
   .................................   :      |   ALTO Server   |      :
   :                               :   :      |                 |      :
   :    +----------------+         :   :      | +-------------+ |      :
   :    |   ALTO Server  |--------------------->| ALTO Client | |      :
   :    +----------------+         :   :      | +-------------+ |      :
   :                               :   :      +-----------------+      :
   :                               :   :                               :
   : +------+ C(1-4)    +--------+ :   : +--------+    C(6-8) +------+ :
   : | Host |<--------->| Border |: c6  :| Border |<--------->| CDN  | :
   : | PID1 |       +-->| Router |-------| Router |<--+       | PID8 | :
   : +------+       |+->|  PID4  | :    :|  PID6  |<-+|       +------+ :
   :                ||  +--------+ :   : +--------+  ||                :
   :                ||             :   :             ||                :
   : +------+ C(2-4)||             :   :             ||C(6-9) +------+ :
   : | Host |<------+|             :   :             |+------>| CDN  | :
   : | PID2 |        |             :   :             |        | PID9 | :
   : +------+        |             :   :             |        +------+ :
   :                 |             :   :             |                 :
   :                 |             :   :             |                 :
   : +------+ C(3-4) |  +--------+ :   : +--------+  | C(6-10)+------+ :
   : | Host |<-------+  | Border |: c7  :| Border |  +------->|  CDN | :
   : | PID3 |           | Router |-------| Router |           | PID10| :
   : +------+           |  PID5  | :   : |  PID7  |           +------+ :
   :                    +--------+ :   : +--------+                    :
   :                               :   :                               :
   :  ISP Administrative Domain    :   :   CDN Administrative Domain   :
   :...............................:   :...............................:

           Figure 5: Map advertising between ISP and CDN domains

   The ALTO server in the CDN provider network is assumed to be
   initialized with information about the ISP networks it serves.  For
   every such ISP network, it consults the routing plane to find the set
   of Border routers.  The CDN network ALTO server computes the cost of
   reaching each Border router from every CDN node (say, C_cdn).




Penno, et al.           Expires December 6, 2010               [Page 13]


Internet-Draft              Abbreviated-Title                  June 2010


   Next, the CDN ALTO server contacts the ISP network's ALTO server and
   downloads the network map.  In order to help the CDN ALTO server
   compute the cost from a CDN node to a subscriber's PID, we break it
   down into two parts - the cost from the CDN node to the Border router
   (C_cdn) and the cost from the Border router to the subscriber's PID
   (say, C_isp).  Note that, this implies that each Border router is a
   PID in itself to accommodate this cost computation.  Hence the cost
   map at the ISP's ALTO server has the costs between every pair of
   subscriber PID and Border router PID.

   With the network map and the cost map from the ISP ALTO server, the
   CDN ALTO server now computes the cost of reaching each subscriber PID
   from a given CDN node as: C_cdn(CDN Node, Border router) +
   C_isp(Border router, Subscriber PID).  In this computation, the
   Border router is the one that is on the best path from the CDN node
   to the Subscriber PID.

   The CDN ALTO server now has a cost map that provides the cost from
   each CDN node to all known Subscriber PIDs.  The ALTO client in the
   CDN DNS server downloads this cost map in preparation for subscriber
   DNS requests.

   When a subscriber DNS request arrives at the CDN provider's DNS
   server, it looks up the network map and maps the source IP address to
   a Subscriber PID.  It then uses the cost map to pick the best CDN
   node for this Subscriber PID.

      GAP-6: Federation of ALTO servers: There is a need to define how
      ALTO servers may communicate with each other in a federated model.

      GAP-7: ALTO Border Router PID attribute: In order for
      administrative domains to collate costs across domain boundaries,
      the border routers may be placed in their own PIDs.  Such PIDs may
      be identified by a Border Router attribute.

6.3.  Integrating with managed DNS service

   Many organizations / content providers outsource DNS management to
   the external vendors for various reasons like reliability,
   performance improvement, DNS security etc.  Managed DNS service could
   be used either with caches owned by the organization itself (section
   6.3.1) OR with external CDNs (section 6.3.2)

6.3.1.  Managed DNS resolver used to redirect to local cache

   One of the common functions offered by managed DNS service vendor is
   DNS traffic management where DNS resolver can load balance traffic
   dynamically across content servers.



Penno, et al.           Expires December 6, 2010               [Page 14]


Internet-Draft              Abbreviated-Title                  June 2010


   Typically managed DNS service provider has DNS resolvers spread
   across geographical locations to improve performance.  This also
   makes easier for DNS resolver to redirect host to the nearest cache.
   Such a DNS resolver would be an ideal candidate to implement ALTO
   client where it can fetch network map and cost map from ALTO servers
   located in the same geographical area only.  Load balancing
   implemented with the knowledge of network and cost map would be more
   efficient than other mechanisms like round robin.

                         2        +----------------+
           +--------------------> |       root     |
           | +------------------- |   Name Server  |
           | |           3        +----------------+
           | |
           | |           4        +----------------+
           | |   +--------------> |       com      |
           | |   | +------------- |   Name Server  |
           | |   | |     5        +----------------+
           | |   | |
          _|-|---|-|--------------------.
      ,-'' | V   | V                     `--.
     '   +---------+    6    +---------------`+.
     |   |   DNS   |-------->|     xyz.com    | `
     |   |  Proxy  |<--------|   DNS Resolver | |
     |   +---------+    7    |                | |
     |     1^  | 8           | +------------+ | |
     |      |  |             | |ALTO Client | | |
     |   +-----V---+         | +------------+ | |
     |   |  Host   |         +----------------.-'
     |   +---------+                |   ^  .-'
     |        |       DOMAIN 1      |   |-'   ALTO Protocol
     |        V                     |.-'|     (Map Service)
      `--. CDN Node          __.--:-|   |
          `----.        _.--'       |   |
                `---.-''      ,---------+-------.
                            ,'+----------------+ \
                           /  |   ALTO Server  |  :
                          (   +----------------+  |
                           \                      ;
                            \    DOMAIN 2       ,'
                             `-----------------'

   In the figure above, there exists 2 possibilities:

   Case 1: Domain 1 and Domain 2 are connected to the same service
   provider network.  This case is similar to section 6.1

   Case 2: Domain 1 and Domain 2 are connected to different service



Penno, et al.           Expires December 6, 2010               [Page 15]


Internet-Draft              Abbreviated-Title                  June 2010


   provider network.  This case is similar to section 6.2

6.3.2.  Managed DNS resolver used with multiple CDN vendors

   In this Model, Managed DNS service can be used along with multiple
   CDN vendors where DNS resolver can redirect to different caches
   depending on the subdomain e.g.  DNS resolver could have below
   records

   subdomain1.xyz.com CNAME cdn1.com

   subdomain2.xyz.com CNAME cdn2.com

   In this case CDN DNS resolver needs to be an ALTO client.  This
   deployment will be similar to ones described in section 6.1 and
   section 6.2 earlier.


7.  Tracker Integration

   In the case of P2P CDNs, the application tracker takes the role of
   the ALTO Client, fetching the map from the ALTO Server and
   integrating it its peer database.  The result is a peer database
   taking into account current metrics such as peer availability,
   content availability and also localization.  This architecture in the
   context of file sharing was extensively studied and trialed by ISPs
   such as Comcast [RFC5632] under the P4P [P4P] protocol.


8.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.


9.  Security Considerations

   When the ALTO Server and Client are operated by different entities
   the issue of trust and security comes forward.  The exchange of
   information could be done using the encryption methods already
   present in HTTP but preventing unauthorized redistribution comes into
   play.  A further issue is if the ALTO information information is
   transitive, which modifications are allowed.






Penno, et al.           Expires December 6, 2010               [Page 16]


Internet-Draft              Abbreviated-Title                  June 2010


10.  Acknowledgements

   TBD


11.  References

11.1.  Normative References

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

11.2.  Informative References

   [ARBOR]    Labovitz, "Internet Traffic and Content Consolidation",
              2009, <http://www.ietf.org/proceedings/10mar/slides/
              plenaryt-4.pdf>.

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

   [P4P]      Xie, H., Yang, YR., Krishnamurthy, A., Liu, Y., and A.
              Silberschatz, "P4P: Provider Portal for (P2P)
              Applications", March 2009.

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

   [RFC5632]  Griffiths, C., Livingood, J., Popkin, L., Woundy, R., and
              Y. Yang, "Comcast's ISP Experiences in a Proactive Network
              Provider Participation for P2P (P4P) Technical Trial",
              RFC 5632, September 2009.


Authors' Addresses

   Reinaldo Penno
   Juniper Networks
   1194 N Mathilda Avenue
   Sunnyvale
   USA

   Email: rpenno@juniper.net





Penno, et al.           Expires December 6, 2010               [Page 17]


Internet-Draft              Abbreviated-Title                  June 2010


   Satish Raghunath
   Juniper Networks
   1194 N Mathilda Avenue
   Sunnyvale
   USA

   Email: satishr@juniper.net


   Jan Medved
   Juniper Networks
   1194 N Mathilda Avenue
   Sunnyvale
   USA

   Email: jmedved@juniper.net


   Mayuresh Bakshi
   Juniper Networks
   1194 N Mathilda Avenue
   Sunnyvale
   USA

   Email: mbakshi@juniper.net


   Richard Alimi
   Yale University


   Email: richard.alimi@yale.edu


   Stefano Previdi
   Cisco Systems


   Email: sprevidi@cisco.com












Penno, et al.           Expires December 6, 2010               [Page 18]


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