[Docs] [txt|pdf|xml|html] [Tracker] [WG] [Email] [Diff1] [Diff2] [Nits] [IPR]

Versions: (draft-lefaucheur-cdni-requirements) 00 01 02 03 04 05 06 07 08 09 10 11 12 13 14 15 16 17

Network Working Group                                      K. Leung, Ed.
Internet-Draft                                                     Cisco
Intended status: Informational                               Y. Lee, Ed.
Expires: August 3, 2014                                          Comcast
                                                            Jan 30, 2014


    Content Distribution Network Interconnection (CDNI) Requirements
                    draft-ietf-cdni-requirements-17

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 and Enterprise Service Providers 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 Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on August 3, 2014.

Copyright Notice

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



Leung & Lee              Expires August 3, 2014                 [Page 1]

Internet-Draft              CDNI Requirements                   Jan 2014


   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  . . . . . . . . . . . . . . . . . . . . . . .  3
   2.  CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . .  4
   3.  Generic CDNI Requirements  . . . . . . . . . . . . . . . . . .  7
   4.  CDNI Control Interface Requirements  . . . . . . . . . . . . .  8
   5.  CDNI Request Routing Redirection Interface Requirements  . . . 11
   6.  CDNI Footprint & Capabilities Advertisement Interface
       Requirements . . . . . . . . . . . . . . . . . . . . . . . . . 13
   7.  CDNI Metadata Interface Requirements . . . . . . . . . . . . . 15
   8.  CDNI Logging Interface Requirements  . . . . . . . . . . . . . 19
   9.  CDNI Security Requirements . . . . . . . . . . . . . . . . . . 21
   10. IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 22
   11. Security Considerations  . . . . . . . . . . . . . . . . . . . 22
   12. Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 22
   13. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22
   14. References . . . . . . . . . . . . . . . . . . . . . . . . . . 23
     14.1. Normative References . . . . . . . . . . . . . . . . . . . 23
     14.2. Informative References . . . . . . . . . . . . . . . . . . 23
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24



















Leung & Lee              Expires August 3, 2014                 [Page 2]

Internet-Draft              CDNI Requirements                   Jan 2014


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 Network Service
   Providers and Enterprise Service Providers are deploying their own
   CDNs.  Subject to the policy of the Content Service Provider (CSP),
   it is generally desirable that a given item 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.

   CDNI Problem Statement [RFC6707] outlines the problem area that the
   CDNI working group is chartered to address.  Use Cases for CDNI
   [RFC6770] discusses the use cases for CDN Interconnection.  Framework
   for CDN Interconnection [I-D.ietf-cdni-framework] 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 timelines
   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 in the following
   way:

   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.





Leung & Lee              Expires August 3, 2014                 [Page 3]

Internet-Draft              CDNI Requirements                   Jan 2014


   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.


2.  CDNI Model and CDNI Interfaces

   The "CDNI Expanded Model and CDNI Interfaces" figure and brief
   descriptions of the CDNI interfaces in [I-D.ietf-cdni-framework] 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 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
         [I-D.ietf-cdni-framework]) 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 [I-D.ietf-cdni-framework]) 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:



Leung & Lee              Expires August 3, 2014                 [Page 4]

Internet-Draft              CDNI Requirements                   Jan 2014


      *  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              Expires August 3, 2014                 [Page 5]

Internet-Draft              CDNI Requirements                   Jan 2014


      --------
     /        \
     |   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              Expires August 3, 2014                 [Page 6]

Internet-Draft              CDNI Requirements                   Jan 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 [RFC2616].
           (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 [RFC2616].  (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.






Leung & Lee              Expires August 3, 2014                 [Page 7]

Internet-Draft              CDNI Requirements                   Jan 2014


   GEN-8   {LOW} The CDNI solution may support acquisition across CDNs
           based on protocols other than HTTP.

   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
           fully qualified domain names) 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



Leung & Lee              Expires August 3, 2014                 [Page 8]

Internet-Draft              CDNI Requirements                   Jan 2014


   to the interface it is associated with.

   CI-1   {HIGH} The CDNI Control interface shall allow the Upstream CDN
          to request that the Downstream CDN, including downstream
          cascaded CDNs, delete an object or set of objects and/or its
          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 downstream
          cascaded 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 downstream cascaded 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              Expires August 3, 2014                 [Page 9]

Internet-Draft              CDNI Requirements                   Jan 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 vs
              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              Expires August 3, 2014                [Page 10]

Internet-Draft              CDNI Requirements                   Jan 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.

   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:




Leung & Lee              Expires August 3, 2014                [Page 11]

Internet-Draft              CDNI Requirements                   Jan 2014


          *   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 fully qualified
              domain name in case of HTTP-based Request Routing, DNS
              Proxy fully qualified domain name 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.

   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.



Leung & Lee              Expires August 3, 2014                [Page 12]

Internet-Draft              CDNI Requirements                   Jan 2014


   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)

          *   a set of affinities (e.g.  Preferences, indication of
              distribution/delivery fees)




