Network Working Group                                   B. Niven-Jenkins
Internet-Draft                                  Velocix (Alcatel-Lucent)
Intended status: Informational                            F. Le Faucheur
Expires: July 24, September 11, 2012                                        Cisco
                                                                N. Bitar
                                                                 Verizon
                                                        January 21,
                                                          March 10, 2012

 Content Distribution Network Interconnection (CDNI) Problem Statement
                  draft-ietf-cdni-problem-statement-03
                  draft-ietf-cdni-problem-statement-04

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 End
   User's location or attachment network.  This creates a requirement is the motivation 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 of CDN
   interconnection for the IETF CDNI (CDN Interconnection) working
   group.

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 July 24, September 11, 2012.

Copyright Notice

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

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

Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  CDN Background . . . . . . . . . . . . . . . . . . . . . .  8
   2.  CDN Interconnection Use Cases  . . . . . . . . . . . . . . . .  9
   3.  CDN Interconnection Model & Problem Area for IETF  . . . . . . 10
   4.  Design Approach for Realizing  Scoping the CDNI Interfaces  . Problem . . . . . 14
     4.1.  CDNI Request Routing Interface . . . . . . . . . . . . . . 15
     4.2. 14
     4.1.  CDNI Metadata Request Routing Interface . . . . . . . . . . . . . . . . . 17
     4.3. 14
     4.2.  CDNI Logging Metadata Interface  . . . . . . . . . . . . . . . . . . 18
     4.4. 15
     4.3.  CDNI Control Logging Interface . . . . . . . . . . . . . . . . . . 19
   5.  Relevant work from other standardization activities  . . . . . 19
     5.1.  Content Acquisition across CDNs and Delivery to End
           User (Data plane)  . . . . . . . . . . . . . . . . . . . . 20
     5.2. 16
     4.4.  CDNI Metadata  . . . . . Control Interface . . . . . . . . . . . . . . . . . 21
   6.  Relationship to relevant IETF Working Groups . 16
   5.  IANA Considerations  . . . . . . . . 22
     6.1.  ALTO . . . . . . . . . . . . . 16
   6.  Security Considerations  . . . . . . . . . . . . . . 22
     6.2.  DECADE . . . . . 16
   7.  Acknowledgements . . . . . . . . . . . . . . . . . . . . . 23
     6.3.  PPSP . . 17
   8.  References . . . . . . . . . . . . . . . . . . . . . . . . . 24
   7.  IANA Considerations . 17
     8.1.  Normative References . . . . . . . . . . . . . . . . . . . 17
     8.2.  Informative References . 25
   8.  Security Considerations . . . . . . . . . . . . . . . . . 17
   Appendix A.  Design considerations for realizing the CDNI
                Interfaces  . . 25
   9.  Acknowledgements . . . . . . . . . . . . . . . . . . . 19
     A.1.  CDNI Request Routing Interface . . . . 25
   10. References . . . . . . . . . . 19
     A.2.  CDNI Metadata Interface  . . . . . . . . . . . . . . . . 25
     10.1. Normative References . 21
     A.3.  CDNI Logging Interface . . . . . . . . . . . . . . . . . . 25
     10.2. Informative References 22
     A.4.  CDNI Control Interface . . . . . . . . . . . . . . . . . . 25 23
   Appendix A. B.  Additional Material . . . . . . . . . . . . . . . . . 28
     A.1. 24
     B.1.  Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 28
     A.2. 24
     B.2.  Related standardization activities activites  . . . . . . . . . . . . 29
       A.2.1. 25
       B.2.1.  IETF CDI Working Group (Concluded) . . . . . . . . . . 29
       A.2.2. 26
       B.2.2.  3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 30
       A.2.3. 27
       B.2.3.  ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 31
       A.2.4. 28
       B.2.4.  ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 31
       A.2.5. 28
       B.2.5.  CableLabs  . . . . . . . . . . . . . . . . . . . . . . 31
       A.2.6. 29
       B.2.6.  ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 32
       A.2.7. 29
       B.2.7.  ETSI TISPAN  . . . . . . . . . . . . . . . . . . . . . 32
       A.2.8. 29
       B.2.8.  ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . 32
       A.2.9. 29
       B.2.9.  Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 33
       A.2.10. 30
       B.2.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 33
       A.2.11. 30
       B.2.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 33
     A.3. 30
       B.2.12. Summary of existing stanardization work  . . . . . . . 31
     B.3.  Related Research Projects  . . . . . . . . . . . . . . . . 34
       A.3.1. 33
       B.3.1.  IRTF P2P Research Group  . . . . . . . . . . . . . . . 34
       A.3.2. 33
       B.3.2.  OCEAN  . . . . . . . . . . . . . . . . . . . . . . . . 34
       A.3.3. 33
       B.3.3.  Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses 33
     B.4.  Relationship to relevant IETF Working Groups . . . . . . . 33
       B.4.1.  ALTO . . . . . . . . . . . . . . . . . 34

