Network Working Group                                      K. Leung, Ed.
Internet-Draft                                                     Cisco
Intended status: Informational                               Y. Lee, Ed.
Expires: June 9, 2012                                            Comcast
                                                        December 7, 2011


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

Abstract

   Content Delivery Networks (CDNs) are frequently used for large-scale
   content delivery.  As a result, existing CDN providers are scaling up
   their infrastructure and many Network Service Providers (NSPs) are
   deploying their own CDNs.  There is a requirement for interconnecting
   standalone CDNs so that their collective CDN footprint can be
   leveraged for the end-to-end delivery of content from Content Service
   Providers (CSPs) to end users.  The Content Distribution Network
   Interconnection (CDNI) working group has been chartered to develop an
   interoperable and scalable solution for such CDN interconnection.

   The goal of the present document is to outline the requirements for
   the solution and interfaces to be specified by the CDNI working
   group.  This draft is a work in progress and requirements may be
   added, modified, or removed by the working group.

Requirements Language

   The key words "High Priority", "Medium Priority" and "Low Priority"
   in this document are to be interpreted in the following way:

   o  "High Priority" indicates requirements that are to be supported by
      the CDNI interfaces.  A requirement is stated as "High Priority"
      when it is established by the working group that it can be met
      without compromising the targeted schedule for WG deliverables, or
      when it is established that specifying a solution without meeting
      this requirement would not make sense and would justify re-
      adjusting the WG schedule, or both.  This is tagged as "[HIGH]".

   o  "Medium Priority" indicates requirements that are to be supported
      by the CDNI interfaces unless the WG realizes at a later stage
      that attempting to meet this requirement would compromise the
      overall WG schedule (for example it would involve complexities
      that would result in significantly delaying the deliverables).
      This is tagged as "[MED]".





Leung & Lee               Expires June 9, 2012                  [Page 1]


Internet-Draft              CDNI Requirements              December 2011


   o  "Low Priority" indicates requirements that are to be supported by
      the CDNI interfaces provided that dedicating WG resources to this
      work does not prevent addressing "High Priority" and "Medium
      Priority" requirements and that attempting to meet this
      requirement would not compromise the overall WG schedule.  This is
      tagged as "[LOW]".


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 June 9, 2012.

Copyright Notice

   Copyright (c) 2011 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.












Leung & Lee               Expires June 9, 2012                  [Page 2]


Internet-Draft              CDNI Requirements              December 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  CDNI Model and CDNI Interfaces . . . . . . . . . . . . . . . .  4
   3.  Generic CDNI Requirements  . . . . . . . . . . . . . . . . . .  6
   4.  CDNI Control Interface Requirements  . . . . . . . . . . . . .  7
   5.  CDNI Request Routing Interface Requirements  . . . . . . . . . 10
   6.  CDNI Metadata Distribution Interface Requirements  . . . . . . 13
   7.  CDNI Logging Interface Requirements  . . . . . . . . . . . . . 16
   8.  CDNI Security Requirements . . . . . . . . . . . . . . . . . . 18
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 18
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 19
   11. Authors  . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
   12. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 19
   13. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20
     13.1. Normative References . . . . . . . . . . . . . . . . . . . 20
     13.2. Informative References . . . . . . . . . . . . . . . . . . 20
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 20
































Leung & Lee               Expires June 9, 2012                  [Page 3]


Internet-Draft              CDNI Requirements              December 2011


