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

Versions: 00 01 02 draft-ietf-cdni-use-cases

Internet Engineering Task Force                              G. Bertrand
Internet-Draft                                                E. Stephan
Intended status: Informational                   France Telecom - Orange
Expires: August 1, 2011                                        G. Watson
                                                            T. Burbridge
                                                              P. Eardley
                                                                      BT
                                                        January 28, 2011


       Use Cases for Content Distribution Network Interconnection
                    draft-bertrand-cdni-use-cases-01

Abstract

   Content Delivery Networks (CDNs) are commonly used for improving the
   footprint and the end-user experience of a content delivery service,
   at a reasonable cost.  This document outlines real world use-cases
   (not technical solutions) for interconnecting CDNs.  The intention is
   to motivate CDN Interconnection and to support the case for formation
   of a Working Group, which would work on the definition of
   standardized, inter-operable method(s) for interconnecting CDNs.

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 1, 2011.

Copyright Notice

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



Bertrand, et al.         Expires August 1, 2011                 [Page 1]


Internet-Draft               CDNI Use Cases                 January 2011


   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 1, 2011                 [Page 2]


Internet-Draft               CDNI Use Cases                 January 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  6
   2.  High Level Use Cases for Multi-CDN Systems . . . . . . . . . .  7
     2.1.  Footprint Extension Use Cases  . . . . . . . . . . . . . .  8
       2.1.1.  Geographic Extension . . . . . . . . . . . . . . . . .  8
       2.1.2.  Country to Country Interconnection . . . . . . . . . .  8
       2.1.3.  Nomadic Users  . . . . . . . . . . . . . . . . . . . .  8
       2.1.4.  Geo-blocking . . . . . . . . . . . . . . . . . . . . .  9
       2.1.5.  Device and Network Technology Extension  . . . . . . .  9
     2.2.  Offload Use Cases  . . . . . . . . . . . . . . . . . . . . 10
       2.2.1.  Overload Handling and Dimensioning . . . . . . . . . . 10
       2.2.2.  Resiliency . . . . . . . . . . . . . . . . . . . . . . 11
     2.3.  Technology and Vendor Interoperability . . . . . . . . . . 12
     2.4.  QoE and QoS improvement  . . . . . . . . . . . . . . . . . 12
       2.4.1.  NSP CDSP Use Case  . . . . . . . . . . . . . . . . . . 12
   3.  Experiments with Existing CDN Solutions and Lessons Learned  . 12
     3.1.  France Telecom-Orange Experiments  . . . . . . . . . . . . 12
     3.2.  Gaps in Existing Solutions and Need for Specifications . . 14
   4.  Discussion on Priorities for the Proposed Charter  . . . . . . 14
   5.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 15
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     8.2.  Informative References . . . . . . . . . . . . . . . . . . 15
   Appendix A.  CDN Interconnection Patterns  . . . . . . . . . . . . 16
     A.1.  Single CDN . . . . . . . . . . . . . . . . . . . . . . . . 16
     A.2.  Dual CDN with Direct Content Delivery  . . . . . . . . . . 17
     A.3.  Intermediary CDN . . . . . . . . . . . . . . . . . . . . . 19
       A.3.1.  Option A - Recursive . . . . . . . . . . . . . . . . . 19
       A.3.2.  Option B - Iterative . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
















Bertrand, et al.         Expires August 1, 2011                 [Page 3]


Internet-Draft               CDNI Use Cases                 January 2011