1.  Introduction

   The volume of video and multimedia content delivered over the
   Internet is rapidly increasing and . . . . . . . . 33
       B.4.2.  DECADE . . . . . . . . . . . . . . . . . . . . . . . . 34
       B.4.3.  PPSP . . . . . . . . . . . . . . . . . . . . . . . . . 35
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36

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 End User's location or attachment
   network.  However, a given CDN in charge of delivering a given
   content may not have a footprint that expands close enough to the End
   User's current location or attachment network, or may not have the
   necessary resources, to realize the user experience and cost benefit
   that a more distributed CDN infrastructure would allow.  This creates
   a requirement is the
   motivation for interconnecting standalone CDNs so that their
   collective CDN footprint and resources can be leveraged for the end-
   to-end delivery of content from Content Service Providers (CSPs) to
   End Users.  As an example, a CSP could contract with an
   "authoritative" CDN Provider for the delivery of content and that
   authoritative CDN Provider could contract with one or more downstream
   CDN Provider(s) to distribute and deliver some or all of the content
   on behalf of the authoritative CDN Provider.  The formation and
   details of any business relationships between a CSP and a CDN
   Provider and between one CDN Provider and another CDN Provider are
   out of scope of this document.  However, no standards or open
   specifications currently exist to facilitate such CDN
   interconnection.

   The goal of this document is to outline the problem area of CDN
   interconnection for the IETF CDNI (CDN Interconnection) working
   group.
   interconnection.  Section 2 discusses the use cases for CDN
   interconnection.  Section 3 presents the CDNI model and problem area
   being considered by the IETF.  Section 4 describes each CDNI
   interface individually and highlights example candidate protocols
   that could be considered for reuse or leveraging to implement the
   CDNI interfaces.  Section 5  Appendix B.2 discusses the relevant work of other
   standards organizations.
   Section 6  Appendix B.4 describes the relationships
   between the CDNI problem space and other relevant IETF Working
   Groups.

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 Metadata: This is metadata about Content.  Content Metadata
   comprises:

   1.  Metadata that is relevant to the distribution of the content (and
       therefore relevant to a CDN involved in the delivery of that
       content).  We refer to this type of metadata as "Content
       Distribution Metadata".  See also the definition of Content
       Distribution Metadata.
   2.  Metadata that is associated with the actual Content or content
       representation, and not directly relevant to the distribution of
       that Content.  For example, such metadata may include information
       pertaining to the Content's genre, cast, rating, etc as well as
       information pertaining to the Content representation's
       resolution, aspect ratio, etc.

   Content Distribution Metadata: The subset of Content Metadata that is
   relevant to the distribution of the content.  This is the metadata
   required by a CDN in order to enable and control content distribution
   and delivery by the CDN.  In a CDN Interconnection environment, some
   of the Content Distribution Metadata may have an intra-CDN scope (and
   therefore need not be communicated between CDNs), while some of the
   Content Distribution Metadata may have an inter-CDN scope (and
   therefore needs to be communicated between CDNs).

   CDNI Metadata: Content Distribution Metadata with inter-CDN scope.
   For example, CDNI Metadata may include geo-blocking information (i.e.
   information defining geographical areas where the content is to be
   made available or blocked), availability windows (i.e. information
   defining time windows during which the content is to be made
   available or blocked) and access control mechanisms to be enforced
   (e.g.  URI signature validation).  CDNI Metadata may also include
   information about desired distribution policy (e.g. prepositioned vs
   dynamic acquisition) and about where/how a CDN can acquire the
   content.  CDNI Metadata may also include content management
   information (e.g. request for deletion of Content from Surrogates)
   across interconnected CDNs.

   Dynamic content acquisition: Dynamic content acquisition is where a
   CDN acquires content from the content source in response to an End
   User requesting that content from the CDN.  In the context of CDN
   Interconnection, dynamic acquisition means that a downstream CDN
   acquires the content from content sources (including upstream CDNs)
   at some point in time after a request for that content is delegated
   to the downstream CDN by an Upstream CDN (and that specific content
   is not yet available in the downstream CDN).

   Dynamic CDNI metadata acquisition: In the context of CDN
   Interconnection, dynamic CDNI metadata acquisition means that a
   downstream CDN acquires CDNI metadata for content from the upstream
   CDN at some point in time after a request for that content is
   delegated to the downstream CDN by an Upstream CDN (and that specific
   CDNI metadata is not yet available in the downstream CDN).

   Pre-positioned content acquisition: Content Pre-positioning is where
   a CDN acquires content from the content source prior to, or
   independently of, any End User requesting that content from the CDN.
   In the context of CDN interconnection the Upstream CDN instructs the
   Downstream CDN to acquire the content from content sources (including
   upstream CDNs) in advance of or independent of any End User
   requesting it.

   Pre-positioned CDNI Metadata acquisition: In the context of CDN
   Interconnection, CDNI Metadata pre-positioning is where the
   Downstream CDN acquires CDNI metadata for content prior to or
   independent of any End User requesting that content from the
   Downstream CDN.

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

   User Agent (UA): Software (or a combination of hardware and software)
   through which the End User interacts with a Content Service.  The
   User Agent will communicate with a Content Service for the selection
   of content and one or more CDNs for the delivery of the Content.
   Such communication is not restricted to HTTP and may be via a variety
   of protocols.  Examples of User Agents (non-exhaustive) are:
   Browsers, Set Top Boxes (STBs), dedicated content applications (e.g.
   media players), etc.

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

   Content Service Provider (CSP): Provides a Content Service to End
   Users (which they access via a User Agent).  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 providing access to 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, or CDNs, involved in the distribution and delivery of the
   content.

   Content Distribution Network (CDN) / Content Delivery Network (CDN):
   Network infrastructure in which the network elements cooperate at
   layers 4 through layer 7 for more effective delivery of Content to
   User Agents.  Typically a CDN consists of a Request Routing system, a
   Distribution System (that includes a set of Surrogates), a Logging
   System and a CDN control system.

   CDN Provider: The service provider who operates a CDN and offers a
   service of content delivery, typically used by a Content Service
   Provider or another CDN Provider.  Note that a given entity may
   operate in more than one role.  For example, a company may
   simultaneously operate as a Content Service Provider, a Network
   Service Provider and a CDN Provider.

   CDN Interconnection (CDNI): A relationship between a pair of CDNs
   that enables one CDN to provide content delivery services on behalf
   of another CDN.  A CDN Interconnection may be wholly or partially
   realised
   realized through a set of interfaces over which a pair of CDNs
   communicate with each other in order to achieve the delivery of
   content to User Agents by Surrogates in one CDN (the downstream CDN)
   on behalf of another CDN (the upstream CDN).

   Authoritative CDN: A CDN which has a direct relationship with a CSP
   for the distribution & delivery of that CSP's content by the
   authoritative CDN or by downstream CDNs of the authoritative CDN.

   Upstream CDN: For a given End User request, the CDN (within a pair of
   directly interconnected CDNs) that redirects the request to the other
   CDN.

   Downstream CDN: For a given End User request, the CDN (within a pair
   of directly interconnected CDNs) to which the request is redirected
   by the other CDN (the Upstream CDN).  Note that in the case of
   successive redirections (e.g.  CDN1-->CDN2-->CDN3) a given CDN (e.g.
   CDN2) may act as the Downstream CDN for a redirection (e.g.
   CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection
   of the same request (e.g.  CDN2-->CDN3).

   Over-the-top (OTT): A service, e.g. content delivery using a CDN,
   operated by a different operator than the NSP to which the users of
   that service are attached.

   Surrogate: A device/function (often called a cache) 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
   receiving a content request from a User Agent, obtaining and
   maintaining necessary information about a set of candidate surrogates
   or candidate CDNs, and for selecting and redirecting the user to the
   appropriate surrogate or CDN.  To enable CDN Interconnection, the
   Request Routing System must also be capable of handling User Agent
   content requests passed to it by another CDN.

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

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

   Logging System: The function within a CDN responsible for collecting
   the 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.

   Control System: The function within a CDN responsible for
   bootstrapping and controlling the other components of the CDN as well
   as for handling interactions with external systems (e.g. handling
   delivery service creation/update/removal requests, or specific
   service provisioning requests).

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 Interconnection 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 of a network so that
   a given item of content can be delivered by a CDN Surrogate (i.e. a
   cache) to multiple User Agents (and their End Users) without
   transiting multiple times through the network core (i.e from the
   content origin to the surrogate).  This contributes to bandwidth cost
   reductions for the NSP and to improved quality of experience for the
   End Users.  CDNs also enable replication of popular content across
   many surrogates, which enables content to be served to large numbers
   of User Agents 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 IP delivery of television services to Set Top
   Boxes, but are also used for delivery of content to other devices
   including PCs, tablets, mobile phones etc.

   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, that represents a first use
   case for CDNI.  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 numbers of End Users and/or over many/all geographies and/or
   with Users, who are often distributed across a number
   of geographies, while maintaining a high quality of experience, all
   without having to maintain direct business relationships with many
   different CDN Providers (or having to extend their own CDN to a large
   number of locations).  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.  This represents a second use case for
   CDNI.  In particular, this would enable the CSPs to benefit from on-net on-
   net delivery (i.e. within the Network Service Provider's own network/CDN network/
   CDN footprint) whenever possible and off-net delivery otherwise,
   without requiring the CSPs to maintain direct business relationships
   with all the CDNs involved in the delivery.  Again, for this requirement, CDN Providers
   (NSPs or over-the-top CDN operators) are faced with a lack of open
   specifications and best practices.

   NSPs have often deployed CDNs as specialized cost-reduction projects
   within the context of a particular service or environment, some 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, representing a third use case for CDNI.  Again, NSPs face the
   problem of lack of open interfaces for CDN interconnection.

   For operational reasons (e.g. disaster, flash crowd) or commercial
   reasons, an over-the-top CDN may elect to make use of another CDN
   (e.g. an NSP CDN with on-net Surrogates for a given footprint) for
   serving a subset of the user requests (e.g. requests from users
   attached to that NSP), which results in a fourth use case for CDNI.
   Again, for this requirement, CDNI
   because CDN Providers (over-the-top CDN Providers or NSPs) are faced
   with a lack of open specifications and best practices.

   Use cases for CDN Interconnection are further discussed in
   [I-D.ietf-cdni-use-cases].

3.  CDN Interconnection Model & Problem Area for IETF

   This section discusses the problem area for the IETF work on CDN
   Interconnection.

   Interconnecting CDNs involves interactions among multiple different
   functions and components that form each CDN.  Only some of those
   require standardization.  This section discusses the problem area for
   the IETF work on

   Some NSPs have started to perform experiments to explore whether
   their CDN Interconnection.  The CDNI model and problem
   area defined for IETF work use cases can already be addressed with existing CDN
   implementations.  One set of such experiments is illustrated documented in Figure 1.

     --------
    /        \
    |   CSP  |
    \        /
     --------
         *
         *
         *                         /\
         *                        /  \
     ----------------------      |CDNI|        ----------------------
    /     Upstream
   [I-D.bertrand-cdni-experiments].  The conclusions of those
   experiments are that while some basic limited CDN     \     |    |       /    Downstream Interconnection
   functionality can be achieved with existing CDN    \
    |      +-------------+ | Control Interface| +-------------+      |
    |*******   Control   |<======|====|========>|   Control   *******|
    |*     +------*----*-+ |     |    |       | +-*----*------+     *|
    |*            *    *   |     |    |       |   *    *            *|
    |*     +------*------+ | Logging Interface| +------*------+     *|
    |* *****   Logging   |<======|====|========>|   Logging   ***** *|
    |* *   +-*-----------+ |     |    |       | +-----------*-+   * *|
    |* *     *         *   | Request Routing  |   *         *     * *|
  .....*...+-*---------*-+ |    Interface     | +-*---------*-+...*.*...
  . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
  . |* * * +-------------+.|     |    |       | +-------------+ * * *| .
  . |* * *                 .  CDNI Metadata   |                 * * *| .
  . |* * * +-------------+ |.   Interface     | +-------------+ * * *| .
  . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
  . |* * * |             | |  .   \  /        | |             | * * *| .
  . |* * * |+---------+  | |   .   \/         | |  +---------+| * * *| .
  . |* * ***| +---------+| |    ....Request......+---------+ |*** * *| .
  . |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
  . |*******  +---------+| |   Acquisition    | |+----------+ *******| .
  . |      +-------------+ |                  | +-------*-----+      | .
  . \                      /                  \         *            / .
  .  ----------------------                    ---------*------------  .
  .                                                     *              .
  .                                                     * Delivery     .
  .                                                     *              .
  .                                                  +--*---+          .
  ...............Request.............................| User |..Request..
                                                     | Agent|
                                                     +------+

  <==>  interfaces inside technology, the scope
   current lack of any standardized CDNI
  **** interfaces outside with the scope necessary
   level of CDNI
  ....  interfaces outside functionality such as those discussed in this document is
   preventing the scope deployment of CDNI

                           Figure 1: CDNI Model CDN Interconnection.

   Listed below are the four interfaces required to interconnect a pair
   of CDNs and that constitute the problem space that is proposed to be
   addressed by of CDN Interconnection
   along with the required functionality of each interface for which
   standards do not currently exist.  As part of the development of the
   CDNI working group in interfaces it will also be necessary to agree on common
   mechanisms for how to identify and name the IETF. data objects that are to
   be interchanged between interconnected CDNs.

   The use of the term "interface" is meant to encompass the protocol
   over which CDNI data representations (e.g.  CDNI Metadata objects)
   are exchanged as well as the specification of the data
   representations themselves (i.e. what properties/fields each object
   contains, its structure, etc.).

   o  CDNI Control interface: This interface allows the "CDNI Control"
      system in interconnected CDNs to communicate.  This interface may
      support the following:
      *  Allow bootstrapping of the other CDNI interfaces (e.g.
         interface address/URL discovery and establishment of security
         associations).
      *  Allow configuration of the other CDNI interfaces (e.g.
         Upstream CDN specifies information to be reported through the
         CDNI Logging interface).
      *  Allow the downstream CDN to communicate static (or fairly
         static) information about its delivery capabilities and
         policies.
      *  Allow bootstrapping of the interface between CDNs for content
         acquisition (even if that interface itself is outside the scope
         of the CDNI work).
      *  Allow an upstream CDN to initiate or request specific actions
         to be undertaken in the downstream CDN.  For example, this may
         include the following capabilities:
         +  Allow to allow
         an upstream CDN to request that initiate content files and/or or CDNI Metadata that it previously shared, be purged from, or
            invalidated in, a downstream CDN.  Support for content
            deletion
         acquisition (pre-positioning) or invalidation from a CDN is a key requirement for
            some Content Service Providers in order, amongst other use
            cases for content deletion, to support the content rights
            agreements they have negotiated.  Today's CDNs use
            proprietary control interfaces to enable CSPs to remove
            content cached in request the CDN and therefore there is a need to
            have a similar but standardized content deletion capability
            between interconnected CDNs.
         +  Allow an upstream CDN to initiate Pre-positioned invalidation or
         purging of content
            acquisition files and/or Pre-positioned CDNI Metadata acquisition in a downstream
         CDN.
   o  CDNI Request Routing interface: This interface allows the Request
      Routing systems 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 downstream CDN).  In particular, the
      CDN Request Routing interface, may support the following:
      *  Allow the upstream CDN to query the downstream CDN at request
         routing time before redirecting the request to the downstream
         CDN.
      *  Allow the downstream CDN to provide to the upstream CDN (static
         or dynamic) information (e.g. resources, footprint, load) to
         facilitate selection of the downstream CDN by the upstream CDN
         request routing system when processing subsequent content
         requests from User Agents.
   o  CDNI Metadata distribution interface: This interface allows the
      Distribution system in interconnected CDNs to communicate to
      ensure CDNI Metadata can be exchanged across CDNs.  See
      Section 1.1 for definition and examples of CDNI Metadata.
   o  CDNI Logging interface: This interface 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 or for settlement purposes across
      CDNs.  Similarly, an upstream CDN may collect delivery logs from a
      downstream CDN in order to provide consolidated reporting and
      monitoring to the CSP.

   Note that the actual grouping of functionalities under these four
   interfaces is considered tentative at this stage and may be changed
   after further study (e.g. some subset of functionality be moved from
   one interface into another).

   The above list covers a significant potential problem space, in part
   because in order to interconnect two CDNs there are several 'touch
   points' that require standardization.  However, it is expected that
   the CDNI interfaces need not be defined from scratch and instead can
   very significantly reuse or leverage existing protocols: this is
   discussed further in Section 4.  Also, it is expected that the items
   above will be prioritized so

   The interfaces that form the CDNI Working Group can focus
   (at least initially) on the most essential and urgent work.

   As part of the development of the CDNI interfaces and solutions it
   will also be necessary to agree on common mechanisms for how to
   identify and name the data objects that problem area are to be interchanged
   between interconnected CDNs.

   Some NSPs have started to perform experiments to explore whether
   their CDN use cases can already be addressed with existing CDN
   implementations.  One set of such experiments is documented illustrated in
   [I-D.bertrand-cdni-experiments].  The conclusions of those
   experiments are that while some basic limited
   Figure 1.

     --------
    /        \
    |   CSP  |
    \        /
     --------
         *
         *
         *                         /\
         *                        /  \
     ----------------------      |CDNI|        ----------------------
    /     Upstream CDN Interconnection
   functionality can be achieved with existing     \     |    |       /    Downstream CDN technology,    \
    |      +-------------+ | Control Interface| +-------------+      |
    |*******   Control   |<======|====|========>|   Control   *******|
    |*     +------*----*-+ |     |    |       | +-*----*------+     *|
    |*            *    *   |     |    |       |   *    *            *|
    |*     +------*------+ | Logging Interface| +------*------+     *|
    |* *****   Logging   |<======|====|========>|   Logging   ***** *|
    |* *   +-*-----------+ |     |    |       | +-----------*-+   * *|
    |* *     *         *   | Request Routing  |   *         *     * *|
  .....*...+-*---------*-+ |    Interface     | +-*---------*-+...*.*...
  . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
  . |* * * +-------------+.|     |    |       | +-------------+ * * *| .
  . |* * *                 .  CDNI Metadata   |                 * * *| .
  . |* * * +-------------+ |.   Interface     | +-------------+ * * *| .
  . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
  . |* * * |             | |  .   \  /        | |             | * * *| .
  . |* * * |+---------+  | |   .   \/         | |  +---------+| * * *| .
  . |* * ***| +---------+| |    ....Request......+---------+ |*** * *| .
  . |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
  . |*******  +---------+| |   Acquisition    | |+----------+ *******| .
  . |      +-------------+ |                  | +-------*-----+      | .
  . \                      /                  \         *            / .
  .  ----------------------                    ---------*------------  .
  .                                                     *              .
  .                                                     * Delivery     .
  .                                                     *              .
  .                                                  +--*---+          .
  ...............Request.............................| User |..Request..
                                                     | Agent|
                                                     +------+

  <==>  interfaces inside the
   current lack scope of any standardized CDNI interfaces/protocols such as
   those discussed in this document is preventing
  ****  interfaces outside the deployment scope of
   production CDN Interconnection solutions with CDNI
  ....  interfaces outside the scope of CDNI

                Figure 1: A Model for the necessary level of
   functionality. CDNI Problem Area

   As illustrated in Figure 1, the acquisition of content between
   interconnected CDNs is out of scope for CDNI, which deserves some
   additional explanation.  The consequence of such a decision is that
   the CDNI working group problem space described in this document is focussed on only
   defining the control plane for CDNI; and the CDNI data plane (i.e.
   the acquisition & distribution of the actual content objects) will not be addressed by
   the CDNI working group.  The rationale for such a decision is that
   CDNs today typically already use standardized protocols such as HTTP,
   FTP, rsync, etc. to acquire content from their CSP customers and it
   is expected that the same protocols could be used for acquisition
   between interconnected CDNs.  Therefore the problem of content
   acquisition is considered already solved and all that is required
   from specifications developed by the CDNI working group is to
   describe within the CDNI Metadata where to go and which protocol to
   use to retrieve the content.

