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

Versions: 00 01 02 03 04 05 06 07 08 09 10 draft-ietf-alto-cdni-request-routing-alto

Content Delivery Networks                                     J. Seedorf
Interconnection                                                      NEC
Internet-Draft                                             July 16, 2012
Intended status: Informational
Expires: January 17, 2013


                     CDNI Request Routing with ALTO
               draft-seedorf-cdni-request-routing-alto-02

Abstract

   Network Service Providers (NSPs) are currently considering to deploy
   Content Delivery Networks (CDNs) within their networks.  As a
   consequence of this development, there is a need for interconnecting
   these local CDNs.  The necessary interfaces for inter-connecting CDNs
   are currently being defined in the Content Delivery Networks
   Interconnection (CDNI) WG.  This document focusses on the Request
   Routing Interface of CDNI, and more specifically on how the solutions
   currently being defined in the Application Layer Traffic Optimization
   (ALTO) WG can improve CDNI request routing.  The overall intention
   behind this document is to foster discussions (in the CDNI as well as
   in the ALTO WG) regarding if, how, and under what conditions ALTO can
   be useful to optimize CDNI request routing.  As basis for this
   discussion, this document provides concrete examples of how ALTO can
   be integrated within CDNI request routing and in particular in the
   process of selecting a downstream CDN.  The examples in this document
   are based on the use cases and examples currently being discussed in
   the CDNI WG.

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 17, 2013.

Copyright Notice



Seedorf                 Expires January 17, 2013                [Page 1]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


   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.


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  ALTO within CDNI Request Routing . . . . . . . . . . . . . . .  4
   3.  Assumptions and High-Level Design Considerations . . . . . . .  6
   4.  Selection of a Downstream CDN with ALTO  . . . . . . . . . . .  8
     4.1.  Footprint Advertisement with ALTO Network Map  . . . . . .  8
     4.2.  Using ALTO maps to convey Additional Information for
           Downstream CDN Selection . . . . . . . . . . . . . . . . .  8
     4.3.  Example of Selecting a Downstream CDN based on ALTO
           Maps . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     4.4.  Advantages of using ALTO . . . . . . . . . . . . . . . . . 11
   5.  Useful ALTO extensions for CDNI Request Routing  . . . . . . . 13
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   7.  Summary and Outlook  . . . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 17
   9.  Informative References . . . . . . . . . . . . . . . . . . . . 18
   Author's Address . . . . . . . . . . . . . . . . . . . . . . . . . 20



















Seedorf                 Expires January 17, 2013                [Page 2]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


1.  Introduction

   Many Network Service Providers (NSPs) are currently considering or
   have already started to deploy Content Delivery Networks (CDNs)
   within their networks.  As a consequence of this development, there
   is a need for interconnecting these local CDNs.  Content Delivery
   Networks Interconnection (CDNI) has the goal of standardizing
   protocols to enable such interconnection of CDNs
   [I-D.ietf-cdni-problem-statement].

   The CDNI problem statement envisions four interfaces to be
   standardized within the IETF for CDN interconnection
   [I-D.ietf-cdni-problem-statement]:

   o  CDNI Request Routing Interface

   o  CDNI Metadata Interface

   o  CDNI Logging Interface

   o  CDNI Control Interface

   This document focusses solely on the CDNI Request Routing Interface.
   In particular, this document shows concrete examples of how ALTO
   [RFC5693] can be integrated in CDNI request routing.  The goal of
   this document is to show in what cases ALTO can benefit CDNI request
   routing, giving concrete examples and explaining how ALTO improves
   CDNI request routing in each of these examples.  The examples used in
   this document are based on the use cases and request routing
   proposals currently being discussed in the CDNI WG
   [I-D.ietf-cdni-use-cases] [I-D.peterson-CDNI-strawman] and in the
   ALTO WG [I-D.jenkins-alto-cdn-use-cases].  The overall rationale of
   this document is to foster discussions (in the CDNI as well as in the
   ALTO WG) regarding if, how, and under what conditions ALTO can be
   useful to optimize CDNI request routing.  Most importantly, the
   document has the goal of finding consensus regarding which part of
   the CDNI request routing interface can use ALTO.

   A previous version of this document [I-D.seedorf-alto-for-cdni]
   contained detailed examples of actual request routing and surrogate
   selection with ALTO.  This version solely focuses on selection of a
   downstream CDN and how ALTO can support such downstream CDN
   selection.

   Throughout this document, we use the terminology for CDNI defined in
   [I-D.ietf-cdni-problem-statement].