1.  Introduction

   The volume of video and multimedia content delivered over the
   Internet is rapidly increasing and expected to continue doing so in
   the future.  In the face of this growth, Content Delivery Networks
   (CDNs) provide numerous benefits: reduced delivery cost for cacheable
   content, improved quality of experience for end users, and increased
   robustness of delivery.  For these reasons CDNs are frequently used
   for large-scale content delivery.  As a result, existing CDN
   providers are scaling up their infrastructure and many Network
   Service Providers (NSPs) are deploying their own CDNs.  It is
   generally desirable that a given content item can be delivered to an
   End User regardless of that End User's location or attachment
   network.  However, the footprint of a given CDN in charge of
   delivering a given content may not expand close enough to the End
   User's current location or attachment network to realize the cost
   benefit and user experience that a more distributed CDN would
   provide.  This creates a requirement for interconnecting standalone
   CDNs so that their collective CDN footprint can be leveraged for the
   end-to-end delivery of content from Content Service Providers (CSPs)
   to End Users.  The Content Distribution Network Interconnection
   (CDNI) working group has been chartered to develop an interoperable
   and scalable solution for such CDN interconnection.

   [I-D.ietf-cdni-problem-statement] outlines the problem area that the
   CDNI working group is chartered to address.
   [I-D.ietf-cdni-use-cases] discusses the use cases for CDN
   Interconnection.  [I-D.davie-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 section 1.1 of
   [I-D.davie-cdni-framework].


2.  CDNI Model and CDNI Interfaces

   For convenience Figure 1 from [I-D.davie-cdni-framework] illustrating
   the CDNI problem area and the CDNI protocols is replicated below.





Leung & Lee               Expires June 9, 2012                  [Page 4]


Internet-Draft              CDNI Requirements              December 2011


     --------
    /        \
    |   CSP  |
    \        /
     --------
         *
         *
         *                         /\
         *                        /  \
     ----------------------      |CDNI|        ----------------------
    /     Upstream CDN     \     |    |       /    Downstream CDN    \
    |      +-------------+ | Control Interface| +-------------+      |
    |*******   Control   |<======|====|========>|   Control   *******|
    |*     +------*----*-+ |     |    |       | +-*----*------+     *|
    |*            *    *   |     |    |       |   *    *            *|
    |*     +------*------+ | Logging Interface| +------*------+     *|
    |* *****   Logging   |<======|====|========>|   Logging   ***** *|
    |* *   +-*-----------+ |     |    |       | +-----------*-+   * *|
    |* *     *         *   | Request Routing  |   *         *     * *|
  .....*...+-*---------*-+ |    Interface     | +-*---------*-+...*.*...
  . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
  . |* * * +-------------+.|     |    |       | +-------------+ * * *| .
  . |* * *                 .  CDNI Metadata   |                 * * *| .
  . |* * * +-------------+ |.   Interface     | +-------------+ * * *| .
  . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
  . |* * * |             | |  .   \  /        | |             | * * *| .
  . |* * * |+---------+  | |   .   \/         | |  +---------+| * * *| .
  . |* * ***| +---------+| |    ....Request......+---------+ |*** * *| .
  . |* *****+-|Surrogate|************************|Surrogate|-+***** *| .
  . |*******  +---------+| |   Acquisition    | |+----------+ *******| .
  . |      +-------------+ |                  | +-------*-----+      | .
  . \                      /                  \         *            / .
  .  ----------------------                    ---------*------------  .
  .                                                     *              .
  .                                                     * Delivery     .
  .                                                     *              .
  .                                                  +--*---+          .
  ...............Request.............................| User |..Request..
                                                     | Agent|
                                                     +------+

  <==>  interfaces inside the scope of CDNI

  ****  interfaces outside the scope of CDNI
  ....  interfaces outside the scope of CDNI

                 Figure 1: CDNI Model and CDNI Interfaces




Leung & Lee               Expires June 9, 2012                  [Page 5]


Internet-Draft              CDNI Requirements              December 2011


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.

   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 to benefit from
           content delivery through interconnected CDNs.

   GEN-4   [HIGH] The CDNI solution shall not require 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 delivery to the user
           agent 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 which acquisition and delivery
           protocols).

   GEN-6   [HIGH] The CDNI solution shall support acquisition across
           CDNs based on HTTP [RFC2616].

   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.

   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.






Leung & Lee               Expires June 9, 2012                  [Page 6]


Internet-Draft              CDNI Requirements              December 2011


   GEN-10  [MED] The CDNI solution should support an arbitrary topology
           of interconnected CDNs (i.e. the CDN topology cannot be
           restricted to a tree, a loop-free topology, 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 litterals, 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. to identify 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

   GEN-14  [HIGH] The CDNI solution shall support HTTP Adaptive Bit Rate
           (ABR) content.


4.  CDNI Control Interface Requirements

   The primary purpose of the CDNI Control interface 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).  We observe that while the CDNI Control 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.






