GENWiki

Premier IT Outsourcing and Support Services within the UK

User Tools

Site Tools


rfc:rfc7337

Internet Engineering Task Force (IETF) K. Leung, Ed. Request for Comments: 7337 Cisco Category: Informational Y. Lee, Ed. ISSN: 2070-1721 Comcast

                                                           August 2014
  Content Distribution Network Interconnection (CDNI) Requirements

Abstract

 Content delivery is frequently provided by specifically architected
 and provisioned Content Delivery Networks (CDNs).  As a result of
 significant growth in content delivered over IP networks, existing
 CDN providers are scaling up their infrastructure.  Many Network
 Service Providers (NSPs) and Enterprise Service Providers (ESPs) are
 also deploying their own CDNs.  To deliver contents from the Content
 Service Provider (CSP) to end users, the contents may traverse across
 multiple CDNs.  This creates a need for interconnecting (previously)
 standalone CDNs so that they can collectively act as a single
 delivery platform from the CSP to the end users.
 The goal of the present document is to outline the requirements for
 the solution and interfaces to be specified by the CDNI 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/rfc7337.

Leung & Lee Informational [Page 1] RFC 7337 CDNI Requirements August 2014

Copyright Notice

 Copyright (c) 2014 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 ....................................................2
    1.1. Terminology ................................................3
 2. CDNI Model and CDNI Interfaces ..................................4
 3. Generic CDNI Requirements .......................................6
 4. CDNI Control Interface Requirements .............................7
 5. CDNI Request Routing Redirection Interface Requirements ........10
 6. CDNI Footprint & Capabilities Advertisement Interface
    Requirements ...................................................12
 7. CDNI Metadata Interface Requirements ...........................14
 8. CDNI Logging Interface Requirements ............................18
 9. CDNI Security Requirements .....................................20
 10. Security Considerations .......................................21
 11. Contributors ..................................................21
 12. Acknowledgements ..............................................21
 13. References ....................................................22
    13.1. Normative References .....................................22
    13.2. Informative References ...................................22

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 of the significant
 growth in content delivered over IP networks, existing CDN providers
 are scaling up their infrastructure and many NSPs and ESPs are
 deploying their own CDNs.  Subject to the policy of the Content
 Service Provider (CSP), it is generally desirable that a given item

Leung & Lee Informational [Page 2] RFC 7337 CDNI Requirements August 2014

 of content can be delivered to an end user regardless of that end
 user's location or attachment network.  This creates a need for
 interconnecting (previously) standalone CDNs so they can interoperate
 and collectively behave as a single delivery infrastructure.  The
 Content Distribution Network Interconnection (CDNI) working group has
 been chartered to develop an interoperable and scalable solution for
 such CDN interconnections.
 The CDNI Problem Statement [RFC6707] outlines the problem area that
 the CDNI working group is chartered to address.  The Use Cases for
 CDNI document [RFC6770] discusses the use cases for CDN
 Interconnection.  The Framework for CDN Interconnection [RFC7336]
 discusses the technology framework for the CDNI solution and
 interfaces.
 The goal of the present document is to document the requirements for
 the CDNI solution and interfaces.  In order to meet the time lines
 defined in the working group charter, the present document
 categorizes the CDNI requirements as "High Priority", "Medium
 Priority", and "Low Priority".

1.1. Terminology

 This document uses the terminology defined in [RFC6707].  In
 addition, the key words "High Priority", "Medium Priority", and "Low
 Priority" in this document are to be interpreted as follows:
 o  "High Priority": When a requirement is tagged as "{HIGH}", it is
    considered by the working group as an essential function for CDNI
    and necessary to a deployable solution.  This requirement has to
    be met even if it causes a delay in the delivery by the working
    group of a deployable solution.
 o  "Medium Priority": When a requirement is tagged as "{MED}", it is
    considered by the working group as an important function for CDNI.
    This requirement has to be met, unless it is established that
    attempting to meet this requirement would cause a delay in the
    delivery by the working group of a deployable solution.
 o  "Low Priority": When a requirement is tagged as "{LOW}", it is
    considered by the working group as a useful function for CDNI.
    The working group will attempt to meet this requirement as long as
    it does not prevent meeting the "High Priority" and "Medium
    Priority" requirements and does not cause a delay in the delivery
    by the working group of a deployable solution.

Leung & Lee Informational [Page 3] RFC 7337 CDNI Requirements August 2014

2. CDNI Model and CDNI Interfaces

 The "CDNI Expanded Model and CDNI Interfaces" figure and brief
 descriptions of the CDNI interfaces in [RFC7336] are replicated below
 for convenience.  That document contains the definitive reference
 model and descriptions for the CDNI interfaces.
 o  CDNI Control interface (CI): Operations to bootstrap and
    parameterize the other CDNI interfaces, as well as operations to
    pre-position, revalidate, and purge both metadata and content.
    The latter subset of operations is sometimes collectively called
    the "Trigger interface."
 o  CDNI Request Routing interface: Operations to determine what CDN
    (and optionally what Surrogate within a CDN) is to serve an end
    user's requests.  This interface is actually a logical bundling of
    two separate but related interfaces:
  • CDNI Footprint & Capabilities Advertisement interface (FCI):

Asynchronous operations (as defined in [RFC7336]) to exchange

       routing information (e.g., the network footprint and
       capabilities served by a given CDN) that enables CDN selection
       for subsequent user requests; and
  • CDNI Request Routing Redirection interface (RI): Synchronous