4.  Design Approach for Realizing the CDNI Interfaces

   This section expands on how CDNI interfaces can reuse and leverage
   existing protocols before describing each CDNI interface individually
   and highlighting example candidate protocols that could be considered
   for reuse or leveraging to implement the CDNI interfaces.  This
   discussion is not intended to pre-empt any working group decision as
   to the most appropriate protocols, technologies and solutions to
   select to realize the CDNI interfaces but is intended as an
   illustration of the fact that the CDNI interfaces need not be created
   in a vacuum and that reuse or leverage out
   of existing protocols is
   likely possible. scope.  The four CDNI interfaces (CDNI Control interface, CDNI Request
   Routing interface, CDNI Metadata interface, CDNI Logging interface)
   described in Section 3 within the CDNI problem area are all control
   plane interfaces operating at the application layer (Layer 7 in the
   OSI network model).  Firstly, since it rationale for such a decision is not expected that these
   interfaces would exhibit unique session, transport or network
   requirements CDNs today
   typically already use standardized protocols such as compared HTTP, FTP,
   rsync, etc. to the many other existing applications in
   the Internet, acquire content from their CSP customers and it is
   expected that the CDNI interfaces will be defined
   on top of existing session, transport and network protocols.

   Secondly, although a new application protocol same protocols could be designed
   specifically used for CDNI we assume that this acquisition
   between interconnected CDNs.  Therefore the problem of content
   acquisition is unnecessary considered already solved and it is
   recommended all that existing application protocols be reused or
   leveraged (HTTP [RFC2616], Atom Publishing Protocol [RFC5023], XMPP

   [RFC6120], for example) to realize is required
   from specifications developed by the CDNI interfaces.

4.1.  CDNI Request Routing Interface

   The CDNI Request Routing interface enables a Request Routing function
   in an upstream CDN to query a Request Routing function in a
   downstream CDN to determine if the downstream CDN working group is able (and
   willing) to accept
   describe within the delegated content request CDNI Metadata where to go and which protocol to allow the
   downstream CDN
   use to control what retrieve the upstream Request Routing function
   should return to content.

4.  Scoping the User Agent in CDNI Problem

   This section outlines how the redirection message.

   Therefore, scope of work addressing the CDNI Request Routing interface needs to offer a
   mechanism for an upstream CDN to issue a "Redirection Request"
   problem space can be constrained through reuse or leveraging of
   existing protocols to a
   downstream CDN.  The Request Routing interface needs implement the CDNI interfaces.  This discussion
   is not intended to be able pre-empt any working group decision as to
   support scenarios where the initial User Agent request most
   appropriate protocols, technologies and solutions to select to
   realize the
   upstream CDN CDNI interfaces but is received over DNS as well intended as over a content specific
   application protocol (e.g.  HTTP, RTSP, RTMP, etc.).

   Therefore a Redirection Request is expected to contain information
   such as:

   o  The protocol (e.g.  DNS, HTTP) over which the upstream CDN
      received the initial User Agent request.
   o  Additional details an illustration of the User Agent request
   fact that are required to
      perform effective Request Routing by the Downstream CDN.  For DNS
      this would typically CDNI interfaces need not be the IP address of the DNS resolver making
      the request on behalf created in a vacuum and
   that reuse or leverage of the User Agent.  For requests received
      over content specific application existing protocols the Redirection is likely possible.

   The four CDNI interfaces (CDNI Control interface, CDNI Request could contain significantly more information related to
   Routing interface, CDNI Metadata interface, CDNI Logging interface)
   described in Section 3 within the original User Agent request but CDNI problem area are all control
   plane interfaces operating at a minimum the application layer (Layer 7 in the
   OSI network model).  Firstly, since it is not expected that these
   interfaces would exhibit unique session, transport or network
   requirements as compared to
      include the User Agent's IP address, the equivalent of the HTTP
      Host header and many other existing applications in
   the equivalent of Internet, it is expected that the HTTP abs_path CDNI interfaces will be defined in
      [RFC2616].

   It should
   on top of existing session, transport and network protocols.

   Secondly, although a new application protocol could be designed
   specifically for CDNI we assume that this is unnecessary and it is
   recommended that existing application protocols be noted that, reused or
   leveraged (HTTP [RFC2616], Atom Publishing Protocol [RFC5023], XMPP
   [RFC6120], for example) to realize the CDNI architecture needs to consider that
   a downstream CDN may receive requests from User Agents without first
   receiving interfaces.

4.1.  CDNI Request Routing Interface

   The CDNI Request Routing interface enables a Redirection Request from Routing function
   in an upstream CDN for the
   corresponding User Agent request, for example because:

   o  User Agents (or DNS resolvers) may cache DNS or application
      responses from Request Routers.
   o  Responses to Redirection Requests over the query a Request Routing
      interface may be cacheable.
   o  Some CDNs may rely on simple coarse policies, e.g.  CDN B agrees
      to always serve CDN A's delegated redirection requests, function in which
      case the necessary redirection details are exchanged out of band
      (of the CDNI interfaces), e.g. configured.

   On receiving a Redirection Request, the
   downstream CDN will use the
   information provided in the request to determine if it the downstream CDN is able (and
   willing) to accept the delegated content request and needs to return
   the result of its decision to the upstream CDN.

   Thus, a Redirection Response from the downstream CDN is expected to
   contain information such as:

   o  Status code indicating acceptance or rejection (possibly with
      accompanying reasons).
   o  Information to allow redirection by the Upstream CDN.  In the case
      of DNS-based request routing, this is expected to include the
      equivalent of a DNS record(s) (e.g. a CNAME) that the upstream CDN
      should return to the requesting DNS resolver.  In the case of
      application based request routing, this is expected to include the
      information necessary to construct allow the application specific
      redirection response(s)
   downstream CDN to control what the upstream Request Routing function
   should return to the requesting User Agent.
      For HTTP requests from User Agents this could include a URI that
      the upstream CDN could return Agent in a HTTP 3xx response. the redirection message.

   The CDNI Request Routing interface is therefore a fairly
   straightforward request/response interface and could be implemented
   over any number of request/response protocols.  For example, it may
   be implemented as a WebService using one of the common WebServices
   methodologies (XML-RPC, HTTP query to a known URI, etc.).  This
   removes the need for the CDNI working group to define a new protocol
   for the request/response element of the CDNI Request Routing
   interface.  Thus, the CDNI working group would be left only with the
   task of specifying:

   o  The recommended request/response protocol to use along with any
      additional semantics and procedures that are specific to the CDNI
      Request Routing interface (e.g. handling of malformed requests/
      responses).
   o  The syntax (i.e representation/encoding) of the redirection
      requests and responses.
   o  The semantics (i.e. meaning and expected contents) of the
      redirection requests and responses.

   Additionally, as discussed in Section 3, the CDNI Request Routing
   interface is also expected to enable a downstream CDN to provide to
   the upstream CDN (static or dynamic) information (e.g. resources,
   footprint, load) to facilitate selection of the downstream CDN by the
   upstream CDN request routing system when processing subsequent
   content requests from User Agents.  It is expected that such
   functionality of the CDNI request Routing could be specified by the
   CDNI working group with significant leveraging of existing IETF
   protocols supporting the dynamic distribution of reachability
   information (for example by leveraging existing routing protocols) or
   supporting application level queries for topological information (for
   example by leveraging ALTO).

4.2.  CDNI Metadata Interface

   The CDNI Metadata interface enables the Distribution System in a
   downstream CDN to obtain request CDNI Metadata from an upstream CDN so that
   the downstream CDN can properly process and respond to:

   o  Redirection Requests to redirection
   requests received over the CDNI Request Routing
      interface.
   o interface and Content
   Requests received directly from User Agents.

   The CDNI Metadata interface needs to offer a mechanism for an
   Upstream CDN to:

   o  Distribute/update/remove CDNI Metadata to a Downstream CDN.

   and/or to allow a downstream CDN to:

   o  Make direct requests for CDNI Metadata objects
   o  Make recursive requests for CDNI metadata, for example to enable a
      downstream CDN to walk down a tree of objects with inter-object
      relationships.

   The CDNI Metadata interface is therefore similar to the CDNI Request
   Routing interface because it is a request/response interface with the
   potential addition that CDNI Metadata search may have more complex
   semantics than a straightforward Request Routing redirection request.
   Therefore, like the CDNI Request Routing interface, the CDNI Metadata
   interface may be implemented as a WebService using one of the common
   WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.)
   or possibly using other existing protocols such as XMPP [RFC6120].
   This removes the need for the CDNI working group to define a new
   protocol for the request/response element of the CDNI Metadata
   interface.

   Thus, the CDNI working group would be left only with the task of
   specifying:

   o  The recommended request/response protocol to use along with any
      additional semantics that are specific to the CDNI Metadata
      interface (e.g. handling of malformed requests/responses).
   o  The syntax (i.e representation/encoding) of the CDNI Metadata
      objects that will be exchanged over the interface.

   o  The semantics (i.e. meaning and expected contents) of CDNI working group to define a new
   protocol for the
      individual properties request/response element of a Metadata object.
   o  How the relationships between different CDNI Metadata objects are
      represented.
   interface.

4.3.  CDNI Logging Interface

   The CDNI Logging interface enables details of logs or events to be
   exchanged between interconnected CDNs, where events could be:

   o  Log be for
   example log lines related to the delivery of content (similar to the
   log lines recorded in a web server's access log).
   o  Real-time log) as well as real-time
   or near-real time events before, during or after content
      delivery, e.g. delivery and
   operations and diagnostic messages.

   Several protocols already exist that could potentially be used to
   exchange CDNI logs between interconnected CDNs including SNMP,
   syslog, ftp, HTTP POST, etc.

4.4.  CDNI Control Interface

   The CDNI Control interface allows the Control System in
   interconnected CDNs to communicate.  The exact inter-CDN control
   functionality required to be supported by the CDNI Control interface
   is less well defined than the other three CDNI interfaces at this
   time.

   It is expected that for the Control interface, as for the other CDNI
   Interfaces, existing protocols can be reused or leveraged.

5.  IANA Considerations

   This document makes no request of IANA.

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

6.  Security Considerations

   Distribution of content by a CDN comes with a range of security
   considerations such as how to enforce control of access to the
   content by users in line with the CSP policy.  These security aspects
   are already dealt with by CDN Providers and CSPs today in the context
   of standalone CDNs.  However, interconnection of CDNs introduces a
   new set of security considerations by extending the trust model (i.e.
   the CSP "trusts" a CDN that "trusts" another CDN).

   Maintaining the security of the content itself, its associated
   metadata (including distribution and delivery interruption
   o  Operations policies) and diagnostic messages.

   Within the CDNs today, logs
   distributing and events delivering it, are used critical requirements for a variety of purposes
   in addition to real-time and non real-time diagnostics and auditing
   by the both
   CDN Provider and its customers.  Specifically CDNs use logs to
   generate Call Data Records (CDRs) for passing to billing Providers and payment
   systems CSPs and to real-time (and near real-time) analytics systems.
   Such applications place requirements any work on the CDNI Logging interface CDN Interconnection must
   provide sufficient mechanisms to
   support guaranteed and timely delivery maintain the security of log messages between
   interconnected CDNs.  It may also be necessary to be able to prove the integrity overall
   system of received log messages.

   Several protocols already exist that could potentially be used to
   exchange CDNI logs between interconnected CDNs including SNMP Traps,
   syslog, ftp, HTTP POST, etc. although it is likely that some of the
   candidate protocols may not be as well suited as the information (content,
   metadata, logs, etc) distributed and delivered through any CDN
   interconnections.

