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

Versions: 00 01 02 draft-ietf-cdni-problem-statement

Network Working Group                                   B. Niven-Jenkins
Internet-Draft                                  Velocix (Alcatel-Lucent)
Intended status: Informational                            F. Le Faucheur
Expires: June 5, 2011                                              Cisco
                                                                N. Bitar
                                                                 Verizon
                                                        December 2, 2010


 Content Distribution Network Interconnection (CDNI) Problem Statement
                draft-jenkins-cdni-problem-statement-00

Abstract

   Content Delivery Networks (CDNs) provide numerous benefits: reduced
   delivery cost for cacheable content, improved quality of experience
   for end users and increased robustness of delivery.  For these
   reasons they are frequently used for large-scale content delivery.
   As a result, existing CDN providers are scaling up their
   infrastructure and many Network Service Providers (NSPs) are
   deploying their own CDNs.  It is generally desirable that a given
   content item can be delivered to an end user regardless of that
   user's location or attachment network.  This creates a requirement
   for interconnecting standalone CDNs so they can interoperate as an
   open content delivery infrastructure for the end-to-end delivery of
   content from Content Service Providers (CSPs) to end users.  However,
   no standards or open specifications currently exist to facilitate
   such CDN interconnection.

   The goal of this document is to outline the problem area for the IETF
   with a view towards creating a working group.  This working group
   would work on interoperable and scalable solutions for CDN
   interconnection.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-



Niven-Jenkins, et al.     Expires June 5, 2011                  [Page 1]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


   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 June 5, 2011.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




























Niven-Jenkins, et al.     Expires June 5, 2011                  [Page 2]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  CDN Background . . . . . . . . . . . . . . . . . . . . . .  6
   2.  CDN Interconnect Use Cases . . . . . . . . . . . . . . . . . .  6
   3.  Gap Analysis of relevant Standardization Activities  . . . . .  7
     3.1.  IETF Concluded CDI Working Group . . . . . . . . . . . . .  7
     3.2.  IRTF P2P Research Group  . . . . . . . . . . . . . . . . .  8
     3.3.  ETSI . . . . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.1.  TISPAN . . . . . . . . . . . . . . . . . . . . . . . .  9
       3.3.2.  MCD  . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.4.  ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . . .  9
     3.5.  Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . . . 10
     3.6.  ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.7.  OCEAN  . . . . . . . . . . . . . . . . . . . . . . . . . . 10
     3.8.  CableLabs VoD Metadata . . . . . . . . . . . . . . . . . . 11
   4.  CDN Interconnect Problem Area for IETF . . . . . . . . . . . . 11
     4.1.  Candidate CDNI Goals for IETF  . . . . . . . . . . . . . . 13
     4.2.  Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 14
   5.  Relationship to relevant IETF Working Group  . . . . . . . . . 15
     5.1.  ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
   6.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 15
   7.  Security Considerations  . . . . . . . . . . . . . . . . . . . 16
   8.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 16
   9.  References . . . . . . . . . . . . . . . . . . . . . . . . . . 16
     9.1.  Normative References . . . . . . . . . . . . . . . . . . . 16
     9.2.  Informative References . . . . . . . . . . . . . . . . . . 16
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 17






















Niven-Jenkins, et al.     Expires June 5, 2011                  [Page 3]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


1.  Introduction

   The volume of video and multimedia content delivered over the
   Internet is rapidly increasing and expected to continue doing so in
   the future.  In the face of this growth, Content Delivery Networks
   (CDNs) provide numerous benefits: reduced delivery cost for cacheable
   content, improved quality of experience for end users and increased
   robustness of delivery.  For these reasons CDNs are frequently used
   for large-scale content delivery.  As a result, existing CDN
   providers are scaling up their infrastructure and many Network
   Service Providers (NSPs) are deploying their own CDNs.  It is
   generally desirable that a given content item can be delivered to an
   end user regardless of that user's location or attachment network.
   This creates a requirement for interconnecting standalone CDNs so
   they can interoperate as an open content delivery infrastructure for
   the end-to-end delivery of content from Content Service Providers
   (CSPs) to end users.  However, no standards or open specifications
   currently exist to facilitate such CDN interconnection.

   The goal of this document is to outline the problem area for the IETF
   with a view towards creating a working group.  This working group
   would work on interoperable and scalable solutions for CDN
   interconnection.

