Internet DRAFT - draft-bertrand-cdni-experiments

draft-bertrand-cdni-experiments






Internet Engineering Task Force                         G. Bertrand, Ed.
Internet-Draft                                   France Telecom - Orange
Intended status: Informational                            F. Le Faucheur
Expires: August 18, 2012                                   Cisco Systems
                                                             L. Peterson
                                                           Verivue, Inc.
                                                       February 15, 2012


    Content Distribution Network Interconnection (CDNI) Experiments
                   draft-bertrand-cdni-experiments-02

Abstract

   This document reports studies and related experiments on CDN
   interconnection performed by France Telecom-Orange Labs.  The
   document summarizes implications of CDN interconnection to CDN
   service providers and lessons learned through CDNI experiments.

   The main purpose of the experiments was to test the interconnection
   of CDN solutions from two vendors (namely, Cisco and Verivue) and to
   identify the gaps and needs for standardization work for CDN
   interconnection.

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 August 18, 2012.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Bertrand, et al.         Expires August 18, 2012                [Page 1]

Internet-Draft              CDNI Experiments               February 2012


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

   This document may contain material from IETF Documents or IETF
   Contributions published or made publicly available before November
   10, 2008.  The person(s) controlling the copyright in some of this
   material may not have granted the IETF Trust the right to allow
   modifications of such material outside the IETF Standards Process.
   Without obtaining an adequate license from the person(s) controlling
   the copyright in such materials, this document may not be modified
   outside the IETF Standards Process, and derivative works of it may
   not be created outside the IETF Standards Process, except to format
   it for publication as an RFC or to translate it into languages other
   than English.
































Bertrand, et al.         Expires August 18, 2012                [Page 2]

Internet-Draft              CDNI Experiments               February 2012


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  CDN Interconnection Experiments  . . . . . . . . . . . . . . .  4
     2.1.  Experiment Configuration . . . . . . . . . . . . . . . . .  4
     2.2.  Control  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.3.  Logging  . . . . . . . . . . . . . . . . . . . . . . . . .  6
     2.4.  Request Routing and Content Delivery . . . . . . . . . . .  6
       2.4.1.  HTTP Redirection by CDN A and Delivery by CDN B  . . .  7
       2.4.2.  HTTP Redirection by CDN B and Delivery by CDN A  . . .  9
       2.4.3.  Test Result  . . . . . . . . . . . . . . . . . . . . . 11
     2.5.  Content Delivery Metadata  . . . . . . . . . . . . . . . . 12
     2.6.  Content Acquisition  . . . . . . . . . . . . . . . . . . . 12
       2.6.1.  Content Acquisition by CDN B through CDN A . . . . . . 12
       2.6.2.  Content Acquisition by CDN A Directly from CP B  . . . 13
   3.  Lessons Learned  . . . . . . . . . . . . . . . . . . . . . . . 14
     3.1.  Request Routing  . . . . . . . . . . . . . . . . . . . . . 15
       3.1.1.  Request-Routing Information and Policies . . . . . . . 15
       3.1.2.  Iterative and Recursive Redirection  . . . . . . . . . 15
       3.1.3.  Request Looping Avoidance  . . . . . . . . . . . . . . 16
     3.2.  Content Delivery Metadata  . . . . . . . . . . . . . . . . 16
     3.3.  Content Acquisition and Deletion . . . . . . . . . . . . . 17
       3.3.1.  Content Pre-Positioning in Downstream CDN  . . . . . . 17
       3.3.2.  Content Purge  . . . . . . . . . . . . . . . . . . . . 17
   4.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 17
   5.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   6.  Security Considerations  . . . . . . . . . . . . . . . . . . . 18
   7.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 18
     7.1.  Normative References . . . . . . . . . . . . . . . . . . . 18
     7.2.  Informative References . . . . . . . . . . . . . . . . . . 18
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 19



















Bertrand, et al.         Expires August 18, 2012                [Page 3]

Internet-Draft              CDNI Experiments               February 2012