1.  Introduction

   This document now merges input from [I-D.watson-cdni-use-cases].

   Content Delivery Networks (CDNs) are commonly used for improving the
   footprint and the end-user experience of a content delivery service,
   at a reasonable cost.  This document outlines real world use-cases
   (not technical solutions) for interconnecting CDNs.  The intention is
   to motivate CDN Interconnection and to support the case for formation
   of a Working Group, which would work on the definition of
   standardized, inter-operable method(s) for interconnecting CDNs.

   There are many possible combinations for the relationships between
   the different parties (Network Service Provider (NSP), Content
   Delivery Service Provider (CDSP), Content Service Provider (CSP),
   etc.) involved in end-to-end content delivery.  However, in the
   context of interconnecting CDNs the key relationships are listed
   below.

   o  How the CSP interacts with the CDN to publish and deliver content.

   o  How the End User interacts with the interconnected CDNs to request
      and receive content.

   o  How the different CDSPs, operating their CDNs, interact with one
      another to deliver the CSP's content to the End User.

   Section 2 describes a number of use cases that motivate CDN
   Interconnection.  We also briefly describe some experiments with
   existing CDN solutions (Section 4).

1.1.  Terminology

   Except for the terms defined below, we adopt the terminology
   described in [RFC3466], [RFC3568], and [RFC3570].

   Problem statement draft [I-D.jenkins-cdni-problem-statement]defines a
   set of terms.  Below we recall only the terms used in the memo.

   Content Service Provider (CSP):

   Provides Content Services to Users.  A CSP may own the content made
   available as part of the Content Service, or may license content
   rights from another party.

   Content Service:

   The service offered by a CSP.  The Content Service encompasses the



Bertrand, et al.         Expires August 1, 2011                 [Page 4]


Internet-Draft               CDNI Use Cases                 January 2011


   complete service which may be wider than just the delivery of items
   of Content, e.g. the Content Service also includes any middle-ware,
   key distribution, program guide, etc. which may not require any
   direct interaction with the CDN.

   Content Distribution Network (CDN) / Content Delivery Network (CDN):

   A type of network in which the components are arranged for more
   effective delivery of content to User Agents.

   Content Delivery Service

   Set of services offered to CSPs for delivering their contents through
   a single Content Delivery Network or interconnections of Content
   Delivery Networks.

   CDN Service Provider (CDSP):

   An administrative entity who operates a CDN over a NSP or over the
   Internet.

   Authoritative CDN (aCDN):

   The CDSP contracted by the CSP for delivery of content by this CDN or
   by its downstream CDNs.

   Downstream CDN (dCDN):

   A CDSP which is contracted by an aCDN to achieve the delivery of
   content to users.

   Access CDN

   A CDN that is connected to the end-user's access and has information
   about the end-user's profile and access capabilities.

   Delivering CDN

   The CDN that delivers the requested content asset to the end-user.
   In particular, the delivering CDN can be an access CDN.

   CDN Interconnection (CDNI):

   Relationship between two CDNs that enables a CDN to provide content
   delivery services on behalf of another CDN.  It relies on a set of
   interfaces over which two CDNs communicate in order to achieve the
   delivery of content to end-users by one CDN (the downstream CDN) on
   behalf of another CDN (the upstream CDN).



Bertrand, et al.         Expires August 1, 2011                 [Page 5]


Internet-Draft               CDNI Use Cases                 January 2011


   CDN peering: A business relation between two CDSPs based on one or
   more CDN interconnections.

   Recursive request routing:

   Recursive: Where a process is repeated, but embedded within the
   original process.  In the case of Request Routing, this means that
   the initial request received by the Authoritative CDN is processed
   downstream from one CDN to another and that the responses are send
   back upstream to the Authoritative CDN which then replies to the
   initial request.

   Iterative request routing

   Iterative: Where a process is repeated multiple times to make
   progress towards a goal.  In the case of Request Routing, this means
   that the initial request is received by the Authoritative CDN, which
   replies it with a redirection directive to a dowstream CDN.  When the
   end-user sends its request to the downstream CDN, the same process is
   repeated, until the request arrives to the delivering CDN.

1.2.  Abbreviations

   [Ed.  Note: List of abbreviations to be updated later and sorted
   alphabetically]

   o  ISP

   o  NSP

   o  STB

   o  PC

   o  QoS

   o  QoE

   o  SLA

   o  VoD

   o  WiFi

   o  3G