1.1.  Terminology

   This document uses the following terms:

   Content: Any form of digital data.  One important form of Content
   with additional constraints on Distribution and Delivery is
   continuous media (i.e. where there is a timing relationship between
   source and sink).

   Metadata: Metadata in general is data about data.

   Content Metata: this is metadata about content.  It may vary in depth
   from merely identifying the content (e.g. title or other information
   to populate a program guide), to providing a complete index of
   different scenes in a movie or providing business rules detailing how
   the content may be displayed, copied, or sold and it can include
   policies to control the distribution and delivery of the content.

   Content Distribution Metadata: Content Distribution Metadata is the
   subset of the Metadata pertaining to rules that control how the
   content is to be distributed and delivered by CDNs.

   User: The 'real' user of the system, typically a human but maybe some
   combination of hardware and/or software emulating a human (e.g. for



Niven-Jenkins, et al.     Expires June 5, 2011                  [Page 4]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


   automated quality monitoring etc.)

   Network Service Provider (NSP): Provides network-based connectivity/
   services to Users.

   Content Service Provider (CSP): Provides a Content Service 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 Content Service Provider.
   The Content Service encompasses the complete service which may be
   wider than just the delivery of items of Content, e.g. the Content
   Service also includes any middleware, 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 content network elements are arranged
   for more effective delivery of content to User Agents.  Typically a
   CDN consists of a Request Routing system, a Distribution System and a
   set of Surrogates.

   CDN Provider: The service provider who operates a CDN.

   CDN Interconnect (CDNI): The set of interfaces over which two or more
   CDNs communicate with each other in order to achieve the delivery of
   content to users by surrogates in one CDN (the downstream CDN) on
   behalf of another CDN (the upstream CDN).

   Over-the-top (OTT): A service, e.g. a CDN, operated over the Internet
   rather than by a particular NSP.

   Surrogate: A device/function that interacts with other elements of
   the CDN for the control and distribution of Content within the CDN
   and interacts with User Agents for the delivery of the Content.

   Request Routing System: The function within a CDN responsible for
   steering or directing a content request received directly from an end
   user to a suitable Surrogate.

   Distribution System: the function within a CDN responsible for
   distributing Content Distribution Metadata as well as content inside
   the CDN (e.g. down to the surrogates)

   Delivery: the function within CDN surrogates responsible for
   delivering a piece of content to the end user.  For example, delivery
   may be based on HTTP progressive download or HTTP adaptive streaming.




Niven-Jenkins, et al.     Expires June 5, 2011                  [Page 5]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


   Logging System: the function within a CDN responsible for collecting
   measurement and recording of distribution and delivery activities.
   The information recorded by the logging system may be used for
   various purposes including charging (e.g. of the CSP), analytics and
   monitoring.

1.2.  CDN Background

   Readers are assumed to be familiar with the architecture, features
   and operation of CDNs.  For readers less familiar with the operation
   of CDNs, the following resources may be useful:

   o  RFC 3040 [RFC3040] describes many of the component technologies
      that are used in the construction of a CDN
   o  Taxonomy [TAXONOMY] compares the architecture of a number of CDNs
   o  RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the
      IETF Content Delivery Internetworking (CDI) working group which
      was closed in 2003.

   Note: Some of the terms used in this document are similar to terms
   used the above referenced documents.  When reading this document
   terms should be interpreted as having the definitions provided in
   Section 1.1.


2.  CDN Interconnect Use Cases

   An increasing number of NSPs are deploying CDNs in order to deal
   cost-effectively with the growing usage of on-demand video services
   and other content delivery applications.

   CDNs allow caching of content closer to the edge so that a given item
   of content can be delivered by a CDN surrogate (i.e. a cache) to
   multiple end users without transiting multiple times through the
   network core (i.e from the content origin to the cache).  This
   contributes to bandwidth cost reductions for the NSP.  CDNs also
   enable replication of popular content across many surrogates, which
   enables content to be served to large numbers of users concurrently.
   This also helps dealing with situations such as flash crowds and
   denial of service attacks.

   The CDNs deployed by NSPs are not just restricted to the delivery of
   content to support the Network Service Provider's own 'walled garden'
   services, such as delivery of IPTV services to Set Top Boxes, but are
   also used for delivery of content to other devices including PCs,
   tablets, mobile phones etc.

   Traditional CDNs have operated as over-the-top providers of digital