7.  Acknowledgements

   The authors would like to thank Andre Beck, Gilles Bertrand, Mark
   Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li,
   Kevin Ma, Julien Maisonneuve, Guy Meador, Emile Stephan, Oskar van
   Deventer, Mahesh Viveganandhan and Richard Woundy for their review
   comments and contributions to meet all the
   requirements of CDNI.  For example SNMP traps pose scalability
   concerns text.

8.  References

8.1.  Normative References

8.2.  Informative References

   [3GP-DASH]
              "Transparent end-to-end Packet-switched Streaming Service
              (PSS); Progressive Download and SNMP does not support guaranteed delivery of Traps Dynamic Adaptive Streaming
              over HTTP (3GP-DASH)
              http://www.3gpp.org/ftp/Specs/html-info/26247.htm".

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

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

   [ATIS-COD]
              "ATIS IIF: IPTV Content on Demand Service, January 2011 (h
              ttp://www.atis.org/iif/_Com/Docs/Task_Forces/ARCH/
              ATIS-0800042.pdf)".

   [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/)".

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

   [I-D.bertrand-cdni-experiments]
              Faucheur, F. and
   therefore could result L. Peterson, "Content Distribution
              Network Interconnection (CDNI) Experiments",
              draft-bertrand-cdni-experiments-02 (work in log records being lost and the consequent
   CDRs progress),
              February 2012.

   [I-D.ietf-cdni-use-cases]
              Gilles, B., Watson, G., Ma, K., Eardley, P., Emile, S.,
              and billing records T. Burbridge, "Use Cases for that content delivery not being produced
   as well as that content delivery being invisible to any analytics
   platforms.

   Although it is not necessary to define a new protocol Content Delivery Network
              Interconnection", draft-ietf-cdni-use-cases-03 (work in
              progress), January 2012.

   [I-D.jenkins-alto-cdn-use-cases]
              Previdi, S., Watson, G., Medved, J., Bitar, N., and B.
              Niven-Jenkins, "Use Cases for exchanging
   logs across the CDNI Logging interface, the CDNI working group would
   still need to specify:

   o  The recommended protocol to use.
   o  A default set of log fields ALTO within CDNs",
              draft-jenkins-alto-cdn-use-cases-02 (work in progress),
              December 2011.

   [MPEG-DASH]
              "Information technology - MPEG systems technologies - Part
              6: Dynamic adaptive streaming over HTTP (DASH), (DIS
              version), February 2011
              http://mpeg.chiariglione.org/
              working_documents.htm#MPEG-B".

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

   [P2PRG-CDNI]
              Davie, B. and their syntax & semantics.  Today
      there is no standard set of common log fields across different
      content delivery protocols F. Le Faucheur, "Interconnecting CDNs aka
              "Peering Peer-to-Peer"
              (http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)",
              March 2010.

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

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3040]  Cooper, I., Melve, I., and in some cases there is not even a
      standard set of log field names G. Tomlinson, "Internet Web
              Replication and values Caching Taxonomy", RFC 3040, January 2001.

   [RFC3466]  Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
              for different
      implementations 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.

   [RFC5023]  Gregorio, J. and B. de hOra, "The Atom Publishing
              Protocol", RFC 5023, October 2007.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
              Protocol (XMPP): Core", RFC 6120, March 2011.

   [SNIA-CDMI]
              "SNIA CDMI (http://www.snia.org/tech_activities/standards/
              curr_standards/cdmi)".

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

   [Y.1910]   "ITU-T Recomendation Y.1910 "IPTV functional
              architecture"", September 2008.

   [Y.2019]   "ITU-T Recomendation Y.2019 "Content delivery protocol.

   o  A default set of events that trigger logs to be generated.

4.4.  CDNI Control Interface

   The CDNI Control interface allows the Control System functional
              architecture in
   interconnected CDNs to communicate.  The exact inter-CDN control
   functionality required to be supported by NGN"", September 2010.

Appendix A.  Design considerations for realizing the CDNI Control interface
   is less well defined than the other three Interfaces

   This section expands on how CDNI interfaces at this
   time.

   However, as discussed in Section 3, the can reuse and leverage
   existing protocols before describing each CDNI Control interface may be
   required to support functionality similar individually
   and highlighting example candidate protocols that could be considered
   for reuse or leveraging to implement the following:
   o  Allow CDNI interfaces.

A.1.  CDNI Request Routing Interface

   The CDNI Request Routing interface enables a Request Routing function
   in an upstream CDN and to query a Request Routing function in a
   downstream CDN to establish, update or
      terminate their CDNI interconnection.
   o  Allow bootstrapping of the other CDNI interfaces (e.g. protocol
      address discovery and establishment of security associations).
   o  Allow configuration of determine if the other CDNI interfaces (e.g.  Upstream downstream CDN specifies information is able (and
   willing) to be reported through accept the CDNI Logging
      interface).
   o  Allow delegated content request and to allow the
   downstream CDN to communicate static information about
      its delivery capabilities, resources and policies.
   o  Allow bootstrapping of control what the interface between CDNs for content
      acquisition (even if that interface itself is outside upstream Request Routing function
   should return to the scope of User Agent in the redirection message.

   Therefore, the CDNI work).
   It is expected that Request Routing interface needs to offer a
   mechanism for the Control an upstream CDN to issue a "Redirection Request" to a
   downstream CDN.  The Request Routing interface also, existing
   protocols can be reused or leveraged.  Those will needs to be considered once able to
   support scenarios where the requirements for initial User Agent request to the Control interface have been refined.

5.  Relevant work from other standardization activities

   There are
   upstream CDN is received over DNS as well as over a number content specific
   application protocol (e.g.  HTTP, RTSP, RTMP, etc.).

   Therefore a Redirection Request is expected to contain information
   such as:

   o  The protocol (e.g.  DNS, HTTP) over which the upstream CDN
      received the initial User Agent request.
   o  Additional details of other standards bodies and industry forums the User Agent request that are working in areas related to CDNs, and in some cases related required to
   CDNI.  This section outlines any potential overlap with
      perform effective Request Routing by the work Downstream CDN.  For DNS
      this would typically be the IP address of the CDNI working group and any component that could potentially be
   reused to realize DNS resolver making
      the CDNI interfaces.

   A number request on behalf of standards bodies have produced specifications the User Agent.  For requests received
      over content specific application protocols the Redirection
      Request could contain significantly more information related to
   CDNs, for example:

   o  ETSI TISPAN (Telecommunications and Internet converged Services
      and Protocols for Advanced Networking) has
      the original User Agent request but at a series minimum is expected to
      include the User Agent's IP address, the equivalent of
      specifications focusing on CDNs.
   o  The Open IPTV Forum (OIPF) and ATIS IPTV Interoperability Forum
      (IIF) specify the architecture HTTP
      Host header and the protocols equivalent of an IPTV
      solution.  Although OIPF and ATIS specifications include the
      interaction with a CDN, HTTP abs_path defined in
      [RFC2616].

   It should be noted that, the CDNI architecture needs to consider that
   a downstream CDN specifications are coupled with
      their IPTV specifications and do not cover interconnection of
      CDNs. may receive requests from User Agents without first
   receiving a Redirection Request from an upstream CDN for the
   corresponding User Agent request, for example because:

   o  ATIS Cloud Services Forum (CSF) has started investigating
      interconnection of CDNs.  The ATIS CSF focuses  User Agents (or DNS resolvers) may cache DNS or application
      responses from Request Routers.
   o  Responses to Redirection Requests over the Request Routing
      interface may be cacheable.
   o  Some CDNs may rely on defining use
      cases and requirements for such simple coarse policies, e.g.  CDN interconnection, which are
      expected B agrees
      to be considered as input into always serve CDN A's delegated redirection requests, in which
      case the work necessary redirection details are exchanged out of band
      (of the CDNI
      working group.  At interfaces), e.g. configured.

   On receiving a Redirection Request, the time of writing this document, ATIS CSF is
      not specifying downstream CDN will use the corresponding protocols or interfaces and
   information provided in the request to determine if it is
      expected able (and
   willing) to leverage the work of accept the IETF CDNI working group for
      those.
   o  CableLabs, SNIA and ITU have developed (or are working on)
      definitions for delegated content related metadata request and specifications for
      its distribution.  However, they do not include metadata specific needs to return
   the distribution result of content within its decision to the upstream CDN.

   Thus, a Redirection Response from the downstream CDN is expected to
   contain information such as:

   o  Status code indicating acceptance or between
      interconnected CDNs. rejection (possibly with
      accompanying reasons).
   o  IETF CDI working group (now concluded) touched on the same problem
      space as  Information to allow redirection by the present document.  However, in accordance with its
      initial charter, Upstream CDN.  In the CDI working group 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 case
      of DNS-based request routing, this is expected to justify rechartering include the
      equivalent of a DNS record(s) (e.g. a CNAME) that the working group upstream CDN
      should return to conduct the corresponding protocol work.

   Although some requesting DNS resolver.  In the case of
      application based request routing, this is expected to include the specifications describe multi-CDN cooperation or
      information necessary to construct the application specific
      redirection response(s) to return to the requesting User Agent.
      For HTTP requests from User Agents this could include reference points for interconnecting CDNs, none of them
   specify in sufficient detail all a URI that
      the upstream CDN could return in a HTTP 3xx response.

   The CDNI interfaces Request Routing interface is therefore a fairly
   straightforward request/response interface and CDNI
   Metadata representations required to enable even could be implemented
   over any number of request/response protocols.  For example, it may
   be implemented as a base level WebService using one of CDN
   Interconnection functionality the common WebServices
   methodologies (XML-RPC, HTTP query to be implemented.

   The following sections will summarize a known URI, etc.).  This
   removes the existing work need for the CDNI working group to define a new protocol
   for the request/response element of the
   standard bodies listed earlier against CDNI Request Routing
   interface.  Thus, the CDNI problem space.
   Section 5.1 summarises existing interfaces that could working group would be leveraged
   for content acquisition between CDNs left only with the
   task of specifying:

   o  The recommended request/response protocol to use along with any
      additional semantics and Section 5.2 summarises
   existing metadata specifications procedures that may be applicable to CDNI.  To
   date we are not aware of any standardisation activities in the areas
   of specific to the remaining CDNI interfaces (CDNI
      Request Routing, CDNI Control Routing interface (e.g. handling of malformed requests/
      responses).
   o  The syntax (i.e representation/encoding) of the redirection
      requests and CDNI Logging).

5.1.  Content Acquisition across CDNs responses.
   o  The semantics (i.e. meaning and Delivery to End User (Data
      plane)

   A number expected contents) of standards bodies have completed work in the areas of
   content acquisition interface between a CSP
      redirection requests and a CDN, as well as responses.

   Additionally, as
   on discussed in Section 3, the delivery CDNI Request Routing
   interface between is also expected to enable a downstream CDN to provide to
   the surrogate and upstream CDN (static or dynamic) information (e.g. resources,
   footprint, load) to facilitate selection of the downstream CDN by the
   upstream CDN request routing system when processing subsequent
   content requests from User Agent.
   Some of this work Agents.  It is summarized below.

   TISPAN, OIPF and ATIS have expected that such
   functionality of the CDNI request Routing could be specified IPTV and/or Content on Demand
   (CoD) services, including by the data plane aspects (typically different
   flavors
   CDNI working group with significant leveraging of RTP/RTCP and HTTP) existing IETF
   protocols supporting the dynamic distribution of reachability
   information (for example by leveraging existing routing protocols) or
   supporting application level queries for topological information (for
   example by leveraging ALTO).

