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

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:

• "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]".
• "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]".
• "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 March 12, 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.

Table of Contents

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

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.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 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". (OPEN ISSUE: Should requirements in each section be ordered by 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.

   -------- 
  /        \
  |   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

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-15

[MED] Wherever possible, the CDNI interfaces should reuse or leverage existing IETF protocols.

GEN-16

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

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

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

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

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

GEN-21

[LOW] The CDNI solution may support delivery to the user agent based on protocols other than HTTP.

GEN-22

[LOW] The CDNI solution may support acquisition across CDNs based on protocols other than HTTP.

GEN-23

[MED] The CDNI solution should support cascaded CDN redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an arbitrary number of levels.(OPEN ISSUE: arbitrary number should more than one level?)

GEN-24

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

[HIGH] The CDNI solution shall prevent looping of any CDNI information exchange.

GEN-26

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

[LOW] The CDNI solution should support virtualization of the Downstream CDN, so that the Downstream CDN can appear as multiple logical Downstream CDNs. (OPEN ISSUE: Virtualization is transparent to CDNI, remove requirement or justify why uCDN/dCDN needs to be aware?)

GEN-28

(OPEN ISSUE: Add HTTP ABR requirements)

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.

CNTL-12

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

CNTL-13

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

CNTL-14

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

[MED] The CDNI Control interface should support initiation and control by the Upstream CDN of pre-positioned content acquisition by the Downstream CDN.(OPEN ISSUE: how much influence the Upstream CDN ought to have on pre-positioning of the content on surrogates inside the Downstream CDN is TBD).

CNTL-16

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

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

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

• negotiation of the Request-Routing method (e.g. DNS vs HTTP, if more than one method is specified)
• discovery of the Request-Routing protocol endpoints
• information necessary to establish secure communication between the Request-Routing protocol endpoints.

CNTL-19

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

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

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

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

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-15

[HIGH] The CDNI Control 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. (OPEN ISSUE: Belong to Control Interface section?)

REQ-16

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

[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 requests received by the Upstream CDN. In that case, the CDNI Request-Routing interface shall prevent looping of such information exchange.

REQ-18

[LOW] The CDNI Control 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-19

[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). (OPEN ISSUE: Surrogate selection is out of scope?)

REQ-20

[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. (OPEN ISSUE: Surrogate selection is out of scope?)

REQ-21

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

REQ-22

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

REQ-23

[MED] 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). (OPEN ISSUE: Why route a looped request?)

REQ-24

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

REQ-25

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

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

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

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

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

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

[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). (OPEN ISSUE: Confirm high priority)

META-22

[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). (OPEN ISSUE: Confirm medium priority)

META-23

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

META-24

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

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

META-26

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

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

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

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

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

META-31

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

[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) (OPEN ISSUE: Expiration time needed?)
• delegation whitelist/blacklist (i.e. Information defining which downstream CDNs the content may/may not be delivered through)

META-33

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

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

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

[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
• 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-10

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

LOG-11

[HIGH] The CDNI Logging interface shall provide logging of deliveries to User Agents performed by the Downstream CDN as a result of request redirection by the Upstream CDN.

LOG-12

[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 performed by the Downstream CDN itself as well as logging for deliveries performed by cascaded CDNs on behalf of the Downstream CDN.

LOG-13

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

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

LOG-15

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

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

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

LOG-18

[LOW] 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).

[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)] (OPEN ISSUE: LOW for aggregate/summarized logs)

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-6

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

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

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

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

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

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, and Kevin Ma for their input.

13. References

13.1. Normative References

13.2. Informative References

Authors' Addresses