Niven-Jenkins, et al.     Expires June 5, 2011                  [Page 6]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


   content distribution services, operating as an overlay on the
   Internet.  More recently, Network Service Providers have begun to
   operate their own CDNs by deploying CDN devices within their network
   infrastructure.

   Some service providers operate over multiple geographies and federate
   multiple affiliate NSPs.  These NSPs typically operate independent
   CDNs.  As they evolve their services (e.g. for seamless support of
   content services to nomadic users across affiliate NSPs) there is a
   need for interconnection of these CDNs.  However there are no open
   specifications, nor common best practices, defining how to achieve
   such CDN interconnection.

   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.  Some NSPs
   are considering interconnecting their respective CDNs (as well as
   possibly over-the-top CDNs) so that this collective infrastructure
   can address the requirements of CSPs in a cost effective manner.  In
   particular, this would enable the CSPs to benefit from on-net
   delivery (i.e. within the Network Service Provider's own network/CDN
   footprint) whenever possible and off-net delivery otherwise without
   requiring the CSPs having to maintain direct business relationships
   with all the CDNs involved in the delivery.  Again, for this
   requirement, CDN operators (NSPs or over-the-top) are faced with a
   lack of open specifications and best practices.

   Finally, NSPs have often deployed CDNs as specialized cost-reduction
   projects within the context of a particular service or environment,
   some NSPs operate separate CDNs for separate services.  For example,
   there may be a CDN for managed IPTV service delivery, a CDN for
   web-TV delivery and a CDN for video delivery to Mobile terminals.  As
   NSPs integrate their service portfolio, there is a need for
   interconnecting these CDNs.  Again, NSPs face the problem of lack of
   open interfaces for CDN interconnection.


3.  Gap Analysis of relevant Standardization Activities

3.1.  IETF Concluded CDI Working Group

   The Content Distribution Internetworking (CDI) Working Group was
   formed in the IETF following a BoF in December 2000 and closed in mid
   2003.

   For convenience, here is an extract from the CDI WG charter
   [CDI-Charter]:



Niven-Jenkins, et al.     Expires June 5, 2011                  [Page 7]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


   "

   o  The goal of this working group is to define protocols to allow the
      interoperation of separately-administered content networks.
   o  A content network is an architecture of network elements, arranged
      for efficient delivery of digital content.  Such content includes,
      but is not limited to, web pages and images delivered via HTTP,
      and streaming or continuous media which are controlled by RTSP.
   o  The working group will first define requirements for three modes
      of content internetworking: interoperation of request-routing
      systems, interoperation of distribution systems, and
      interoperation of accounting systems.  These requirements are
      intended to lead to a follow-on effort to define protocols for
      interoperation of these systems.
   o  In its initial form, the working group is not chartered to deliver
      those protocols [...]

   "

   Thus, the CDI WG touched on the same problem space as the present
   document.

   The CDI WG published 3 Informational RFCs:

   o  RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)".
   o  RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing
      Mechanisms".
   o  RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios".

   Although the market, design and requirements placed on CDNs has
   changed since 2003, the RFCs above provide a reasonable starting
   point and framework for discussing CDN Interconnect.

   However, in accordance with its initial charter, the CDI WG did not
   define any protocols or interfaces to actually enable CDN
   Interconnection and at that time (2003) there was not enough industry
   interest and real life requirements to justify rechartering the WG to
   conduct the corresponding protocol work.

3.2.  IRTF P2P Research Group

   Some information on CDN interconnection motivations and technical
   issues were presented in the P2P RG at IETF 77.  The presentation can
   be found in [P2PRG-CDNI].







