Internet Engineering Task Force                         G. Bertrand, Ed.
Internet-Draft                                                E. Stephan
Intended status: Informational                   France Telecom - Orange
Expires: March 25, June 23, 2012                                         G. Watson
                                                            T. Burbridge
                                                              P. Eardley
                                                                   K. Ma
                                                           Azuki Systems
                                                      September 22,
                                                       December 21, 2011

         Use Cases for Content Delivery Network Interconnection


   Content Delivery Networks (CDNs) are commonly used for improving the
   footprint and the end-user
   End User experience of a content delivery service, at a reasonable
   cost.  This document outlines real world use-cases use cases (not technical
   solutions) for interconnecting CDNs.  It can be used to provide
   guidance to the CDNI WG about the interconnection arrangements to be
   supported and to validate the requirements of the various CDNI

   This document describes a number of use cases that motivate CDN
   Interconnection.  It represents a work in progress and may be
   extended later to cover additional use-cases.

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

   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 March 25, June 23, 2012.

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Abbreviations  . . . . . . . . . . . . . . . . . . . . . .  5  4
     1.3.  Rationale for Multi-CDN Systems  . . . . . . . . . . . . .  5
     1.4.  The Need for CDNI CDN Interconnection Standards . . . . . . . . . . . . . . .  7  6
   2.  Footprint Extension Use Cases  . . . . . . . . . . . . . . . .  7
     2.1.  Geographic Extension . . . . . . . . . . . . . . . . . . .  7
     2.2.  Inter-Affiliates Interconnection . . . . . . . . . . . . .  8
     2.3.  Mastering Incoming Traffic . . . . . . . . . . . . . . . .  8
     2.4.  Nomadic Users  . . . . . . . . . . . . . . . . . . . . . .  8
   3.  Offload Use Cases  . . . . . . . . . . . . . . . . . . . . . .  8 10
     3.1.  Overload Handling and Dimensioning . . . . . . . . . . . .  8 10
     3.2.  Resiliency . . . . . . . . . . . . . . . . . . . . . . . .  9 10
       3.2.1.  Failure of Content Delivery Resources  . . . . . . . .  9 10
       3.2.2.  Failure of  Content Acquisition Resiliency . . . . . . . . . . . .  9 10
   4.  CDN Capability Use Cases . . . . . . . . . . . . . . . . . . .  9 11
     4.1.  Device and Network Technology Extension  . . . . . . . . . 10 11
     4.2.  Technology and Vendor Interoperability . . . . . . . . . . 10 12
     4.3.  QoE and QoS Improvement  . . . . . . . . . . . . . . . . . 11 12
   5.  Policy  Enforcement of Content Delivery Policy . . . . . . . . . . . . . . . . . . . . . . 11 13
     5.1.  Content Availability . . . . . . . . . . . . . . . . . . . 11
       5.1.1.  Geo-location Restrictions  . . . . . . . . . . . . . . 11
       5.1.2.  Temporal Restrictions  . . . . . . . . . . . . . . . . 12
       5.1.3.  Content Encoding Restrictions  . . . . . . . . . . . . 12 13
     5.2.  Branding . . . . . . . . . . . . . . . . . . . . . . . . . 13
     5.3.  Secure Access  . . . . . . . . . . . . . . . . . . . . . . 13 14
   6.  Open issues  . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 13
   8.  Acknowledgments  . . . . . . . . . . . . . . . . . . . . . . . 14
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 14
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 14
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 15
     11.1. 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 15
     11.2. 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 15 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 16

1.  Introduction

   Content Delivery Networks (CDNs) are commonly used for improving the
   footprint and the end-user
   End User experience of a content delivery service, at a reasonable
   cost.  This document outlines real world use-cases use cases (not technical
   solutions) for interconnecting CDNs.  It can be used to provide
   guidance to the CDNI WG about the interconnection arrangements to be
   supported and to validate the requirements of the various CDNI

   This document describes a number of use cases that motivate CDN
   Interconnection.  It represents a work in progress and may be
   extended later to cover additional use-cases.

   This document identifies the main motivations for a CDN Provider to
   interconnect its CDN:

   o  CDN Footprint Extension Use Cases (Section 2)

   o  CDN Offload Use Cases (Section 3)

   o  CDN Capability Use Cases (Section 4)

   Then, the document highlights the need for interoperability to
   exchange and enforce content delivery policies (Section 5).