1.  Introduction

   This document reports studies and related experiments on CDN
   interconnection performed by France Telecom-Orange Labs.  The
   document summarizes implications of CDN interconnection to CDN
   service providers and lessons learned through CDNI experiments.

   The main purpose of the experiments was to test the interconnection
   of CDN solutions from two vendors (namely, Cisco and Verivue) and to
   identify the gaps and needs for standardization work for CDN
   interconnection.

   This study is not intended to explore the entire scope of CDNI, and
   in fact, it purposely takes a minimalist approach.  That is, we focus
   on what's minimally required to interconnect two cooperating CDNs in
   a "best effort" way.  This provides a constructive foundation for
   adding requirements and mechanisms only after they prove essential in
   practice.

1.1.  Terminology

   We adopt the terminology described in [RFC3466], [RFC3568],
   [RFC3570], CDNI problem statement draft
   [I-D.ietf-cdni-problem-statement], CDNI framework draft
   [I-D.davie-cdni-framework] and CDNI use cases draft
   [I-D.ietf-cdni-use-cases].

   Content Delivery Service

   Set of services offered to content service providers (CSPs) for
   delivering their content through a single Content Delivery Network or
   interconnections of Content Delivery Networks.


2.  CDN Interconnection Experiments

2.1.  Experiment Configuration

   The interconnection of two CDN solutions from different vendors has
   been tested.  These tests have been run with CDN solutions from Cisco
   (hereafter referred to as Vendor A) and from Verivue/CoBlitz
   (hereafter referred to as Vendor B).

   As depicted in Figure 1, we have interconnected two experimental CDNs
   (CDN A and CDN B) operated by different subsidiaries of a large CDSP.
   The CDNs lab equipment were located in two different countries,
   henceforth referred to as Country A and Country B and they relied on
   CDN solutions from two different equipment vendors, namely, Vendor A



Bertrand, et al.         Expires August 18, 2012                [Page 4]

Internet-Draft              CDNI Experiments               February 2012


   and Vendor B. The CDNI experiment supported the services of two
   emulated CPs (CP A and CP B).


          +-------+      :       +-------+
          | CP  A |      :       | CP  B |
          +-------+      :       +-------+
              |          :           |
         ,--,--,--.      :      ,--,--,--.
      ,-'  CDN A   `-.   :   ,-'  CDN B   `-.
     (   (Vendor A)   )=====(   (Vendor B)   )
      `-.          ,-'   :   `-.          ,-'
         `--'--'--'      :      `--'--'--'
                         :
               COUNTRY A : COUNTRY B

     === CDN Interconnect


                                 Figure 1

   More precisely, we have run the experiments represented in Figure 2
   and Figure 4.  We base our description on Figure 2.  In this
   experiment, CP A has an agreement with CDSP A for content delivery to
   end-users located in Country A and Country B. However, CDSP A
   operates a CDN (CDN A), whose footprint does not include country B.
   Therefore, CDSP A has an agreement with CDSP B, so that CDN A can
   delegate to CDN B the delivery of some content.  More specifically,
   CDN A is allowed to delegate to CDN B the handling of requests sent
   by end-users located in Country B for CP A's content.

   When CDN A receives a content request related to CP A and from an
   end-user in Country B, it redirects the end-user to CDN B. If CDN B
   does not have a local copy of the requested content yet (cache miss),
   CDN B ingests the content from CDN A (or from the CP's origin
   servers, depending on the test scenario); if CDN A also does not have
   a local copy of the requested content, it requests this asset from
   the CP's origin servers before sending the asset to CDN B.

   There are several differences between the tests in Figure 2 and
   Figure 4, in addition to the different role played by the two CDN
   solutions.  We list the main ones below.

   o  We have tested different content acquisition methods (see
      Section 2.6).

   o  Specific URL schemes were involved in providing content
      acquisition source information to the downstream CDN.  As we have



Bertrand, et al.         Expires August 18, 2012                [Page 5]

