Network Working Group                                           K. Leung
Internet-Draft                                                     Cisco
Intended status: Informational                                    Y. Lee
Expires: January 10, 2012                                        Comcast
                                                          F. Le Faucheur
                                                        M. Viveganandhan
                                                                   Cisco
                                                               G. Watson
                                                                      BT
                                                            July 9, 2011


    Content Distribution Network Interconnection (CDNI) Requirements
                 draft-lefaucheur-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.

Requirements Language

   The key words "Must", "Should" and "May" in this document are to be
   interpreted in the following way:

   o  "Must" indicates requirements that are to be supported by the CDNI
      protocols in the stated scope (aka "within initial CDNI scope" or
      "beyond initial scope").  A requirement is stated as a "Must" when
      it is established by 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.

   o  "Should" indicates requirements that are to be supported by the
      CDNI protocols in the stated scope (aka "within initial CDNI
      scope" or "beyond initial scope") unless the WG realizes at a



Leung, et al.           Expires January 10, 2012                [Page 1]


Internet-Draft              CDNI Requirements                  July 2011


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

   o  "May" indicates requirements that are to be supported by the CDNI
      protocols in the stated scope (aka "within initial CDNI scope" or
      "beyond initial scope") provided that dedicating WG resources to
      this work does not prevent addressing "Should" and "Must"
      requirements and that attempting to meet this requirement would
      not compromise the overall WG schedule.


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 January 10, 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, et al.           Expires January 10, 2012                [Page 2]


Internet-Draft              CDNI Requirements                  July 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
   2.  CDNI Model and CDNI protocols  . . . . . . . . . . . . . . . .  5
   3.  Generic Requirements . . . . . . . . . . . . . . . . . . . . .  7
     3.1.  Within Initial CDNI Scope  . . . . . . . . . . . . . . . .  7
     3.2.  Beyond Initial CDNI Scope  . . . . . . . . . . . . . . . .  8
   4.  CDNI Control Protocol Requirements . . . . . . . . . . . . . .  8
     4.1.  Within Initial CDNI Scope  . . . . . . . . . . . . . . . .  9
     4.2.  Beyond Initial CDNI Scope  . . . . . . . . . . . . . . . .  9
   5.  CDNI Request Routing Protocol Requirements . . . . . . . . . . 11
     5.1.  Within Initial CDNI Scope  . . . . . . . . . . . . . . . . 11
     5.2.  Beyond Initial CDNI Scope  . . . . . . . . . . . . . . . . 14
   6.  CDNI Metadata Distribution Protocol Requirements . . . . . . . 15
     6.1.  Within Initial CDNI Scope  . . . . . . . . . . . . . . . . 15
     6.2.  Beyond Initial CDNI Scope  . . . . . . . . . . . . . . . . 17
   7.  CDNI Logging Protocol Requirements . . . . . . . . . . . . . . 18
     7.1.  Within Initial CDNI Scope  . . . . . . . . . . . . . . . . 18
     7.2.  Beyond Initial CDNI Scope  . . . . . . . . . . . . . . . . 19
   8.  CDNI Security Requirements . . . . . . . . . . . . . . . . . . 19
     8.1.  Within Initial CDNI Scope  . . . . . . . . . . . . . . . . 19
     8.2.  Beyond Initial CDNI Scope  . . . . . . . . . . . . . . . . 20
   9.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 20
   10. Security Considerations  . . . . . . . . . . . . . . . . . . . 20
   11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 21
   12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 21
     12.1. Normative References . . . . . . . . . . . . . . . . . . . 21
     12.2. Informative References . . . . . . . . . . . . . . . . . . 21
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 22





















Leung, et al.           Expires January 10, 2012                [Page 3]


Internet-Draft              CDNI Requirements                  July 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.  However, no standards or open specifications currently
   exist to facilitate such CDN interconnection.

   [I-D.jenkins-cdni-problem-statement] outlines the problem area that
   the CDNI working group is chartered to address.
   [I-D.bertrand-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 accordance with the working
   group charter, the work is prioritized in a "walk before you run"
   approach: the present document separates the CDNI requirements into a
   set of more urgent requirements that are within the initial scope of
   the CDNI working group, and a set of less urgent additional
   requirements that are left to potential future rechartering of the
   working group.

1.1.  Terminology

   This document uses the terminology defined in section 1.1 of
   [I-D.jenkins-cdni-problem-statement].

   This also defined the following additional terms [Editor's Note:
   these definitions may be better located in another document such as
   the Problem Statement]:





Leung, et al.           Expires January 10, 2012                [Page 4]


Internet-Draft              CDNI Requirements                  July 2011


   o  Recursive CDNI request routing: When an Upstream CDN elects to
      redirect a request towards a Downstream CDN, the Upstream CDN can
      query the Downstream CDN Request Routing system via the CDNI
      Request Routing protocol (or use information cached from earlier
      similar queries) to find out how the Downstream CDN wants the
      request to be redirected, which allows the Upstream CDN to factor
      in the Downstream CDN response when redirecting the user agent.
      This approach is referred to as "recursive" CDNI request routing.
      Note that the Downstream CDN may elect to have the request
      redirected directly to a Surrogate inside the Downstream CDN, to
      the Request-Routing System of the Downstream CDN, to another CDN,
      or to any other system that the Downstream CDN sees as fit for
      handling the redirected request.

   o  Iterative CDNI Request Routing: When an Upstream CDN elects to
      redirect a request towards a Downstream CDN, the Upstream CDN can
      base its redirection purely on a local decision (and without
      attempting to take into account how the Downstream CDN may in turn
      redirect the user agent).  In that case, the Upstream CDN
      redirects the request to the request routing system in the
      Downstream CDN, which in turn will decide how to redirect that
      request: this approach is referred to as "iterative" CDNI request
      routing.


2.  CDNI Model and CDNI protocols

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





















Leung, et al.           Expires January 10, 2012                [Page 5]


Internet-Draft              CDNI Requirements                  July 2011


      --------
     /        \
     |   CSP  |
     \        /
      --------
          *
          *
          *                        /\
          *                       /  \
      ---------------------      |CDNI|       ---------------------
     /    Upstream CDN     \     |    |      /   Downstream CDN    \
     |     +-------------+ | Control protocol| +-------------+     |
     |     |CDN Control  |<======|====|=======>| CDN Control |     |
     |     +------*-*-*--+ |     |    |      | +-*-*-*-------+     |
     |            * * *    |     |    |      |   * * *             |
     |     +------*------+ | Logging protocol| +-----*-------+     |
     | ****| Logging     |<======|====|=======>|  Logging    |**** |
     | *   --------------+ |     |    |      | +-------------+   * |
     | *            * *    | Request Routing |   * *             * |
   ....*...+--------*----+ |    protocol     | +---*---------+...*.....
   . | * **|Req-Routing  |<======|====|=======>| Req-Routing |** * |  .
   . | * * +-------------+.|     |    |      | +-------------+ * * |  .
   . | * *            *    .  CDNI Metatdata |   *             * * |  .
   . | * * +----------*--+ |.   protocol     | +-*-----------+ * * |  .
   . | * * |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 APIs




Leung, et al.           Expires January 10, 2012                [Page 6]


Internet-Draft              CDNI Requirements                  July 2011


3.  Generic Requirements

   This section identifies generic requirements independent of the
   individual CDNI protocols.  Some of those are expected to affect
   multiple or all protocols.

3.1.  Within Initial CDNI Scope

   R1   Wherever possible, the CDNI protocols Should reuse or leverage
        existing IETF protocols.

   R2   The CDNI solution Must not require a change, or an upgrade, to
        the User Agent to benefit from content delivery through
        interconnected CDNs.

   R3   The CDNI solution Must 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.

   R4   The CDNI solution Must 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].

   R5   The CDNI solution Must support acquisition across CDNs based on
        HTTP [RFC2616].

   R6   The CDNI solution May support delivery to the user agent based
        on protocols other than HTTP.

   R7   The CDNI solution May support acquisition across CDNs based on
        protocols other than HTTP.

   R8   The CDNI solution Should support cascaded CDN redirection (CDN1
        redirects to CDN2 that redirects to CDN3) to an arbitrary number
        of levels.

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






Leung, et al.           Expires January 10, 2012                [Page 7]


Internet-Draft              CDNI Requirements                  July 2011


   R10  The CDNI solution Must prevent looping of any CDNI information
        exchange.

   R11  When making use of third party reference, the CDNI solution Must
        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).