1.1.  Terminology

   We adopt the terminology described in
   [I-D.ietf-cdni-problem-statement], [I-D.davie-cdni-framework],
   [RFC3466], and [RFC3568], except
   for the terms defined below.

   Authoritative CDN (aCDN):

   A CDN provider contracted by the CSP for delivery of content by its
   CDN or by its downstream CDNs. [RFC3568].

   Access CDN:

   A CDN that is directly connected to the end-user's access and has End User's access.  An Access
   CDN may have specific information about the end-user's End User and the network,
   for instance, End User's profile and access capabilities.

   Delivering CDN:

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

   [Ed.  Note: Definition of recursive and iterative request routing
   should be added to [I-D.davie-cdni-framework].]

   CDN Interconnection:

   Relationship between two CDNs that enables a CDN to provide content
   delivery services on behalf of another Access 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).

   CDN peering: A business relation between two CDN providers based on
   one or more CDN Interconnections.

1.2.  Abbreviations

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

   o  CDN: Content Delivery Network also known as Content Distribution

   o  CSP: Content Service Provider

   o  dCDN: downstream CDN
   o  DNS: Domain Name System

   o  DRM: Digital Rights Management

   o  EU: End User

   o  ISP: Internet Service Provider

   o  NSP: Network Service Provider

   o  QoE: Quality of Experience

   o  QoS: Quality of Service

   o  SLA: Service Level Agreement

   o  uCDN: upstream CDN

   o  UA: User Agent

   o  UE: User Equipment

   o  VoD: Video on Demand  URL: Uniform Resource Locator

   o  WiFi: Wireless Fidelity

1.3.  Rationale for Multi-CDN Systems

   Content Delivery Networks (CDNs) are used to deliver content because
   they can:

   o  improve the experience for the End User; for instance delivery has
      lower latency (decreased round-trip-time between the user and the
      delivery server) and better robustness,

   o  reduce the network operator's costs; for instance instance, lower delivery
      cost (reduced bandwidth usage) for cacheable content,

   o  reduce the Content Service Provider Provider's (CSP) costs, such as
      datacenter capacity, space, and electricity consumption. consumption, as
      popular content is delivered through the CDN rather than through
      the CSP's servers.

   Indeed, many network service providers Network Service Providers (NSPs) and enterprise service
   providers are deploying or have deployed their own CDNs.  Despite the
   potential benefits of interconnecting CDNs, today each CDN is a
   standalone network.  The objective of CDN interconnection Interconnection is to
   overcome this restriction: the interconnected CDNs should be able to
   collectively behave as a single delivery infrastructure.

   Let's take an example, as

   An example is depicted in Figure 1.  Two CDN Providers establish a
   CDN Interconnection.  The Content Service Provider CSP-1 reaches an
   agreement with CDN Provider A 'A' for the delivery of its content.  CDN
   Provider A 'A' and CDN Provider B 'B' agree to interconnect their CDNs.

   When a User Agent that is connected to CDN Provider B's
   network requests Content content from CSP-1, the Content CDN-A considers that
   delivery by CDN-B is actually
   delivered from CDN-B, appropriate, for instance, because CDN-B is an
   Access CDN and the user is directly attached to it.  CDN-A has
   delegated the handling of requests for CSP-1's
   Content has been delegated as part of content through the
   CDN Interconnection
   agreement. agreement, thus, the content is actually
   delivered from CDN-B.

   The End User benefits from this arrangement through a better quality Quality
   experience, Experience (QoE), because the Content content is delivered from a nearby
   Surrogate.  CDN Provider A 'A' benefits because it doesn't does not need to
   deploy such an extensive CDN, whilst CDN Provider B receives 'B' may receive
   some compensation for the delivery.  CSP-1 benefits because it only
   needs to make one business agreement and one physical connection,
   with CDN Provider A, 'A', but its End Users get a service quality as
   though CSP-1 had also gone to the trouble of making a business
   agreement with CDN Provider B. 'B'.

    +-------+ +-------+
    | CSP-1 | | CSP-2 |
    +-------+ +-------+
        |         |
       ,--,--,--./            ,--,--,--.
    ,-'          `-.       ,-'          `-.
    ( CDN
   (CDN Provider A )=====( CDN 'A')=====(CDN Provider B ) 'B')
    `-.  (CDN-A) ,-'       `-. (CDN-B)  ,-'
       `--'--'--'             `--'--'--'
                            | User Agent |
    === CDN Interconnection

                                 Figure 1

   To extend the example, another Content Service Provider, CSP-3, CSP-2, may
   also reach an agreement with CDN Provider A. 'A'.  But it does not want
   Content content to be distributed by CDN Provider B, B; for example, CSP-3 CSP-2
   may not have distribution rights in the country where CDN Provider B
   'B' operates.  This example illustrates that policy considerations
   are an important part of CDNI.