operations (as defined in [RFC7336]) to select a delivery CDN

       (Surrogate) for a given user request.
 o  CDNI Metadata interface (MI): Operations to communicate metadata
    that governs how the content is delivered by interconnected CDNs.
    Examples of CDNI Metadata include geo-blocking directives,
    availability windows, access control mechanisms, and purge
    directives.  It may include a combination of:
  • Asynchronous operations to exchange metadata that govern

subsequent user requests for content; and

  • Synchronous operations that govern behavior for a given user

request for content.

 o  CDNI Logging interface (LI): Operations that allow interconnected
    CDNs to exchange relevant activity logs.  It may include a
    combination of:
  • Real-time exchanges, suitable for runtime traffic monitoring;

and

  • Offline exchanges, suitable for analytics and billing.

Leung & Lee Informational [Page 4] RFC 7337 CDNI Requirements August 2014

  1. ——-

/ \

   |   CSP  |
   \        /
    --------
        *
        *
        *                         /\
        *                        /  \
    ----------------------      |CDNI|       ----------------------
   /     Upstream CDN     \     |    |      /    Downstream CDN    \
   |      +-------------+ |     | CI |      | +-------------+      |
   |*******   Control   |<======|====|=======>|   Control   *******|
   |*     +------*----*-+ |     |    |      | +-*----*------+     *|
   |*            *    *   |     |    |      |   *    *            *|
   |*     +------*------+ |     | LI |      | +------*------+     *|
   |* *****   Logging   |<======|====|=======>|   Logging   ***** *|
   |* *   +-*-----------+ |     |    |      | +-----------*-+   * *|
   |* *     *         *   |     |    |      |   *         *     * *|
 .....*...+-*---------*-+ |     | RI |      | +-*---------*-+...*.*...
 . |* *   |             |<======|====|=======>|             |   * *| .
 . |* *   | Req-Routing | |     |FCI |      | | Req-Routing |   * *| .
 . |* * ***             |<======|====|=======>|             |** * *| .
 . |* * * +-------------+.|     |    |      | +-------------+ * * *| .
 . |* * *                 .     |    |      |                 * * *| .
 . |* * * +-------------+ |.    | MI |      | +-------------+ * * *| .
 . |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| .
 . |* * * |             | |  .   \  /       | |             | * * *| .
 . |* * * |+---------+  | |   .   \/        | |  +---------+| * * *| .
 . |* * ***| +---------+| |    ...Request......+---------+ |*** * *| .
 . |* *****+-|Surrogate|***********************|Surrogate|-+***** *| .
 . |*******  +---------+| |   Acquisition   | |+----------+ *******| .
 . |      +-------------+ |                 | +-------*-----+      | .
 . \                      /                 \         *            / .
 .  ----------------------                   ---------*------------  .
 .                                                    *              .
 .                                                    * Delivery     .
 .                                                    *              .
 .                                                 +--*---+          .
 ...............Request............................| User |..Request..
                                                   | Agent|
                                                   +------+
 <==>           interfaces inside the scope of CDNI
  • *** and …. interfaces outside the scope of CDNI
           Figure 1: CDNI Expanded Model and CDNI Interfaces

Leung & Lee Informational [Page 5] RFC 7337 CDNI Requirements August 2014

3. Generic CDNI Requirements

 This section identifies generic requirements independent of the
 individual CDNI interfaces.  Some of those are expected to affect
 multiple or all interfaces.  Management is an important aspect of CDN
 operation.  The fault and performance management is covered in CDNI
 Logging interface requirements.  The other types of management are
 specific to the CDN provider and not needed for interoperability
 between CDN providers.
 GEN-1   {MED} Wherever possible, the CDNI interfaces should reuse or
         leverage existing IETF protocols.
 GEN-2   {HIGH} The CDNI solution shall not require a change, or an
         upgrade, to the User Agent to benefit from content delivery
         through interconnected CDNs.
 GEN-3   {HIGH} The CDNI solution shall not require a change, or an
         upgrade, to the Content Service Provider delivering content
         through a single CDN, to benefit from content delivery
         through interconnected CDNs.
 GEN-4   {HIGH} The CDNI solution shall not depend on intra-CDN
         information to be exposed to other CDNs for effective and
         efficient delivery of the content.  Examples of intra-CDN
         information include Surrogate topology, Surrogate status,
         cached content, etc.
 GEN-5   {HIGH} The CDNI solution shall support CDN interconnection
         when delivery to the User Agent is based on HTTP [RFC7230].
         (Note that while delivery and acquisition "data plane"
         protocols are out of the CDNI solution scope, the CDNI
         solution "control plane" protocols are expected to
         participate in enabling, selecting or facilitating operations
         of such acquisition and delivery protocols.  Hence, it is
         useful to state requirements on the CDNI solution in terms of
         specifying which acquisition and delivery protocols are to be
         supported).
 GEN-6   {HIGH} The CDNI solution shall support acquisition across
         CDNs based on HTTP [RFC7230].  (The note above applies to
         this requirement, too.)
 GEN-7   {LOW} The CDNI solution may support delivery to the User
         Agent based on protocols other than HTTP.
 GEN-8   {LOW} The CDNI solution may support acquisition across CDNs
         based on protocols other than HTTP.