3.2.  Beyond Initial CDNI Scope

   R12  The CDNI solution Must support cascaded CDN redirection (CDN1
        redirects to CDN2 that redirects to CDN3) to an arbitrary number
        of levels.  [Note: this "Must" requirement appeared as a
        "Should" requirement in Section 3.1]

   R13  The CDNI solution Must support an arbitrary topology of
        interconnected CDNs (i.e. the CDN topology cannot be restricted
        to a tree, a loop-free topology, etc.).  [Note: this "Must"
        requirement appeared as a "Should" requirement in Section 3.1]

   R14  The CDNI solution Should support virtualization of the
        Downstream CDN, so that the Downstream CDN can appear as
        multiple logical Downstream CDNs.


4.  CDNI Control Protocol Requirements

   The primary purpose of the CDNI Control protocol 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 protocol is
   currently discussed as a single "protocol", further analysis will
   determine whether the corresponding requirements are to be realized



Leung, et al.           Expires January 10, 2012                [Page 8]


Internet-Draft              CDNI Requirements                  July 2011


   over a single interface and protocol, or over multiple interfaces and
   protocols.

4.1.  Within Initial CDNI Scope

   R15  The CDNI Control protocol Must 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(s) and/or its CDNI metadata as "stale" and
            revalidate them before they are delivered again

        *   Delete an object(s) and/or its CDNI metadata from the CDN
            surrogates and any storage.

   R16  The CDNI Control protocol Must 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).

   R17  The CDNI Control protocol Must support initiation and control by
        the Upstream CDN of pre-positioned CDNI metadata acquisition by
        the Downstream CDN.

   R18  The CDNI Control protocol Should support initiation and control
        by the Upstream CDN of pre-positioned content acquisition by the
        Downstream CDN.[Editor's Note: how much influence the Upstream
        CDN ought to have on pre-positioning of the content on
        surrogates inside the Downstream CDN is TBD].