1.4.  The Need for CDNI CDN Interconnection Standards

   The problem statement draft [I-D.ietf-cdni-problem-statement]
   describes extensively the CDNI problem space and explains why CDNI
   standards are required.

   Existing CDN interfaces are proprietary and have often been designed
   for intra-CDN/intra-domain operations.  So  Consequently, an external CDN
   typically cannot use them, these interfaces, especially if the two CDNs to
   be interconnected rely on different implementations.  Nevertheless,
   [I-D.bertrand-cdni-experiments] shows that some level of CDN interconnection
   Interconnection can be achieved experimentally without standardized
   interfaces between the CDNs.  However, the methods used in these
   experiments are hardly usable in an operational context, because they
   suffer from several limitations in terms of functionalities,
   scalability, and security level.

   The aim of IETF CDNI WG's solution is therefore is, therefore, to overcome such
   shortcomings; a full list of requirements is being developed in

2.  Footprint Extension Use Cases

   Footprint extension is expected to be a the major use case for CDN

2.1.  Geographic Extension

   In this use case, the CDN Provider wants to extend the geographic
   distribution that it can offer to its CSPs:

   o  without compromising the quality of delivery,

   o  without incurring additional transit and other network costs that
      would result from serving content from geographically or
      topologically remote surrogates. Surrogates.

   If there are several CDN Providers that have a geographically limited
   footprint (e.g., restricted to one country), or do not serve all end-
   users End
   Users in a geographic area, then interconnecting their CDNs enables
   these CDN Providers to provide their services beyond their own

   As an example, suppose a French CSP wants to distribute its TV
   programs to End Users located in France and various countries in
   North Africa.  It asks a French CDN Provider to deliver the content.
   The French CDN Provider's network only covers France, so it makes an
   agreement with another CDN Provider that covers North Africa.
   Overall, from the CSP's perspective the French CDN Provider provides
   a CDN service for both France and North Africa.

   In addition to video, this use case applies to other types of content
   such as automatic software updates (browser updates, operating system
   patches, virus database update, etc).

2.2.  Inter-Affiliates Interconnection

   In the previous section, we have described the case of geographic
   extension between CDNs operated by different entities.  A large CDN
   Provider may also operate CDNs from several subsidiaries (which may
   rely on different CDN solutions, see Section 4.2).  In certain
   circumstances, the CDN Provider needs to make its CDNs interoperate
   to provide a consistent service to its customers on its whole
   footprint.  For example, the CDN Provider might want to expose a
   single set of interfaces to the CSPs.

2.3.  Mastering Incoming Traffic

   Consider an ISP carrying to its subscribers a lot of content that
   comes from a third party CSP and that is injected into the access
   network by an Authoritative CDN Provider.  There are mutual benefits
   to the Access CDN, the Authoritative CDN, and the CSP that would make
   a case for establishing a CDNI agreement.  For example:

   o  Allow the CSP to offer improved QoE and QoE services to
      subscribers, for example, QoS and reduced round trip time.

   o  Allow the Authoritative CDN to reduce hardware capacity and
      footprint, by using the ISP caching and delivery capacity.

   o  Allow the ISP to reduce traffic load on some segments of the
      network by caching inside of the ISP network.

   o  Allow the ISP to influence and/or control the traffic ingestion

   o  Allow the ISP to derive some incremental revenue for transport of
      the traffic and to monetize QoE services.

2.4.  Nomadic Users

   In this scenario scenario, a CSP wishes to allow users End Users who move to other
   geographic regions between
   CDNs to continue to access their content.  The motivation in of this
   case is to allow nomadic users End Users to maintain access to content with
   a consistent quality of experience, rather than to allow all
   residents within QoE, across a region access to the content.

   [Ed.  Note: expand on which CDNs need to be interconnected to address
   the use case (ie with CDN of "home NSP" interconnected to CDN range of
   visited NSP).  Add a picture for clarifying the text.  Use the term
   "TV everywhere"?] devices and/or geographic

   This use case covers situations like users like:

   o  End Users moving between different CDN Providers Providers, which may reside
      within the same geographic region, region or users different geographic regions,

   o  End Users switching between different devices, devices or delivery
      technologies, as discussed in Section 4.