Leung & Lee Informational [Page 6] RFC 7337 CDNI Requirements August 2014

 GEN-9   {MED} The CDNI solution should support cascaded CDN
         redirection (CDN1 redirects to CDN2 that redirects to CDN3)
         to an arbitrary number of levels beyond the first level.
 GEN-10  {MED} The CDNI solution should support an arbitrary topology
         of interconnected CDNs (i.e., the topology of interconnected
         CDNs cannot be restricted to a tree, ring, star, etc.).
 GEN-11  {HIGH} The CDNI solution shall prevent looping of any CDNI
         information exchange.
 GEN-12  {HIGH} When making use of third-party reference, the CDNI
         solution shall consider the potential issues associated with
         the use of various format of third-party references (e.g.,
         NAT or IPv4/IPv6 translation potentially breaking third-party
         references based on an IP addresses such as URI containing
         IPv4 or IPv6 address literals, split DNS situations
         potentially breaking third-party references based on DNS
         FQDNs) and wherever possible avoid, minimize or mitigate the
         associated risks based on the specifics of the environments
         where the reference is used (e.g., likely or unlikely
         presence of NAT in the path).  In particular, this applies to
         situations where the CDNI solution needs to construct and
         convey uniform resource identifiers for directing/redirecting
         a content request, as well as to situations where the CDNI
         solution needs to pass on a third-party reference (e.g.,
         identify the IP address of a User Agent) in order to allow
         another entity to make a more informed decision (e.g., make a
         more informed request routing decision by attempting to
         derive location information from the third-party reference).
 GEN-13  {HIGH} The CDNI solution shall support HTTP Adaptive
         Streaming content.

4. CDNI Control Interface Requirements

 The primary purpose of the CDNI Control interface (CI) is to initiate
 the interconnection across CDNs, bootstrap the other CDNI interfaces
 and trigger actions into the Downstream CDN by the Upstream CDN (such
 as delete object from caches or trigger pre-positioned content
 acquisition).  The working group attempts to align requirements with
 the appropriate interface; however, solutions to these requirements
 may apply to a different interface or another interface in addition
 to the interface with which it is associated.
 CI-1   {HIGH} The CDNI Control interface shall allow the Upstream CDN
        to request that the Downstream CDN, including cascaded
        Downstream CDNs, delete an object or set of objects and/or its

Leung & Lee Informational [Page 7] RFC 7337 CDNI Requirements August 2014

        CDNI Metadata from the CDN Surrogates and any storage.  Only
        the object(s) and CDNI Metadata that pertain to the requesting
        Upstream CDN are allowed to be purged.
 CI-2   {MED} The CDNI Control interface should allow for multiple
        content items identified by a Content Collection ID to be
        purged using a single Content Purge action.
 CI-3   {MED} The CDNI Control interface should allow the Upstream CDN
        to request that the Downstream CDN, including cascaded
        Downstream CDNs, mark an object or set of objects and/or its
        CDNI Metadata as "stale" and revalidate them before they are
        delivered again.
 CI-4   {HIGH} The CDNI Control interface shall allow the Downstream
        CDN to report on the completion of these actions (by itself,
        and including cascaded Downstream CDNs), in a manner
        appropriate for the action (e.g., synchronously or
        asynchronously).  The confirmation receipt should include a
        success or failure indication.  The failure indication and the
        reason are included if the Downstream CDN cannot delete the
        content in its storage.
 CI-5   {MED} The CDNI Control interface should support initiation and
        control by the Upstream CDN of pre-positioned CDNI Metadata
        acquisition by the Downstream CDN.
 CI-6   {MED} The CDNI Control interface should support initiation and
        control by the Upstream CDN of pre-positioned content
        acquisition by the Downstream CDN.
 CI-7   {LOW} The CDNI Control interface may allow a CDN to establish,
        update and terminate a CDN interconnection with another CDN
        whereby one CDN can act as a Downstream CDN for the other CDN
        (that acts as an Upstream CDN).
 CI-8   {LOW} The CDNI Control interface may allow control of the CDNI
        interfaces between any two CDNs independently for each
        direction (e.g., for the direction where CDN1 is the Upstream
        CDN and CDN2 is the Downstream CDN, and for the direction
        where CDN2 is the Upstream CDN and CDN1 is the Downstream
        CDN).

Leung & Lee Informational [Page 8] RFC 7337 CDNI Requirements August 2014

 CI-9   {LOW} The CDNI Control interface may allow bootstrapping of
        the CDNI Request Routing interface.  For example, this can
        potentially include:
  • negotiation of the request routing method (e.g., DNS versus

HTTP, if more than one method is specified).

  • discovery of the CDNI Request Routing interface endpoints.
  • information necessary to establish secure communication

between the CDNI Request Routing interface endpoints.

 CI-10  {LOW} The CDNI Control interface may allow bootstrapping of
        the CDNI Metadata interface.  This information could, for
        example, include:
  • discovery of the CDNI Metadata interface endpoints
  • information necessary to establish secure communication

between the CDNI Metadata interface endpoints.

 CI-11  {LOW} The CDNI Control interface may allow bootstrapping of
        the Content Acquisition interface.  This could, for example,
        include exchange and negotiation of the Content Acquisition
        methods to be used across the CDNs (e.g., HTTP, HTTPS, FTP,
        ATIS C2 [ATIS-0800042]).
 CI-12  {LOW} The CDNI Control interface may allow bootstrapping of
        the CDNI Logging interface.  This information could, for
        example, include:
  • discovery of the CDNI Logging interface endpoints.
  • information necessary to establish secure communication