4.2.  Beyond Initial CDNI Scope

   R19  The CDNI Control protocol Must support support initiation and
        control by the Upstream CDN of pre-positioned content
        acquisition.[Editor's Note: how much influence the Upstream CDN
        ought to have on pre-positioning of the content on surrogates
        inside the Downstream CDN is TBD].  [Note: this "Must"
        requirement appeared as a "Should" requirement in Section 4.1]

   R20  The CDNI Control protocol Must 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).






Leung, et al.           Expires January 10, 2012                [Page 9]


Internet-Draft              CDNI Requirements                  July 2011


   R21  The CDNI Control protocol Must 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).

   R22  The CDNI Control protocol Should allow bootstrapping of the
        Request-Routing protocol.  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 Request-Routing protocol endpoints

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

   R23  The CDNI Control protocol Should allow bootstrapping of the
        Metadata Signaling protocol.  This information could, for
        example, include:

        *   discovery of the Metadata Signaling protocol endpoints

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

   R24  The CDNI Control protocol Should allow bootstrapping of the
        Content Acquisition protocol.  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).

   R25  The CDNI Control protocol Should allow exchange and negotiation
        of delivery authorization mechanisms to be supported across the
        CDNs (e.g.  URI signature based validation).

   R26  The CDNI Control protocol Should allow bootstrapping of the CDNI
        Logging protocol.  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).




Leung, et al.           Expires January 10, 2012               [Page 10]


Internet-Draft              CDNI Requirements                  July 2011


        *   negotiation/definition of parameters related to transaction
            Logs export (e.g., export protocol, file compression, export
            frequency, directory).


5.  CDNI Request Routing Protocol Requirements

5.1.  Within Initial CDNI Scope

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

   R27  The CDNI Control protocol Must 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.

   R28  The CDNI Request-Routing protocol 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.]



Leung, et al.           Expires January 10, 2012               [Page 11]


Internet-Draft              CDNI Requirements                  July 2011


   R29  If cascaded redirection is supported by the CDNI solution, the
        CDNI Request-Routing protocol Must 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 protocol Must prevent looping of such
        information exchange.

   R30  The CDNI Control protocol 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.

   R31  The CDNI Request-Routing architecture and protocol Must 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).

   R32  The CDNI Request-Routing architecture and protocol Must 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.

   R33  The CDNI Request-Routing architecture Must support recursive
        CDNI request routing.

   R34  The CDNI Request-Routing architecture Must support iterative
        CDNI request routing.

   R35  In case of detection of a request redirection loop, the CDNI
        Request-Routing loop prevention mechanism Should allow routing
        of the request (as opposed to the request loop being simply
        interrupted without routing the request).




Leung, et al.           Expires January 10, 2012               [Page 12]


Internet-Draft              CDNI Requirements                  July 2011


   R36  The CDNI Request-Routing protocol Should support an optional
        mechanism allowing enforcment of a limit on the number of
        successive CDN redirections for a given request.

   R37  The CDNI Request-Routing protocol May support an optional
        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.

   R38  The CDNI Request-Routing protocol Must 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).

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

   R40  The CDNI Request-Routing protocol Must 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)