Leung & Lee               Expires June 9, 2012                  [Page 7]


Internet-Draft              CDNI Requirements              December 2011


   CNTL-1   [HIGH] The CDNI Control interface shall allow the Upstream
            CDN to request that the Downstream CDN (and, if cascaded
            CDNs are supported by the solution, that the potential
            cascaded Downstream CDNs) perform the following actions on
            an object or object set:

            *   Mark an object or set of objects and/or its CDNI
                metadata as "stale" and revalidate them before they are
                delivered again

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

   CNTL-2   [HIGH] The CDNI Control interface shall allow the Downstream
            CDN to report on the completion of these actions (by itself,
            and if cascaded CDNs are supported by the solution, by
            potential 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 is used if the
            Downstream CDN cannot delete the content in its storage.

   CNTL-3   [HIGH] The CDNI Control interface shall support initiation
            and control by the Upstream CDN of pre-positioned CDNI
            metadata acquisition by the Downstream CDN.

   CNTL-4   [MED] The CDNI Control interface should support initiation
            and control by the Upstream CDN of pre-positioned content
            acquisition by the Downstream CDN.

   CNTL-5   [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).

   CNTL-6   [LOW] The CDNI Control interface may allow control of the
            CDNI interconnection between any two CDNs independently for
            each direction (i.e.  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).

   CNTL-7   [LOW] The CDNI Control interface may allow bootstrapping of
            the Request-Routing interface.  For example, this can
            potentially include:




Leung & Lee               Expires June 9, 2012                  [Page 8]


Internet-Draft              CDNI Requirements              December 2011


            *   negotiation of the Request-Routing method (e.g.  DNS vs
                HTTP, if more than one method is specified)

            *   discovery of the Request-Routing protocol endpoints

            *   information necessary to establish secure communication
                between the Request-Routing protocol endpoints.

   CNTL-8   [LOW] The CDNI Control interface may allow bootstrapping of
            the CDNI Metadata interface.  This information could, for
            example, include:

            *   discovery of the CDNI Metadata signaling protocol
                endpoints

            *   information necessary to establish secure communication
                between the CDNI Metadata signaling protocol endpoints.

   CNTL-9   [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
            protocols to be used across the CDNs (e.g.  HTTP, HTTPS,
            FTP, ATIS C2).

   CNTL-10  [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).

   CNTL-11  [LOW] The CDNI Control interface may allow bootstrapping of
            the CDNI Logging interface.  This information could, for
            example, include:

            *   discovery of the Logging protocol endpoints

            *   information necessary to establish secure communication
                between the Logging protocol 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 June 9, 2012                  [Page 9]


Internet-Draft              CDNI Requirements              December 2011


5.  CDNI Request Routing Interface Requirements

   The main function of the Request Routing interface is to allow the
   Request-Routing systems in interconnected CDNs to communicate to
   facilitate redirection of the request across CDNs.

   REQ-1   [HIGH] The CDNI Request-Routing 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.

   REQ-2   [MED] The CDNI Request-Routing 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)

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

   REQ-3   [MED] In the case of cascaded redirection, the CDNI Request-
           Routing interface shall 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



Leung & Lee               Expires June 9, 2012                 [Page 10]


Internet-Draft              CDNI Requirements              December 2011


           requests received by the Upstream CDN.  In that case, the
           CDNI Request-Routing interface shall prevent looping of such
           information exchange.

   REQ-4   [LOW] The CDNI Request-Routing 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.

   REQ-5   [HIGH] The CDNI Request-Routing architecture and 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).

   REQ-6   [HIGH] The CDNI Request-Routing architecture and 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.

   REQ-7   [HIGH] The CDNI Request-Routing architecture shall support
           recursive CDNI request routing.

   REQ-8   [HIGH] The CDNI Request-Routing architecture shall support
           iterative CDNI request routing.

   REQ-9   [MED] In case of detection of a request redirection loop, the
           CDNI Request-Routing loop prevention mechanism should allow
           routing of the request by avoiding the loop (as opposed to
           the request loop being simply interrupted without routing the
           request).

   REQ-10  [MED] The CDNI Request-Routing protocol should support a
           mechanism allowing enforcment of a limit on the number of
           successive CDN redirections for a given request.