Seedorf                 Expires January 17, 2013                [Page 3]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


2.  ALTO within CDNI Request Routing

   The main purpose of the CDNI Request Routing Interface is described
   in [I-D.ietf-cdni-problem-statement] as follows: "The CDNI Request
   Routing interface enables a Request Routing function in an upstream
   CDN to query a Request Routing function in a downstream CDN to
   determine if the downstream CDN is able (and willing) to accept the
   delegated content request and to allow the downstream CDN to control
   what the upstream Request Routing function should return to the User
   Agent in the redirection message".  On a high level, the scope of the
   CDNI Request Routing Interface therefore contains two main tasks:

   o  A) Determining if the downstream CDN is willing to accept a
      delegated content request

   o  B) Redirecting the content request coming from an upstream CDN to
      the proper entry point or entity in the downstream CDN

   More precisely, in [I-D.ietf-cdni-framework] the request routing
   interface is broadly divided into two functionalities:

   o  1) the asynchronous advertisement of footprint and capabilities by
      a dCDN that allows a uCDN to decide whether to redirect particular
      user requests to that dCDN;

   o  2) the synchronous operation of actually redirecting a user
      request.

   Accorduing to consensus found at the CDNI working group session at
   IETF-82, we refer to 1) as "Request Routing Interface - Footprint and
   Capabilities Advertisement" and 2) as "Request Routing Interface -
   Redirection" in this document.  A previous version of this document
   [I-D.seedorf-alto-for-cdni] provided some concrete examples how ALTO
   could be used for the actual "redirection" part of the request
   routing interface.  Based on feedback received from the CDNI working
   group (mostly at the IETF-82 meeting), this document solely focuses
   on the "Footprint and Capabilities Advertisement" part of the request
   routing interface.  In particular, the scope of the current version
   of this document is to show how ALTO [RFC5693] can be used for
   selecting a downstream CDN.  Thus, the scope of the current document
   is to provide examples and discuss how a downstream CDN can advertise
   its footprint and other information by means of ALTO.

   Application Layer Traffic Optimization (ALTO) is an approach for
   guiding the resource provider selection process in distributed
   applications that can choose among several candidate resources
   providers to retrieve a given resource.  By conveying network layer
   (topology) information, an ALTO server can provide important



Seedorf                 Expires January 17, 2013                [Page 4]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


   information to "guide" the resource provider selection process in
   distributed applications.  Usually, it is assumed that an ALTO server
   conveys information these applications cannot measure themselves
   [RFC5693].

   Originally, ALTO was motivated by the huge amount of cross-ISP
   traffic generated by P2P applications [RFC5693].  Recently, however,
   ALTO is also being considered for improving the request routing in
   CDNs [I-D.jenkins-alto-cdn-use-cases].  In this context, it has also
   been proposed to use ALTO for selecting an entry-point in a
   downstream NSP's network (see section 3.4 "CDN delivering Over-The-
   Top of a NSP's network" in [I-D.jenkins-alto-cdn-use-cases]).  Also,
   the CDNI problem statement explicitly mentions ALTO as a candidate
   protocol for "algorithms for selection of CDN or Surrogate by
   Request-Routing systems" [I-D.ietf-cdni-problem-statement].  Yet,
   there have not been concrete proposals so far on how to use ALTO in
   the context of CDN interconnection.  This document tries to close
   this gap by giving some examples on how ALTO could be used within
   CDNI request routing.
































Seedorf                 Expires January 17, 2013                [Page 5]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