Leung & Lee              Expires August 3, 2014                [Page 13]

Internet-Draft              CDNI Requirements                   Jan 2014


          *   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 vs. RTMP)

          *   acquisition protocol (for acquiring content from an
              Upstream CDN)

          *   redirection mode (e.g., DNS Redirection vs. HTTP
              Redirection)

          *   capabilities related to CDNI Logging (e.g., supported
              logging mechanisms)



Leung & Lee              Expires August 3, 2014                [Page 14]

Internet-Draft              CDNI Requirements                   Jan 2014


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

   MI-4   {MED} The CDNI Metadata interface should support a mode where
          all the relevant Metadata is initially communicated to the
          Downstream CDN (i.e.  Pre-positioned CDNI metadata
          acquisition).




Leung & Lee              Expires August 3, 2014                [Page 15]

Internet-Draft              CDNI Requirements                   Jan 2014


   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
          associated to the 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 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
          and metadata that is applicable to an individual content where
          content level metadata overrides content collection metadata
          that overrides metadata for any content.





Leung & Lee              Expires August 3, 2014                [Page 16]

Internet-Draft              CDNI Requirements                   Jan 2014


   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
              which Downstream CDNs the content may/may not be delivered
              through)

   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

          *   enforcement of caching directives by Downstream CDN that
              are different than the ones signalled in the HTTP headers
              (e.g.  "Expires" field)





Leung & Lee              Expires August 3, 2014                [Page 17]

Internet-Draft              CDNI Requirements                   Jan 2014


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

   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



Leung & Lee              Expires August 3, 2014                [Page 18]

Internet-Draft              CDNI Requirements                   Jan 2014


          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 architecture and interface 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              Expires August 3, 2014                [Page 19]

Internet-Draft              CDNI Requirements                   Jan 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              Expires August 3, 2014                [Page 20]

Internet-Draft              CDNI Requirements                   Jan 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              Expires August 3, 2014                [Page 21]

Internet-Draft              CDNI Requirements                   Jan 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.  IANA Considerations

   This document makes no request of IANA.

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


11.  Security Considerations

   This document discusses CDNI security requirements in Section 9.


12.  Contributors

   This document reflects the contributions from the following authors:

   Francois Le Faucheur

      Cisco Systems

      flefauch@cisco.com

   Mahesh Viveganandhan

      Cisco Systems

      mvittal@cisco.com

   Grant Watson

      Alcatel-Lucent (Velocix)

      gwatson@velocix.com


13.  Acknowledgements

   This document leverages the earlier work of the IETF CDI working
   group in particular as documented in [I-D.cain-request-routing-req],



Leung & Lee              Expires August 3, 2014                [Page 22]

Internet-Draft              CDNI Requirements                   Jan 2014


   [I-D.amini-cdi-distribution-reqs] and [I-D.gilletti-cdnp-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.


14.  References

14.1.  Normative References

   [I-D.ietf-cdni-framework]
              Peterson, L. and B. Davie, "Framework for CDN
              Interconnection", draft-ietf-cdni-framework-07 (work in
              progress), November 2013.

   [RFC6707]  Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", RFC 6707, September 2012.

14.2.  Informative References

   [ATIS-0800042]
              "ATIS IPTV Content on Demand Service,
              https://www.atis.org/docstore/product.aspx?id=25670",
              December 2010.

   [I-D.amini-cdi-distribution-reqs]
              Amini, L., "Distribution Requirements for Content
              Internetworking", draft-amini-cdi-distribution-reqs-02
              (work in progress), November 2001.

   [I-D.cain-request-routing-req]
              Cain, B., "Request Routing Requirements for Content
              Internetworking", draft-cain-request-routing-req-03 (work
              in progress), November 2001.



Leung & Lee              Expires August 3, 2014                [Page 23]

Internet-Draft              CDNI Requirements                   Jan 2014


   [I-D.gilletti-cdnp-aaa-reqs]
              "CDI AAA Requirements,
              draft-gilletti-cdnp-aaa-reqs-01.txt", June 2001.

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

   [RFC4949]  Shirey, R., "Internet Security Glossary, Version 2",
              RFC 4949, August 2007.

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

   [RTMP]     "Adobe's Real Time Messaging Protocol, http://
              www.adobe.com/content/dam/Adobe/en/devnet/rtmp/pdf/
              rtmp_specification_1.0.pdf", December 2012.


Authors' Addresses

   Kent Leung (editor)
   Cisco Systems
   170 West Tasman Drive
   San Jose, CA  95134
   U.S.A.

   Phone: +1 408 526 5030
   Email: kleung@cisco.com


   Yiu Lee (editor)
   Comcast
   One Comcast Center
   Philadelphia, PA  19103
   U.S.A.

   Email: yiu_lee@cable.comcast.com












Leung & Lee              Expires August 3, 2014                [Page 24]


Html markup produced by rfcmarkup 1.107, available from http://tools.ietf.org/tools/rfcmarkup/