Leung, et al.           Expires January 10, 2012               [Page 13]


Internet-Draft              CDNI Requirements                  July 2011


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

5.2.  Beyond Initial CDNI Scope

   R41  The CDNI Request-Routing protocol Must 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: this "Must" requirement appeared as a "Should"
        requirement in Section 5.1]

   R42  The CDNI Request-Routing protocol Must 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.  The CDNI Control
        protocol Must prevent looping of such information exchange.
        [Note: this "Must" requirement appeared as a conditional "Must"
        requirement in Section 5.1]

   R43  The CDNI Request-Routing protocol Should 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
            that to be served simultaneously by the Downstream CDN



Leung, et al.           Expires January 10, 2012               [Page 14]


Internet-Draft              CDNI Requirements                  July 2011


        *   maximum aggregate volume of content (e.g. in Terabytes) to
            be delivered by the Downstream CDN over a time period

        [Note: this "Should" requirement appeared as a "May" requirement
        in Section 5.1]

   R44  The CDNI Request-Routing loop prevention mechanism Must allow
        routing of the request (as opposed to the request loop being
        simply interrupted without routing the request).  [Note: this
        "Must" requirement appeared as a "Should" requirement in
        Section 5.1]

   R45  The CDNI Request-Routing protocol Must support optional
        enforcement of a limit on the number of successive CDN
        redirections for a given request.  [Note: this "Must"
        requirement appeared as a "Should" requirement in Section 5.1]


6.  CDNI Metadata Distribution Protocol Requirements

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

6.1.  Within Initial CDNI Scope

   R46  The CDNI Metadata Distribution protocol Must allow the Upstream
        CDN to provide the Downstream CDN with content distribution
        metadata of inter-CDN scope.

   R47  The CDNI Metadata Distribution protocol Must support exchange of
        CDNI metadata for both the dynamic content acquisition model and
        the pre-positioning content acquisition model.

   R48  The CDNI Metadata Distribution protocol Must/Should/May? 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).



Leung, et al.           Expires January 10, 2012               [Page 15]


Internet-Draft              CDNI Requirements                  July 2011


   R49  The CDNI Metadata Distribution protocol Must/Should/May? support
        a mode where all the relevant Metadata is initially communicated
        to the Downstream CDN (i.e.  Pre-positioned CDNI metadata
        acquisition).

   R50  Whether in the pre-positioned content acquisition model or in
        the dynamic content acquisition model, the CDNI Metadata
        Distribution protocol Must 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).

   R51  The CDNI metadata Must 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.

   R52  The CDNI Metadata Distribution protocol Must allow the Upstream
        CDN to request addition and modification of CDNI Metadata into
        the Downstream CDN.

   R53  The CDNI Metadata Distribution protocol Must 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).

   R54  The CDNI Metadata Distribution protocol Must 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.

   R55  The CDNI Metadata Distribution protocol Must 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.

   R56  The CDNI Metadata Distribution protocol Must 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



Leung, et al.           Expires January 10, 2012               [Page 16]


Internet-Draft              CDNI Requirements                  July 2011


        for any content.

   R57  The CDNI Metadata Distribution protocol Must ensure that
        conflicting metadata with overlapping scope are prevented or
        deterministically handled.

   R58  The CDNI Metadata Distribution protocol Must 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.

   R59  The CDNI Metadata Distribution protocol Must 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)

        *   delegation whitelist/blacklist (i.e.  Information defining
            which downstream CDNs the content may/may not be delivered
            through)

   R60  The CDNI Metadata Distribution protocol Must 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).

6.2.  Beyond Initial CDNI Scope

   R61  The CDNI Metadata Distribution protocol Must 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).  [Note: this "Must" requirement appeared
        as a "Must/Should/May?" requirement in Section 6.1]






Leung, et al.           Expires January 10, 2012               [Page 17]


Internet-Draft              CDNI Requirements                  July 2011


   R62  The CDNI Metadata Distribution protocol Must support a mode
        where all the relevant Metadata is initially communicated to the
        Downstream CDN (i.e.Pre-positioned CDNI metadata acquisition).
        [Note: this "Must" requirement appeared as a "Must/Should/May?"
        requirement in Section 6.1]

   R63  The CDNI Metadata Distribution protocol Must 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

        *   content revalidation parameters (e.g.  TTL)


7.  CDNI Logging Protocol Requirements

   This section identifies the requirements related to the CDNI Logging
   protocol.  We observe that while the CDNI Logging 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.