3.  Assumptions and High-Level Design Considerations

   In this section we list some assumptions and design issues to be
   considered when using ALTO for CDNI "footprint and capabilities
   advertisement":

   o  As explicitly being out-of-scope for CDNI
      [I-D.ietf-cdni-problem-statement], the examples used in this
      document assume that ingestion of content or acquiring content
      across CDNs is not part of request routing as considered within
      CDNI standardization work.  The focus of using ALTO (as considered
      in this document) is hence on request routing only, assuming that
      the content (desired by the end user) is available in the
      downstream CDN (or can be aquired by the downstream CDN by some
      means).

   o  Federation Model: "footprint and capabilities advertisement" and
      in general CDN request routing depends on the federation model
      among the CDN providers.  Designing a suitable solution thus
      depends on whether a solution is needed for different settings,
      where CDNs consist of both NSP CDNs (serving individual ASes) and
      general, traditional CDNs (such as Akamai).  We assume that CDNI
      is not designed for a setting where only NSP CDNs each serve a
      single AS only.

   o  Many CDNs can claim that they can serve any host on the Internet
      due to Internet connectivity.  For example, even if an NSP CDN A
      does not have surrogate servers inside network C, A can
      legitimately claim that it can serve customers inside network C.
      Hence, what a downstream CDN should inform an upstream CDN is
      performance and capability, and not (only) reachability or
      coverage.  Although one may turn performance into (binary)
      reachability by defining a threshold, the metric can be content-
      dependent (image, video, files) or artificial.  The requirement of
      conveying performance and capability is consistent with the
      context: after all, the foundation of the CDN business is to
      improve user QoE.

   o  In this document, we assume that the upstream CDN (uCDN) makes the
      decision on selecting a downstream CDN, based on information that
      each downstream CDN has made available to the upstream CDN.
      Further, we assume that in principle more than one dCDN may be
      suitable for a given end-user request (i.e. different dCDNs may
      claim "overlapping" footprints).  The uCDN hence potentially has
      to select among several candidate downstream CDNs for a given end
      user request.





Seedorf                 Expires January 17, 2013                [Page 6]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


   o  The term "footprint" has not been precisely defined by the CDNI
      working group yet [I-D.spp-cdni-rr-foot-cap-semantics].  In this
      document we assume that some notion of IP prefix-range is suitable
      to define a footprint of a downstream CDN.  Thus, a dCDN footprint
      may be expressed as an IP-prefix range that a given dCDN claims it
      can cover.  However, in principle any host can reach any other
      host on the Internet.  Thus, simple "coverage" of IP-prefix ranges
      seems insufficient for a uCDN to make a choice of a dCDN (see
      [I-D.spp-cdni-rr-foot-cap-semantics] for a discussion of this
      issue).  The uCDN needs additional information that is "tagged
      along" (either implicitly or explicitly) with such a coverage
      footprint.  Such additonal information has the prupose of
      conveying to the uCDN more information about a footprint, so that
      the uCDN can judge/assess the delivery quality that is associated
      with a given dCDN footprint (or part of that footprint, in the
      likely case that the delivery quality is not the same for a whole
      dCDN footprint).

   o  It is not clear what kind(s) of business, contract, and
      operational relationships two peering CDNs may form.  For the
      Internet, we see provider-customer and peering as two main
      relations; providers may use different charging models (e.g., 95-
      percentile, total volume) and may provide different SLAs.  Given
      such unknown characteristics of CDN peering business agreements,
      we should design the protocol to support as much diverse potential
      business and operational models as possible.

























Seedorf                 Expires January 17, 2013                [Page 7]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


4.  Selection of a Downstream CDN with ALTO

   Under the considerations stated in Section 3, ALTO can help the
   upstream CDN provider to select a proper downstream CDN provider for
   a given end user request as follows: Each downstream CDN provider
   hosts an ALTO server which provides ALTO information (i.e.  ALTO
   network maps and ALTO cost maps [I-D.ietf-alto-protocol]) to an ALTO
   client at the upstream CDN provider.  A network map provided by each
   of several candidate downstream CDNs can provide information to the
   upstream CDN provider about each dCDN's "coverage" footprint, e.g.
   regarding geopgraphical coverage, the (exact or rough) location of
   "surrogates", the IP-prefix ranges the dCDN claims it can "cover"
   with "good" delivery quality, or similar.  Additional ALTO network
   maps or cost maps can provide an upstream CDN provider additional
   information about the footprint each individual dCDN offers, e.g. the
   "cost" or quality associated with delivering certain content via the
   downstream CDN which provided such a map.  "Cost" in this context is
   a generic term; many types of costs are possible and can be useful in
   the context of CDNI request routing (see Section 4.2 for a detailed
   discussion), e.g. average link load, expected delay, or monetary
   costs.