Bertrand, et al.         Expires August 1, 2011                 [Page 6]


Internet-Draft               CDNI Use Cases                 January 2011


2.  High Level Use Cases for Multi-CDN Systems

   The prevalent use cases for CDNI are presented according to a CDSP's
   main motivation for interconnecting its CDN.  They are classified
   according to their level of priority for the CDSP:

   o  CDN Footprint Extension Use Cases

   o  CDN Offload Use Cases

   o  Technology and vendor interoperability

   o  QoE and QoS improvement

   "CSPs have a desire to be able to get (some of their) content to very
   large number of users and/or over many/all geographies and/or with a
   high quality of experience, all without having to maintain direct
   business relationships with many different CDN providers"
   [draft-jenkins-cdni-problem-statement].

   In order to minimize the number of direct business relationships
   between a CSP and a set of interconnected CDNs, it is assumed that a
   CSP will only be required/ desire to have a direct relationship with
   a single CDN, although relationships with more than one CDN are not
   precluded.  A CDN selected by the CSP is referred to as an
   "Authoritative CDN" in this document.  When receiving requests from
   User Agents, the Authoritative CDN will select an appropriate
   Surrogate in its own CDN or will decide to delegate the delivery to
   another CDN, to which a CDN interconnection can be established.

   The CDNI model enables Content Delivery Networks to collaborate,
   allowing Content Delivery Service Providers to offer consistent
   delivery services throughout the CDN Interconnection

   The CDNI model helps enables Content Delivery Networks that
   collaborate to provide Content Service Providers with delivery
   services throughout CDN Interconnections.

   Let's take an example.  CDSP-A and CDSP-B respectively operate CDN-A
   and CDN-B.  They establish a CDN peering for building the CDN
   interconnections from CDN-A to CDN-B and from CDN-B to CDN-A.  The
   content service provider CSP-A reaches an agreement with CDSP-A.
   CDSP-A services rely on the CDN-A and on the interconnection from
   CDN-A to CDN-B.  Meanwhile, the content service provider CSP-B
   reaches an agreement with CDSP-B.  These services rely on the CDN-A
   and on the interconnection from CDN-A to CDN-B.

   [Ed.  Note: Figure to be added to help the reader understand the



Bertrand, et al.         Expires August 1, 2011                 [Page 7]


Internet-Draft               CDNI Use Cases                 January 2011


   example]

2.1.  Footprint Extension Use Cases

   Footprint extension is a major use case for CDN interconnection.

2.1.1.  Geographic Extension

   In this use case, the CDSP is concerned with extending the geographic
   distribution that it can offer to the CSP without overly compromising
   the quality of delivery and without attracting transit and other
   network costs by serving from geographically or topologically remote
   surrogates.  For example, several CDSPs have a geographically limited
   footprint (e.g., a country), or do not serve all end-users in a
   geographic area.  Interconnecting CDNs enables CDSPs to provide their
   services beyond their own footprint by relying on other CDNs.

   As an example, a French CSP that distributes TV series wants to
   distribute them to end-users located in various countries in Europe
   and North Africa.  It asks a French CDSP to deliver the series to
   several countries.  The French CDSP makes an agreement with an
   external CDSP that covers North Africa , so that overall the French
   CDSP provides a CDN service for both France and North Africa.

   This use case applies to other types of contents such as automatic
   software updates (browser updates, operating system patches, or virus
   database update, etc).