3.  Offload Use Cases

3.1.  Overload Handling and Dimensioning

   A CDN is likely to be dimensioned

   The term "Nomadic" does not necessarily relate to support geographic roaming.

   Consider the prime-time traffic.
   However, unexpected spikes following example, illustrated in Figure 2: End User A
   has subscription to a broadband service from NSP A, her "home NSP".
   NSP A hosts CDN-A.  Ordinarily, when End User A accesses content popularity may drive load
   beyond via
   NSP A (her "home NSP") the expected peak.  The prime recurrent time content is delivered from CDN-A, which in
   this example is within NSP A's network.

   However, while End User A is not connected to NSP A's network, for
   example, because it is connected to a WiFi provider or mobile
   network, End User A can also access the same content.  In this case,
   End User A may benefit from accessing the same content but delivered
   by an alternate CDN (CDN-B), in this case, hosted in the network of
   the WiFi or mobile provider, rather than from CDN-A in NSP A's

       ,--,--,--.             ,--,--,--.
    ,-'  NSP A   `-.       ,-'  NSP B   `-.
   (    (CDN-A)     )=====(    (CDN-B)     )
    `-.          ,-'       `-.          ,-'
       `--'--'--'             `--'--'--'
            |                     |
      +------------+      +---------------+
      + EU A (home)|      | EU A (nomadic)|
      +------------+      +---------------+
    === CDN Interconnection

                                 Figure 2

   The alternate CDN (CDN-B) is allowed to distribute the content of CSP
   A to End User A; however, no other End Users in the region of CDN B
   are allowed to retrieve the content unless they too have such an
   agreement for nomadic access to content.

   Depending on CSP's content delivery policies (see Section 5.1), a
   user moving to a different geographic region may be subject to geo-
   blocking content delivery restrictions.  In this case, he/she may not
   be allowed to access some pieces of content.

3.  Offload Use Cases

3.1.  Overload Handling and Dimensioning

   A CDN is likely to be dimensioned to support an expected maximum
   traffic load.  However, unexpected spikes in content popularity
   (flash crowd) may drive load beyond the expected peak.  The prime
   recurrent time peaks of content distribution may differ between two
   CDNs.  Taking advantage of the different traffic peak times, a CDN
   may interconnect with another CDN to increase its effective capacity
   during the peak of traffic.  This brings dimensioning savings to the
   CDNs as they can use the resources of each other during their
   respective peaks of activity.. activity.

   Offload also applies to planned situations where a CDN Provider needs
   CDN capacities in a particular region during a short period of time.
   For example, a CDN can offload traffic to another CDN during a
   specific maintenance operation or for covering the distribution of a
   special event.  For instance, consider a TV-channel which has
   exclusive distribution rights on a major event, such as a
   celebrities' wedding, or a major sport competitions. competition.  The CDNs that
   the TV-channel uses for delivering the content related to this event
   are likely to experience a flash crowd during the event and to need
   offloading traffic, while other CDNs will support a more usual
   traffic load and be able to handle the offloaded traffic load.

3.2.  Resiliency