Leung & Lee               Expires June 9, 2012                 [Page 11]


Internet-Draft              CDNI Requirements              December 2011


   REQ-11  [LOW] The CDNI Request-Routing protocol 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.

   REQ-12  [HIGH] The CDNI Request-Routing protocol 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 location 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).

   REQ-13  [LOW] The CDNI Request-Routing protocol 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.

   REQ-14  [HIGH] The CDNI Request-Routing 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



Leung & Lee               Expires June 9, 2012                 [Page 12]


Internet-Draft              CDNI Requirements              December 2011


               case of DNS-based Request Routing).


6.  CDNI Metadata Distribution Interface Requirements

   The primary function of the CDNI Metadata Distribution interface 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).

   META-1   [HIGH] The CDNI Metadata Distribution interface shall allow
            the Upstream CDN to provide the Downstream CDN with content
            distribution metadata of inter-CDN scope.

   META-2   [HIGH] The CDNI Metadata Distribution interface shall
            support exchange of CDNI metadata for both the dynamic
            content acquisition model and the pre-positioning content
            acquisition model.

   META-3   [HIGH] The CDNI Metadata Distribution 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).

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

   META-5   [HIGH] Whether in the pre-positioned content acquisition
            model or in the dynamic content acquisition model, the CDNI
            Metadata Distribution 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).






Leung & Lee               Expires June 9, 2012                 [Page 13]


Internet-Draft              CDNI Requirements              December 2011


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

   META-7   [HIGH] The CDNI Metadata Distribution interface shall allow
            the Upstream CDN to request addition and modification of
            CDNI Metadata into the Downstream CDN.

   META-8   [HIGH] The CDNI Metadata Distribution 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).

   META-9   [HIGH] The CDNI Metadata Distribution 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.

   META-10  [HIGH] The CDNI Metadata Distribution 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.

   META-11  [HIGH] The CDNI Metadata Distribution 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.

   META-12  [HIGH] The CDNI Metadata Distribution interface shall ensure
            that conflicting metadata with overlapping scope are
            prevented or deterministically handled.






Leung & Lee               Expires June 9, 2012                 [Page 14]


Internet-Draft              CDNI Requirements              December 2011


   META-13  [HIGH] The CDNI Metadata Distribution interface shall
            provide indication by the Downstream CDN to the Upstream CDN
            of whether the CDNI metadata (and corresponding future
            request redirections) is accepted or rejected.  When
            rejected, the CDNI Metadata Distribution protocol Must allow
            the Downstream CDN to provide information about the cause of
            the rejection.

   META-14  [HIGH] The CDNI Metadata Distribution 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)

   META-15  [HIGH] The CDNI Metadata interface shall be able to exchange
            a set of well-accepted metadata elements with specified
            semantics (e.g. start of time window, end of time window).

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

   META-17  [HIGH] The CDNI Metadata Distribution 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:

            *   need to validate URI signed information (e.g.  Expiry
                time, Client IP address).

   META-18  [LOW] The CDNI Metadata Distribution interface may 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               Expires June 9, 2012                 [Page 15]


Internet-Draft              CDNI Requirements              December 2011


            *   content revalidation parameters (e.g.  TTL)


7.  CDNI Logging Interface Requirements

   This section identifies the requirements related to the CDNI Logging
   interface.  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.

   LOG-1   [HIGH] The CDNI logging architecture and interface shall
           ensure reliable logging of CDNI events.

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

   LOG-3   [MED] In the case of cascaded CDNs, the CDNI Logging
           interface shall 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.

   LOG-4   [HIGH] The CDNI Logging interface shall provide logging of
           distribution performed by the Upstream CDN as a result of
           acquisition request by the Downstream CDN.

   LOG-5   [HIGH] The CDNI Logging interface shall support batch/offline
           exchange of logging records.

   LOG-6   [MED] The CDNI Logging interface should also support
           additional timing constraints for some types of logging
           records (e.g. near-real time for monitoring and analytics
           applications)

   LOG-7   [HIGH] The CDNI Logging interface shall define a log file
           format and a set of fields to be exported through the Logging
           protocol, with some granularity (e.g.  On a per content type
           basis).

   LOG-8   [HIGH] The CDNI Logging interface shall define a transport
           mechanisms to exchange CDNI Logging files.