2.1.2.  Country to Country Interconnection

   There is a specific scenario where a large content delivery service
   provider (CDSP) operates the CDNs of a set of subsidiaries from
   different countries.  These CDNs can rely on different CDN solutions.
   Such a situation may occur due to independent regional operations, or
   through mergers and acquisitions.  In certain circumstances, the CDSP
   needs to make its CDNs interoperate to provide a consistent service
   to its customers on its whole footprint.



   [Ed. Note: FIGURE TO BE INCLUDED
   Figure 1

2.1.3.  Nomadic Users

   Another scenario is nomadic situation.  In this scenario a CSP wishes
   to allow users who move to other geographic regions to continue to
   access their content.  The motivation in this case is to allow



Bertrand, et al.         Expires August 1, 2011                 [Page 8]


Internet-Draft               CDNI Use Cases                 January 2011


   nomadic users to maintain access, rather than to allow all residents
   within a region access to the content.

2.1.4.  Geo-blocking

   Currently, the distribution of some content is restricted.  For
   instance, distribution rights for audiovisual content are often
   negotiated per country.

   The selection of the Authoritative CDN is influenced by policies
   which may include "geo-blocking" rules that specify

   o  the geographic regions where content can be delivered from (i.e.
      the location of the Surrogates),

   o  geographic locations where content can be delivered to (i.e. the
      location of the End Users),

   o  or quality of service policies specifying how the content is to be
      delivered.

   Hence, the exchange through the CDN interconnection of information
   for controlling the footprint of the delivery is an important use
   case.

2.1.5.  Device and Network Technology Extension

   In this use case the CDSP may have the geographic and end-user
   coverage that it requires, but wishes to support the delivery of
   content to alternative end devices.  These devices may sit on remote
   networks (such as smartphones connected to a mobile network) and may
   also require unique delivery capabilities in the CDN.  In this case
   the CDSP may federate with another CDSP that offers service to these
   devices.

   As depicted in Figure 2, an end-user can use its tablet to download a
   VoD through WiFi (1) from CDN1 and then switch to 3G network (2),
   which is served by CDN2.  The end user should be able to reach the
   selected VoD content through any access network technology.
   Consequently, every considered CDN must have access to this VoD
   content.  One way to proceed consists in having an ingestion
   interface among the CDNs to access the content.  Replication of the
   requested VoD content in the CDN serving the terminal (a) enables
   controlling the QoS (e.g. screen size, bitrate) of the VoD
   distribution to the terminal used by the end-user.  In another
   situation, the serving of the VoD without replication (b) will save
   storage resources.  The end-user's experience improves thanks to an
   increase of the number of situations where the end-user can access



Bertrand, et al.         Expires August 1, 2011                 [Page 9]


Internet-Draft               CDNI Use Cases                 January 2011


   the service.


                 --------------                    --------------
                /   CDN1       \                  /   CDN2       \
                |  Fixed       |                  |  Mobile      |
                |  ,---.       |                  |  ,---.       |
       +---+    | .     )      |        (a)       | .     )      |
       |CSP|****| |`---'|      |''''`---------.....>|`---'|      |
       +---+    | |     |      -..  Acquisition   | |     |      |
                | (     )      |  `-.._           | (     )      |
                |  `---'       |       `-..       |  `---'       |
                |,------------.|       (b) ``-._  |,------------.|
                ||Delivery    ||                `->.  Delivery  ||
                \`------------'/                  \`------------'/
                 ----------+---                    -----*--+-----
                           :                            *  |
                           :                            *  |
                        +........+                     +--------+
                        : Tablet : (1)                 | Tablet |(2)
                        +........+                     +--------+


   Figure 2: Fixed-Mobile CDN Inter-connection

   .: This use case is similar to use case in Section 2.3.

2.2.  Offload Use Cases

   Offload is a major use case of CDN interconnection.

2.2.1.  Overload Handling and Dimensioning

   The support of prime-time traffic load requires over-dimensioning the
   CDN capacity.  In addition unexpected spikes in content popularity
   may drive load beyond the expected peak.  As prime time and peaks of
   content distribution may differ between two CDNs, a CDN may
   interconnect with another CDN to increase its effective peak
   capacity.  Similarly, two CDNs may benefit from dimensioning savings
   by using the resources of each other during their peaks of activity.

   The profile of activity peaks (time, duration ...) differ not only
   from a country to another but also according to the kind of CDNs.
   Therefore, CDN interconnect will be required since the additional
   capacity is likely to be provided by alternative technology.

   Offload also applies to planned situation where a CDSP needs CDN
   capacities in a particular region during a short period of time.  For



Bertrand, et al.         Expires August 1, 2011                [Page 10]


Internet-Draft               CDNI Use Cases                 January 2011


   example, during a specific maintenance operation or for covering the
   distribution of a special event, such as an international sport
   competition.

2.2.2.   Resiliency

   It is important for CDNs to be able to guarantee service continuity
   during partial failures (e.g., failure of a set of surrogates).  In
   partial failure scenarios, a CDSP could redirect some requests toward
   another CDN.  This downstream CDN must be able to serve the
   redirected requests or, depending on traffic management policies, to
   forward these requests to the CSP origin server.

   Resiliency may also be required against failure to ingest content
   from the CSP.  In these cases the content may be available from
   another CDSP.



                 --------------                    --------------
                /   CDN1       \                  /   CDN2       \
                |  ,---.       |                  |  ,---.       |
    +---+       | .     )      |                  | .     )      |
    |CSP|*******| |`---'|      |__________________| |`---'|      |
    +---+       | |     |      |    Acquisition   | |     |      |
                | (     )      |                  | (     )      |
                |  `---'       |                  |  `---'       |
                |+-----------+ |                  |,------------.|
                ||Req-Routing| |                  .|Delivery    ||
                \+-----------+ /                  \`------------'/
                  ------------                     .-'-----------
                        |                       .-'
                        | --------------- >  .-'
                        |    Redirect     .-'
                        |              .-'
                        |           .-'
                        |        .-'
                        |     .-'
                        |  .-'
                     +-----+
                     | User|
                     +-----+



   Figure 3: Example of CDN Interconnection for failure resiliency





Bertrand, et al.         Expires August 1, 2011                [Page 11]


Internet-Draft               CDNI Use Cases                 January 2011


2.3.  Technology and Vendor Interoperability

   ISPs have deployed platforms per service or per network technology.
   They are deploying CDNs or enhancing existing platforms to CDN.  It
   is desirable in certain circumstances to share the content or the
   resources among these internal CDNs.  A CDSP may wish to operate a
   multi-vendor strategy for its CDN.  Currently, operating a single
   controller for such multi-vendor CDNs is problematic.  This problem
   can be alleviated by a CDN interconnection that allows the automation
   of some operations among these CDNs.

2.4.  QoE and QoS improvement

   Some existing CDNs make the decision to work with ISPs to deploy
   surrogates closer to the end users.  Compared to alternatives such as
   adding capacity at major peering points, this method offers better
   experience to the end users.  Some CSPs are willing to pay a premium
   for such enhanced service rather than just using the CDSP to mitigate
   their server and network access costs.  Improved experience may be
   provided by closer proximity to the end users.  It could also involve
   network characteristics, such as provisioning or QoS, and specific
   delivery techniques such as encoding for constant Quality of
   Experience.

2.4.1.  NSP CDSP Use Case

   In a interconnection use case, CDSP-A is likely to offer an SLA to
   the CSP including performance or other quality metrics.  If it cannot
   meet the SLA it will push content via the interconnection to a CDSP-B
   with CDN capabilities that are in a position to guaranty the SLA, and
   redirect users appropriately to CDSP-B.  CDSP-A may not be able to,
   or may not wish to deploy its own CDN capabilities to meet the SLA
   requirements for only a subset of its CSP customers.  The ability to
   offer stringent delivery quality SLAs is a differentiator against
   other CDSPs and can be sold as a premium service.

   Although this use case has similarities to extending geographic
   reach, in this case it is expected that the CDSP does have a CDN
   deployed which could effectively serve content to the end-users, but
   wishes to increase experience for specific CSPs.


3.  Experiments with Existing CDN Solutions and Lessons Learned

3.1.   France Telecom-Orange Experiments

   As depicted in Figure 1, we have interconnected two CDNs (CDN A and
   CDN B) operated by different subsidiaries of a large CDSP.  The CDNs



Bertrand, et al.         Expires August 1, 2011                [Page 12]


Internet-Draft               CDNI Use Cases                 January 2011


   cover two different countries, henceforth referred to as Country A
   and Country B and they rely on CDN solutions from two different
   equipment vendors (Vendor A and Vendor B).  The CDNI experiment
   supported the services of two CSPs (CSP A and CSP B).


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

     === CDN Interconnect



   Experiment configuration

                                 Figure 1

   We have run several experiments in the configuration represented in
   Figure 2.  In these experiments, CSP 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 CSP A's content.

   When CDN A receives a content request related to CSP A and from an
   end-user in Country B, it redirects the end-user to the appropriate
   content on 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 CSP'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 CSP's origin servers before
   sending the asset to CDN B.








Bertrand, et al.         Expires August 1, 2011                [Page 13]


Internet-Draft               CDNI Use Cases                 January 2011


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

     === CDN Interconnect


   Test scenario with heterogeneous solutions

                                 Figure 2

3.2.  Gaps in Existing Solutions and Need for Specifications

   Our experiments have shown that the current CDN technologies suffer
   from the following limitations.

   o  The content management policies must be defined manually, so that
      the end-user's request triggers content delivery from the most
      appropriate CDN (e.g., a CDN in the country of the end-user, or a
      CDN that serves the type of files requested by the end-user).

   o  The target URLs for the request redirection must also be defined
      manually, so that the authoritative CDN provides to the end-user a
      valid URI on the downstream CDN.

   o  The content ingestion from an upstream CDN worked only in pull
      mode.

   To address more sophisticated scenarios, we consider that common
   interfaces are required for request routing among interconnected CDNs
   and for the exchange of content distribution metadata.


4.  Discussion on Priorities for the Proposed Charter

   This section will be worked out later according to the discussions on



Bertrand, et al.         Expires August 1, 2011                [Page 14]


Internet-Draft               CDNI Use Cases                 January 2011


   the mailing list.


5.  Acknowledgments

   The authors would like to thank Francois Le Faucheur and Ben Niven-
   Jenkins for lively discussions.

   They also thank the contributors of the EU FP7 OCEAN and ETICS
   projects for valuable inputs.


6.  IANA Considerations

   This memo includes no request to IANA.


7.  Security Considerations

   CDN interconnect, as described in this document, has a wide variety
   of security issues that should be considered.  For example, every
   interconnected CDN should be able to assess if it must serve a
   delegated request or if this request is delegated by a non-allowed
   CDN.  The CDNs should also be protected so as to avoid being
   overwhelmed by delegated requests.  This document focuses on the
   motivational use cases for CDN interconnect, and therefore, does not
   analyze the threats in detail.


8.  References

8.1.  Normative References

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

8.2.  Informative References

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

   [I-D.lefaucheur-cdni-requirements]
              Faucheur, F., Viveganandhan, M., Watson, G., and Y. Lee,
              "Content Distribution Network Interconnection (CDNI)
              Requirements", draft-lefaucheur-cdni-requirements-00 (work



Bertrand, et al.         Expires August 1, 2011                [Page 15]


Internet-Draft               CDNI Use Cases                 January 2011


              in progress), January 2011.

   [I-D.watson-cdni-use-cases]
              Watson, G., "CDN Interconnect Use Cases",
              draft-watson-cdni-use-cases-00 (work in progress),
              January 2011.

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


Appendix A.   CDN Interconnection Patterns

   In this section we attempt to pull out the generic CDN
   interconnection patterns that may result from the use cases detailed
   previously.  We find little difference between the use cases in the
   generic interconnection patterns that occur, and these are presented
   below.  However, differences do occur due to the the business
   concerns of the different parties operating the components in each
   use case.  This will result in different technical requirements at a
   more detailed level (for example in reporting and accounting
   mechanisms).

A.1.  Single CDN

   This section outlines an illustrative model for content delivery via
   a single CDN where there is no interconnection with other CDNs.  It
   does not describe all the details and variations but rather the high
   level interactions between the different Actors (CSP, CDN, End User)
   which can be used as a point of comparison with the CDN
   Interconnection patterns described in subsequent sections.












Bertrand, et al.         Expires August 1, 2011                [Page 16]


Internet-Draft               CDNI Use Cases                 January 2011


                       +-------+
                       | CSP-1 |
                       +-------+
                           |
                      ,---------.
                   ,-'           `-.
                  (      CDN-A      )
                   `-.           ,-'
                      `---------'
                           |
                      ,---------.
                   ,-'    0 or   `-.
                  (    more other   )
                   `-.  networks ,-'
                  /   `---------'  \
                 /                  \
          ,---------.            ,---------.
       ,-'           `-.      ,-'           `-.
      (      NSP-X      )    (      NSP-Y      )
       `-.           ,-'      `-.           ,-'
          `---------'            `---------'
               |                      |
           +-------+              +-------+
           | UA-X  |              | UA-Y  |
           +-------+              +-------+