Internet-Draft              CDNI Experiments               February 2012


      tested different content acquisition methods, depending on which
      solution played the role of dCDN, the two solutions have used
      different URL schemes to address content.  Therefore, the tests
      required the configuration of different content delivery metadata
      on the uCDN (see Section 2.4).

   o  The two solutions use different methods to identify the end-user's
      geographic locations (see Section 2.4).

2.2.  Control

   The tested CDN solutions support control APIs but those are
   proprietary, so that the tested CDN solutions do not support a common
   inter-operable CDNI control interface.  Therefore, we have not tested
   CDNI control operations and we had to perform manually most
   operations related to the configuration of the CDNI.

2.3.  Logging

   Proprietary mechanisms to export transaction logs
   [I-D.bertrand-cdni-logging] were available in the tested CDN
   solutions, but have not been covered by our tests.

2.4.  Request Routing and Content Delivery

   As defined in [I-D.davie-cdni-framework], two main types of request-
   routing call flows can be used for CDNI:

   1.  iterative request-routing,

   2.  recursive request-routing.

   Moreover, two main methods can be used for redirecting an end-user
   from the authoritative CDN to the downstream CDN:

   1.  DNS-based redirection,

   2.  Service-level redirection, for example HTTP-based or RTSP-based.

   We have focused our tests on iterative request-routing.  Our tests
   involved HTTP-based request redirection by the authoritative CDN, as
   they focused on the delivery of large objects, such as movies.

   The tested CDN solutions did not feature a CDNI request-routing
   interface allowing exchange of "CDN routing" information among CDNs.
   Therefore, we have manually configured appropriate policies on the
   authoritative CDN to permit iterative request-routing (e.g., CDN A
   redirects the end-user to CDN B request-routing system, cf.



Bertrand, et al.         Expires August 18, 2012                [Page 6]

Internet-Draft              CDNI Experiments               February 2012


   Figure 3).

2.4.1.  HTTP Redirection by CDN A and Delivery by CDN B

   This section describes the tested request routing and content
   delivery features in the scenario depicted in Figure 2, with HTTP
   redirection by CDN A and delivery by CDN B.

   We have tested the selection of the downstream CDN based on the
   content type in the client request and/or the geographic location of
   the client.

   o  File-type based selection relied on static XML files where content
      file extensions can be associated to a specific delivery CDN.

   o  The geographic location of the end-user was determined by an
      external geolocation server.




          +-------+      :
          |  CP A |      :
          +-------+      :
              |          :
         ,--,--,--.      :      ,--,--,--.
      ,-'  CDN A   `-.   :   ,-'  CDN B   `-.
     (   (Vendor A)   )=====(   (Vendor B)   )
      `-.  CDSP A  ,-'   :   `-.  CDSP B  ,-'
         `--'--'--'      :      `--'--'--'
                         :           |
                         :        +------+
                         :        | EU B |
                         :        +------+
                         :
               COUNTRY A : COUNTRY B

     === CDN Interconnect

                                 Figure 2

   Figure 3 details the messages exchanged by the components involved in
   the experiment.








Bertrand, et al.         Expires August 18, 2012                [Page 7]