Niven-Jenkins, et al.     Expires June 5, 2011                  [Page 8]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


3.3.  ETSI

   ETSI is the European Telecommunications Standards Institute.  ETSI
   produces standards for Information and Communications Technologies
   (ICT), including fixed, mobile, radio, converged, broadcast and
   internet technologies.

3.3.1.  TISPAN

   TISPAN (Telecommunications and Internet converged Services and
   Protocols for Advanced Networking) is an ETSI technical committee
   creating Next Generation Networks (NGN) specifications.

   TISPAN has published two IPTV specifications, one of which is based
   on IMS.  An extension of these specifications is being designed with
   a CDN architecture supporting VoD for delivery to TISPAN devices
   (UEs) or regular PCs.  The use cases allow for hierarchically and
   geographically distributed CDN scenarios, along with multi-CDN
   cooperation.  As a result, the architecture contains reference points
   to support interconnection of other TISPAN CDNs.  There is no intent
   to support heterogeneous interconnection at this point.  Also, this
   effort is focusing on managed IPTV services.

   The protocols phase has not yet started, and thus no protocols have
   yet been defined.

3.3.2.  MCD

   MCD (Media Content Distribution) is the ETSI technical committee "in
   charge of guiding and coordinating standardization work aiming at the
   successful overall development of multimedia systems (television and
   communication) responding to the present and future market requests
   on media content distribution".

   MCD created a specific work item on interconnection of heterogeneous
   CDNs ("CDN Interconnection, use cases and requirements") in March
   2010.  However, no protocol level work has yet started in MCD for CDN
   Interconnect.

3.4.  ATIS IIF

   ATIS ([ATIS]) is the Alliance for Telecommunications Industry
   Solutions.

   IIF is the IPTV Interoperability Forum (within ATIS) that develops
   requirements, standards, and specifications for IPTV.

   The IIF is developing the "IPTV Content on Demand (CoD) Service"



Niven-Jenkins, et al.     Expires June 5, 2011                  [Page 9]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


   specification.  This includes use of a CDN (referred to in ATIS IIF
   CoD as the "Content Distribution and Delivery Functions") for support
   of a Content on Demand (CoD) Service as part of a broader IPTV
   service.  However, this only covers the case of a managed IPTV
   service (in particular where the CDN is administered by the IPTV
   service provider) and does not cover the use, or interconnection, of
   multiple CDNs.

   The "IPTV Content on Demand (CoD) Service" specification defines a
   reference point (C2) and the corresponding HTTP-based data plane
   protocol for content acquisition between an authoritative origin
   server and the CDN.  While this protocol has not been explicitly
   specified for content acquisition across CDNs, it could be a
   candidate (in addition to others such as standard HTTP) for content
   acquisition between CDNs in a CDN Interconnect environment.

3.5.  Open IPTV Forum (OIPF)

   "The Open IPTV Forum has developed an end-to-end solution to allow
   any consumer end-device, compliant to the Open IPTV Forum
   specifications, to access enriched and personalised IPTV services
   either in a managed or a non-managed network.  To that end, the Open
   IPTV Forum focuses on standardising the user-to-network interface
   (UNI) both for a managed and a non-managed network" [OIPF-Overview].

   OIPF has defined specifications for Content Metadata, however they
   specify a definition for IPTV service related metadata and do not
   include a metadata definition or interface that could be used between
   CDNs.

3.6.  ITU-T

   Text to be added in a future version of this document.