A.2.  CDNI Metadata Interface

   The CDNI Metadata interface enables the Distribution System in a
   downstream CDN to obtain content CDNI Metadata from an upstream CDN so that
   the downstream CDN can properly process and deliver it to
   User Agents.  For example, : respond to:

   o  The OIPF data plane includes both RTP and HTTP flavors (HTTP
      progressive download, HTTP Adaptive streaming [3GP-DASH]).  Redirection Requests received over the CDNI Request Routing
      interface.
   o  The ATIS IIF specification "IPTV Content on Demand (CoD) Service"
      [ATIS-COD] defines  Content Requests received directly from User Agents.

   The CDNI Metadata interface needs to offer a reference point (C2) and the corresponding
      HTTP-based data plane protocol mechanism for content acquisition between an
      authoritative origin server and the
   Upstream CDN to:

   o  Distribute/update/remove CDNI Metadata to a Downstream CDN.
   While these protocols have not been explicitly specified for content
   acquisition across CDNs, they are suitable (in addition

   and/or to others
   such as standard HTTP) for content acquisition between CDNs in allow a downstream CDN
   Interconnection environment.  Therefore to:

   o  Make direct requests for the purpose CDNI Metadata objects
   o  Make recursive requests for CDNI metadata, for example to enable a
      downstream CDN to walk down a tree of objects with inter-object
      relationships.

   The CDNI Metadata interface is therefore similar to the CDNI
   working group there are already multiple existing data plane
   protocols that can be used for content acquisition across CDNs.

   Similarly, there are multiple existing standards (e.g. Request
   Routing interface because it is a request/response interface with the OIPF data
   plane mentioned above, HTTP adaptive streaming [3GP-DASH]) or public
   specifications (e.g. vendor specific HTTP Adaptive streaming
   specifications) so
   potential addition that content delivery can be considered already
   solved (or at least sufficiently addressed in other forums).

   Thus, specification of CDNI Metadata search may have more complex
   semantics than a straightforward Request Routing redirection request.
   Therefore, like the content acquisition interface between CDNs
   and CDNI Request Routing interface, the delivery CDNI Metadata
   interface between may be implemented as a WebService using one of the surrogate and common
   WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.)
   or possibly using other existing protocols such as XMPP [RFC6120].
   This removes the User Agent
   are out of scope need for the CDNI working group.  The group to define a new
   protocol for the request/response element of the CDNI Metadata
   interface.

   Thus, the CDNI working group
   may would be left only concern itself with the negotiation/selection aspects task of the
   acquisition
   specifying:

   o  The recommended request/response protocol to be used in a CDN interonnect scenario.

5.2.  CDNI Metadata

   CableLabs, ITU, OIPF and TV-Anytime have work items dedicated use along with any
      additional semantics that are specific to the
   specification of content metadata:

   o  CableLabs has defined specifications for CoD Content CDNI Metadata as
      part
      interface (e.g. handling 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 malformed requests/responses).
   o  The syntax (i.e representation/encoding) 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 CDNI Metadata
      objects that could will be used between CDNs. exchanged over the interface.
   o  ITU Study Group 16 has started work on a number  The semantics (i.e. meaning and expected contents) of draft
      Recommendations (H.IPTV-CPMD, H.IPTV-CPMD, HSTP.IPTV-CMA,
      HSTP.IPTV-UMCI) specifying metadata for content distribution in
      IPTV services.
   o  An Open IPTV Terminal receives the technical description
      individual properties of a Metadata object.
   o  How the
      content distribution from the OIPF IPTV platform before receiving
      any content. relationships between different CDNI Metadata objects are
      represented.