Internet-Draft              CDNI Experiments               February 2012


   End-User                                                   CP A
   served by                                             contract with
   CDN B          DNS    CDN A   Geoloc   CDN B  SurgtB      CDN A
     | DNS REQ (1)|        |        |       |      |         |
     |----------->|        |        |       |      |         |
     | DNS REP (2)|        |        |       |      |         |
     |<-----------|        |        |       |      |         |
     | HTTP GET (3)        |        |       |      |         |
     |------------+------->|  (3.1) |       |      |         |
     |            |        |------->|       |      |         |
     |            |        |  (3.2) |       |      |         |
     | HTTP 302 (4)        |<-------|       |      |         |
     |<-----------+--------|        |       |      |         |
     | HTTP GET (5)        |        |       |      |         |
     |------------+--------+--------+------>|      |         |
     | HTTP 302 (6)        |        |       |      |         |
     |<-----------+--------+--------+-------|      |         |
     | HTTP GET (7)        |        |       |      |         |
     |------------+--------+--------+-------+----->|         |
     | HTTP 200 OK (8)     |        |       |      |         |
     |<-----------+--------+--------+-------+------|         |


              HTTP redirection by CDN A and delivery by CDN B

                                 Figure 3

   Message details

   (1) The user-agent sends a DNS request to resolve the FQDN of the
   content URI.

   (2) The DNS answers with the IP address of a request-router in CDN A.

   (3) The user-agent sends to CDN A request-router an HTTP GET request
   for the content URI.

   (3.1) CDN A request-router analyzes the request and queries a
   geolocation database to identify the geographic location of the end-
   user.

   (3.2) The geolocation database answers with geolocation information
   related to the end-user's IP address.  The end-user is in country B;
   thus, CDN A determines that the end-user's request must be served by
   CDN B.

   (4) CDN A request-router replies to the user-agent with an HTTP 302
   redirection message, which provides the URI of the content on CDN B.



Bertrand, et al.         Expires August 18, 2012                [Page 8]

Internet-Draft              CDNI Experiments               February 2012


   (5) If necessary, the user-agent resolves the FQDN on the redirection
   URI (steps not represented in the figure), and thus, determines the
   IP address of a request-router in CDN B. Then, it sends an HTTP GET
   request to this request-router.

   (6) CDN B request-router analyzes the request and replies to the
   user-agent with an HTTP 302 redirection message that provides the URI
   of the content on a surrogate in CDN B.

   (7) If necessary, the user-agent resolves the FQDN of the redirection
   URI (steps not represented in the figure), and thus, determines the
   IP address of a surrogate in CDN B. Then, it sends an HTTP GET
   request to the surrogate.

   (8) The surrogate analyzes the request and delivers the requested
   content to the end-user, through an HTTP 200 OK message.

2.4.2.  HTTP Redirection by CDN B and Delivery by CDN A

   This section describes the tested request routing and content
   delivery features in the scenario depicted in Figure 4, with HTTP
   redirection by CDN B and delivery by CDN A.

   We have tested the selection of the downstream CDN based on end-
   user's geolocation.  For these tests, the geolocation database had
   been populated manually with the mapping of IP prefixes to countries.
   Alternative solutions, such as geolocation based on BGP communities
   or on the extraction of per country IP prefixes thanks to commercial
   geoIP databases, exist but they have not been tested in this
   experiment.





















Bertrand, et al.         Expires August 18, 2012                [Page 9]

Internet-Draft              CDNI Experiments               February 2012


                       :       +-------+
                       :       |  CP B |
                       :       +-------+
                       :           |
       ,--,--,--.      :      ,--,--,--.
    ,-'  CDN A   `-.   :   ,-'  CDN B   `-.
   (   (Vendor A)   )=====(   (Vendor B)   )
    `-.  CDSP A  ,-'   :   `-.  CDSP B  ,-'
       `--'--'--'      :      `--'--'--'
           |           :
        +------+       :
        | EU A |       :
        +------+       :
                       :
             COUNTRY A : COUNTRY B

   === CDN Interconnect

                                 Figure 4

   Figure 5 details the messages exchanged by the components involved in
   the experiment.


    End-User                                            CP B
    served by                                       contract with
    CDN A        DNS     CDN A   Srgt A   CDN B        CDN B
     | DNS REQ (1)|        |       |        |             |
     |----------->|        |       |        |             |
     | DNS REP (2)|        |       |        |             |
     |<-----------|        |       |        |             |
     | HTTP GET (3)        |       |        |             |
     |------------+--------+-------+------->|             |
     | HTTP 302 (4)        |       |        |             |
     |<-----------+--------+-------+--------|             |
     | HTTP GET (5)        |       |        |             |
     |------------+------->|       |        |             |
     | HTTP 302 (6)        |       |        |             |
     |<-----------+--------|       |        |             |
     | HTTP GET (7)        |       |        |             |
     |------------+--------+------>|        |             |
     | HTTP 200 OK (8)     |       |        |             |
     |<-----------+--------+-------|        |             |


              HTTP redirection by CDN B and delivery by CDN A

                                 Figure 5