4.1.  Footprint Advertisement with ALTO Network Map

   An ALTO network map contains a "set of Network Location groupings"
   [I-D.ietf-alto-protocol].  The groupings are defined in the form of
   so-called "PIDs".  A PID is an identifier to group network location
   endpoints, e.g.  IP-addresses in the form of prefixes (see section 4
   in [I-D.ietf-alto-protocol] for details).

   The concept of an ALTO network map (and the PIDs contained therein)
   is a natural and straightforward candidate for CDNI fooprint
   advertisement: The downstream CDN provider groups the IP-addresses in
   its footprint into PIDs and makes these groupings available to an
   upstream CDN via an ALTO network map.  With such a network map, the
   upstream CDN provider can easily match a given end user request with
   the footprint of the downstream CDN provider to see if a given
   downstream CDN can in principle provide "coverage" for the IP-address
   of the end user.  Whenever the footprint changes, the downstream CDN
   creates an updated network map and makes it available via its ALTO
   server.

4.2.  Using ALTO maps to convey Additional Information for Downstream
      CDN Selection

   Additonal information (so that the uCDN can judge/assess the delivery
   quality that is associated with a given dCDN footprint it received in
   a network map from the dCDN) can be conveyed to a uCDN with



Seedorf                 Expires January 17, 2013                [Page 8]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


   additional ALTO network maps or ALTO cost maps that the dCDN will
   provide via its ALTO server.  An ALTO cost map contains costs between
   defined groupings of a corresponding network map (i.e. costs between
   PIDs): "An ALTO Cost Map defines Path Costs pairwise amongst sets of
   source and destination Network Locations" [I-D.ietf-alto-protocol].
   This concept enables the provider of a cost map to express (and
   quantify) preferences of a destination network location with respect
   to a given source network location.

   In the context of CDNI, the ALTO cost map concept is an extensive
   tool to facilitate selection of the "best" downstream CDN because it
   enables the upstream CDN provider to assess a candidate downstream
   CDN based on other factors besides simply network coverage (coverage
   footprint).  Most importantly, the cost map concept provides a means
   for a downstream CDN provider to convey a multitude of dynamically
   changing information which the upstream CDN provider cannot measure
   itself (or only roughly estimate) otherwise.

   For instance, the following types of "delivery cost" can be conveyed
   by a downstream CDN provider via ALTO for each combination of source
   PID and destination PID:

   o  Latency: the expected/average RTT

   o  Bandwidth: the maximum bandwidth (e.g. due too bottlenecks)

   o  Monetary Costs: The amount of actual monetary costs the downstream
      CDN provider would charge for the delivery of content to a given
      destination (see also [I-D.liu-cdni-cost])

   Normally, an ALTO cost map defines "costs" pairwise among two PIDs
   [I-D.ietf-alto-protocol].  In the current scope of the CDNI working
   group, however, the destination of a request routing redirection will
   always be the request router of the selected downstream CDN (as
   direct redirection to dCDN surrogates is currently out of scope of
   the CDNI work).  The destination PID in an ALTO cost map offered by a
   dCDN is thus always (i.e. in all entries) the same.  Moreover, this
   destination PID semantically refers to the whole dCDN (or to its
   request router, as the decision where to route within the dCDN is
   outside the scope of the CDNI request routing interface).  Therefore,
   a corresponding ALTO network map for footprint coverage offered by a
   dCDN should always contain a special PID that covers the whole
   footprint of the dCDN, i.e. the overall, whole prefix range the dCDN
   claims it can cover (obviously, it can additonally contain smaller
   prefix ranges in other PIDs, so that a cost map can have pairwise
   costs entries of these smaller-scale source PIDs to the overall dCDN
   coverage PID).




Seedorf                 Expires January 17, 2013                [Page 9]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


   Note that such ALTO cost maps are always of the type N-to-1, i.e.
   "costs" are expressed for each of N end user source PIDs to 1 single
   dCDN request router PID.  Semantically, the source PID in a CDNI ALTO
   cost map is thus the end user location, whereas the destination is
   the request router to which the uCDN redirects the end user request.
   Note that this perspective is driven by the CDNI request routing.  An
   alternative way - seen from the perspective of content retrieval -
   would be to have a 1-to-N cost map where the source is always the
   dCDN and the destination is the end user (with the semantic "if the
   source dCDN would deliver content to an end user in the destination
   PID, the costs would be the following).

   Alternatively to using cost maps for expressing delivery quality for
   a given coverage footprint, ALTO networks map could be used.  In this
   case, an additional network map provided by the dCDN groups the
   dCDN's coverage footprint into several PIDs, where each PID name has
   a certain "quality" semantic.  In other words, all IP-prefixes in a
   certain PID have the same "quality", and the meaning of this quality
   is expressed by the PID name.