A.3.  CDNI Logging Interface

   The Content distribution metadata is sent in CDNI Logging interface enables details of logs or events to be
   exchanged between interconnected CDNs, where events could be:

   o  Log lines related to the
      format delivery of a TV-Anytime XSD including tags content (similar to describes the
      location and program type (on demand log
      lines recorded in a web server's access log).
   o  Real-time or Live) as well as
      describing the near-real time availability events before, during or after content
      delivery, e.g. content delivery interruption
   o  Operations and diagnostic messages.

   Within CDNs today, logs and events are used for a variety of the on demand purposes
   in addition to real-time and live
      content.

   However non real-time diagnostics and auditing
   by the specifications outlined above do not include metadata
   specific CDN Provider and its customers.  Specifically CDNs use logs to
   generate Call Data Records (CDRs) for passing to billing and payment
   systems and to real-time (and near real-time) analytics systems.
   Such applications place requirements on the distribution CDNI Logging interface to
   support guaranteed and timely delivery of content within a CDN or log messages between
   interconnected CDNs, for example geo-blocking information,
   availability windows, access control mechanisms CDNs.  It may also be necessary to be enforced by able to prove
   the
   surrogate, how integrity of received log messages.

   Several protocols already exist that could potentially be used to map an incoming content request
   exchange CDNI logs between interconnected CDNs including SNMP Traps,
   syslog, ftp, HTTP POST, etc. although it is likely that some of the
   candidate protocols may not be well suited to a file on meet all the
   origin server or acquire it from
   requirements of CDNI.  For example SNMP traps pose scalability
   concerns and SNMP does not support guaranteed delivery of Traps and
   therefore could result in log records being lost and the upstream CDN etc.

   The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata consequent
   CDRs and billing records for that can
   be associated with data content delivery not being produced
   as well as that content delivery being invisible to any analytics
   platforms.

   Although it is stored by not necessary to define a cloud storage provider.
   While new protocol for exchanging
   logs across the metadata currently defined do not match CDNI Logging interface, the CDNI working group would
   still need to specify:

   o  The recommended protocol to use.
   o  A default set of a CDN
   Interconnection solution, it log fields and their syntax & semantics.  Today
      there is worth considering CDMI as one no standard set of common log fields across different
      content delivery protocols and in some cases there is not even a
      standard set of log field names and values for different
      implementations of the
   existing pieces same delivery protocol.
   o  A default set of work events that may potentially trigger logs to be leveraged for the generated.

A.4.  CDNI Metadata Control Interface

   The CDNI Control interface (e.g by extending allows the CDMI metadata to
   address more specific CDNI needs).

6.  Relationship to relevant IETF Working Groups

6.1.  ALTO

   As stated Control System 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
   interconnected CDNs 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 communicate.  The exact inter-CDN control
   functionality required to be supported by the user, etc.  The working group will consider CDNI Control interface
   is less well defined than the
   needs of BitTorrent, tracker-less P2P, and other applications, such three CDNI interfaces at this
   time.

   However, as content delivery networks (CDN) and mirror selection."

   In particular, discussed in Section 3, the ALTO service can CDNI Control interface may be used by a CDN Request Routing
   system
   required to improve its selection of a CDN surrogate support functionality similar to serve a
   particular User Agent request (or the following:
   o  Allow an upstream CDN and downstream CDN to serve a request from another
   surrogate).  [I-D.jenkins-alto-cdn-use-cases] describes a number establish, update or
      terminate their CDNI interconnection.
   o  Allow bootstrapping of
   use cases for a the other CDNI interfaces (e.g. protocol
      address discovery and establishment of security associations).
   o  Allow configuration of the other CDNI interfaces (e.g.  Upstream
      CDN specifies information to be able reported through the CDNI Logging
      interface).
   o  Allow the downstream CDN to obtain network topology and cost communicate static information from an ALTO server(s) about
      its delivery capabilities, resources and discusses how CDN Request
   Routing could be used as an integration point policies.
   o  Allow bootstrapping of ALTO into CDNs. the interface between CDNs for content
      acquisition (even if that interface itself is outside the scope of
      the CDNI work).
   It is possible expected that for the ALTO service could Control interface also, existing
   protocols can be used in the same manner in
   a multi-CDN environment based on CDN Interconnection.  For example,
   an upstream CDN may take advantage of reused or leveraged.  Those will be considered once
   the ALTO service in its
   decision requirements for selecting a downstream CDN the Control interface have been refined.

Appendix B.  Additional Material

   Note to which a user request
   should be delegated.

   However, the current work of ALTO RFC Editor: This appendix is complementary to and does not
   overlap with be removed on publication as
   an RFC.

B.1.  Non-Goals for IETF

   Listed below are aspects of content delivery that the work described in this document because authors propose
   be kept outside of the
   integration scope of a potential CDNI working group:
   o  The interface between ALTO Content Service Provider and a the
      Authoritative CDN is an internal decision for a
   specific (i.e. the upstream CDN and is therefore out of scope for contracted by the CDNI working
   group.  One area CSP for further study is whether additional information
   should be provided
      delivery by an ALTO service to facilitate CDNI this CDN
   selection.

6.2.  DECADE or by its downstream CDNs).
   o  The DECADE Working Group [DECADE-Charter] is addressing delivery interface between the problem
   of reducing traffic on delivering CDN surrogate and
      the last-mile uplink, as well User Agent, such as backbone and
   transit links caused by P2P streaming protocols.
   o  The request interface between the User Agent and file sharing applications.
   It addresses the problem request-
      routing system of a given CDN.  Existing IETF protocols (e.g.
      HTTP, RTSP, DNS) are commonly used by enabling an application endpoint User Agents to make request
      content available from an in-network storage service a CDN and by enabling
   other application endpoints CDN request routing systems to retrieve the content from there.

   Exchanging data through redirect
      the in-network storage service in User Agent requests.  The CDNI working group need not define
      new protocols for this
   manner, instead purpose.  Note however, that the CDNI
      control plane interface may indirectly affect some of through direct communication, provides significant
   gain where: the
      information exchanged through the request interface (e.g.  URI).
   o  The network capacity/bandwidth content acquisition interface between CDNs (i.e. the data
      plane interface for actual delivery of a piece of content from in-network storage service one
      CDN to
      application endpoint significantly exceeds the capacity/bandwidth
      from application endpoint other).  This is expected to application endpoint (e.g. because of use existing protocols
      such as HTTP or protocols defined in other forums for content
      acquisition between an end-user uplink bottleneck); origin server and
   o  Where a CDN (e.g.  HTTP-based
      C2 reference point of ATIS IIF CoD).  The CDN Interconnection
      problem space described in this document may therefore only
      concern itself with the agreement/negotiation aspects of which
      content acquisition protocol is to be accessed by multiple instances of
      application endpoints (e.g. as is typically the case for P2P
      applications).

   While, as is the case for any other data distribution application,
   the DECADE architecture and mechanisms could potentially be used for
   exchange of CDNI control plane information via an in-network-storage
   service (as opposed to directly between the entities terminating the
   CDNI interfaces two
      interconnected CDNs in view of facilitating interoperability.
   o  End User/User Agent Authentication.  End User/User Agent
      authentication and authorization are the neighbor CDNs), we observe that: responsibility of the
      Content Service Provider.
   o  Content preparation, including encoding and transcoding.  The CDNI would operate
      architecture aims at allowing distribution across interconnected
      CDNs of content treated as a "Content Distribution Application" from
      the DECADE viewpoint (i.e. would operate on top opaque objects.  Interpretation and
      processing of DECADE).
   o  There does not seem to be obvious benefits in integrating the
      DECADE control plane responsible for signaling information
      relating to control objects, as well as optimized delivery of these
      objects by the in-network storage service itself, surrogate to the End User are outside the scope of
      CDNI.
   o  Digital Rights Management (DRM).  DRM is an end-to-end issue
      between a content protection system and the User Agent.
   o  Applications consuming CDNI control plane responsible for application-specific CDNI
      interactions (such as exchange logs (e.g. charging, analytics,
      reporting,...).
   o  Internal CDN interfaces & protocols (i.e. interfaces & protocols
      within one CDN).
   o  Scalability of CDNI metadata, CDNI request
      redirection, transfer individual CDNs.  While scalability of the CDNI logging information).
      interfaces/approach is in scope, how an individual CDN scales is
      out of scope.
   o  There would typically  Actual algorithms for selection of CDNs or Surrogates by Request
      Routing systems (however, some specific parameters required as
      input to these algorithms may be limited benefits in making use scope when they need to be
      communicated across CDNs).
   o  Surrogate algorithms.  For example caching algorithms and content
      acquisition methods are outside the scope of a
      DECADE in-network storage service because the CDNI interfaces are
      expected work.
      Content management (e.g.  Content Deletion) as it relates to be terminated by a very small number of CDNI clients
      (if not one)
      content management policies, is in each CDN, and scope but the CDNI clients are expected internal
      algorithms used by a cache to
      benefit from high bandwidth/capacity determine when communicating directly to each other (at least as high as if they were communicating via no longer cache an in-network storage server).

   The DECADE in-network storage architecture and mechanisms may
   theoretically be used for
      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 acquisition
      interconnections of the content objects
   themselves between interconnected CDNs.  It is not expected

B.2.  Related standardization activites

   There are a number of other standards bodies and industry forums that this
   would have obvious benefits
   are working in typical situations where a content
   object is acquired only once from an Upstream CDN areas related to a Downstream CDN
   (and then distributed as needed inside the Downstream CDN).  But it
   might have benefits CDNs, and in some particular situations.  Since the
   acquisition protocol between CDNs is outside cases related to
   CDNI.  This section outlines any potential overlap with the scope work of
   the CDNI
   work, this question is left working group and any component that could potentially be
   reused to realize the CDNI interfaces.

   A number of standards bodies have produced specifications related to
   CDNs, for further study. example:

   o  ETSI TISPAN (Telecommunications and Internet converged Services
      and Protocols for Advanced Networking) has a series of
      specifications focusing on CDNs.
   o  The DECADE in-network storage Open IPTV Forum (OIPF) and ATIS IPTV Interoperability Forum
      (IIF) specify the architecture and mechanisms may
   potentially also be used within the protocols of an IPTV
      solution.  Although OIPF and ATIS specifications include the
      interaction with a given CDN, the CDN specifications are coupled with
      their IPTV specifications and do not cover interconnection of
      CDNs.
   o  ATIS Cloud Services Forum (CSF) has started investigating
      interconnection of CDNs.  The ATIS CSF focuses on defining use
      cases and requirements for such CDN interconnection, which are
      expected to be considered as input into the distribution work of the content objects themselves among surrogates of that CDN.  Since CDNI
      working group.  At the CDNI work does not concern itself with operation within a CDN, time of writing this question document, ATIS CSF is left for further study.

   Therefore,
      not specifying the work of DECADE may be complementary corresponding protocols or interfaces and is
      expected to but does not
   overlap with leverage the CDNI work described in this document.

6.3.  PPSP

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

   "The Peer-to-Peer Streaming Protocol (PPSP) IETF CDNI working group develops
   two signaling and control protocols for a peer-to-peer (P2P)
   streaming system for transmitting live and time-shifted media content
   with near real-time delivery requirements."
      those.
   o  CableLabs, SNIA and "The PPSP ITU have developed (or are working
   group designs a protocol on)
      definitions for signaling and control between trackers
   and peers (the PPSP "tracker protocol") and a signaling content related metadata and control
   protocol specifications for communication among the peers (the PPSP "peer
   protocol").  The two protocols enable peers to receive streaming data
   within the time constraints required by
      its distribution.  However, they do not include metadata specific content items."

   Therefore PPSP is concerned with
      to the distribution of the streamed content itself along with within a CDN or between
      interconnected CDNs.
   o  IETF CDI working group (now concluded) touched on the necessary signaling and control
   required to distribute same problem
      space as the content.  As such, it could potentially be
   used for present document.  However, in accordance with its
      initial charter, the acquisition of streamed content across interconnected
   CDNs.  But since CDI working group 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 acquisition protocol is outside working group
      to conduct the scope corresponding protocol work.

   Although some of the
   work proposed for CDNI, we leave this specifications describe multi-CDN cooperation or
   include reference points for further study.  Also,
   because of its streaming nature, PPSP is not seen as applicable to
   the distribution and control interconnecting CDNs, none of them
   specify in sufficient detail all the CDNI control plane interfaces and CDNI data
   representations.

   Therefore, the work of PPSP may be complementary
   Metadata representations required to but does not
   overlap with the work described in this document for CDNI.

7.  IANA Considerations

   This document makes no request enable even a base level of IANA.

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

8.  Security Considerations implemented.

B.2.1.  IETF CDI Working Group (Concluded)

   The Content Distribution of content by a CDN comes with a range of security
   considerations such as how to enforce control of access to the
   content by users Internetworking (CDI) Working Group was
   formed in line with the CSP policy.  These security aspects
   are already dealt with by CDN Providers IETF following a BoF in December 2000 and CSPs today closed in mid
   2003.

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

   "
   o  The goal of standalone CDNs.  However, interconnection this working group is to define protocols to allow the
      interoperation of CDNs introduces a
   new set separately-administered content networks.
   o  A content network is an architecture of security considerations by extending the trust model (i.e.
   the CSP "trusts" a CDN that "trusts" another CDN).

   Maintaining the security network elements, arranged
      for efficient delivery of the digital content.  Such content itself, its associated
   metadata (including distribution and delivery policies) includes,
      but is not limited to, web pages and the CDNs
   distributing images delivered via HTTP,
      and delivering it, streaming or continuous media which are critical controlled by RTSP.
   o  The working group will first define requirements for both
   CDN Providers and CSPs three modes
      of content internetworking: interoperation of request-routing
      systems, interoperation of distribution systems, and any work on CDN Interconnection must
   provide sufficient mechanisms
      interoperation of accounting systems.  These requirements are
      intended to maintain the security lead to a follow-on effort to define protocols for
      interoperation of these systems.
   o  In its initial form, the overall
   system of interconnected CDNs as well working group is not chartered to deliver
      those protocols [...]

   "

   Thus, the CDI working group touched on the same problem space as the information (content,
   metadata, logs, etc) distributed and delivered through any CDN
   interconnections.

9.  Acknowledgements
   present document.

   The authors would like CDI working group 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".

B.2.2.  3GPP

   3GPP was the first organization that released a specification related
   to thank Andre Beck, Gilles Bertrand, Mark
   Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li,
   Kevin Ma, Julien Maisonneuve, Guy Meador, Emile Stephan, Oskar van
   Deventer adaptive streaming over HTTP. 3GPP Release 9 specification on
   adaptive HTTP streaming was published in March 2010, and Mahesh Viveganandhan there have
   been some bug fixes on this specification since the publication.  In
   addition, 3GPP has produced an extended version for their review comments Release 10, which
   was published in 2011.  This release will include a number of
   clarifications, improvements and
   contributions to the text.

10.  References

10.1.  Normative References

10.2.  Informative References new features.

   [3GP-DASH]
              "Transparent end-to-end Packet-switched Streaming Service
              (PSS); Progressive Download is defined as a general framework independent of the data
   encapsulation format.  It has support for fast initial startup and Dynamic Adaptive Streaming
              over
   seeking, adaptive bitrate switching, re-use of HTTP (3GP-DASH)
              http://www.3gpp.org/ftp/Specs/html-info/26247.htm".

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

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

   [ATIS-COD]
              "ATIS IIF: IPTV Content on Demand Service, January 2011 (h
              ttp://www.atis.org/iif/_Com/Docs/Task_Forces/ARCH/
              ATIS-0800042.pdf)".

   [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/)".

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

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

   [I-D.ietf-cdni-use-cases]
              Gilles, B., Emile, S., Watson, G., Burbridge, T., Eardley,
              P., cache
   servers, re-use of existing media playout engines, on-demand, live
   and K. Ma, "Use Cases time-shifted delivery.  It specifies syntax and semantics of
   Media Presentation Description (MPD), format of segments and delivery
   protocol for Content Delivery Network
              Interconnection", draft-ietf-cdni-use-cases-02 (work segments.  It does not specify content provisioning,
   client behavior or transport of MPD.

   The content retrieved by a client using [3GP-DASH] adaptive streaming
   could be obtained from a CDN but this is not discussed or specified
   in
              progress), January 2012.

   [I-D.jenkins-alto-cdn-use-cases]
              Niven-Jenkins, B., Watson, G., Bitar, N., Medved, J., the 3GPP specifications as it is transparent to [3GP-DASH]
   operations.  Similarly, it is expected that [3GP-DASH] can be used
   transparently from the CDNs as a delivery protocol (between the
   delivering CDN surrogate and
              S. Previdi, "Use Cases the User Agent) in a CDN Interconnection
   environment. [3GP-DASH] could also be a candidate for ALTO within CDNs",
              draft-jenkins-alto-cdn-use-cases-01 (work content
   acquisition between CDNs in progress),
              June 2011.

   [MPEG-DASH]
              "Information technology - a CDN Interconnection environment.

B.2.3.  ISO MPEG systems technologies - Part
              6:

   Within ISO MPEG, the Dynamic adaptive streaming Adaptive Streaming over HTTP (DASH), (DIS
              version), February 2011
              http://mpeg.chiariglione.org/
              working_documents.htm#MPEG-B".

   [OIPF-Overview]
              "OIPF (DASH) ad-
   hoc group adopted the 3GPP Release 2 Specification Volume 1 - Overview",
              September 2010.

   [P2PRG-CDNI]
              Davie, B. 9 [3GP-DASH] specification as a
   starting point and F. Le Faucheur, "Interconnecting has made some improvements and extensions.
   Similar to 3GPP SA4, the MPEG DASH ad-hoc group has been working on
   standardizing the manifest file and the delivery format.
   Additionally, the MPEG DASH ad-hoc group has also been working on the
   use of MPEG-2 Transport Streams as a media format, conversion from/to
   existing file formats, common encryption, and so on.  The MPEG DASH
   specification could also be a candidate for delivery to the User
   Agent and for content acquisition between CDNs aka
              "Peering Peer-to-Peer"
              (http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)",
              March 2010.

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

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., in a CDN
   Interconnection environment.  The Draft International Standard (DIS)
   version [MPEG-DASH] is currently publicly available since early
   February 2011.

   In the 95th MPEG meeting in January 2011, the DASH ad-hoc group
   decided to start a new evaluation experiment called "CDN-EE".  The
   goals are to understand the requirements for MPEG DASH to better
   support CDN-based delivery, and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3040]  Cooper, I., Melve, I., to provide a guidelines document for
   CDN operators to better support MPEG DASH streaming services.  The
   ongoing work is still very preliminary and G. Tomlinson, "Internet Web
              Replication does not currently target
   looking into CDN Interconnection use cases.

B.2.4.  ATIS IIF

   ATIS ([ATIS]) IIF is the IPTV Interoperability Forum (within ATIS)
   that develops requirements, standards, and Caching Taxonomy", RFC 3040, January 2001.

   [RFC3466]  Day, M., Cain, B., Tomlinson, G., specifications for IPTV.

   ATIS IIF is developing the "IPTV Content on Demand (CoD) Service"
   specification.  This includes use of a CDN (referred to in ATIS IIF
   CoD as the "Content Distribution and P. Rzewski, "A Model Delivery Functions") for support
   of a Content Internetworking (CDI)", RFC 3466,
              February 2003.

   [RFC3568]  Barbir, A., Cain, B., Nair, R., 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 service
   provider) and O. Spatscheck, "Known does not cover the use, or interconnection, of multiple
   CDNs.

B.2.5.  CableLabs

   "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]

   CableLabs has defined specifications for CoD Content Network (CN) Request-Routing Mechanisms",
              RFC 3568, July 2003.

   [RFC3570]  Rzewski, P., Day, M., Metadata as part
   of its VOD Metadata project.

B.2.6.  ETSI MCD

   ETSI MCD (Media Content Distribution) is the ETSI technical committee
   "in charge of guiding and D. Gilletti, "Content
              Internetworking (CDI) Scenarios", RFC 3570, July 2003.

   [RFC5023]  Gregorio, J. coordinating standardization work aiming at
   the successful overall development of multimedia systems (television
   and B. de hOra, "The Atom Publishing
              Protocol", RFC 5023, October 2007.

   [RFC6120]  Saint-Andre, P., "Extensible Messaging communication) responding to the present and Presence
              Protocol (XMPP): Core", RFC 6120, 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 2011.

   [SNIA-CDMI]
              "SNIA CDMI (http://www.snia.org/tech_activities/standards/
              curr_standards/cdmi)".

   [TAXONOMY]
              Pathan, A., "A Taxonomy
   2010.  MCD very recently created a working group to progress this
   work item.  However, no protocol level work has yet started in MCD
   for CDN Interconnection.