Bertrand, et al.         Expires August 18, 2012               [Page 10]

Internet-Draft              CDNI Experiments               February 2012


   Message details

   (1) The user-agent sends a DNS request to resolve the FQDN of the
   content URI.

   (2) The DNS answers with the IP address of a request-router in CDN B.

   (3) The user-agent sends to CDN B request-router an HTTP GET request
   for the content URI.

   (4) CDN B request-router analyzes the request.  The end-user is in
   country A; thus, CDN B determines that the end-user's request must be
   served by CDN A. Consequently, CDN B replies to the user-agent with
   an HTTP 302 redirection message that provides the URI of the content
   on CDN A.

   (5) If necessary, the user-agent resolves the FQDN on the redirection
   URI (steps not represented in the figure), and thus, determines the
   IP address of a request-router in CDN A. Then, it sends an HTTP GET
   request to this request-router.

   (6) CDN A request-router analyzes the request and replies to the
   user-agent with an HTTP 302 redirection message, which provides the
   URI of the content on a surrogate in CDN A.

   (7) If necessary, the user-agent resolves the FQDN of the redirection
   URI (steps not represented in the figure), and thus, determines the
   IP address of a surrogate in CDN A. Then, it sends an HTTP GET
   request to the surrogate.

   (8) The surrogate analyzes the request and delivers the requested
   content to the end-user, through an HTTP 200 OK message.

2.4.3.  Test Result

   HTTP redirection by the authoritative CDN was successful in the
   tests: end-users were redirected to the CDN that served their
   country.  This guaranteed that:

   o  content from CP A be delivered by CDN B to end-users in country B,
      even if CP A had no direct relationship with CDSP B;

   o  content from CP B be delivered by CDN A to end-users in country A,
      even if CP B had no direct relationship with CDSP A.







Bertrand, et al.         Expires August 18, 2012               [Page 11]

Internet-Draft              CDNI Experiments               February 2012


2.5.  Content Delivery Metadata

   The tested CDN solutions feature proprietary metadata APIs, but these
   APIs have not been covered by the tests.  We had to configure
   distribution metadata consistently in the dCDN and the uCDN (e.g.,
   rules to determine upstream source for content acquisition).

   Content pre-positioning in the dCDN has not been tested: only dynamic
   content acquisition has been covered by the experiments.

   Proprietary APIs were available for content purge, but those have not
   been covered by tests.

2.6.  Content Acquisition

   We have used regular HTTP for content acquisition.  We have relied on
   HTTP custom headers to transfer trivial metadata such as content
   integrity check (MD5 hash).

   The correct acquisition and delivery of the requested file has been
   tested for Adobe Flash and MS HTTP smooth-streaming files.

2.6.1.  Content Acquisition by CDN B through CDN A

   We describe here the content acquisition operations triggered in case
   of cache miss, for the test scenario depicted in Figure 2 and
   Figure 3, with HTTP redirection by CDN A and delivery by CDN B. In
   this scenario, the dCDN (CDN B) does not have the requested content
   in cache and must request it to the uCDN (CDN A).

   The uCDN treats the dCDN surrogate as an end-user: Figure 6 provides
   a summary (the involved internal entities of the uCDN are not
   detailed) of the related content acquisition operations.
   Section 3.1.3 provides more details on specific issues related to
   this content acquisition mode.
















Bertrand, et al.         Expires August 18, 2012               [Page 12]