A.2.  Dual CDN with Direct Content Delivery

   Taking the above use cases into account the base pattern for CDN
   Interconnection is shown in the diagram below.  To simplify the
   diagram the cloud showing "zero or more other networks" has been
   excluded and NSPs are shown as though they are directly attached to
   CDNs.  This is not intended to imply any direct relationships or to
   exclude the case where one or more networks may exist between the NSP
   illustrated and the CDN.















Bertrand, et al.         Expires August 1, 2011                [Page 17]


Internet-Draft               CDNI Use Cases                 January 2011


           +-------+
           | CSP-1 |
           +-------+
               |
          ,---------.            ,---------.
       ,-'           `-.      ,-'           `-.
      (      CDN-A      )==I==(      CDN-B     )
       `-.           ,-'     /`-.           ,-'
          `---------'       /    `---------'
               |        ___/          |
               |       /              |
          ,---------. /          ,---------.
       ,-'           `-.      ,-'           `-.
      (      NSP-X      )    (      NSP-Y      )
       `-.           ,-'      `-.           ,-'
          `---------'            `---------'
               |                      |
           +-------+              +-------+
           | UA-X  |              | UA-Y  |
           +-------+              +-------+

      ==I== CDN Intercon

   As shown in the diagram CSP-1 maintains a direct relationship with
   CDN-A and so CDN-A is the Authoritative CDN for CSP-1.  CDN-A
   maintains a CDN Interconnect with CDN-B.  CDN-A may decide to
   delegate to CDN-B the delivery of contentto a UA/NSP.  How CDN-A
   makes such a decision is out of scope for this document, although the
   motivations for doing so are captured in the above use cases.  Let us
   assume that an End User, at User Agent Y, wishes to use CSP-1's
   service and that CDN-A decides to delegate the delivery of the
   content to CDN-B and that CDN-B is willing to perform the delegated
   delivery.  In order for EU-Y to receive content the following
   illustrative interactions occur:

   1.  UA-Y selects a piece of content (as directed by EU-Y) from
   CSP-1's service.

   2.  CSP-1 returns a URL, URL-A, for the selected content which
   resolve to the Request Router in CDN-A, the Authoritative CDN for
   CSP-1.

   3.  CDN-A's Request Router makes a decision to delegate the delivery
   to CDN-B.

   4.  CDN-A makes a request to CDN-B to deliver the content on behalf
   of CDN-A and CDN-B responds with details of how CDN-A's Request
   Router should respond to the request.