B.2.7.  ETSI TISPAN

   ETSI TISPAN has published two sets of IPTV specifications, one of
   which is based on IMS.  In addition, TISPAN has published a CDN
   architecture supporting delivery of various content services such as
   time-shifted TV and Survey VoD 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.  The protocol definition phase for the
   corresponding CDN architecture was kicked-off at the end of 2010 as
   is still in progress.  In line with its long history of leveraging
   IETF protocols, ETSI could potentially leverage CDNI interfaces
   developed in the IETF for their related protocol level work on
   interconnections of CDNs.

B.2.8.  ITU-T

   SG13 is developing standards related to the support of Content Delivery
              Networks
              (http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007.

   [Y.1910]   "ITU-T Recomendation IPTV services
   (i.e.. multimedia services such as television/VoD/audio/text/
   graphics/data delivered over IP-based managed networks).

   ITU-T Recommendation Y.1910 "IPTV [Y.1910] provides the description of the
   IPTV functional
              architecture"", September 2008.

   [Y.2019]   "ITU-T Recomendation Y.2019 "Content architecture.  This architecture includes functions
   and interfaces for the distribution and delivery functional of content.  This
   architecture is aligned with the ATIS IIF architecture.

   Based upon ITU-T Rec. Y.1910, ITU-T Rec. Y.2019 [Y.2019] describes in NGN"", September 2010.

Appendix A.  Additional Material

   Note to RFC Editor:
   more detail the content delivery functional architecture.  This appendix is to be removed on publication
   architecture allows CDN Interconnection: some interfaces (such as
   an RFC.

A.1.  Non-Goals for IETF

   Listed below D3,
   D4) at the control level allow relationships between different CDNs,
   in the same domain or in different domains.  Generic procedures are aspects
   described, but the choice of content delivery that the authors propose protocols is open.

B.2.9.  Open IPTV Forum (OIPF)

   The Open IPTV Forum has developed an end-to-end solution to allow any
   OIPF terminal to access enriched and personalized IPTV services
   either in a managed or a non-managed network[OIPF-Overview].  Some
   OIPF services (such as Network PVR) may be kept outside of hosted in a CDN.

   To that end, the scope Open IPTV Forum specification is made of a potential CDNI working group: 5 parts:

   o  Media Formats including HTTP Adaptive Streaming
   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 Metadata
   o  Protocols
   o  Terminal (Declarative or by its downstream CDNs). Procedural Application Environment)
   o  The delivery interface between the delivering CDN surrogate  Authentication, Content Protection and Service Protection

B.2.10.  TV-Anytime Forum

   Version 1 of the User Agent, such TV-Anytime Forum specifications were published as streaming protocols.
   o  The request interface between the User Agent
   ETSI TS 102 822-1 through ETSI TS 102 822-7 "Broadcast and the request-
      routing system On-line
   Services: Search, select, and rightful use of a given CDN.  Existing IETF protocols (e.g.
      HTTP, RTSP, DNS) are commonly used by User Agents to request content from a CDN and by CDN request routing on personal
   storage systems to redirect ("TV-Anytime")".  It includes the User Agent requests.  The CDNI working group need not specification of
   content metadata in XML schemas (ETSI TS 102 822-3) which define
      new protocols
   technical parameters for this purpose.  Note however, that the CDNI
      control plane interface may indirectly affect some description of CoD and Live contents.
   The specification is referenced by DVB and OIPF.

   The TV-anytime Forum was closed in 2005.

B.2.11.  SNIA

   The Storage Networking Industry Association (SNIA) is an association
   of producers and consumers of storage networking products whose goal
   is to further storage networking technology and applications.

   SNIA has published the
      information exchanged through Cloud Data Management Interface (CDMI)
   standard ([SNIA-CDMI]).

   "The Cloud Data Management Interface defines the request interface (e.g.  URI).
   o  The content acquisition functional interface between CDNs (i.e. the
   that applications will use to create, retrieve, update and delete
   data
      plane interface for actual delivery elements from the Cloud.  As part of a piece this interface the client
   will be able to discover the capabilities of content from one
      CDN the cloud storage
   offering and use this interface to manage containers and the other).  This data
   that is expected to use existing protocols
      such as HTTP or protocols defined placed in other forums for content
      acquisition between an origin server them.  In addition, metadata can be set on
   containers and a CDN (e.g.  HTTP-based
      C2 reference point their contained data elements through this interface."

B.2.12.  Summary of ATIS IIF CoD). existing stanardization work

   The CDN Interconnection
      solution may only concern itself with following sections will summarize the agreement/negotiation
      aspects existing work of which the
   standard bodies listed earlier against the CDNI problem space.
   Appendix B.2.12.1 summarizes existing interfaces that could be
   leveraged for content acquisition protocol is to be used between two interconnected CDNs in view of facilitating
      interoperability.
   o  End User/User Agent Authentication.  End User/User Agent
      authentication and authorization Appendix B.2.12.2
   summarizes existing metadata specifications that may be applicable to
   CDNI.  To date we are not aware of any standardization activities in
   the responsibility areas of the
      Content Service Provider.
   o  Content preparation, including encoding remaining CDNI interfaces (CDNI Request Routing,
   CDNI Control and transcoding.  The CDNI
      architecture aims at allowing distribution Logging).

B.2.12.1.  Content Acquisition across interconnected CDNs of content treated as opaque objects.  Interpretation and
      processing Delivery to End User
           (Data plane)

   A number of standards bodies have completed work in the objects, areas of
   content acquisition interface between a CSP and a CDN, as well as optimized as
   on the delivery of these
      objects by interface between the surrogate to and the End User are outside the scope Agent.
   Some of
      CDNI.
   o  Digital Rights Management (DRM).  DRM this work is an end-to-end issue
      between a summarized below.

   TISPAN, OIPF and ATIS have specified IPTV and/or Content on Demand
   (CoD) services, including the data plane aspects (typically different
   flavors of RTP/RTCP and HTTP) to obtain content protection system and the deliver it to
   User Agent.
   o  Applications consuming CDNI logs (e.g. charging, analytics,
      reporting,...). Agents.  For example, :
   o  Internal CDN interfaces & protocols (i.e. interfaces & protocols
      within one CDN).  The OIPF data plane includes both RTP and HTTP flavors (HTTP
      progressive download, HTTP Adaptive streaming [3GP-DASH]).
   o  Scalability of individual CDNs.  While scalability of  The ATIS IIF specification "IPTV Content on Demand (CoD) Service"
      [ATIS-COD] defines a reference point (C2) and the CDNI
      interfaces/approach is in scope, how an individual CDN scales is
      out of scope.
   o  Actual algorithms corresponding
      HTTP-based data plane protocol for selection of CDNs or Surrogates by Request
      Routing systems (however, some specific parameters required as
      input to content acquisition between an
      authoritative origin server and the CDN.
   While these algorithms may be in scope when protocols have not been explicitly specified for content
   acquisition across CDNs, they need are suitable (in addition to be
      communicated across CDNs).
   o  Surrogate algorithms.  For example caching algorithms and others
   such as standard HTTP) for content acquisition methods are outside between CDNs in a CDN
   Interconnection environment.  Therefore for the scope purpose of the CDNI work.
      Content management (e.g.  Content Deletion) as it relates to CDNI
      content management policies, is in scope but the internal
      algorithms
   working group there are already multiple existing data plane
   protocols that can be used by a cache to determine when to no longer cache an
      item of Content (in for content acquisition across CDNs.

   Similarly, there are multiple existing standards (e.g. the absence of any OIPF data
   plane mentioned above, HTTP adaptive streaming [3GP-DASH]) or public
   specifications (e.g. vendor specific metadata to the
      contrary) is out HTTP Adaptive streaming
   specifications) so that content delivery can be considered already
   solved (or at least sufficiently addressed in other forums).

   Thus, specification of scope.
   o  Element management interfaces.
   o  Commercial, business the content acquisition interface between CDNs
   and legal aspects related to the
      interconnections of CDNs.

A.2.  Related standardization activities

A.2.1.  IETF CDI Working Group (Concluded)

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

   For convenience, here is an extract from the CDI User Agent
   are out of scope for the CDNI working group
   charter [CDI-Charter]:

   "

   o group.  The goal of this CDNI working group is
   may only concern itself with the negotiation/selection aspects of the
   acquisition protocol to define protocols be used in a CDN interonnect scenario.

B.2.12.2.  CDNI Metadata

   CableLabs, ITU, OIPF and TV-Anytime have work items dedicated to allow the
      interoperation
   specification of separately-administered content networks. metadata:

   o  A content network is an architecture of network elements, arranged  CableLabs has defined specifications for efficient delivery CoD Content Metadata as
      part of digital content.  Such content includes,
      but its VOD Metadata project.  "The VOD Metadata project is not limited to, web pages a
      cable television industry and images delivered via HTTP, cross-industry-wide effort to
      specify the metadata and streaming or continuous media which are controlled by RTSP. 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.
   o  The working group will first define requirements for three modes  ITU Study Group 16 has started work on a number of draft
      Recommendations (H.IPTV-CPMD, H.IPTV-CPMD, HSTP.IPTV-CMA,
      HSTP.IPTV-UMCI) specifying metadata for 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. in
      IPTV services.
   o  In its initial form, the working group is not chartered to deliver
      those protocols [...]

   "

   Thus,  An Open IPTV Terminal receives the CDI working group touched on technical description of the same problem space as
      content distribution from the
   present document. OIPF IPTV platform before receiving
      any content.  The CDI working group 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".

A.2.2.  3GPP

   3GPP was distribution metadata is sent in the first organization that released
      format of a specification related TV-Anytime XSD including tags to adaptive streaming over HTTP. 3GPP Release 9 specification on
   adaptive HTTP streaming was published in March 2010, describes the
      location and there have
   been some bug fixes program type (on demand or Live) as well as
      describing the time availability of the on this specification since demand and live
      content.

   However the specifications outlined above do not include metadata
   specific to the distribution of content within a CDN or between
   interconnected CDNs, for example geo-blocking information,
   availability windows, access control mechanisms to be enforced by the publication.  In
   addition, 3GPP is preparing
   surrogate, how to map an extended version for Release 10, which
   is scheduled incoming content request to a file on the
   origin server or acquire it from the upstream CDN etc.

   The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata that can
   be published later in 2011.  This release will
   include associated with data that is stored by a number cloud storage provider.
   While the metadata currently defined do not match the needs of clarifications, improvements and new features.

   [3GP-DASH] CDN
   Interconnection, it is defined worth considering CDMI as a general framework independent one of the data
   encapsulation format.  It has support for fast initial startup and
   seeking, adaptive bitrate switching, re-use of HTTP origin and cache
   servers, re-use of existing media playout engines, on-demand, live
   and time-shifted delivery.  It specifies syntax and semantics of
   Media Presentation Description (MPD), format
   pieces of segments and delivery
   protocol work that may potentially be leveraged for segments.  It does not specify content provisioning,
   client behavior or transport of MPD.

   The content retrieved the CDNI
   Metadata interface (e.g by a client using [3GP-DASH] adaptive streaming
   could be obtained from a extending the CDMI metadata to address
   more specific CDNI needs).

B.3.  Related Research Projects

B.3.1.  IRTF P2P Research Group

   Some information on CDN but this is not discussed or specified interconnection motivations and technical
   issues were presented in the 3GPP specifications as it is transparent to [3GP-DASH]
   operations.  Similarly, it is expected that [3GP-DASH] P2P RG at IETF 77.  The presentation can
   be used
   transparently from the CDNs as found in [P2PRG-CDNI].