Internet-Draft              CDNI Experiments               February 2012


  End-User                                                        CP A
  served by                                                contract with
  CDN B          DNS          CDN A      Geoloc    CDN B        CDN A
    |            |            |         |           |            |
    |            |            | HTTP GET (7.1)      |            |
    |            |            |<--------+-----------|            |
    |            |            | HTTP GET (7.2)      |            |
    |            |            |---------+-----------+----------->|
    |            |            | HTTP 200 OK (7.3)   |            |
    |            |            |<--------+-----------+------------|
    |            |            | HTTP 200 OK (7.4)   |            |
    |            |            |---------+---------->|            |
    |            |            |         |           |            |


   Pull content acquisition by CDN B through CDN A in case of cache miss
                        (continuation of Figure 3)

                                 Figure 6

   Message details

   (7.1) CDN B surrogate or parent cache sends a content acquisition
   request to the uCDN (CDN A).  In the tests, (7.1) was triggered by a
   cache miss on delivery request.  Stated differently, the tests
   implemented dynamic acquisition, as opposed to content pre-
   positioning.

   (7.2) CDN A analyzes the request.  In case of cache miss, it sends an
   acquisition request to the CP's origin servers.

   (7.3) The CP's origin server authorizes the request and delivers the
   requested content to CDN A, through an HTTP 200 OK.

   (7.4) CDN A delivers the requested content to CDN B surrogate or
   parent cache, through an HTTP 200 OK.

2.6.2.  Content Acquisition by CDN A Directly from CP B

   We describe here (Figure 7) the content acquisition operations
   triggered in case of cache miss, for the test scenario with HTTP
   redirection by CDN B and delivery by CDN A (Figure 4 and Figure 5).
   In this scenario, the dCDN (CDN A) does not have the requested
   content in cache and must request it to CP B.







Bertrand, et al.         Expires August 18, 2012               [Page 13]

Internet-Draft              CDNI Experiments               February 2012


   End-User                                               CP B
   served by                                       contract with
   CDN A          DNS          CDN A         CDN B      CDN B
     |            |            |             |            |
     |            |            |HTTP GET (7.1)            |
     |            |            |-------------+----------->|
     |            |            |HTTP 200 OK (7.2)         |
     |            |            |<------------+------------|


    Pull content acquisition by CDN A directly from content provider's
      origin servers in case of cache miss (continuation of Figure 5)

                                 Figure 7

   Message details

   (7.1) CDN A surrogate sends a content acquisition request to an
   origin server of the CP.  In the tests, (7.1) was triggered by a
   cache miss on a delivery request.  Stated differently, the tests
   implemented dynamic acquisition, as opposed to content pre-
   positioning.

   (7.2) The CP's origin server authorizes the request and delivers the
   requested content to CDN A, through an HTTP 200 OK.


3.  Lessons Learned

   For basic interconnection tests, we have relied on extremely limited
   information exchanges between the two interconnected CDNs and we have
   configured most CDNI related features manually.  This is because,
   while present CDN technologies support APIs allowing configuration of
   some of this information, those are difficult to use in multi-vendor
   environments since:

   o  they are proprietary APIs;

   o  they are designed as "internal" APIs and therefore lack the
      necessary inter-domain security and policy control.

   Therefore, those APIs have not been used in these tests.

   In the present section, we highlight some of the limitations induced
   by the lack of standard CDNI interfaces that we have faced in our
   tests.

   One of the insights from this work is that by encoding information



Bertrand, et al.         Expires August 18, 2012               [Page 14]

Internet-Draft              CDNI Experiments               February 2012


   inside the redirection URI, it is possible to communicate some
   essential CDNI-related information across CDNs "in-band" (i.e., as
   part of HTTP), rather than communicating it through an out-of-band
   interface.  In these tests, the information communicated in-band was
   restricted to the most fundamental information; that is, a handle
   allowing the Downstream CDN to determine where to acquire the
   content.  This was key to achieving multi-CDN operations without any
   common CDNI "out-of-band" interface supported by existing CDN
   technologies.  This raises an interesting general question: what
   subset of inter-CDN information is to be communicated between
   interconnected CDNs in-band (possibly using existing methods) as
   opposed to communicated via out-of-band interfaces?