7.1.  Within Initial CDNI Scope

   R64  The CDNI logging architecture and protocol Must ensure reliable
        logging of CDNI events.

   R65  The CDNI Logging protocol Must provide logging of deliveries to
        User Agents performed by the Downstream CDN as a result of
        request redirection by the Upstream CDN.

   R66  If cascaded CDNs are supported, the CDNI logging protocol Must
        allow the Downstream CDN to report to the Upstream CDN logging
        for deliveries performed by the Downstream CDN itself as well as
        logging for deliveries performed by cascaded CDNs on behalf of
        the Downstream CDN.

   R67  The CDNI Logging protocol Must provide logging of distribution
        performed by the Upstream CDN as a result of acquisition request
        by the Downstream CDN.

   R68  The CDNI Logging protocol Must support batch/offline exchange of
        logging records.





Leung, et al.           Expires January 10, 2012               [Page 18]


Internet-Draft              CDNI Requirements                  July 2011


   R69  The CDNI Logging protocol Should also support additional timing
        constraints for some types of logging records (e.g. near-real
        time for monitoring and analytics applications)

   R70  The CDNI Logging protocol Must 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).

   R71  The CDNI Logging protocol Must define a transport mechanisms to
        exchange CDNI Logging files.

   [Editor's note: should we add a requirement for support of aggregate/
   summarized logs (e.g. total bytes delivered for a content regardless
   of individual USer Agents to which it was delivered)]

7.2.  Beyond Initial CDNI Scope

   R72  The CDNI logging protocol Must allow the Downstream CDN to
        report to the Upstream CDN logging for deliveries performed by
        the Downstream CDN itself as well as logging for deliveries
        performed by cascaded CDNs on behalf of the Downstream CDN.
        [Note: this "Must" requirement appeared as a conditional "Must"
        requirement in Section 7.1]

   R73  The CDNI Logging protocol Must support real-time exchange of
        some types of logging records (e.g.  For real-time monitoring of
        deliveries across CDNs).  [Note: this "Must" requirement
        appeared as a "Should" requirement in Section 7.1]

   R74  The CDNI Logging protocol Must allow a CDN to query another CDN
        for relevant current logging records (e.g.  For on-demand access
        to real-time logging information).


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.

8.1.  Within Initial CDNI Scope

   R75  All the CDNI protocols Must 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.





Leung, et al.           Expires January 10, 2012               [Page 19]


Internet-Draft              CDNI Requirements                  July 2011


   R76  The CDNI solution Must 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.

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

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

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

8.2.  Beyond Initial CDNI Scope

   R80  The CDNI solution Must 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).  [Note: this "Must"
        requirement appeared as a "May" requirement in Section 8.1]


9.  IANA Considerations

   This document makes no request of IANA.

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


10.  Security Considerations

   This document discusses CDNI security requirements in Section 8.



Leung, et al.           Expires January 10, 2012               [Page 20]


Internet-Draft              CDNI Requirements                  July 2011


11.  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, Agustin Schapira and Emile Stephan for
   their input.  We also want to thank Ben Niven-Jenkins for his review
   and comments.


12.  References

12.1.  Normative References

   [I-D.bertrand-cdni-use-cases]
              Bertrand, G., Stephan, E., Watson, G., Burbridge, T.,
              Eardley, P., and K. Ma, "Use Cases for Content Delivery
              Network Interconnection", draft-bertrand-cdni-use-cases-02
              (work in progress), July 2011.

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

   [I-D.jenkins-cdni-problem-statement]
              Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", draft-jenkins-cdni-problem-statement-02 (work
              in progress), March 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.

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



Leung, et al.           Expires January 10, 2012               [Page 21]


Internet-Draft              CDNI Requirements                  July 2011


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


Authors' Addresses

   Kent Leung
   Cisco Systems
   3625 Cisco Way
   San Jose  95134
   USA

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


   Yiu Lee
   Comcast


   Email: yiu_lee@cable.comcast.com


   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410
   France

   Phone: +33 4 97 23 26 19
   Email: flefauch@cisco.com


   Mahesh Viveganandhan
   Cisco Systems
   375 East Tasman Drive
   San Jose  95134
   USA

   Email: mvittal@cisco.com










Leung, et al.           Expires January 10, 2012               [Page 22]


Internet-Draft              CDNI Requirements                  July 2011


   Grant Watson
   BT


   Email: grant.watson@bt.com














































Leung, et al.           Expires January 10, 2012               [Page 23]