4.3.  Example of Selecting a Downstream CDN based on ALTO Maps

   In the following, we will outline an example of dCDN selection by a
   uCDN based on ALTO maps provided by each dCDN.  In the example, an
   ALTO network map "NM_cov" is used to express the overall "coverage"
   footprint of each dCDN.  In addition (as outlined in Section 4.2),
   each dCDN provides one or more ALTO cost maps "CM_1", "CM_2", ...,
   "CM_n" to express the delivery "costs"/quality associated with each
   PID in the corresponding "NM_cov" coverage footprint network map.

   Consider the following example: An upstream CDN (uCDN) has agreed on
   CDN interconnection with several downstream CDNs (dCDN-a, dCDN-b, and
   dCDN-c).  Each of these downstream CDNs runs an ALTO server to
   provide information about what locations it can deliver content to
   (coverage footprint) by means of a network map "NM_cov" and at which
   "cost" (additional delivery quality information) by means of one or
   more cost maps "CM_1", "CM_2", ..., "CM_n". uCDN has downloaded from
   each candidate downstream CDN "NM_cov" and one or more ALTO cost maps
   (e.g. by using the "Filtered Cost Map" option and different "cost-
   types" as specified in 7.7.3.2. of [I-D.ietf-alto-protocol]).  The
   ALTO network map provides "coverage" (footprint) for each downstream
   CDN as aggregated network locations in the form of ALTO PIDs.  The
   cost maps provide the upstream CDN information regarding the delivery
   quality the selection of each individual downstream CDN would imply
   depending on the given location of an end user request.

   Whenever the upstream CDN receives a request from an end user and has
   determined that this request is best served by an interconnected



Seedorf                 Expires January 17, 2013               [Page 10]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


   dCDN, the uCDN uses ALTO maps to make a redirection decision.  For a
   given request, assume that only the ALTO network maps provided by
   dCDN-a and dCDN-c, "NM_cov(dCDN-a)" and "NM_cov(dCDN-c)", indicate
   that these downstream CDNs can deliver content to the location of the
   request.  In this case, the ALTO costs maps received from dCDN-a and
   dCDN-c provide useful additional information to the upstream CDN in
   order to make a selection decision regarding either dCDN-a or dCDN-c.
   For instance, if both downstream CDNs have provided two ALTO cost
   maps "CM_monetary" and "CM_latency" - one regarding monetary costs
   and one regarding expected latency for delivery - uCDN can make a
   downstream CDN selection based on its preferences: If one downstream
   CDN can deliver cheaper, but the other faster, ALTO cost maps provide
   such information in detail to the upstream CDN.  This enables the
   upstream CDN to make a well-considered downstream CDN selection.  In
   particular, the uCDN decision may take into account different
   delivery quality indicators or other factors (which can be weighted
   by the upstream CDN to make a decision).

4.4.  Advantages of using ALTO

   The following reasons make ALTO a suitable candidate protocol for
   downstream CDN selection as part of CDNI request routing:

   o  CDN request routing is done at the application layer.  ALTO is a
      protocol specifically designed to improve application layer
      traffic (and application layer connections among hosts on the
      Internet) by providing additonal information to applications that
      these applications could not easily retrieve themselves.  For
      CDNI, this is exactly the case: a uCDN wants to improve
      application layer CDN request routing by using dedicated
      information (provided by a dCDN) that the uCDN could not easily
      obtain otherwise.

   o  The semantics of an ALTO network are an exact match for the needed
      information to convey a footprint by a downstream CDN, in
      particular if such a footprint is being expressed by IP-prefix
      ranges.

   o  ALTO cost maps are suitable to express various types of delivery
      "cost" and can hence be used by an upstream to judge the delivery
      quality associated with a given dCDN for a given end user request.
      Further, an ALTO cost map can convey relevant network topology
      information other than simply routing hops or reachability.  This
      facilitiates advanced and more sophisticated selection of a
      downstream CDN based on various metrics by the upstream CDN and
      increases flexibility to cover different use cases and business
      models for CDN interconnection.




Seedorf                 Expires January 17, 2013               [Page 11]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


   o  Flexible granularity: The concept of the PID and ALTO network/cost
      maps allows for different degrees of granularity.  This enables a
      dCDN to differentiate the delivery quality for serving an end user
      request on a fine granularity depending on the end user location
      (and not only express delivery quality e.g. on an AS-level).  It
      remains at the discretion of each dCDN how fine-granular the ALTO
      network and cost maps are that it publishes.

   o  ALTO maps can be signed and hence provide inherent integrity
      protection (see Section 6)









































Seedorf                 Expires January 17, 2013               [Page 12]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


5.  Useful ALTO extensions for CDNI Request Routing

   It is envisioned that yet-to-be-defined ALTO extensions will be
   standardized that make the ALTO protocol more suitable and useful for
   applications other than the originally considered P2P use case
   [I-D.marocco-alto-next].  Some of these extensions to the ALTO
   protocol would be useful for ALTO to be used as a protocol within
   CDNI request routing, and in particular within the "Footprint and
   Capabilities Advertisment" part of the CDNI request routing
   interface.

   The following proposed extensions to ALTO would be beneficial to
   facilitate CDNI request routing with ALTO as outlined in Section 4:

   o  Server-initiated Notifications and Incremental Updates: In case
      the footprint or the capabilities of a downstream CDN change
      abruptly (i.e. unexpectedly from the perspective of an upstream
      CDN), server initiated notifications would enable a dCDN to
      directly inform an upstream CDN about such changes.  Consider the
      case where - due to failure - part of the footprint of the dCDN is
      not functioning, i.e. the CDN cannot serve content to such clients
      with reasonable QoS.  Without server-initiated notifications, the
      uCDN might still use a very recent network and cost map from dCDN,
      and therefore redirect request to dCDN which it cannot serve.
      Similarly, the possibility for incremental updates would enable
      efficient conveyance of the aforementioned (or similar) status
      changes by the dCDN to the uCDN.  A proposal for server-initiated
      ALTO updates can be found in [I-D.marocco-alto-ws].  A discussion
      of incremental ALTO updates can be found in
      [I-D.schwan-alto-incr-updates].

   o  Content Availability on Hosts: A dCDN might want to express CDN
      capabilties in terms of certain content types (e.g. codecs/
      formats, or content from certain content providers).  A new
      endpoint property for ALTO that would be able to express such
      "content availability" would enable a dCDN to make available such
      information to an upstream CDN.  This would enable a uCDN to
      determine if a given dCDN actually has the capabilities for a
      given request with respect to the type of content requested.

   o  Resource Availability on Hosts or Links: The capabilities on links
      (e.g. maximum bandwidth) or caches (e.g. average load) might be
      useful information for an upstream CDN for optimized dowmstream
      CDN selection.  For instance, if a uCDN receives a streaming
      request for content with a certain bitrate, it needs to know if it
      is likely that a dCDN can fulfill such stringent application-level
      requirements (i.e. can be expected to have enough consistent
      bandwidth) before it redirects the request.  In general, if ALTO



Seedorf                 Expires January 17, 2013               [Page 13]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


      could convey such information via new endpoint properties, it
      would enable more sophisticated means for downstream CDN selection
      with ALTO.
















































Seedorf                 Expires January 17, 2013               [Page 14]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


6.  Security Considerations

   One important security consideration is the proper authentication of
   advertisement information provided by a downstream CDN.  The ALTO
   protocol provides a specification for a signature of ALTO maps (see
   8.2.2. of [I-D.ietf-alto-protocol].  ALTO thus provides a proper
   means for protecting the integrity of footprint advertisment
   information.

   More Security Considerations will be discussed in a future version of
   this document.








































Seedorf                 Expires January 17, 2013               [Page 15]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


7.  Summary and Outlook

   This document presented conrete examples of how ALTO can be used
   within the downstream CDN selection of CDNI Request Routing.
   Further, the document provides arguments why ALTO is a meaningful
   protocol in this context.  Essentially, ALTO network and cost maps
   are a means to provide detailed and various types of information to
   an upstream CDN, in order to facilitate well-considered downstream
   CDN selection.

   The intention of this document is to find consensus in the CDNI WG
   that ALTO is a useful protocol for CDNI request routing, and that
   ALTO has many benefits for proper selection of a downstream CDN.  The
   overall objective is to form agreement on how ALTO should be used
   within the CDNI request routing protocol.  It is the intention to
   capture the outcome of such continuing discussions in future versions
   of this document.


































Seedorf                 Expires January 17, 2013               [Page 16]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


8.  Acknowledgements

   Jan Seedorf is partially supported by the COAST project (COntent
   Aware Searching, retrieval and sTreaming, http://www.coast-fp7.eu), a
   research project supported by the European Commission under its 7th
   Framework Program (contract no. 248036).  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 COAST project or
   the European Commission.

   Thanks to Richard Yang for providing valuable comments, and for
   contributiong some design considerations and assumptions.






































Seedorf                 Expires January 17, 2013               [Page 17]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


9.  Informative References

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

   [I-D.peterson-CDNI-strawman]
              Peterson, L. and J. Hartman, "Content Distribution Network
              Interconnection (CDNI) Problem Statement",
              draft-peterson-CDNI-strawman-01 (work in progress),
              May 2011.

   [I-D.ietf-cdni-problem-statement]
              Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", draft-ietf-cdni-problem-statement-08 (work in
              progress), June 2012.

   [I-D.marocco-alto-next]
              Marocco, E. and V. Gurbani, "Extending the Application-
              Layer Traffic Optimization (ALTO) Protocol",
              draft-marocco-alto-next-00 (work in progress),
              January 2012.

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

   [I-D.ietf-cdni-requirements]
              Leung, K. and Y. Lee, "Content Distribution Network
              Interconnection (CDNI) Requirements",
              draft-ietf-cdni-requirements-03 (work in progress),
              June 2012.

   [I-D.ietf-cdni-use-cases]
              Bertrand, G., Emile, S., Burbridge, T., Eardley, P., Ma,
              K., and G. Watson, "Use Cases for Content Delivery Network
              Interconnection", draft-ietf-cdni-use-cases-09 (work in
              progress), July 2012.

   [I-D.marocco-alto-ws]
              Marocco, E. and J. Seedorf, "WebSocket-based server-to-
              client notifications for the Application-Layer Traffic
              Optimization (ALTO) Protocol", draft-marocco-alto-ws-01
              (work in progress), July 2012.

   [I-D.schwan-alto-incr-updates]
              Schwan, N. and B. Roome, "ALTO Incremental Updates",



Seedorf                 Expires January 17, 2013               [Page 18]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


              draft-schwan-alto-incr-updates-02 (work in progress),
              July 2012.

   [I-D.jenkins-alto-cdn-use-cases]
              Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., and
              S. Previdi, "Use Cases for ALTO within CDNs",
              draft-jenkins-alto-cdn-use-cases-03 (work in progress),
              June 2012.

   [I-D.seedorf-alto-for-cdni]
              Seedorf, J., "ALTO for CDNi Request Routing",
              draft-seedorf-alto-for-cdni-00 (work in progress),
              October 2011.

   [I-D.ietf-cdni-framework]
              Peterson, L. and B. Davie, "Framework for CDN
              Interconnection", draft-ietf-cdni-framework-00 (work in
              progress), April 2012.

   [I-D.liu-cdni-cost]
              Liu, H., "A Cost Perspective on Using Multiple CDNs",
              draft-liu-cdni-cost-00 (work in progress), October 2011.

   [I-D.spp-cdni-rr-foot-cap-semantics]
              Seedorf, J., Peterson, J., and S. Previdi, "CDNI Request
              Routing: Footprint and Capabilities Semantics",
              draft-spp-cdni-rr-foot-cap-semantics-00 (work in
              progress), March 2012.























Seedorf                 Expires January 17, 2013               [Page 19]


Internet-Draft       CDNI Request Routing with ALTO            July 2012


Author's Address

   Jan Seedorf
   NEC Laboratories Europe, NEC Europe Ltd.
   Kurfuersten-Anlage 36
   Heidelberg  69115
   Germany

   Phone: +49 (0) 6221 4342 221
   Email: jan.seedorf@neclab.eu
   URI:   http://www.neclab.eu








































Seedorf                 Expires January 17, 2013               [Page 20]


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