3.1.  Request Routing

3.1.1.  Request-Routing Information and Policies

   Because of the lack of CDNI interfaces allowing CDNs to exchange
   information such as their coverage, capabilities, and performance, we
   had to configure request-routing policies manually in the CDNs that
   acted as uCDNs.  While this may be tolerable for initial limited
   deployments of CDNI scenarios with a small number of participants,
   this is expected to create operational constraints in larger scale
   deployments.

3.1.2.  Iterative and Recursive Redirection

   Because of the lack of CDNI interfaces allowing an upstream CDN to
   query dCDN for how to redirect a request, the tests only covered
   iterative redirection (i.e. uCDN redirects the user-agent to the dCDN
   request-routing system, which redirects the user-agent to ...), not
   recursive redirection.

   While iterative redirection allows supporting redirection across
   CDNs, it has some limitations:

   o  multiple redirections are exposed to the end-user;

   o  redirection latency cannot easily be reduced for future requests,
      through the caching of request-routing decisions;

   o  some client implementations support a limited number of successive
      redirections;

   o  the dCDN cannot reject a redirection, while allowing the uCDN to
      handle the rejected request.

   A standard request-routing API would allow supporting recursive



Bertrand, et al.         Expires August 18, 2012               [Page 15]

Internet-Draft              CDNI Experiments               February 2012


   redirection, which removes these shortcomings.

3.1.3.  Request Looping Avoidance

   In case of cache-miss, the downstream CDN must fetch the requested
   content, either through the authoritative CDN, or directly from the
   CP's origin server.

   Consider the situation where the downstream CDN fetches the content
   from the authoritative CDN, as illustrated in Section 2.6.1.  In this
   case, the authoritative CDN must not redirect the acquisition request
   to the downstream CDN, because this would create the following
   request-routing loop: dCDN -> uCDN -> dCDN.  Consequently, the
   upstream CDN must be able to determine that the source of the request
   is a partner CDN and not a regular end-user.  In addition, the
   upstream CDN must be able to acquire content from the CP's origin
   server on behalf of the downstream CDN, if necessary: dCDN -> uCDN ->
   CP.

   In the tests, we have successfully solved the request-looping issue,
   through the use of separated URL spaces for regular users and CDN
   users, as well as the manual configuration of appropriate request-
   routing policies for every URL space.  In other words, the URL used
   by regular users to fetch content was different from the one used by
   the downstream CDN to fetch the content.  This way, we eliminated the
   loops.  More automated operation would be required in larger-scale
   deployments.

3.2.  Content Delivery Metadata

   CDN technology typically supports APIs allowing creation, update, and
   deletion of content delivery metadata in the CDN.  However, while
   often similar, those are proprietary and would require custom
   support.  In the tests, passing of the most essential information,
   i.e., the upstream source for content acquisition, was achieved
   indirectly via conveying a handle inside the URI and configuring
   manually in the downstream CDN rules for extracting the upstream
   source.

   The upstream source for content acquisition can be specified through
   the use of a specific URI scheme.  For example, CDN A could use the
   following scheme: http://cdni.cdna.com/origin-URI to point to a
   cached copy of the content reachable at "origin-URI".  The domain
   name inside the URI scheme designates the request-routing system of a
   CDN, and the remainder of the URI defines upstream source for content
   acquisition: here, the content URI on the CP's origin servers.  If
   the authoritative CDN and the downstream CDN use this URI scheme, the
   authoritative CDN can easily map the URI that it receives in the end-



Bertrand, et al.         Expires August 18, 2012               [Page 16]

Internet-Draft              CDNI Experiments               February 2012


   user's content request with a valid URI on the downstream CDN.
   Similarly, the downstream CDN can easily extract a content
   acquisition URI from the redirection URI.

   In our tests, we have configured manually the rules that enabled the
   authoritative CDN to redirect end-users to a valid URI on the
   downstream CDN, and the downstream CDN to ingest content from the
   appropriate upstream source.  While this allowed validation of the
   content distribution model, this solution may not be viable in a
   production environment, as it imposes constraints on URI structure.
   In addition, this approach does not support exchange of other
   distribution metadata (e.g., geo-blocking, content validation,...)
   which would require to be manually configured in the downstream CDN.
   In a real-world deployment, the configuration of these policies could
   rely on information that interconnected CDNs would exchange through a
   CDNI interface.