between the CDNI Logging interface endpoints.

  • negotiation/definition of the log file format and set of

fields to be exported through the logging protocol, with

           some granularity (e.g., on a per-content-type basis).
  • negotiation/definition of parameters related to transaction

logs export (e.g., export protocol, file compression,

           export frequency, directory).

Leung & Lee Informational [Page 9] RFC 7337 CDNI Requirements August 2014

5. CDNI Request Routing Redirection Interface Requirements

 The main function of the CDNI Request Routing Redirection interface
 (RI) is to allow the Request Routing systems in interconnected CDNs
 to communicate to facilitate redirection of the request across CDNs.
 RI-1   {HIGH} The CDNI Request Routing Redirection interface shall
        support efficient request routing for small objects.  This
        may, for example, call for a mode of operation (e.g., DNS-
        based request routing) where freshness and accuracy of CDN/
        Surrogate selection can be traded off against reduced request
        routing load (e.g., Via lighter-weight queries and caching of
        request routing decisions).
 RI-2   {HIGH} The CDNI Request Routing Redirection interface shall
        support efficient request routing for large objects.  This
        may, for example, call for a mode of operation (e.g., HTTP-
        based request routing) where freshness and accuracy of CDN/
        Surrogate selection justifies a per-request decision and a
        per-request CDNI Request-Routing protocol call.
 RI-3   {HIGH} The CDNI Request Routing Redirection interface shall
        support recursive CDNI request routing.
 RI-4   {HIGH} The CDNI Request Routing Redirection interface shall
        support iterative CDNI request routing.
 RI-5   {MED} In case of detection of a request redirection loop, the
        CDNI Request Routing Redirection interface's loop prevention
        mechanism should allow redirection of the request on an
        alternate CDN path (as opposed to the request not being
        redirected at all).
 RI-6   {MED} The CDNI Request Routing Redirection interface should
        support a mechanism allowing enforcement of a limit on the
        number of successive CDN redirections for a given request.
 RI-7   {LOW} The CDNI Request Routing Redirection interface may
        support a mechanism allowing an Upstream CDN to avoid
        redirecting a request to a Downstream CDN if that is likely to
        result in the total redirection time exceeding some limit.

Leung & Lee Informational [Page 10] RFC 7337 CDNI Requirements August 2014

 RI-8   {HIGH} The CDNI Request Routing Redirection interface shall
        allow the Upstream CDN to include, in the query to the
        Downstream CDN, the necessary information to allow the
        Downstream CDN to process the redirection query.  This could,
        for example, include:
  • information from which the geographic region pertaining to

the IP address of the User Agent that originated the

           request can be inferred (e.g., User Agent FQDN in case of
           HTTP-based request routing, DNS Proxy FQDN in case of DNS-
           based request routing).
  • requested resource information (e.g., Resource URI in case

of HTTP-based request routing, Resource hostname in case of

           DNS-based request routing).
  • additional available request information (e.g., request

headers in case of HTTP-based request routing).

 RI-9   {LOW} The CDNI Request Routing Redirection interface may also
        allow the Upstream CDN to convey information pointing to CDNI
        Metadata applicable (individually or through inheritance) to
        the requested content.  For illustration, the CDNI Metadata
        pointed to could potentially include metadata that is
        applicable to any content, metadata that is applicable to a
        content collection (to which the requested content belongs)
        and/or metadata that is applicable individually to the
        requested content.
 RI-10  {HIGH} The CDNI Request Routing Redirection interface shall
        allow the Downstream CDN to include the following information
        in the response to the Upstream CDN:
  • status code, in particular indicating acceptance or

rejection of request (e.g., because the Downstream CDN is

           unwilling or unable to serve the request).  In case of
           rejection, an error code is also to be provided, which
           allows the Upstream CDN to react appropriately (e.g.,
           select another Downstream CDN, or serve the request
           itself).
  • redirection information (e.g., Resource URI in case of

HTTP-based request routing, equivalent of a DNS record in

           case of DNS-based request routing).
 RI-11  {HIGH} The CDNI Request Routing Redirection interface shall
        allow for per-chunk request routing of HTTP Adaptive Streaming
        content.

Leung & Lee Informational [Page 11] RFC 7337 CDNI Requirements August 2014

 RI-12  {LOW} The CDNI Request Routing Redirection interface may allow
        the Upstream CDN to use the information conveyed by the
        Downstream CDN during the Recursive Request Routing process to
        rewrite an HTTP Adaptive Streaming manifest file.
 RI-13  {LOW} The CDNI Request Routing interface may allow the
        Upstream CDN to re-compute the message digest or digital
        signature over the invariant portion of the chunk URIs
        embedded in the HTTP Adaptive Streaming manifest file.
 RI-14  {MED} The CDNI Request Routing Redirection interface should
        correlate the HTTP Adaptive Stream manifest file to the
        related chunks referenced in the manifest file.
 RI-15  {MED} The CDNI Request Routing Redirection interface should
        allow for an efficient method of transferring request routing
        information for multiple chunks from the Downstream CDN to the
        Upstream CDN as part of the recursive request routing process.