3.7.  OCEAN

   OCEAN (http://www.ict-ocean.eu/) is an EU funded research project
   that started in February 2010.  Some of its objectives are relevant
   to CDNI, for example "design a new content delivery framework" and
   "foster multi-vendor solutions", however others are much more
   implementation orientated, e.g. "self-learning caching algorithms"
   and "media-aware congestion control mechanisms".

   OCEAN has not yet defined any protocols for CDN Interconnection.







Niven-Jenkins, et al.     Expires June 5, 2011                 [Page 10]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


3.8.  CableLabs VoD Metadata

   "Founded in 1988 by cable operating companies, Cable Television
   Laboratories, Inc. (CableLabs) is a non-profit research and
   development consortium that is dedicated to pursuing new cable
   telecommunications technologies and to helping its cable operator
   members integrate those technical advancements into their business
   objectives."  [CableLabs]

   Cable Labs has defined specifications for CoD Content Metadata as
   part of its VOD Metadata project.  "The VOD Metadata project is a
   cable television industry and cross-industry-wide effort to specify
   the metadata and interfaces for distribution of video-on-demand (VOD)
   material from multiple content providers to cable operators."
   [CableLabs-Metadata]

   However, while the CableLabs work specifies an interface between a
   content provider and a service provider running a CDN, it does not
   include an interface that could be used between CDNs.


4.  CDN Interconnect Problem Area for IETF

   Interconnecting CDNs involves many different functions and components
   being integrated to some degree.  Only some of those require
   standardization.  Out of those, only some fit within the expertise
   and charter of the IETF.  The problem area proposed for IETF work is
   illustrated in Figure 1.  The candidate goals (and respectively the
   non-goals) for IETF work on CDN Interconnection are discussed in
   Section 4.1 (and respectively Section 4.2 ).





















Niven-Jenkins, et al.     Expires June 5, 2011                 [Page 11]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


      --------
     /        \
     |   CSP  |
     \        /
      --------
          *
          *
          *                        /\
          *                       /  \
      ---------------------      |CDNI|       ---------------------
     /    Upstream CDN     \     |    |      /   Downstream CDN    \
     |     +-------------+ |   Control API   | +-------------+     |
     |     |CDNI Control |<======|====|=======>| CDNI Control|     |
     |     +------*-*-*--+ |     |    |      | +-*-*-*-------+     |
     |            * * *    |     |    |      |   * * *             |
     |     +------*------+ |   Logging API   | +-----*-------+     |
     | ****| Logging     |<======|====|=======>|  Logging    |**** |
     | *   --------------+ |     |    |      | +-------------+   * |
     | *            * *    |     |    |      |   * *             * |
     | *   +--------*----+ | Req-Routing API | +---*---------+   * |
     | * **|Req-Routing  |<======|====|=======>| Req-Routing |** * |
     | * * +-------------+ |     |    |      | +-------------+ * * |
     | * *            *    |     |    |      |   *             * * |
     | * * +----------*--+ | CD Metadata API | +-*-----------+ * * |
     | * * |Distribution |<======|====|=======>| Distribution| * * |
     | * * |             | |      \  /       | |             | * * |
     | * * |             | |       \/        | |             | * * |
     | * ****+---------+ | |                 | | +---------+**** * |
     | ******|Surrogate|*************************|Surrogate|****** |
     |     | +---------+ | |   Acquisition   | | +-----*---+ |     |
     |     +-------------+ |                 | +-------*-----+     |
     \                     /                 \         *           /
      ---------------------                   ---------*-----------
                                                       *
                                                       *
                                                    +------+
                                                    | user |
                                                    +------+

   <==>  interfaces inside the scope of CDNI

   ****  interfaces outside the scope of CDNI

                        Figure 1: CDNI Problem Area







Niven-Jenkins, et al.     Expires June 5, 2011                 [Page 12]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


4.1.  Candidate CDNI Goals for IETF

   Listed below are parts of the problem space that are proposed to be
   addressed by a potential CDNI working group in the IETF:
   o  Specification of a control plane architecture for CDN
      Interconnect.
   o  Specification of the APIs and protocols required to Interconnect a
      pair of CDNs (where a given CDN may support multiple interconnects
      with different CDNs).  This is expected to comprise (but possibly
      grouped in a different manner):
      *  CDNI Control API: This API allows the "CDNI Control" system in
         interconnected CDNs to communicate.  This API may support the
         following:
         +  allows an upstream CDN and downstream CDN to establish,
            update or terminate their CDNI relationship
         +  allows bootstrapping of the other CDNI APIs (e.g.  API
            address discovery and establishment of security
            associations)
         +  allows configuration of the other CDNI APIs (e.g.  Upstream
            CDN specifies information to be reported through the Logging
            API)
         +  allows the downstream CDN to communicate information about
            its delivery capabilities, resources and policies
         +  allows bootstrapping of the interface between CDNs for
            content acquisition (even if that interface itself is
            outside the scope of the CDNI work)
      *  Request-Routing API: This API allows the Request-Routing system
         in interconnected CDNs to communicate to ensure that an end-
         user request can be (re)directed from an upstream CDN to a
         surrogate in the downstream CDN, in particular where selection
         responsibilities may be split across CDNs (for example the
         upstream CDN may be responsible for selecting the downstream
         CDN while the downstream CDN may be responsible for selecting
         the actual surrogate within that CDN).
      *  Content Distribution Metadata Signaling API: This API allows
         the Distribution system in interconnected CDNs to communicate
         to ensure content distribution metadata can be exchanged across
         CDNs.  For example, the distribution metadata information may
         include information about desired distribution policy (e.g.
         prepositioning vs dynamic acquisition) and about content access
         policy (e.g. allowed/blocked time/geography, authorization
         checks to be performed at delivery time).  It may also contain
         information about where/how to acquire the content.  This may
         also include content management (e.g. deletion of Content from
         caches) across interconnected CDNs.  It is expected that the
         specification of this API will comprise (i) specification of a
         schema for Content Distribution Metadata as well as (ii)
         specification/selection of a signaling protocol (quite possibly



Niven-Jenkins, et al.     Expires June 5, 2011                 [Page 13]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


         an existing IETF protocol) to signal the actual Content
         Distribution Metadata encoded as per the schema.
      *  Logging API: This API allows the Logging system in
         interconnected CDNs to communicate the relevant activity logs
         in order to allow log consuming applications to operate in a
         multi-CDN environments.  For example, an upstream CDN may
         collect delivery logs from a downstream CDN in order to perform
         consolidated charging of the CSP.  Similarly, an upstream CDN
         may collect delivery logs from a downstream CDN in order to
         provide consolidated reporting and monitoring to the CSP.
   o  Scalability of the CDNI protocols & approach.

4.2.  Non-Goals for IETF

   Listed below are aspects of content delivery that the authors propose
   be kept outside of the scope of a potential CDNI working group:
   o  The interface between Content Service Provider and the
      Authoritative CDN (i.e. the upstream CDN contracted by the CSP for
      delivery by this CDN or by its downstream CDNs).
   o  The delivery interface between the delivering CDN surrogate and
      the enduser, such as streaming protocols.
   o  The content acquisition interface between CDNs (i.e. the dataplane
      interface for actual delivery of a piece of content from one CDN
      to the other).  This is expected to use existing protocols such as
      HTTP or protocols defined in other forums for content acquisition
      between an origin server and a CDN (e.g.  HTTP-based C2 reference
      point of ATIS IIF CoD).
   o  User Authentication.  User authentication and authorization are
      the responsibility of the Content Service Provider.
   o  Content preparation, including encoding and transcoding.  The CDNI
      architecture aims at allowing distribution across interconnected
      CDNs of content treated as opaque objects.  Interpretation and
      processing of the objects, as well as optimised delivery of these
      objects by the surrogate to the enduser are outside the scope of
      CDNI.
   o  Digital Right Management (DRM).  DRM is an end-to-end issue
      between Origin and User-Agent.
   o  applications consuming CDNI logs (e.g. charging, analytics,
      reporting,...)
   o  Internal CDN Protocols. i.e. protocols within one CDN.
   o  Scalability of individual CDNs.  While scalability of the CDNI
      protocols/approach is in scope, how an individual CDN scales is
      out of scope.
   o  actual criteria and algorithms for selection of CDN or Surrogate
      by Request-Routing systems.
   o  Surrogate algorithms - e.g. how to acquire content or cache
      replacement algorithms.  Content management (e.g.  Content
      Deletion) is in scope but the internal algorithms used by a cache



Niven-Jenkins, et al.     Expires June 5, 2011                 [Page 14]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


      to determine when to no longer cache an item of Content (in the
      absence of any specific metadata to the contrary) is out of scope.
   o  Element management interfaces
   o  commercial, business and legal aspects related to the
      interconnections of CDNs.


5.  Relationship to relevant IETF Working Group

5.1.  ALTO

   As stated in the ALTO Working Group charter [ALTO-Charter]:

   "The Working Group will design and specify an Application-Layer
   Traffic Optimization (ALTO) service that will provide applications
   with information to perform better-than-random initial peer
   selection.  ALTO services may take different approaches at balancing
   factors such as maximum bandwidth, minimum cross-domain traffic,
   lowest cost to the user, etc.  The WG will consider the needs of
   BitTorrent, tracker-less P2P, and other applications, such as content
   delivery networks (CDN) and mirror selection."

   In particular, the ALTO service could be used by a CDN Request
   Routing system to improve its selection of a CDN surrogate to serve a
   particular user request.  See [I-D.penno-alto-cdn] for a detailed
   discussion on how CDN Request Routing can be used as an integration
   point of ALTO into CDNs.  It is possible that the ALTO service could
   be used in the same manner in a multi-CDN environment based on CDN
   Interconnect.  For example, an upstream CDN may take advantage of the
   ALTO service in its decision for selecting a downstream CDN to which
   a user request should be delegated.

   However, the work of ALTO is complementary to and does not overlap
   with the work proposed in this document because the integration
   between ALTO and a CDN would fall under "algorithms for selection of
   CDN or Surrogate by Request-Routing systems" in Section 4.2


6.  IANA Considerations

   This document makes no request of IANA.

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







Niven-Jenkins, et al.     Expires June 5, 2011                 [Page 15]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


7.  Security Considerations

   This document describes a problem faced by CDN Providers and does not
   itself introduce any new security considerations.

   However, maintaining the security of the content itself, its
   associated metadata (including distribution and delivery policies)
   and the CDNs distributing and delivering it are critical requirements
   for both CDN Providers and their customers and any work on CDN
   Interconnection must provide sufficient mechanisms to maintain the
   security of the overall system of interconnected CDNs as well as the
   information (content, metadata, logs, etc) distributed and delivered
   through any CDN Interconnects.


8.  Acknowledgements

   The authors would like to thank David Ferguson, Julien Maisonneuve,
   Mahesh Viveganandhan and Bruce Davie for their early review comments
   and contributions to the text.


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

   [ALTO-Charter]
              "IETF ALTO WG Charter
              (http://datatracker.ietf.org/wg/alto/charter/)".

   [ATIS]     "ATIS (http://www.atis.org/)".

   [CDI-Charter]
              "IETF CDI WG Charter
              (http://www.ietf.org/wg/concluded/cdi)".

   [CableLabs]
              "CableLabs (http://www.cablelabs.com/about/)".

   [CableLabs-Metadata]
              "CableLabs VoD Metadata Project Primer
              (http://www.cablelabs.com/projects/metadata/primer/)".




Niven-Jenkins, et al.     Expires June 5, 2011                 [Page 16]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


   [I-D.penno-alto-cdn]
              Penno, R., Raghunath, S., Medved, J., Alimi, R., Yang, R.,
              and S. Previdi, "ALTO and Content Delivery Networks",
              draft-penno-alto-cdn-02 (work in progress), October 2010.

   [OIPF-Overview]
              "OIPF Release 2 Specification Volume 1 - Overview",
              September 2010.

   [P2PRG-CDNI]
              Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka
              "Peering Peer-to-Peer"
              (http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)",
              March 2010.

   [RFC3040]  Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
              Replication and Caching Taxonomy", RFC 3040, January 2001.

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

   [TAXONOMY]
              Pathan, A., "A Taxonomy and Survey of Content Delivery
              Networks
              (http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007.


Authors' Addresses

   Ben Niven-Jenkins
   Velocix (Alcatel-Lucent)
   326 Cambridge Science Park
   Milton Road, Cambridge  CB4 0WG
   UK

   Email: ben@velocix.com







Niven-Jenkins, et al.     Expires June 5, 2011                 [Page 17]


Internet-Draft    CDN Interconnection Problem Statement    December 2010


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

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


   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA  02145
   USA

   Email: nabil.bitar@verizon.com


































Niven-Jenkins, et al.     Expires June 5, 2011                 [Page 18]


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