3.3.  Content Acquisition and Deletion

3.3.1.  Content Pre-Positioning in Downstream CDN

   CDN technology typically supports APIs that allow triggering of
   content and metadata pre-positioning in a CDN.  However, while often
   similar, these APIs are proprietary and would require custom support.
   For this reason content pre-positioning in dCDN was not covered in
   the tests.  While the highest requirements is for support of dynamic
   acquisition, CDNI use-cases call for support of pre-positioning,
   which requires a triggering mechanism in a CDNI API.

3.3.2.  Content Purge

   CDN technology typically supports APIs allowing content purge in a
   CDN.  However, while often similar, these APIs are proprietary and
   would require custom support.  For this reason, content purge was not
   covered in the tests.  There is a strong requirement for content
   purge in CDNI scenarios, which introduces the need for a purge
   triggering mechanism in a CDNI API.


4.  Acknowledgments

   The authors would like to acknowledge the work of Elodie Hemon and
   Marcin Pilarski on the tests, with the technical support of Sharon
   Schwartzman and Marc Fiuczynski.  They would like to thank Slim Gara,
   Vincent Lauwers, Emile Stephan, Benoit Gaussen, and Mateusz Dzida for
   valuable input and discussions.  Finally, the authors acknowledge
   interesting discussions with contributors of the EU FP7 OCEAN
   project.



Bertrand, et al.         Expires August 18, 2012               [Page 17]

Internet-Draft              CDNI Experiments               February 2012


5.  IANA Considerations

   This memo includes no request to IANA.


6.  Security Considerations

   CDN interconnect, as described in this document, has a wide variety
   of security issues that should be considered.  This document focuses
   on specific experiments for CDN interconnect, and therefore, does not
   analyze the threats in detail.


7.  References

7.1.  Normative References

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

7.2.  Informative References

   [I-D.bertrand-cdni-logging]
              Gilles, B. and S. Emile, "CDNI Logging Interface",
              draft-bertrand-cdni-logging-00 (work in progress),
              February 2012.

   [I-D.davie-cdni-framework]
              Davie, B. and L. Peterson, "Framework for CDN
              Interconnection", draft-davie-cdni-framework-01 (work in
              progress), October 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-03 (work in
              progress), January 2012.

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

   [I-D.ietf-cdni-use-cases]
              Gilles, B., Emile, S., Watson, G., Burbridge, T., Eardley,
              P., and K. Ma, "Use Cases for Content Delivery Network
              Interconnection", draft-ietf-cdni-use-cases-03 (work in



Bertrand, et al.         Expires August 18, 2012               [Page 18]

Internet-Draft              CDNI Experiments               February 2012


              progress), January 2012.

   [RFC3466]  Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
              for Content Internetworking (CDI)", RFC 3466,
              February 2003.

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

   [RFC3570]  Rzewski, P., Day, M., and D. Gilletti, "Content
              Internetworking (CDI) Scenarios", RFC 3570, July 2003.


Authors' Addresses

   Gilles Bertrand (editor)
   France Telecom - Orange
   38-40 rue du General Leclerc
   Issy les Moulineaux  92130
   FR

   Phone: +33 1 45 29 89 46
   Email: gilles.bertrand@orange.com


   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410
   FR

   Phone: +33 4 97 23 26 19
   Email: flefauch@cisco.com


   Larry Peterson
   Verivue, Inc.
   2 Research Way
   Princeton, NJ  08540
   US

   Phone: +1 978 303 8032
   Email: lpeterson@verivue.com







Bertrand, et al.         Expires August 18, 2012               [Page 19]