6. CDNI Footprint & Capabilities Advertisement Interface Requirements

 The main function of the CDNI Footprint & Capabilities Advertisement
 interface (FCI) is to allow the Downstream CDN to advertise the
 information regarding its footprint and capabilities to the Upstream
 CDN.
 FCI-1  {HIGH} The CDNI Footprint & Capabilities Advertisement
        interface shall allow the Downstream CDN to communicate to the
        Upstream CDN coarse information about the Downstream CDN
        ability and/or willingness to handle requests from the
        Upstream CDN.  For example, this could potentially include a
        binary signal ("Downstream CDN ready/not-ready to take
        additional requests from Upstream CDN") to be used in case of
        excessive load or failure condition in the Downstream CDN.
 FCI-2  {MED} The CDNI Footprint & Capabilities Advertisement
        interface should allow the Downstream CDN to communicate to
        the Upstream CDN aggregate information to facilitate CDN
        selection during request routing, such as Downstream CDN
        capabilities, resources and affinities (i.e., preferences or
        cost).  This information could, for example, include:
  • supported content types and delivery protocols
  • footprint (e.g., Layer 3 coverage).
  • a set of metrics/attributes (e.g., streaming bandwidth,

storage resources, distribution and delivery priority).

Leung & Lee Informational [Page 12] RFC 7337 CDNI Requirements August 2014

  • a set of affinities (e.g., preferences, indication of

distribution/delivery fees).

  • information to facilitate request redirection (e.g.,

Reachability information of Downstream CDN Request Routing

           system).
        [Note: Some of this information -- such as supported content
        types and delivery protocols -- may also potentially be taken
        into account by the Distribution system in the Upstream CDN
        for pre-positioning of content and/or metadata in the
        Downstream CDN in case of pre-positioned content acquisition
        and/or pre-positioned CDNI Metadata acquisition.]
 FCI-3  {MED} In the case of cascaded redirection, the CDNI Footprint
        & Capabilities Advertisement interface should allow the
        Downstream CDN to also include in the information communicated
        to the Upstream CDN, information on the capabilities,
        resources and affinities of CDNs to which the Downstream CDN
        may (in turn) redirect requests received by the Upstream CDN.
        In that case, the CDNI Request Routing interface shall prevent
        looping of such information exchange.
 FCI-4  {LOW} The CDNI Footprint & Capabilities Advertisement
        interface may allow the Downstream CDN to communicate to the
        Upstream CDN aggregate information on CDNI administrative
        limits and policy.  This information can be taken into account
        by the Upstream CDN Request Routing system in its CDN
        Selection decisions.  This information could, for example,
        include:
  • maximum number of requests redirected by the Upstream CDN

to be served simultaneously by the Downstream CDN.

  • maximum aggregate volume of content (e.g., in Terabytes) to

be delivered by the Downstream CDN over a time period.

 FCI-5  {MED} The CDNI Footprint & Capabilities Advertisement
        interface should support advertisement of the following types
        of capabilities:
  • delivery protocol (e.g., HTTP versus Real Time Messaging

Protocol [RTMP]).

  • acquisition protocol (for acquiring content from an

Upstream CDN).

Leung & Lee Informational [Page 13] RFC 7337 CDNI Requirements August 2014

  • redirection mode (e.g., DNS Redirection versus HTTP

Redirection).

  • capabilities related to CDNI Logging (e.g., supported

logging mechanisms).

  • capabilities related to CDNI Metadata (e.g., authorization

algorithms or support for proprietary vendor metadata).

 FCI-6  {LOW} The CDNI Control interface may allow exchange and
        negotiation of delivery authorization mechanisms to be
        supported across the CDNs (e.g., URI-signature-based
        validation).
 FCI-7  {HIGH} The CDNI Footprint & Capabilities Advertisement
        interface shall support extensible fields used to convey the
        CDN capabilities and methods to indicate the footprint in the
        advertisement from the Downstream CDN to the Upstream CDN.

7. CDNI Metadata Interface Requirements

 The primary function of the CDNI Metadata interface (MI) is to allow
 the Distribution system in interconnected CDNs to communicate to
 ensure Content Distribution Metadata with inter-CDN scope can be
 exchanged across CDNs.  We observe that while the CDNI Metadata
 Distribution protocol is currently discussed as a single "protocol",
 further analysis will determine whether the corresponding
 requirements are to be realized over a single interface and protocol,
 or over multiple interfaces and protocols.  For example, a subset of
 the CDNI Metadata might be conveyed in-band along with the actual
 content acquisition across CDNs (e.g.  content MD5 in HTTP header)
 while another subset might require an out-of-band interface and
 protocol (e.g., geo-blocking information).
 MI-1   {HIGH} The CDNI Metadata interface shall allow the Upstream
        CDN to provide the Downstream CDN with content distribution
        metadata of inter-CDN scope.
 MI-2   {HIGH} The CDNI Metadata interface shall support exchange of
        CDNI Metadata for both the dynamic content acquisition model
        and the pre-positioning content acquisition model.
 MI-3   {HIGH} The CDNI Metadata interface shall support a mode where
        no, or a subset of, the CDNI Metadata is initially
        communicated to the Downstream CDN along with information
        about how/where to acquire the rest of the CDNI Metadata
        (i.e., Dynamic CDNI Metadata acquisition).

Leung & Lee Informational [Page 14] RFC 7337 CDNI Requirements August 2014

 MI-4   {MED} The CDNI Metadata interface should support a mode where
        all the relevant CDNI Metadata is initially communicated to
        the Downstream CDN (i.e., pre-positioned CDNI Metadata
        acquisition).
 MI-5   {HIGH} Whether in the pre-positioned content acquisition model
        or in the dynamic content acquisition model, the CDNI Metadata
        interface shall provide the necessary information to allow the
        Downstream CDN to acquire the content from an upstream source
        (e.g., acquisition protocol and Uniform Resource Identifier in
        Upstream CDN -- or rules to construct this URI).
 MI-6   {HIGH} The CDNI Metadata shall allow signaling of one or more
        upstream sources, where each upstream source can be in the
        Upstream CDN, in another CDN, the CSP origin server or any
        arbitrary source designated by the Upstream CDN.  Note that
        some upstream sources (e.g., the content origin server) may or
        may not be willing to serve the content to the Downstream CDN;
        if this policy is known to the Upstream CDN, then it may omit
        those sources when exchanging CDNI Metadata.
 MI-7   {HIGH} The CDNI Metadata interface (possibly in conjunction
        with the CDNI Control interface) shall allow the Upstream CDN
        to request addition and modification of CDNI Metadata into the
        Downstream CDN.
 MI-8   {HIGH} The CDNI Metadata interface (possibly in conjunction
        with the CDNI Control interface) shall allow removal of
        obsolete CDNI Metadata from the Downstream CDN (this could,
        for example, be achieved via an explicit removal request from
        the Upstream CDN or via expiration of a Time-To-Live (TTL)
        associated with the CDNI Metadata).
 MI-9   {HIGH} The CDNI Metadata interface shall allow association of
        CDNI Metadata at the granularity of individual object.  This
        is necessary to achieve fine-grain CDNI Metadata distribution
        at the level of an individual object when necessary.
 MI-10  {HIGH} The CDNI Metadata interface shall allow association of
        CDNI Metadata at the granularity of an object set.  This is
        necessary to achieve scalable distribution of metadata when a
        large number of objects share the same distribution policy.
 MI-11  {HIGH} The CDNI Metadata interface shall support multiple
        levels of inheritance with precedence to more specific
        metadata.  For example, the CDNI Metadata Distribution
        protocol may support metadata that is applicable to any
        content, metadata that is applicable to a content collection

Leung & Lee Informational [Page 15] RFC 7337 CDNI Requirements August 2014

        and metadata that is applicable to an individual content where
        content level metadata overrides content collection metadata
        that overrides metadata for any content.
 MI-12  {HIGH} The CDNI Metadata interface shall ensure that
        conflicting metadata with overlapping scope are prevented or
        deterministically handled.
 MI-13  {HIGH} The CDNI Metadata interface shall allow signaling of
        content distribution control policies.  For example, this
        could potentially 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; expiration time may also be included to remove
           content).
  • delegation whitelist/blacklist (i.e., information defining

through which Downstream CDNs the content may/may not be

           delivered)
 MI-14  {HIGH} The CDNI Metadata interface shall be able to exchange a
        set of metadata elements with specified semantics (e.g., start
        of time window, end of time window).
 MI-15  {HIGH} The CDNI Metadata interface shall allow exchange of
        opaque metadata element, whose semantic is not defined in CDNI
        but established by private CDN agreement.
 MI-16  {HIGH} The CDNI Metadata interface shall allow signaling of
        authorization checks and validation that are to be performed
        by the Surrogate before delivery.  For example, this could
        potentially include the need to validate information (e.g.,
        Expiry time, Client IP address) required for access
        authorization.
 MI-17  {MED} The CDNI Metadata interface should allow signaling of
        CDNI-relevant Surrogate cache behavior parameters.  For
        example, this could potentially include:
  • control of whether the query string of HTTP URI is to be