3.2.1.  Failure of Content Delivery Resources

   It is important for CDNs to traffic.

   In this use case, the Delivering CDN on which requests are offloaded
   should be able to guarantee service continuity
   during partial failures (e.g., handle the offloaded requests.  Therefore, the uCDN
   might require information on the dCDNs to be aware of the amount of
   traffic it can offload to every dCDN.

3.2.  Resiliency

3.2.1.  Failure of Content Delivery Resources

   It is important for CDNs to be able to guarantee service continuity
   during partial failures (e.g., failure of some Surrogates).  In
   partial failure scenarios, a CDN Provider could has at least two options:
   (1) depending on traffic management policies, forward some requests
   to the CSP's origin servers, and (2) redirect some requests towards toward
   another CDN, which must be able to serve the redirected requests or, depending on traffic management policies, to
   forward these requests to the CSP's origin server. requests.

3.2.2.  Failure of  Content Acquisition Resiliency

   Source content acquisition is typically may be handled in one of two ways:

   o  CDN  CSP origin, where a downstream CDN acquires content directly from an
      upstream CDN, and the authoritative CDN acquires content from an CSP's
      origin server of the CSP, server, or

   o  Other  CDN origin, where the CDNs acquire a downstream CDN acquires content directly from a
      Surrogate within an
      origin server outside upstream CDN.

   The ability to support content acquisition resiliency, is an
   important use case for interconnected CDNs.  When the uCDN.

   Resiliency may be required against failure content
   acquisition source fails, the CDN might switch to ingest content.  If another content
   acquisition source.  Similarly, when several content acquisition
   sources are available, a CDN is unable to retrieve might balance the content, it load between these
   multiple sources.

   Though other server and/or DNS load balancing techniques may be that
   employed in the CSP's network, interconnected CDNs may have a better
   understanding of origin server is inaccessible availability and be better equipped to only this CDN, in which case
   redirection of the end-users
   both distribute load between origin servers and attempt content
   acquisition from alternate origin servers when acquisition failures
   occur.  When normal content acquisition fails, a CDN may need to try
   other origin server options, e.g.:

   o  an alternative upstream CDN may circumvent the
   problem.  A acquire content from an alternate CSP origin

   o  a downstream CDN may also choose to specify one acquire content from an alternate Surrogate
      within an upstream CDN, as directed by the upstream CDN's request
      routing interface,

   o  a downstream CDN may acquire content from an alternate upstream
      CDN, or more backup

   o  a downstream CDN may acquire content directly from the CSP's
   servers. server.

   Though content acquisition protocols are beyond the scope of CDNI,
   the selection of content acquisition sources should be considered.

4.  CDN Capability Use Cases

4.1.  Device and Network Technology Extension

   In this use case, the CDN Provider may have the right geographic
   footprint, but may wish to extend the supported range of devices and
   User Agents or the supported range of supported delivery technologies.  In this
   case, a CDN Provider may interconnect with a CDN that offers

   o  that its own the CDN Provider is not able willing to support provide or,
   o  that the its own CDN provider is not willing able to provide. support

   The following examples illustrate this use case:

   1.  CDN-A cannot support a specific delivery protocol.  For instance,
       CDN-A may interconnect with CDN-B to serve a proportion of its
       traffic that requires HTTPS.  CDN-A may use CDN-B's footprint
       (which may overlap with its own) to deliver HTTPS without needing
       to deploy its own infrastructure.  This case could also be true
       of other formats, delivery protocols (RTMP, RTSP, etc.) and
       features (specific forms of tokenization, authorization such as tokens, per
       session encryption, etc.).

   2.  CDN-A has footprint covering traditional fixed line broadband and
       wants to extend coverage to mobile devices.  In this case, CDN-A
       may contract and interconnect with CDN-B who has both:

       *  physical footprint inside the mobile network,

       *  the ability to deliver content over a protocol that is
          required by specific mobile devices and not supported by

       In this case also it may be that CDN-B provides other features
       related to adapting the content. devices.

   These cases can apply to many CDN features that a given CDN provider Provider
   may not be able to support or not be willing to invest in, and thus,
   that the CDN provider Provider would delegate to another CDN.

4.2.  Technology and Vendor Interoperability

   A CDN Provider may deploy a new CDN to run alongside its existing
   CDN, as a simple way of migrating its CDN service to a new
   technology.  A  In addition, a CDN Provider may have a multi-vendor
   strategy for its CDN deployment.  A  Finally, a CDN Provider may want to
   deploy a separate CDN for a particular CSP or a specific network.  In
   all these circumstances, CDNI benefits the CDN Provider, as it
   simplifies or automates some inter-CDN operations (e.g., migrating
   the request routing function progressively).

4.3.  QoE and QoS Improvement

   Some CSPs are willing to pay a premium for enhanced delivery of
   content to their End Users.  In some cases, even if the CDN Provider
   could deliver the content to the end users, End Users, it cannot meet the CSP's
   service level requirements.  So, it makes  As a result, the CDN Provider may
   establish a CDN Interconnection agreement with another CDN Provider
   that can provide the expected
   quality of experience QoE to the end-user, for instance End User, e.g., via an
   Access CDN able to deliver content from Surrogates located closer to
   the end-
   user. End User and with the required service level.

5.  Policy  Enforcement

   For the interconnection use cases described in previous sections, the
   delegation of content delivery may be dependent upon the ability to
   delegate delivery policy enforcement as well. Content Delivery Policy

   CSPs may rely on commonly require the ability to place delivery restriction on
   sets of content, which are provided by existing CDNs.  While the  The ability to
   support these
   features such delivery restrictions across interconnected CDNs is
   desirable, that may not always
   be feasible.  It but depends on the capabilities of the involved CDNs.
   Thus, it is important to be able to detect or and define when these
   features cannot be enforced.

5.1.  Content Availability

   The content distribution policies that a CSP attaches to a piece of
   asset depend on many criteria.  For instance, distribution policies
   for audiovisual content often combine:

   o  temporal constraints (e.g., available for 24 hours, available 28
      days after DVD release, etc.),

   o  resolution-based constraints (e.g., high definition vs. standard
      definition), and

   o  geolocation-based constraints (e.g., per country).

5.1.1.  Geo-location Restrictions

   "Geo-blocking" rules may specify:

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

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

   If a default value of "geo-blocking rules not supported" is set, the
   CSP may wish to deny all access to the content, or blacklist specific
   dCDNs which lack support for these features.

5.1.2.  Temporal Restrictions

   Time-based rules

   CSPs may specify:

   o  an activation time (i.e., the time when require from their CDN Providers that they translate some of
   the above requirements into content should become
      available delivery policies for delivery), their CDNs.
   For instance, CDNs might implement "geo-blocking" rules specifying:

   o  a deactivation time (i.e., time after which  the geographic regions from where content should no
      longer can be delivered), or

   o  an expiration time delivered (i.e.,
      the time at which the content files
      should be expunged from all CDN storage).

   If a default value location of "time-based rules not supported" is set, the
   CSP may wish to deny all access to the content, or blacklist specific
   dCDNs which lack support for these features.

5.1.3.  Content Encoding Restrictions

   [Ed.  Note: Section to be removed? reworded?]

   Encoding-based rules may specify:

   o  a subset of encodings deliverable to specific devices,

   o  a subset of encodings deliverable though a specific NSP, Surrogates), or

   o  a subset of encodings deliverable  geographic locations to users based on a subscription
      or quality of service levels.

   [Ed.  Note: FLF The first bullet only makes sense if the solution
   supports transcoding/transrating, which I don't know if it will content can be
   supported in Initial scope.  The last bullet does not make sense to
   me as we do not want delivered (i.e., the CDNs to be aware of any user subscription
   levels (ie only CSP is aware of user subscription level)."]

   If a default value
      location of "encoding-based rules not supported" is set, the CSP may wish to deny all End Users).

   Similarly, an uCDN might implement some temporal constraints on
   content availability.  For example, it could restrict access to pre-
   positioned content prior to the content, or blacklist
   specific dCDNs which lack support for these features.

5.2.  Branding

   There are situations where one CDN Provider cannot opening of the availability window or does not want
   to operate all
   disable the functions delivery of a uCDN, e.g., a CDN exchange, which
   handles request routing (and possibly log retrieval) but delegates
   all content delivery to from the surrogates of other dCDNs. dCDNs (e.g., through
   purging) after the availability window has closed.

5.2.  Branding

   Preserving the branding of the CSP throughout delivery is often
   important to the CSP.  CSPs may desire to offer content services
   under their own name, even when the associated CDN service involves
   other CDSPs. CDN Providers.  The CSP may request that the name of the CDSPs CDN
   Providers does not appear in the URLs and may wish to specify a
   specific brand related tag to appear in the URLs.  Similarly, in offload situations,  The CSP may wish
   to forbid the delivery of its content by specific dCDNs that lack
   support for such branding preservation features.

   Similar restrictions may exist when the uCDN might want wants to offer CDN
   services under its own branding.

   If branding even if dCDNs are involved.
   Conversely, a default value of "branding rules CDN Provider might not supported" is set, want the CSP
   may wish to deny all access brand of a CDN Exchange
   to be visible, even if the content, or blacklist specific
   dCDNs which lack support for these features. CDN Exchange is involved in the content
   delivery call flow.

5.3.  Secure Access

   Many protocols exist for delivering content to End Users.  CSPs may
   often wish to dictate a specific protocol or set of protocols which
   are acceptable for delivery of their content, especially in the case
   where content protection or user authentication is required (e.g.,
   must use HTTPS and not HTTP, HTTPS, or must use URL hashing, etc.).

   If a default value of "secure access rules not supported" is set, the

   The CSP may wish to deny all access to the content, or blacklist specific dCDNs which lack support for
   these secure access features.

6.  Open issues

   The section about nomadic users must be clarified

   The section about Content Encoding Restrictions requires a
   discussion: must the CDN enforce such restrictions?

7.  Contributors

   [Ed.  Note: long list of co-authors.  As per current practice, you
   would want to split that into "editors" and "contributors".]

   The following people have strongly contributed to this
   specification's content:

8.  Acknowledgments

   The authors would like to thank Kent Leung, Francois Le Faucheur and Faucheur, Ben Niven-Jenkins
   Niven-Jenkins, and Scott Wainner for lively discussions, as well as
   for their reviews and comments on the mailing list.

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


7.  IANA Considerations

   This memo includes no request to IANA.


8.  Security Considerations

   CDN Interconnection, as described in this document, has a wide
   variety of security issues that should be considered.

   In addition to the security considerations within the uCDN and dCDN,
   four contexts involve security and trust issues:

   a.  The relationship between the CSP and the uCDN: the main contract
       arrangement for distribution, which authorizes the uCDN to
       acquire content on CSP's origin servers and to deliver it,
       potentially with content delivery restrictions.

   b.  The relationship between the uCDN and dCDN: the transitive trust
       relationship that extends the contract defined in (a) above and
       that authorizes the dCDN to acquire content on uCDN's or CSP's
       origin servers and to deliver it, potentially with content
       delivery restrictions.

   c.  The relationship between the End User and dCDN: the recognition
       of right to download predicated on (b) above.

   d.  The relationship between the End User and the CSP: the contract
       that authorizes the End User to access to the content.

   CDNI should enable the four parties (CSP, uCDN, dCDN, End User) to
   negotiate a security method or a method for confirming authorization
   along the chain of trust (CSP -> uCDN -> dCDN -> End User).

   The security issues fall into three general categories:

   o  CSP Trust: where the CSP may have negotiated service level
      agreements for delivery quality of service with the uCDN, and/or
      configured distribution policies (e.g., geo-restrictions,
      availability windows, or other licensing restrictions), which it
      assumes will be upheld by dCDNs to which the uCDN delegates
      requests.  Furthermore, billing and accounting information must be
      aggregated from dCDNs with which the CSP may have no direct
      business relationship.  These situations where trust is delegated
      must be handled in a secure fashion to ensure CSP confidence in
      the CDN interconnection.

   o  Client Transparency: where the client device or application which
      connects to the CDN must be able to interact with any dCDN using
      its existing security and DRM protocols (e.g., cookies,
      certificate-based authentication, custom DRM protocols, URL
      signing algorithms, etc.) in a transparent fashion.

   o  CDN Infrastructure Protection: where the dCDNs must be able to
      identify and validate delegated requests, in order to prevent
      unauthorized use of the network and to be able to properly bill
      for delivered content.  A dCDN may not wish to advertise that it
      has access to or is carrying content for the uCDN or CSP,
      especially if that information may be used to enhance denial of
      service attacks.  In general,  CDNI interfaces and protocols should attempt to
      minimize overhead for dCDNs.

   This document focuses on the motivational use cases for CDN
   Interconnection, and does not analyze these threats in detail.


9.  References


9.1.  Normative References

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


9.2.  Informative References

              Bertrand, G., Faucheur, F., and L. Peterson, "Content
              Distribution Network Interconnection (CDNI) Experiments",
              draft-bertrand-cdni-experiments-01 (work in progress),
              August 2011.

              Davie, B. and L. Peterson, "Framework for CDN
              Interconnection", draft-davie-cdni-framework-00 draft-davie-cdni-framework-01 (work in
              progress), July October 2011.

              Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", draft-ietf-cdni-problem-statement-00 draft-ietf-cdni-problem-statement-01 (work in
              progress), September October 2011.

              Leung, K. and Y. Lee, "Content Distribution Network
              Interconnection (CDNI) Requirements",
              draft-ietf-cdni-requirements-00 (work in progress),
              September 2011.

              Nair, R. and K. Ma, "Content Distribution Network
              Interconnection (CDNI) Publisher Use",
              draft-ma-cdni-publisher-use-cases-00 (work in progress),
              March 2011.

              Watson, G., "CDN Interconnect Use Cases",
              draft-ietf-cdni-requirements-02 (work in progress),
              December 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.

Authors' Addresses

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

   Phone: +33 1 45 29 89 46

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


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


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


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

   Kevin Ma
   Azuki Systems
   43 Nagog Park
   Acton,   MA 01720

   Phone: +1 978 844 5100