Bertrand, et al.         Expires August 1, 2011                [Page 18]


Internet-Draft               CDNI Use Cases                 January 2011


   5.  CDN-A's Request Router returns the appropriate response to UA-Y
   or another device acting on its behalf (such as a DNS resolver).

   6.  UA-Y will connect to CDN-B and request the content.  At this
   point there are several possible variations:

   a.  The content request is directed to the Request Router of CDN-B.
   In this manner the UA can be iteratively passed between CDNs.  The
   Request Router of CDN-B may identify a surrogate in CDN-B, or may
   identify another CDN (as elaborated in the Intermediary Pattern
   below).

   b.  The content request is directed to a surrogate in CDN-B.

   7.  UA-Y receives the content from the surrogate in CDN-B.  Again
   there are a couple of options:

   a.  The content already exists in the chosen surrogate and is
   delivered to the UA.

   b.  The content is not stored within the chosen surrogate and is
   dynamically transferred to the surrogate and sequentially delivered
   to the UA.

   8.  CDN-B may link the content to URL-B.  In this manner another
   service may use URL-B to preferentially serve the content from CDN-B
   directly rather than being directed through CDN-A.

A.3.  Intermediary CDN

   This use case extends the dual CDN pattern by allowing CDN-B to
   accept a delegated content delivery from CDN-A and then delegate the
   delivery to CDN-C.  There are a couple of options for this pattern.