ignored by Surrogate cache.

Leung & Lee Informational [Page 16] RFC 7337 CDNI Requirements August 2014

  • enforcement of caching directives by Downstream CDN that

are different than the ones signaled in the HTTP headers

           (e.g., "Expires" field).
  • rate-pacing by Downstream CDN for content delivery (e.g.,

Progressive Download).

 MI-18  {HIGH} The CDNI Metadata interface shall provide indication of
        related content (e.g., HTTP Adaptive Bit Rate chunks) by the
        Content Collection ID (CCID) metadata.  This could be used by
        the Downstream CDN for operations on the group of content.
        For example, this could potentially include:
  • content acquisition for the entire set of files when one

piece of content is requested.

  • local file management and storage bundles all the files for

the content.

  • purging the entire set of files associated with the

content.

  • logging of the delivery of the content for the session when

at least one file in the set was delivered.

 MI-19  {MED} The CDNI Metadata interface should support an optional
        mechanism allowing the Upstream CDN to indicate to the
        Downstream CDN which CDNI Log fields are to be provided for
        all content items, for specific sets of content items, or for
        specific content items delivered using HTTP.  A CDNI
        implementation that does not support this optional CDNI
        Metadata Distribution interface mechanism shall ignore this
        log format indication and generate CDNI Logging format for
        HTTP Adaptive Streaming using the default set of CDNI Logging
        fields.  (Note: This function may be part of the CDNI Metadata
        interface or the CDNI Control interface.)
 MI-20  {MED} The CDNI Metadata interface should allow the Upstream
        CDN to signal to the Downstream CDN the Content Collection ID
        value for all, for specific sets of, or for specific content
        items delivered using HTTP.  Whenever the Downstream CDN is
        instructed by the Upstream CDN to report the Content
        Collection ID field in the log records, the Downstream CDN is
        to use the value provided through the CDNI Metadata interface
        for the corresponding content.  Note the Session ID field
        along with Content Collection ID may be used for HTTP Adaptive
        Streaming content.