B.3.2.  OCEAN

   OCEAN (http://www.ict-ocean.eu/) is an EU funded research project
   that started in February 2010 for 3 years.  Some of its objectives
   are relevant to CDNI.  It aims, among other things, at designing a
   new architectural framework for audiovisual content delivery protocol (between over the
   delivering CDN surrogate
   Internet, defining public interfaces between its major building
   blocks in order to foster multi-vendor solutions and interconnection
   between Content Networks (the term "Content Networks" corresponds
   here to the User Agent) definition introduced in a [RFC3466], which encompasses
   CDNs).

   OCEAN has not yet published any open specifications, nor common best
   practices, defining how to achieve such CDN Interconnection
   environment. [3GP-DASH] could also be interconnection.

B.3.3.  Eurescom P1955

   Eurescom P1955 was a candidate for content
   acquisition between CDNs in 2010 research project involving a CDN Interconnection environment.

A.2.3.  ISO MPEG

   Within ISO MPEG, four European
   Network operators, which studied the Dynamic Adaptive Streaming over HTTP (DASH) ad-
   hoc group adopted interests and feasibility of
   interconnecting CDNs by firstly elaborating the 3GPP Release 9 [3GP-DASH] specification main service models
   around CDN interconnection, as a
   starting point well as analyzing an adequate CDN
   interconnection technical architecture and has framework, and finally by
   providing recommendations for telcos to implement CDN
   interconnection.  The Eurescom P1955 project ended in July 2010.

   The authors are not aware of material discussing CDN interconnection
   protocols or interfaces made some improvements publicly available as a deliverable of
   this project.

B.4.  Relationship to relevant IETF Working Groups

B.4.1.  ALTO

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

   "The Working Group will design and extensions.
   Similar 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 3GPP SA4, the MPEG DASH ad-hoc group has been user, etc.  The working on
   standardizing the manifest file and the delivery format.
   Additionally, the MPEG DASH ad-hoc group has also been working on will consider the
   use
   needs of MPEG-2 Transport Streams BitTorrent, tracker-less P2P, and other applications, such
   as a media format, conversion from/to
   existing file formats, common encryption, content delivery networks (CDN) and so on.  The MPEG DASH
   specification could also mirror selection."

   In particular, the ALTO service can be used by a candidate for delivery CDN Request Routing
   system to the User
   Agent and for content acquisition between CDNs in improve its selection of a CDN
   Interconnection environment.  The Draft International Standard (DIS)
   version [MPEG-DASH] is currently publicly available since early
   February 2011.

   In the 95th MPEG meeting in January 2011, the DASH ad-hoc group
   decided surrogate to start serve a new evaluation experiment called "CDN-EE".  The
   goals are to understand the requirements for MPEG DASH to better
   support CDN-based delivery, and
   particular User Agent request (or to provide serve a guidelines document for
   CDN operators to better support MPEG DASH streaming services.  The
   ongoing work is still very preliminary and does not currently target
   looking into CDN Interconnection request from another
   surrogate).  [I-D.jenkins-alto-cdn-use-cases] describes a number of
   use cases.

A.2.4.  ATIS IIF

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

   ATIS IIF is developing the "IPTV Content on Demand (CoD) Service"
   specification.  This includes use of a CDN (referred to in ATIS IIF
   CoD as the "Content Distribution be able to obtain network topology and cost
   information from an ALTO server(s) and Delivery Functions") for support
   of a Content on Demand (CoD) Service discusses how CDN Request
   Routing could be used as part an integration point of a broader IPTV
   service.  However, this only covers ALTO into CDNs.  It
   is possible that the case of a managed IPTV ALTO service (in particular where could be used in the same manner in
   a multi-CDN environment based on CDN is administered by Interconnection.  For example,
   an upstream CDN may take advantage of the ALTO service
   provider) and does not cover the use, or interconnection, of multiple
   CDNs.

A.2.5.  CableLabs

   "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]

   CableLabs has defined specifications
   decision for CoD Content Metadata as part
   of its VOD Metadata project.

A.2.6.  ETSI MCD

   ETSI MCD (Media Content Distribution) is selecting a downstream CDN to which a user request
   should be delegated.

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

   MCD created a specific does not
   overlap with the work item on interconnection of heterogeneous
   CDNs ("CDN Interconnection, use cases and requirements") described in March
   2010.  MCD very recently created a working group to progress this
   work item.  However, no protocol level work has yet started in MCD document because the
   integration between ALTO and a CDN is an internal decision for a
   specific CDN Interconnection.

A.2.7.  ETSI TISPAN

   ETSI TISPAN has published two sets of IPTV specifications, one of
   which and is based on IMS.  In addition, TISPAN therefore out of scope for the CDNI working
   group.  One area for further study is about whether additional information
   should be provided by an ALTO service to complete the
   specifications of a facilitate CDNI CDN architecture supporting delivery
   selection.

B.4.2.  DECADE

   The DECADE Working Group [DECADE-Charter] is addressing the problem
   of various
   content services such reducing traffic on the last-mile uplink, as time-shifted TV well as backbone and VoD to TISPAN devices
   (UEs) or regular PCs.  The use cases allow for hierarchically
   transit links caused by P2P streaming and
   geographically distributed CDN scenarios, along with multi-CDN
   cooperation.  As a result, file sharing applications.
   It addresses the architecture contains reference points problem by enabling an application endpoint to support interconnection of make
   content available from an in-network storage service and by enabling
   other TISPAN CDNs.  The protocol
   definition phase for application endpoints to retrieve the corresponding CDN architecture was kicked-
   off at content from there.

   Exchanging data through the end in-network storage service in this
   manner, instead of 2010.  In line with its long history through direct communication, provides significant
   gain where:

   o  The network capacity/bandwidth from in-network storage service to
      application endpoint significantly exceeds the capacity/bandwidth
      from application endpoint to application endpoint (e.g. because of leveraging
   IETF protocols, ETSI could potentially leverage CDNI interfaces
   developed in
      an end-user uplink bottleneck); and
   o  Where the IETF for their related protocol level work on
   interconnections content is to be accessed by multiple instances of CDNs.

A.2.8.  ITU-T

   SG13
      application endpoints (e.g. as is developing standards related to typically the support of IPTV services
   (i.e.. multimedia services such case for P2P
      applications).

   While, as television/VoD/audio/text/
   graphics/data delivered over IP-based managed networks).

   ITU-T Recommendation Y.1910 [Y.1910] provides is the description of case for any other data distribution application,
   the
   IPTV functional architecture.  This DECADE architecture includes functions and interfaces mechanisms could potentially be used for the distribution and delivery
   exchange of content.  This
   architecture is aligned with the ATIS IIF architecture.

   Based upon ITU-T Rec. Y.1910, ITU-T Rec. Y.2019 [Y.2019] describes in
   more detail the content delivery functional architecture.  This
   architecture allows CDN Interconnection: some interfaces (such as D3,
   D4) at the CDNI control level allow relationships plane information via an in-network-storage
   service (as opposed to directly between different CDNs,
   in the same domain or in different domains.  Generic procedures are
   described, but the choice of entities terminating the protocols is open.

A.2.9.  Open IPTV Forum (OIPF)

   The Open IPTV Forum has developed an end-to-end solution to allow any
   OIPF terminal to access enriched and personalized IPTV services
   either
   CDNI interfaces in a managed or a non-managed network[OIPF-Overview].  Some
   OIPF services (such the neighbor CDNs), we observe that:

   o  CDNI would operate as Network PVR) may be hosted in a CDN.

   To that end, "Content Distribution Application" from
      the Open IPTV Forum specification is made DECADE viewpoint (i.e. would operate on top of 5 parts:

   o  Media Formats including HTTP Adaptive Streaming
   o  Content Metadata
   o  Protocols
   o  Terminal (Declarative or Procedural Application Environment) DECADE).
   o  Authentication, Content Protection and Service Protection

A.2.10.  TV-Anytime Forum

   Version 1  There does not seem to be obvious benefits in integrating the
      DECADE control plane responsible for signaling information
      relating to control of the TV-Anytime Forum specifications were published as
   ETSI TS 102 822-1 through ETSI TS 102 822-7 "Broadcast and On-line
   Services: Search, select, in-network storage service itself, and rightful
      the CDNI control plane responsible for application-specific CDNI
      interactions (such as exchange of CDNI metadata, CDNI request
      redirection, transfer of CDNI logging information).
   o  There would typically be limited benefits in making use of content on personal a
      DECADE in-network storage systems ("TV-Anytime")".  It includes service because the specification CDNI interfaces are
      expected to be terminated by a very small number of
   content metadata CDNI clients
      (if not one) in XML schemas (ETSI TS 102 822-3) which define
   technical parameters each CDN, and the CDNI clients are expected to
      benefit from high bandwidth/capacity when communicating directly
      to each other (at least as high as if they were communicating via
      an in-network storage server).

   The DECADE in-network storage architecture and mechanisms may
   theoretically be used for the description acquisition of CoD and Live contents.
   The specification the content objects
   themselves between interconnected CDNs.  It is referenced by DVB and OIPF.

   The TV-anytime Forum was closed not expected that this
   would have obvious benefits in 2005.

A.2.11.  SNIA

   The Storage Networking Industry Association (SNIA) typical situations where a content
   object is acquired only once from an association
   of producers and consumers Upstream CDN to a Downstream CDN
   (and then distributed as needed inside the Downstream CDN).  But it
   might have benefits in some particular situations.  Since the
   acquisition protocol between CDNs is outside the scope of storage networking products whose goal the CDNI
   work, this question is to left for further study.

   The DECADE in-network storage networking technology architecture and applications.

   SNIA has published mechanisms may
   potentially also be used within a given CDN for the Cloud Data Management Interface (CDMI)
   standard ([SNIA-CDMI]).

   "The Cloud Data Management Interface defines distribution of
   the functional interface content objects themselves among surrogates of that applications will use to create, retrieve, update and delete
   data elements from CDN.  Since
   the Cloud.  As part of CDNI work does not concern itself with operation within a CDN,
   this interface question is left for further study.

   Therefore, the client
   will work of DECADE may be able complementary to discover but does not
   overlap with the capabilities of CDNI work described in this document.

B.4.3.  PPSP

   As stated in the cloud storage
   offering PPSP Working Group charter [PPSP-Charter]:

   "The Peer-to-Peer Streaming Protocol (PPSP) working group develops
   two signaling and use this interface to manage containers control protocols for a peer-to-peer (P2P)
   streaming system for transmitting live and the data
   that is placed in them.  In addition, metadata can be set on
   containers time-shifted media content
   with near real-time delivery requirements." and their contained data elements through this interface."

A.3.  Related Research Projects

A.3.1.  IRTF P2P Research Group

   Some information on CDN interconnection motivations "The PPSP working
   group designs a protocol for signaling and technical
   issues were presented in control between trackers
   and peers (the PPSP "tracker protocol") and a signaling and control
   protocol for communication among the P2P RG at IETF 77. peers (the PPSP "peer
   protocol").  The presentation can
   be found in [P2PRG-CDNI].

A.3.2.  OCEAN

   OCEAN (http://www.ict-ocean.eu/) two protocols enable peers to receive streaming data
   within the time constraints required by specific content items."

   Therefore PPSP is an EU funded research project
   that started in February 2010 for 3 years.  Some concerned with the distribution of its objectives
   are relevant to CDNI.  It aims, among other things, at designing a
   new architectural framework for audiovisual the streamed
   content delivery over itself along with the
   Internet, defining public interfaces between its major building
   blocks in order to foster multi-vendor solutions necessary signaling and interconnection
   between Content Networks (the term "Content Networks" corresponds
   here control
   required to distribute the definition introduced in [RFC3466], which encompasses
   CDNs).

   OCEAN has content.  As such, it could potentially be
   used for the acquisition of streamed content across interconnected
   CDNs.  But since the acquisition protocol is outside the scope of the
   work proposed for CDNI, we leave this for further study.  Also,
   because of its streaming nature, PPSP is not yet published any open specifications, nor common best
   practices, defining how seen as applicable to achieve such CDN interconnection.

A.3.3.  Eurescom P1955

   Eurescom P1955 was a 2010 research project involving a four European
   Network operators, which studied
   the interests distribution and feasibility control of
   interconnecting CDNs by firstly elaborating the main service models
   around CDN interconnection, as well as analyzing an adequate CDN
   interconnection technical architecture and framework, CDNI control plane and finally by
   providing recommendations for telcos CDNI data
   representations.

   Therefore, the work of PPSP may be complementary to implement CDN
   interconnection.  The Eurescom P1955 project ended in July 2010.

   The authors are but does not aware of material discussing CDN interconnection
   protocols or interfaces made publically available as a deliverable of
   overlap with the work described in this project. document for CDNI.

Authors' Addresses

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

   Email: ben@velocix.com

   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