A.3.1.  Option A - Recursive

   Steps 1 to 3 proceed as for the dual CDN pattern.

   4.  CDN-A makes a request to CDN-B to deliver the content on behalf
   of CDN-A.  CDN-B instead decides to delegate this request to CDN-C,
   as permiited by its CDN peering agreement with CDN-A.  Thus, the
   Request Router of CDN-B refers the request to the Request Router of
   CDN-C.  CDN-C responds to CDN-B and in turn CDN-A's Request Router
   with details of how to respond to UA-Y

   Steps 5 to 8 proceed as for the dual CDN pattern with the exception
   that CDN-B is replaced by CDN-C.




Bertrand, et al.         Expires August 1, 2011                [Page 19]


Internet-Draft               CDNI Use Cases                 January 2011


A.3.2.  Option B - Iterative

   Steps 1 to 5 proceed as for the dual CDN pattern.

   6.  UA-Y will connect to CDN-B and request the content.  The content
   request is directed to the Request Router of CDN-B.  The Request
   Router of CDN-B identifies that the request should be serviced by
   CDN-C.

   The pattern then proceeds from step 4 of the dual CDN pattern with
   CDN-A replaced by CDN-B and CDN-B replaced by CDN-C.




           +-------+
           | CSP-1 |
           +-------+
               |
          ,---------.            ,---------.            ,---------.
       ,-'           `-.      ,-'           `-.      ,-'           `-.
      (      CDN-A      )====(      CDN-B      )====(      CDN-C      )
       `-.           ,-'      `-.           ,-'      `-.           ,-'
          `---------'            `---------'            `---------'
                                                             |
                                                             |
                                                        ,---------.
                                                     ,-'           `-.
                                                    (      NSP-Z      )
                                                     `-.           ,-'
                                                        `---------'
                                                             |
                                                         +-------+
                                                         | UA-Z  |
                                                         +-------+

      ==== CDN Interconnect














Bertrand, et al.         Expires August 1, 2011                [Page 20]


Internet-Draft               CDNI Use Cases                 January 2011


Authors' Addresses

   Gilles Bertrand
   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-ftgroup.com


   Stephan Emile
   France Telecom - Orange
   2 avenue Pierre Marzin
   Lannion  F-22307
   France

   Email: emile.stephan@orange-ftgroup.com


   Grant Watson
   BT
   pp GDC 1 PP14, Orion Building, Adastral Park, Martlesham
   Ipswich,   IP5 3RE
   UK

   Email: grant.watson@bt.com


   Trevor Burbridge
   BT
   B54 Room 70, Adastral Park, Martlesham
   Ipswich,   IP5 3RE
   UK

   Email: trevor.burbridge@bt.com


   Philip Eardley
   BT
   B54 Room 77, Adastral Park, Martlesham
   Ipswich,   IP5 3RE
   UK

   Email: philip.eardley@bt.com





Bertrand, et al.         Expires August 1, 2011                [Page 21]


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