Leung & Lee Informational [Page 17] RFC 7337 CDNI Requirements August 2014

 MI-21  {MED} The CDNI Metadata interface should allow the Upstream
        CDN to signal to the Downstream CDN the Authorization Group ID
        value for all the related HTTP Adaptive Streaming content
        (i.e., manifest file and chunks).  The authorization result of
        a content (e.g., manifest file) is transferred over to related
        content (e.g., chunks).
 MI-22  {HIGH} The CDNI Metadata interface shall support extensible
        format for CDNI Metadata delivery from the Upstream CDN to the
        Downstream CDN.

8. CDNI Logging Interface Requirements

 This section identifies the requirements related to the CDNI Logging
 interface (LI).  We observe that while the CDNI Logging interface is
 currently discussed as a single "protocol", further analysis will
 determine whether the corresponding requirements are to be realized
 over a single interface and protocol or over multiple interfaces and
 protocols.
 LI-1   {HIGH} The CDNI Logging interface and architecture shall
        ensure reliable transfer of CDNI logging information across
        CDNs.
 LI-2   {HIGH} The CDNI Logging interface shall provide logging of
        deliveries and incomplete deliveries to User Agents performed
        by the Downstream CDN as a result of request redirection by
        the Upstream CDN.
 LI-3   {MED} In the case of cascaded CDNs, the CDNI Logging interface
        should allow the Downstream CDN to report to the Upstream CDN
        logging for deliveries and incomplete deliveries performed by
        the Downstream CDN itself as well as logging for deliveries
        and incomplete deliveries performed by cascaded CDNs on behalf
        of the Downstream CDN.
 LI-4   {HIGH} The CDNI Logging interface shall support batch/offline
        exchange of logging records.
 LI-5   {MED} The CDNI Logging interface should also support an
        additional mechanism taking into account the timing
        constraints for some types of logging records (e.g., near-real
        time for monitoring and analytics applications).
 LI-6   {HIGH} The CDNI Logging interface shall define a log file
        format and a set of fields to be exported for various CDNI
        Logging events.

Leung & Lee Informational [Page 18] RFC 7337 CDNI Requirements August 2014

 LI-7   {HIGH} The CDNI Logging interface shall define a transport
        mechanism to exchange CDNI Logging files.
 LI-8   {MED} The CDNI Logging interface should allow a CDN to query
        another CDN for relevant current logging records (e.g., for
        on-demand access to real-time logging information).
 LI-9   {LOW} The CDNI Logging interface may support aggregate/
        summarized logs (e.g., total bytes delivered for a content
        regardless of individual User Agents to which it was
        delivered).
 LI-10  {LOW} The CDNI Logging interface may support logging of
        performance data for deliveries to User Agents performed by
        the Downstream CDN as a result of request redirection by the
        Upstream CDN.  Performance data may include various traffic
        statistics (the specific parameters are to be determined).
        The CDNI Logging interface may support the Upstream CDN to
        indicate the nature and contents of the performance data to be
        reported by the Downstream CDN.
 LI-11  {MED} The CDNI Logging interface should support logging of
        consumed resources (e.g., storage, bandwidth) to the Upstream
        CDN for deliveries where content is stored by the Downstream
        CDN for delivery to User Agents.  The information logged may
        include the type of storage (e.g., Origin, Intermediate, Edge,
        Cache) as well as the amount of storage (e.g., total GB, GB
        used, per time period, per content domain) all of which may
        impact the cost of the services.
 LI-12  {MED} In the case of cascaded CDNs, the CDNI Logging interface
        should support the Downstream CDN to report consumed resources
        (e.g.  storage, bandwidth) to the Upstream CDN where content
        is stored by the Downstream CDN itself as well as logging for
        storage resources when content storage is performed by
        cascaded CDNs on behalf of the Downstream CDN.
 LI-13  {HIGH} The CDNI Logging interface shall support logging of
        deleted objects from the Downstream CDN to the Upstream CDN as
        a result of explicit delete requests on via the CDNI Control
        interface from the Upstream CDN.
 LI-14  {HIGH} The CDNI Logging interface shall support the exchange
        of extensible log file formats to support proprietary
        information fields.  These information fields shall be agreed
        upon ahead of time between the corresponding CDNs.

Leung & Lee Informational [Page 19] RFC 7337 CDNI Requirements August 2014

 LI-15  {HIGH} The CDNI Logging interface shall allow a CDN to notify
        another CDN about which CDNI Logging information is available
        for transfer and/or no longer available (e.g., it exceeded
        some logging retention period or some logging retention
        volume).
 LI-16  {MED} The CDNI Logging interface should support the ability
        for the Downstream CDN to include the Content Collection ID
        and Session ID fields in CDNI log entries generated for HTTP
        Adaptive Streaming content.
 LI-17  {MED} The CDNI Logging interface should provide privacy
        protection by not disclosing information that can be used to
        identify the user (e.g., method that anonymizes the IP address
        carried in the logging field).  The use of the privacy
        protection mechanism is optional.

