    Internet Engineering Task Force (IETF)                  B. Niven-Jenkins
    Request for Comments: 6707                      Velocix (Alcatel-Lucent)
    Category: Informational                                   F. Le Faucheur
    ISSN: 2070-1721                                                    Cisco
                                                                    N. Bitar
                                                                     Verizon
                                                              September 2012

     Content Distribution Network Interconnection (CDNI) Problem Statement

    Abstract

       Content Delivery Networks (CDNs) provide numerous benefits for
       cacheable content: reduced delivery cost, 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 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 document is not an Internet Standards Track specification; it is
       published for informational purposes.

       This document is a product of the Internet Engineering Task Force
       (IETF).  It represents the consensus of the IETF community.  It has
       received public review and has been approved for publication by the
       Internet Engineering Steering Group (IESG).  Not all documents
       approved by the IESG are a candidate for any level of Internet
       Standard; see Section 2 of RFC 5741.

       Information about the current status of this document, any errata,
       and how to provide feedback on it may be obtained at
       http://www.rfc-editor.org/info/rfc6707.

    Niven-Jenkins, et al.         Informational                     [Page 1]

    RFC 6707          CDN Interconnection Problem Statement   September 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 ....................................................3
          1.1. Terminology ................................................4
          1.2. CDN Background .............................................9
       2. CDN Interconnection Use Cases ...................................9
       3. CDN Interconnection Model and Problem Area for IETF ............11
       4. Scoping the CDNI Problem .......................................15
          4.1. CDNI Control Interface ....................................16
          4.2. CDNI Request Routing Interface ............................16
          4.3. CDNI Metadata Interface ...................................17
          4.4. CDNI Logging Interface ....................................17
       5. Security Considerations ........................................17
          5.1. Security of the CDNI Control Interface ....................18
          5.2. Security of the CDNI Request Routing Interface ............18
          5.3. Security of the CDNI Metadata Interface ...................19
          5.4. Security of the CDNI Logging Interface ....................19
       6. Acknowledgements ...............................................19
       7. Informative References .........................................20
       Appendix A. Design Considerations for Realizing the CDNI
                   Interfaces ............................................22
         A.1. CDNI Control Interface .....................................22
         A.2. CDNI Request Routing Interface .............................23
         A.3. CDNI Metadata Interface ....................................25
         A.4. CDNI Logging Interface .....................................26
       Appendix B. Additional Material ...................................27
         B.1. Non-Goals for IETF .........................................27
         B.2. Relationship to Relevant IETF Working Groups and IRTF
              Research Groups ............................................29
           B.2.1. ALTO WG ................................................29
           B.2.2. DECADE WG ..............................................29
           B.2.3. PPSP WG ................................................31
           B.2.4. IRTF P2P Research Group ................................31

    Niven-Jenkins, et al.         Informational                     [Page 2]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

    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 for cacheable content: reduced
       delivery cost, improved quality of experience for End Users (EUs),
       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 EU regardless of that EU's location or the network they are
       attached to.  However, a given CDN in charge of delivering a given
       content may not have a footprint that expands close enough to the
       EU'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 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 EUs.  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 Providers to
       distribute and deliver some or all of the content on behalf of the
       Authoritative CDN Provider.

       A typical end-to-end content delivery scenario would then involve the
       following business arrangements:

       o  A business arrangement between the EU and his CSP, authorizing
          access by the EU to content items controlled by the CSP.

       o  A business arrangement between the CSP and an "authoritative" CDN
          Provider where the CSP mandates that the CDN Provider perform the
          content delivery on behalf of the CSP.

       o  A business arrangement between the Authoritative CDN Provider and
          another (or other) CDN(s) where the Authoritative CDN may delegate
          the actual serving of some of the content delivery requests to the
          other CDN(s).  A particular case is where this other CDN Provider
          happens to also be the Network Service Provider providing network
          access to the EU, in which case there is also a separate and
          independent business relationship between the EU and the NSP for
          the corresponding network access.

    Niven-Jenkins, et al.         Informational                     [Page 3]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       The formation and details of any business relationships between a CSP
       and a CDN Provider as well as between one CDN Provider and another
       CDN Provider are out of scope of this document.  However, this
       document concerns itself with the fact that no standards or open
       specifications currently exist to facilitate such CDN Interconnection
       from a technical perspective.

       One possible flow for performing an end-to-end content delivery
       across a CDN Interconnection is described below:

       o  The initial content request from an EU's User Agent is first
          received by the authoritative (upstream) CDN, which is the CDN
          with a business arrangement with the CSP.

       o  The authoritative (upstream) CDN may serve the request itself, or
          it may elect to use CDN Interconnection to redirect the request to
          a Downstream CDN that is in a better position to do so (e.g., a
          Downstream CDN that is "closer" to the EU).

       o  The EU's User Agent will "follow" the redirect returned by the
          Authoritative CDN and request the content from the Downstream CDN.
          If required, the Downstream CDN will acquire the requested content
          from the authoritative (upstream) CDN, and if necessary the
          Authoritative CDN will acquire the requested content from the
          Content Service Provider.

       The goal of this document is to outline the problem area of CDN
       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.  Appendix B.2 describes the relationships between
       the CDNI problem space and other relevant IETF working groups and
       IRTF research groups.

    1.1.  Terminology

       This document uses the following terms:

       Authoritative CDN: A CDN that has a direct relationship with a CSP
       for the distribution and delivery of that CSP's content by the
       Authoritative CDN or by Downstream CDNs of the Authoritative CDN.

       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
       realized through a set of interfaces over which a pair of CDNs

    Niven-Jenkins, et al.         Informational                     [Page 4]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

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

       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.

       CDNI Metadata: The subset of Content Distribution Metadata that
       has an 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., pre-positioned vs dynamic acquisition) and about where/
       how a CDN can acquire the content.

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

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

       Content Distribution Network (CDN) / Content Delivery Network (CDN):
       Network infrastructure in which the network elements cooperate at
       Layers 4 through 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.

    Niven-Jenkins, et al.         Informational                     [Page 5]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       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 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. that may not require any direct interaction with
       the CDN, or CDNs, involved in the distribution and delivery of the
       content.

       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.

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

       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.

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

       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

    Niven-Jenkins, et al.         Informational                     [Page 6]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

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

       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).  See also
       the definitions for Downstream CDN and Upstream CDN.

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

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

       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.

       Metadata: Metadata in general is data about data.

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

       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.

       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
       independently of, any End User requesting that content from the
       Downstream CDN.

    Niven-Jenkins, et al.         Informational                     [Page 7]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       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 independently of, any End User
       requesting it.

       Quality of Experience (QoE): As defined in Section 2.4 of [RFC6390].

       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.

       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.  Typically, Surrogates will cache requested
       content so that they can directly deliver the same content in
       response to requests from multiple User Agents (and their End Users),
       avoiding the need for the content to transit multiple times through
       the network core (i.e., from the content origin to the Surrogate).

       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.

       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.

    Niven-Jenkins, et al.         Informational                     [Page 8]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

    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 Distribution Internetworking (CDI) working group,
          which was closed in 2003.

       Note: Some of the terms used in this document are similar to terms
       used in 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 in 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

    Niven-Jenkins, et al.         Informational                     [Page 9]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       need for interconnection of these CDNs; this 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 numbers of End 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 delivery (i.e., within the Network Service Provider's own
       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, 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 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
       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
       [CDNI-USE-CASES].

    Niven-Jenkins, et al.         Informational                    [Page 10]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

    3.  CDN Interconnection Model and 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 additional specification by the IETF.

       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 in
       [CDNI-EXPERIMENTS].  The conclusions of those experiments are that
       while some basic limited CDN Interconnection functionality can be
       achieved with existing CDN technology, the current lack of any
       standardized CDNI interfaces with the necessary level of
       functionality such as those discussed in this document is preventing
       the deployment of CDN Interconnection.

       Listed below are the four interfaces required to interconnect a pair
       of CDNs and that constitute the problem space 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 interfaces, it will also be necessary to agree on common
       mechanisms for how to identify and name the 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.

    Niven-Jenkins, et al.         Informational                    [Page 11]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

          *  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, to allow
             an Upstream CDN to initiate content or CDNI Metadata
             acquisition (pre-positioning) or to request the invalidation
             or purging of content files and/or CDNI Metadata 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
          functions of the CDN Request Routing interface may be divided as
          follows:

          *  A CDNI Request Routing Redirection interface, which allows the
             Upstream CDN to query the Downstream CDN at request routing
             time before redirecting the request to the Downstream CDN.

          *  A CDNI Footprint & Capabilities advertisement interface, which
             allows 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 interface: This interface allows the Distribution
          system in interconnected CDNs to communicate to ensure that CDNI
          Metadata can be exchanged across CDNs.  See Section 1.1 for the
          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 environment.  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.

    Niven-Jenkins, et al.         Informational                    [Page 12]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       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 may 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
       reuse or leverage existing protocols to a very significant extent;
       this is discussed further in Section 4.

       The interfaces that form the CDNI problem area are illustrated in
       Figure 1.

    Niven-Jenkins, et al.         Informational                    [Page 13]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

         --------
        /        \
        |   CSP  |
        \        /
         --------
             *
             *
             *                         /\
             *                        /  \
         ----------------------      |CDNI|        ----------------------
        /     Upstream CDN     \     |    |       /    Downstream 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 the scope of CDNI
      ****  interfaces outside the scope of CDNI
      ....  interfaces outside the scope of CDNI

                    Figure 1: A Model for the CDNI Problem Area

    Niven-Jenkins, et al.         Informational                    [Page 14]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       As illustrated in Figure 1, the acquisition of content between
       interconnected CDNs is out of scope for CDNI; this deserves some
       additional explanation.  The consequence of such a decision is that
       the CDNI problem space described in this document is focused on only
       defining the control plane for CDNI, and the CDNI data plane (i.e.,
       the acquisition and distribution of the actual content objects) is
       out of scope.  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
       with respect to content acquisition from specifications developed by
       the CDNI working group is to describe within the CDNI Metadata the
       parameters to use to retrieve the content -- for example, the IP
       address/hostname to connect to, what protocol to use to retrieve the
       content, etc.

    4.  Scoping the CDNI Problem

       This section outlines how the scope of work addressing the CDNI
       problem space can be constrained through reuse or leveraging of
       existing protocols to implement the CDNI interfaces.  This discussion
       is not intended to preempt 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 of existing protocols is likely possible.

       The four CDNI interfaces (CDNI Control interface, CDNI Request
       Routing interface, CDNI Metadata interface, and 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 is not
       expected that these interfaces would exhibit unique session,
       transport, or network requirements as compared to the many other
       existing applications in the Internet, 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 could be designed
       specifically for CDNI, our analysis below shows that this is
       unnecessary, and it is recommended that existing application
       protocols be reused or leveraged (HTTP [RFC2616], the Atom Publishing
       Protocol [RFC5023], the Extensible Messaging and Presence Protocol
       (XMPP) [RFC6120], for example) to realize the CDNI interfaces.

    Niven-Jenkins, et al.         Informational                    [Page 15]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

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

    4.2.  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 is able (and
       willing) to accept the delegated Content Request.  It also allows the
       Downstream CDN to control what should be returned to the User Agent
       in the redirection message by the upstream Request Routing function.

       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 (Extensible Markup Language-Remote Procedure Calling
       (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.

       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 Application-Layer Traffic Optimization
       (ALTO) [RFC5693]).

    Niven-Jenkins, et al.         Informational                    [Page 16]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

    4.3.  CDNI Metadata Interface

       The CDNI Metadata interface enables the Distribution system in a
       Downstream CDN to request CDNI Metadata from an Upstream CDN so that
       the Downstream CDN can properly process and respond to redirection
       requests received over the CDNI Request Routing interface and Content
       Requests received directly from User Agents.

       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.

    4.4.  CDNI Logging Interface

       The CDNI Logging interface enables details of content distribution
       and delivery activities to be exchanged between interconnected CDNs
       -- for example, the exchange of log records related to the delivery
       of content, similar to the log records recorded in a web server's
       access log.

       Several protocols already exist that could potentially be used to
       exchange CDNI logs between interconnected CDNs, including the Simple
       Network Management Protocol (SNMP), syslog, FTP (and secure
       variants), HTTP POST, etc.

    5.  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 End Users in line with the CSP policy, or how to trust the
       logging information generated by the CDN for the purposes of charging
       the CSP.  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 to a chain of trust
       (i.e., the CSP "trusts" a CDN that "trusts" another CDN).  The
       mechanisms used to mitigate these risks in multi-CDN environments may
       be similar to those used in the single-CDN case, but their
       suitability in this more complex environment must be validated.

    Niven-Jenkins, et al.         Informational                    [Page 17]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       The interconnection of CDNs may also introduce additional privacy
       considerations on top of those that apply to the single-CDN case.  In
       a multi-CDN environment, the different CDNs may reside in different
       legal regimes that require differing privacy requirements to be
       enforced.  Such privacy requirements may impact the granularity of
       information that can be exchanged across the CDNI interfaces.  For
       example, the Logging system in a Downstream CDN may need to apply
       some degree of anonymization, obfuscation, or even the complete
       removal of some fields before exchanging log records containing
       details of End User deliveries with an Upstream CDN.

       Maintaining the security of the content itself, its associated
       metadata (including delivery policies), and the CDNs distributing and
       delivering it, are critical requirements for both CDN Providers and
       CSPs, and the CDN Interconnection interfaces must provide sufficient
       mechanisms to maintain the security of the overall system of
       interconnected CDNs as well as the information (content, metadata,
       logs, etc.) distributed and delivered through any set of
       interconnected CDNs.

    5.1.  Security of the CDNI Control Interface

       Information exchanged between interconnected CDNs over this interface
       is of a sensitive nature.  A pair of CDNs use this interface to allow
       bootstrapping of all the other CDNI interfaces, possibly including
       establishment of the mechanisms for securing these interfaces.
       Therefore, corruption of that interface may result in corruption of
       all other interfaces.  Using this interface, an Upstream CDN may
       pre-position or delete content or metadata in a Downstream CDN, a
       Downstream CDN may provide administrative information to an Upstream
       CDN, etc.  All of these operations require that the peer CDNs are
       appropriately authenticated and that the confidentiality and
       integrity of information flowing between them can be ensured.

    5.2.  Security of the CDNI Request Routing Interface

       Appropriate levels of authentication and confidentiality must be used
       in this interface because it allows an Upstream CDN to query the
       Downstream CDN in order to redirect requests, and conversely, allows
       the Downstream CDN to influence the Upstream CDN's Request Routing
       function.

       In the absence of appropriate security on this interface, a rogue
       Upstream CDN could inundate Downstream CDNs with bogus requests or
       have the Downstream CDN send the rogue Upstream CDN private
       information.  Also, a rogue Downstream CDN could influence the

    Niven-Jenkins, et al.         Informational                    [Page 18]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       Upstream CDN so the Upstream CDN redirects requests to the rogue
       Downstream CDN or another Downstream CDN in order to, for example,
       attract additional delivery revenue.

    5.3.  Security of the CDNI Metadata Interface

       This interface allows a Downstream CDN to request CDNI Metadata from
       an Upstream CDN, and therefore the Upstream CDN must ensure that the
       former is appropriately authenticated before sending the data.
       Conversely, a Downstream CDN must authenticate an Upstream CDN before
       requesting metadata to insulate itself from poisoning by rogue
       Upstream CDNs.  The confidentiality and integrity of the information
       exchanged between the peers must be protected.

    5.4.  Security of the CDNI Logging Interface

       Logging data consists of potentially sensitive information (which End
       User accessed which media resource, IP addresses of End Users,
       potential names and subscriber account information, etc.).
       Confidentiality of this information must be protected as log records
       are moved between CDNs.  This information may also be sensitive from
       the viewpoint that it can be the basis for charging across CDNs.
       Therefore, appropriate levels of protection are needed against
       corruption, duplication, and loss of this information.

    6.  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, Larry Peterson, Emile
       Stephan, Oskar van Deventer, Mahesh Viveganandhan, and Richard Woundy
       for their review comments and contributions to the text.

    Niven-Jenkins, et al.         Informational                    [Page 19]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

    7.  Informative References

       [ALTO-CDN-USE-CASES]
                  Niven-Jenkins, B., Ed., Watson, G., Bitar, N., Medved, J.,
                  and S. Previdi, "Use Cases for ALTO within CDNs", Work
                  in Progress, June 2012.

       [ALTO-Charter]
                  "IETF ALTO WG Charter",
                  <http://datatracker.ietf.org/wg/alto/charter/>.

       [CDNI-EXPERIMENTS]
                  Bertrand, G., Ed., Le Faucheur, F., and L. Peterson,
                  "Content Distribution Network Interconnection (CDNI)
                  Experiments", Work in Progress, February 2012.

       [CDNI-USE-CASES]
                  Bertrand, G., Ed., Emile, S., Burbridge, T., Eardley, P.,
                  Ma, K., and G. Watson, "Use Cases for Content Delivery
                  Network Interconnection", Work in Progress, August 2012.

       [DECADE-Charter]
                  "IETF DECADE WG Charter",
                  <http://datatracker.ietf.org/wg/decade/charter/>.

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

       [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 G. Tomlinson, "Internet Web
                  Replication and Caching Taxonomy", RFC 3040, January 2001.

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

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

    Niven-Jenkins, et al.         Informational                    [Page 20]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

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

       [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
                  Optimization (ALTO) Problem Statement", RFC 5693,
                  October 2009.

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

       [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
                  Performance Metric Development", BCP 170, RFC 6390,
                  October 2011.

       [TAXONOMY] Pathan, A. and R. Buyya, "A Taxonomy and Survey of Content
                  Delivery Networks", 2007,
                  <http://www.cloudbus.org/reports/CDN-Taxonomy.pdf>.

    Niven-Jenkins, et al.         Informational                    [Page 21]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

    Appendix A.  Design Considerations 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.  However,
       the options discussed here are purely examples and do not present any
       consensus on protocols to be used later on.

    A.1.  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.

       However, as discussed in Section 3, the CDNI Control interface may be
       required to support functionality similar to the following:

       o  Allow an Upstream CDN and 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 the other CDNI interfaces (e.g., Upstream
          CDN specifies information to be reported through the CDNI Logging
          interface).

       o  Allow the Downstream CDN to communicate static information about
          its delivery capabilities, resources, and policies.

       o  Allow bootstrapping of the interface between CDNs for content
          acquisition (even if that interface itself is outside the scope of
          the CDNI work).

       It is expected that for the Control interface, as for the other CDNI
       interfaces, existing protocols can be reused or leveraged.  Those
       will be considered once the requirements for the Control interface
       have been refined.

    Niven-Jenkins, et al.         Informational                    [Page 22]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

    A.2.  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 is able (and
       willing) to accept the delegated Content Request and to allow the
       Downstream CDN to control what the upstream Request Routing function
       should return to the User Agent in the redirection message.

       Therefore, the CDNI Request Routing interface needs to offer a
       mechanism for an Upstream CDN to issue a "Redirection Request" to a
       Downstream CDN.  The Request Routing interface needs to be able to
       support scenarios where the initial User Agent request to the
       Upstream CDN is received over DNS as well as over a content-specific
       application protocol (e.g., HTTP, the Real Time Streaming Protocol
       (RTSP), the Real Time Messaging Protocol (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 the User Agent request that are required to
          perform effective Request Routing by the Downstream CDN.  For DNS,
          this would typically be the IP address of the DNS resolver making
          the request on behalf of the User Agent.  For requests received
          over content-specific application protocols, the Redirection
          Request could contain significantly more information related to
          the original User Agent request but at a minimum is expected to
          include the User Agent's IP address, the equivalent of the HTTP
          Host header, and the equivalent of the HTTP abs_path as defined in
          [RFC2616].

       It should be noted that the CDNI architecture needs to consider that
       a Downstream CDN may receive requests from User Agents without first
       receiving a Redirection Request from an Upstream CDN for the
       corresponding User Agent request because, for example:

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

    Niven-Jenkins, et al.         Informational                    [Page 23]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       o  Some CDNs may rely on simple coarse policies, e.g., CDN B agrees
          to always serve CDN A's delegated redirection requests, 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 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 the application-specific
          redirection response(s) to return to the requesting User Agent.
          For HTTP requests from User Agents, this could include a URI that
          the Upstream CDN could return in an HTTP 3xx response.

       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.

    Niven-Jenkins, et al.         Informational                    [Page 24]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

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

    A.3.  CDNI Metadata Interface

       The CDNI Metadata interface enables the Distribution system in a
       Downstream CDN to obtain CDNI Metadata from an Upstream CDN so that
       the Downstream CDN can properly process and respond to:

       o  Redirection Requests received over the CDNI Request Routing
          interface.

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

    Niven-Jenkins, et al.         Informational                    [Page 25]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       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 the
          individual properties of a Metadata object.

       o  How the relationships between different CDNI Metadata objects are
          represented.

    A.4.  CDNI Logging Interface

       The CDNI Logging interface enables details of content distribution
       and delivery activities to be exchanged between interconnected CDNs,
       such as log records related to the delivery of content (similar to
       the log records recorded in a web server's access log).

       Within CDNs today, log records are used for a variety of purposes.
       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 CDNI Logging interface to support guaranteed and timely
       delivery of log messages between interconnected CDNs.  It may also be
       necessary to be able to prove the integrity 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 well suited to meet all the
       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 consequent
       CDRs and billing records for that content delivery not being
       produced, as well as that content delivery being invisible to any
       analytics platforms.

    Niven-Jenkins, et al.         Informational                    [Page 26]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       Although it is not necessary to define a new protocol 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 and of their syntax and semantics.
          Today there is 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 same delivery protocol.

       o  A default set of conditions that trigger log records to be
          generated.

    Appendix B.  Additional Material

       This section records related information that was produced as part of
       defining the CDNI problem statement.

    B.1.  Non-Goals for IETF

       Listed below are aspects of content delivery that the authors propose
       be kept outside of the scope of the CDNI working group:

       o  The interface between the Content Service Provider and the
          Authoritative CDN (i.e., the Upstream CDN contracted by the CSP
          for delivery by this CDN or by its Downstream CDNs).

       o  The delivery interface between the delivering CDN Surrogate and
          the User Agent, such as streaming protocols.

       o  The request interface between the User Agent and the Request
          Routing system 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 systems to redirect
          the User Agent requests.  The CDNI working group need not define
          new protocols for this purpose.  Note, however, that the CDNI
          control plane interface may indirectly affect some of the
          information exchanged through the request interface (e.g., URI).

       o  The content acquisition interface between CDNs (i.e., the data
          plane interface for actual delivery of a piece of content from one
          CDN to the other).  This is expected to use existing protocols
          such as HTTP or protocols defined in other forums for content
          acquisition between an origin server and a CDN (e.g., HTTP-based
          C2 reference point of the Alliance for Telecommunications Industry
          Solutions IPTV Interoperability Forum Content on Demand service

    Niven-Jenkins, et al.         Informational                    [Page 27]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

          (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 used between two interconnected CDNs in view of
          facilitating interoperability.

       o  End User/User Agent Authentication.  End User/User Agent
          authentication and authorization are the responsibility of the
          Content Service Provider.

       o  Content preparation, including encoding and transcoding.  The CDNI
          architecture aims at allowing distribution across interconnected
          CDNs of content treated as opaque objects.  Interpretation and
          processing of the objects, as well as optimized delivery of these
          objects by the 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 logs (e.g., charging, analytics,
          reporting, ...).

       o  Internal CDN interfaces and protocols (i.e., interfaces and
          protocols within one CDN).

       o  Scalability of individual CDNs.  While scalability of the CDNI
          interfaces/approach is in scope, how an individual CDN scales is
          out of scope.

       o  Actual algorithms for selection of CDNs or Surrogates by Request
          Routing systems (however, some specific parameters required as
          input to these algorithms may be in 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 the CDNI work.
          Content management (e.g., Content Deletion) as it relates to CDNI
          content management policies is in scope, but the internal
          algorithms used by a cache to determine when to no longer cache an
          item of Content (in the absence of any specific metadata to the
          contrary) is out of scope.

       o  Element management interfaces.

       o  Commercial, business, and legal aspects related to the
          interconnections of CDNs.

    Niven-Jenkins, et al.         Informational                    [Page 28]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

    B.2.  Relationship to Relevant IETF Working Groups and IRTF Research
          Groups

    B.2.1.  ALTO WG

       As stated in the ALTO working group charter [ALTO-Charter]:

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

       In particular, the ALTO service can be used by a CDN Request Routing
       system to improve its selection of a CDN Surrogate to serve a
       particular User Agent request (or to serve a request from another
       Surrogate).  [ALTO-CDN-USE-CASES] describes a number of use cases for
       a CDN to be able to obtain network topology and cost information from
       an ALTO server(s) and discusses how CDN Request Routing could be used
       as an integration point of ALTO into CDNs.  It is possible that the
       ALTO service could be used in the same manner in a multi-CDN
       environment based on CDN Interconnection.  For example, an Upstream
       CDN may take advantage of the ALTO service in its decision for
       selecting a Downstream CDN to which a user request should be
       delegated.

       However, the current work of ALTO is complementary to and does not
       overlap with the work described in this document because the
       integration between ALTO and a CDN is an internal decision for a
       specific CDN and is therefore out of scope for the CDNI working
       group.  One area for further study is whether additional information
       should be provided by an ALTO service to facilitate CDNI CDN
       selection.

    B.2.2.  DECADE WG

       The DECADE working group [DECADE-Charter] is addressing the problem
       of reducing traffic on the last-mile uplink, as well as backbone and
       transit links caused by peer-to-peer (P2P) streaming and file-sharing
       applications.  It addresses the problem by enabling an application
       endpoint to make content available from an in-network storage service
       and by enabling other application endpoints to retrieve the content
       from there.

    Niven-Jenkins, et al.         Informational                    [Page 29]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       Exchanging data through the in-network storage service in this
       manner, instead of through direct communication, provides significant
       gain where:

       o  The network capacity/bandwidth from the in-network storage service
          to the application endpoint significantly exceeds the capacity/
          bandwidth from application endpoint to application endpoint (e.g.,
          because of an end-user uplink bottleneck); and

       o  The content 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 in the neighbor CDNs), we observe that:

       o  CDNI would operate as a "Content Distribution Application" from
          the DECADE viewpoint (i.e., would operate on top of DECADE).

       o  There do not seem to be obvious benefits in integrating the DECADE
          control plane responsible for signaling information relating to
          control of the in-network storage service itself, and the CDNI
          control plane responsible for application-specific CDNI
          interactions (such as exchange of CDNI Metadata, CDNI request
          redirection, and transfer of CDNI logging information).

       o  There would typically be limited benefits in making use of a
          DECADE in-network storage service because the CDNI interfaces are
          expected to be terminated by a very small number of CDNI clients
          (if not one) in 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 acquisition of the content objects
       themselves between interconnected CDNs.  It is not expected that this
       would have obvious benefits in typical situations where a content
       object is acquired only once from an 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 the CDNI
       work, this question is left for further study.

    Niven-Jenkins, et al.         Informational                    [Page 30]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

       The DECADE in-network storage architecture and mechanisms may
       potentially also be used within a given CDN for the distribution of
       the content objects themselves among Surrogates of that CDN.  Since
       the CDNI work does not concern itself with operation within a CDN,
       this question is left for further study.

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

    B.2.3.  PPSP WG

       As stated in the PPSP working group charter [PPSP-Charter]:

          The Peer-to-Peer Streaming Protocol (PPSP) 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...

          ...  The PPSP working group designs a protocol for signaling and
          control between trackers and peers (the PPSP "tracker protocol")
          and a signaling and control protocol for communication among the
          peers (the PPSP "peer protocol").  The two protocols enable peers
          to receive streaming data within the time constraints required by
          specific content items.

       Therefore, PPSP is concerned with the distribution of the streamed
       content itself along with the necessary signaling and control
       required to distribute the 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 seen as applicable to
       the distribution and control of the CDNI control plane and CDNI data
       representations.

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

    B.2.4.  IRTF P2P Research Group

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

    Niven-Jenkins, et al.         Informational                    [Page 31]

    RFC 6707          CDN Interconnection Problem Statement   September 2012

    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
       60 Sylvan Road
       Waltham, MA  02145
       USA

       EMail: nabil.n.bitar@verizon.com

    Niven-Jenkins, et al.         Informational                    [Page 32]