Leung & Lee               Expires June 9, 2012                 [Page 16]


Internet-Draft              CDNI Requirements              December 2011


   LOG-9   [MED] The CDNI Logging interface may allow a CDN to query
           another CDN for relevant current logging records (e.g.  For
           on-demand access to real-time logging information).

   LOG-10  [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).

   LOG-11  [LOW] The CDNI Logging interface shall 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 shall support the Upstream CDN to
           indicate the nature and contents of the performance data to
           be reported by the Downstream CDN.

   LOG-12  [MED] The CDNI Logging interface shall 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.

   LOG-13  [MED] In the case of cascaded CDNs, the CDNI Logging
           interface shall 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.

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

   LOG-15  [HIGH] The CDNI Logging interface shall support extensibility
           to allow proprietary information fields to be carried.  These
           information fields must be agreed upon ahead of time between
           the corresponding CDNs.

   LOG-16  [HIGH] The CDNI Logging interface shall support the exchange
           of extensible log file formats to support proprietary
           information fields.  These information fields must be agreed
           upon ahead of time between the corresponding CDNs.



Leung & Lee               Expires June 9, 2012                 [Page 17]


Internet-Draft              CDNI Requirements              December 2011


8.  CDNI Security Requirements

   This section identifies the requirements related to the CDNI
   security.  Some of those 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 chain of CDN
          Delegation (leading to that request being served by that CDN)
          can be established with non-repudiation.

   SEC-4  [MED] The CDNI solution should be able to ensure that the
          Downstream CDN cannot spoof a transaction log attempting to
          appear as if it corresponds to a request redirected by a given
          Upstream CDN when that request has not been redirected by this
          Upstream CDN.  This ensures non-repudiation by the Upstream
          CDN of transaction logs generated by the Downstream CDN for
          deliveries performed by the Downstream CDN on behalf of the
          Upstream CDN.

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


9.  IANA Considerations

   This document makes no request of IANA.

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






Leung & Lee               Expires June 9, 2012                 [Page 18]


Internet-Draft              CDNI Requirements              December 2011


10.  Security Considerations

   This document discusses CDNI security requirements in Section 8.


11.  Authors

   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

      BT

      grant.watson@bt.com


12.  Acknowledgements

   This document leverages the earlier work of the IETF CDI working
   group in particular as documented in [I-D.cain-request-routing-req],
   [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 Eardly, Ben Niven-Jenkins, Agustin Schapira, Emile
   Stephan, Eric Burger, Susan He, Kevin Ma, and Daryl Malas 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.


13.  References







Leung & Lee               Expires June 9, 2012                 [Page 19]


Internet-Draft              CDNI Requirements              December 2011


13.1.  Normative References

   [I-D.davie-cdni-framework]
              Davie, B. and L. Peterson, "Framework for CDN
              Interconnection", draft-davie-cdni-framework-01 (work in
              progress), October 2011.

   [I-D.ietf-cdni-problem-statement]
              Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", draft-ietf-cdni-problem-statement-01 (work in
              progress), October 2011.

   [I-D.ietf-cdni-use-cases]
              Bertrand, G., Emile, S., Watson, G., Burbridge, T.,
              Eardley, P., and K. Ma, "Use Cases for Content Delivery
              Network Interconnection", draft-ietf-cdni-use-cases-00
              (work in progress), September 2011.

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

13.2.  Informative References

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

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













Leung & Lee               Expires June 9, 2012                 [Page 20]


Internet-Draft              CDNI Requirements              December 2011


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 June 9, 2012                 [Page 21]