9. CDNI Security Requirements

 This section identifies the requirements related to the CDNI
 security.  Some of these are expected to affect multiple or all
 protocols.
 SEC-1  {HIGH} All the CDNI interface shall support secure operation
        over unsecured IP connectivity (e.g., the Internet).  This
        includes authentication, confidentiality, integrity protection
        as well as protection against spoofing and replay.
 SEC-2  {HIGH} The CDNI solution shall provide sufficient protection
        against denial-of-service attacks.  This includes protection
        against spoofed delivery requests sent by User Agents directly
        to a Downstream CDN attempting to appear as if they had been
        redirected by a given Upstream CDN when they have not.
 SEC-3  {MED} The CDNI solution should be able to ensure that for any
        given request redirected to a Downstream CDN, the Downstream
        CDN can determine the Upstream CDN that redirected the request
        directly to the Downstream CDN (leading to that request being
        served by that CDN, or being further redirected).
 SEC-4  {MED} The CDNI solution should be able to ensure that for any
        given transaction log generated by the Downstream CDN and
        communicated to an Upstream CDN, the Upstream CDN can confirm
        the transmitted log record corresponds to a request
        redirection by the Upstream CDN.

Leung & Lee Informational [Page 20] RFC 7337 CDNI Requirements August 2014

 SEC-5  {LOW} The CDNI solution may provide a mechanism allowing an
        Upstream CDN that has credentials to acquire content from the
        CSP origin server (or another CDN), to allow establishment of
        credentials authorizing the Downstream CDN to acquire the
        content from the CSP origin server (or the other CDN) (e.g.,
        in case the content cannot be acquired from the Upstream CDN).

10. Security Considerations

 This document discusses CDNI security requirements in Section 9.

11. Contributors

 This document reflects contributions from the following individuals:
    Francois Le Faucheur
    Cisco Systems
    EMail: flefauch@cisco.com
    Mahesh Viveganandhan
    Cisco Systems
    EMail: mvittal@cisco.com
    Grant Watson
    Alcatel-Lucent (Velocix)
    EMail: gwatson@velocix.com

12. Acknowledgements

 This document leverages the earlier work of the IETF CDI working
 group in particular, as documented in [REQ-ROUTE], [DIST-REQS], and
 [AAA-REQS].
 The authors would like to thank Gilles Bertrand, Christophe Caillet,
 Bruce Davie, Phil Eardley, Ben Niven-Jenkins, Agustin Schapira, Emile
 Stephan, Eric Burger, Susan He, Kevin Ma, Daryl Malas, Iuniana
 Oprescu, and Spencer Dawkins for their input.  Serge Manning along
 with Robert Streijl, Vishwa Prasad, Percy Tarapore, Mike Geller, and
 Ramki Krishnan contributed to this document by addressing the
 requirements of the ATIS Cloud Services Forum.
 Ray Brandenburg, Matt Caufield, and Gilles Bertrand provided valuable
 inputs for HTTP Adaptive Streaming, CDNI Metadata interface, and CDNI
 Logging interface, respectively.
 Stephen Farrell, Adrian Farrel, Benoit Claise, Sean Turner, Christer
 Holmberg, and Carlos Pignataro provided review comments that helped
 improve the document.

Leung & Lee Informational [Page 21] RFC 7337 CDNI Requirements August 2014

13. References

13.1. Normative References

 [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
            Distribution Network Interconnection (CDNI) Problem
            Statement", RFC 6707, September 2012.
 [RFC7336]  Peterson, L., Davie, B., and R. Brandenburg, Ed.,
            "Framework for Content Distribution Network
            Interconnection (CDNI)", RFC 7336, August 2014.

13.2. Informative References

 [AAA-REQS]
            Gilletti, D., Nair, R., Scharber, J., and J. Guha,
            "Content Internetworking (CDI) Authentication,
            Authorization, and Accounting Requirements", Work in
            Progress, June 2001.
 [ATIS-0800042]
            ATIS, "ATIS IPTV Content on Demand Service", ATIS-0800042
            v002, September 2011, <https://www.atis.org/docstore/
            product.aspx?id=25670>.
 [DIST-REQS]
            Amini, L., "Distribution Requirements for Content
            Internetworking", Work in Progress, November 2001.
 [REQ-ROUTE]
            Cain, B., "Request Routing Requirements for Content
            Internetworking", Work in Progress, November 2001.
 [RFC6770]  Bertrand, G., Stephan, E., Burbridge, T., Eardley, P., Ma,
            K., and G. Watson, "Use Cases for Content Delivery Network
            Interconnection", RFC 6770, November 2012.
 [RFC7230]  Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
            (HTTP/1.1): Message Syntax and Routing", RFC 7230, June
            2014.
 [RTMP]     Parmar, H., Ed. and M. Thornburgh, Ed., "Adobe's Real Time
            Messaging Protocol", December 2012,
            <http://www.adobe.com/content/dam/Adobe/en/devnet/rtmp/
            pdf/rtmp_specification_1.0.pdf>.

Leung & Lee Informational [Page 22] RFC 7337 CDNI Requirements August 2014

Authors' Addresses

 Kent Leung (editor)
 Cisco Systems
 170 West Tasman Drive
 San Jose, CA  95134
 USA
 Phone: +1 408 526 5030
 EMail: kleung@cisco.com
 Yiu Lee (editor)
 Comcast
 One Comcast Center
 Philadelphia, PA  19103
 USA
 EMail: yiu_lee@cable.comcast.com

Leung & Lee Informational [Page 23]

/data/webs/external/dokuwiki/data/pages/rfc/rfc7337.txt · Last modified: 2014/08/13 00:23 by 127.0.0.1

Donate Powered by PHP Valid HTML5 Valid CSS Driven by DokuWiki