Network Working Group F. Le Faucheur Internet-Draft M. Viveganandhan Intended status: Informational Cisco Expires: July 30, 2011 G. Watson BT Y. Lee Comcast January 26, 2011 Content Distribution Network Interconnection (CDNI) Requirements draft-lefaucheur-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. However, no standards or open specifications currently exist to facilitate such CDN interconnection. The "CDN Interconnect Problem Statement" Internet-Draft outlines the problem area for the IETF with a view towards creating a working group. This working group would work on an interoperable and scalable solution for CDN interconnection. The goal of the present document is to start outlining the requirements for such a "CDN Interconnection" solution. Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. 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/. Le Faucheur, et al. Expires July 30, 2011 [Page 1] Internet-Draft CDNI Requirements January 2011 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 July 30, 2011. 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. Le Faucheur, et al. Expires July 30, 2011 [Page 2] Internet-Draft CDNI Requirements January 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. CDNI Model and CDNI APIs . . . . . . . . . . . . . . . . . . . 5 3. Generic Requirements . . . . . . . . . . . . . . . . . . . . . 7 3.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 7 3.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 7 4. CDNI Control API Requirements . . . . . . . . . . . . . . . . 8 4.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 8 4.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 9 5. Request Routing API Requirements . . . . . . . . . . . . . . . 12 5.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 12 5.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 14 6. CDNI Metadata API Requirements . . . . . . . . . . . . . . . . 14 6.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 15 6.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 17 7. CDNI Logging API Requirements . . . . . . . . . . . . . . . . 18 7.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 18 7.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 18 8. CDNI Security Requirements . . . . . . . . . . . . . . . . . . 19 8.1. Within Initial CDNI Scope . . . . . . . . . . . . . . . . 19 8.2. Beyond Initial CDNI Scope . . . . . . . . . . . . . . . . 19 9. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 20 10. Security Considerations . . . . . . . . . . . . . . . . . . . 20 11. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 20 12. References . . . . . . . . . . . . . . . . . . . . . . . . . . 20 12.1. Normative References . . . . . . . . . . . . . . . . . . . 20 12.2. Informative References . . . . . . . . . . . . . . . . . . 21 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 21 Le Faucheur, et al. Expires July 30, 2011 [Page 3] Internet-Draft CDNI Requirements January 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 for the IETF with a view towards creating a working group. This working group would work on interoperable and scalable solutions for CDN interconnection. [I-D.watson-cdni-use-cases] and [I-D.bertrand-cdni-use-cases] discuss the use cases for CDN Interconnection. The goal of the present document is to outline the requirements for such a "CDN Interconnection" solution. As discussed in section 5 of [I-D.jenkins-cdni-problem-statement] in order to manage the potential workload of a CDNI WG, it is recommended that the work be prioritized in a "walk before you run" approach. In line with that approach, the present document makes a first attempt at separating the CDNI requirements into a set of more urgent requirements that would be within the initial scope of a potential CDNI Working Group, and a set of less urgent additional requirements that would be left to future rechartering of the potential WG. This is intended to facilitate discussion and convergence on requirements prioritization in view of progressing the definition of a potential Working Group charter. 1.1. Terminology This document uses the terminology defined in section 1.1 of [I-D.jenkins-cdni-problem-statement]. Le Faucheur, et al. Expires July 30, 2011 [Page 4] Internet-Draft CDNI Requirements January 2011 2. CDNI Model and CDNI APIs For convenience Figure 1 from [I-D.jenkins-cdni-problem-statement] illustrating the CDNI problem area and the CDNI APIs is replicated below. Le Faucheur, et al. Expires July 30, 2011 [Page 5] Internet-Draft CDNI Requirements January 2011 -------- / \ | CSP | \ / -------- * * * /\ * / \ --------------------- |CDNI| --------------------- / Upstream CDN \ | | / Downstream CDN \ | +-------------+ | Control API | +-------------+ | | |CDN Control |<======|====|=======>| CDN Control | | | +------*-*-*--+ | | | | +-*-*-*-------+ | | * * * | | | | * * * | | +------*------+ | Logging API | +-----*-------+ | | ****| Logging |<======|====|=======>| Logging |**** | | * --------------+ | | | | +-------------+ * | | * * * | | | | * * * | | * +--------*----+ | Req-Routing API | +---*---------+ * | | * **|Req-Routing |<======|====|=======>| Req-Routing |** * | | * * +-------------+ | | | | +-------------+ * * | | * * * | | | | * * * | | * * +----------*--+ |CDNI Metadata API| +-*-----------+ * * | | * * |Distribution |<======|====|=======>| Distribution| * * | | * * | | | \ / | | | * * | | * * | | | \/ | | | * * | | * ****+---------+ | | | | +---------+**** * | | ******|Surrogate|*************************|Surrogate|****** | | | +---------+ | | Acquisition | | +-----*---+ | | | +-------------+ | | +-------*-----+ | \ / \ * / --------------------- ---------*----------- * * Delivery * +------+ | User | | Agent| +------+ <==> interfaces inside the scope of CDNI **** interfaces outside the scope of CDNI Figure 1: CDNI Model and CDNI APIs Le Faucheur, et al. Expires July 30, 2011 [Page 6] Internet-Draft CDNI Requirements January 2011 3. Generic Requirements This section identifies generic requirements independent of the individual CDNI APIs. Some of those are expected to affect multiple or all APIs. 3.1. Within Initial CDNI Scope R1 Wherever possible, the CDNI APIs 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 to expose the intra-CDN information across CDNs (e.g. Surrogates topology, surrogates status, cached content, ...) for effective and efficient delivery of the content. R4 The CDNI solution MUST support delivery to the user agent based on HTTP [ RFC 3040 [RFC2616]]. R5 The CDNI solution MUST support acquisition across CDNs based on HTTP [ RFC 3040 [RFC2616]]. R6 The CDNI solution MAY support delivery to the user agent based on other protocols than HTTP. R7 The CDNI solution MAY support acquisition across CDNs based on other protocols 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.). 3.2. Beyond Initial CDNI Scope R10 The CDNI solution MUST support cascaded CDN redirection (CDN1 redirects to CDN2 that redirects to CDN3) to an arbitrary number of levels. Le Faucheur, et al. Expires July 30, 2011 [Page 7] Internet-Draft CDNI Requirements January 2011 R11 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.). 4. CDNI Control API Requirements The primary purpose of the CDNI Control API is to initiate the interconnection across CDNs and bootstrap the other CDNI interfaces. We observe that while the CDNI Control API is currently discussed as a single "API", further analysis will determine whether the corresponding requirements are to be realized over a single interface and protocol, or over multiple interfaces and protocols. 4.1. Within Initial CDNI Scope R12 The CDNI Control API 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. R13 The CDNI Control API SHOULD allow the Downstream CDN to communicate to the Upstream CDN aggregate information on the Downstream CDN capabilities, resources and affinities (i.e. Preferences or cost). 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: * 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). [Editor's note: this functionality is currently described in draft-jenkins-cdni-problem-statement-01 under the Control API. Should it be moved under the Request-Routing API since it is about exchange of information that is to be consumed by the Request-Routing system to facilitate its request routing Le Faucheur, et al. Expires July 30, 2011 [Page 8] Internet-Draft CDNI Requirements January 2011 decisions?]. R14 If cascaded redirection is supported by the CDNI solution, the CDNI Control API SHOULD allow the Downstream CDN to also include in the information communicated to the Upstream CDN, information on the capabilities, resources and affinities of CDNs to which the Downstream CDN may (in turn) redirect requests received by the Upstream CDN. In that case, the CDNI Control API MUST prevent looping of information exchange. R15 The CDNI Control API 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 his 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 R16 The CDNI Control API MUST allow the Upstream CDN to request the Downstream CDN (and potential cascaded Downstream CDNs - if cascaded CDNs are supported by the solution) to interrupt delivery of an object (or object set) and trigger specific cache actions or behaviors in the Downstream CDN surrogates (e.g. Object removal from cache, revalidation). [Editor's note: this functionality is currently described in draft-jenkins-cdni-problem-statement-01 under the Metadata API but probably fits better under the Control API]. 4.2. Beyond Initial CDNI Scope R17 The CDNI Control API 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). R18 The CDNI Control API 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). Le Faucheur, et al. Expires July 30, 2011 [Page 9] Internet-Draft CDNI Requirements January 2011 R19 The CDNI Control API SHOULD allow bootstrapping of the Request- Routing API. 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 API endpoints * information necessary to establish secure communication between the Request-Routing API endpoints. R20 The CDNI Control API MUST allow the Downstream CDN to communicate to the Upstream CDN aggregate information on the Downstream CDN capabilities, resources and affinities (i.e. Preferences or cost). This information can be taken into account by the Upstream CDN Request Routing system in his CDN Selection decisions. 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). R21 The CDNI Control API 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 API MUST prevent looping of information exchange. R22 The CDNI Control API 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 his CDN Selection decisions. This information could, for example, include: Le Faucheur, et al. Expires July 30, 2011 [Page 10] Internet-Draft CDNI Requirements January 2011 * maximum number of requests redirected by the Upstream CDN that 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 R23 The CDNI Control API SHOULD support virtualization of the Downstream CDN, so that the Downstream CDN appears as multiple virtual Downstream CDN. In that case, the information discussed in the previous requirement MUST be complemented with a Virtual CDN Identifier that is unique in the context of the pair of CDNs on both sides of the CDNI Control API. R24 The CDNI Control API SHOULD allow bootstrapping of the Metadata Signaling API. This information could, for example, include: * discovery of the Metadata Signaling API endpoints * information necessary to establish secure communication between the Metadata Signaling API endpoints. R25 The CDNI Control API SHOULD allow bootstrapping of the Content Acquisition API. This information could, for example, include: * negotiation of the Content Acquisition protocol to be used (e.g. HTTP, HTTPS, FTP, ATIS C2), with some granularity (e.g. On a per content type basis). R26 The CDNI Control API SHOULD allow the Upstream CDN to distribute the information necessary to bootstrap delivery authorization mechanisms to be performed by Downstream CDN. This information could, for example, include: * information necessary for surrogates to perform URI signature based validation R27 The CDNI Control API SHOULD allow bootstrapping of the CDNI Logging API. This information could, for example, include: * discovery of the Logging API endpoints * information necessary to establish secure communication between the Logging API endpoints * negotiation/definition of the log file format and set of fields to be exported through the Logging API, with some granularity (e.g. On a per content type basis). For example, in the case of HTTP delivery, one candidate Le Faucheur, et al. Expires July 30, 2011 [Page 11] Internet-Draft CDNI Requirements January 2011 approach might be : + to specify one (or set of) base log file format in a similar manner to the Apache Common Log file Format ([Apache-Common] ), and + to specify a mechanism allowing the Upstream CDN to define alternative custom file formats (i.e. Containing an alternative set of fields out of those defined by the CDNI WG) in a similar manner to the Apache LogFormat directive [Apache-Format], and + to specify a mechanism allowing negotiations/selection of the file format (among the base formats or the alternative formats). * negotiation/definition of parameters related to transaction Logs export (e.g., export protocol, file compression, export frequency, directory). 5. Request Routing API Requirements 5.1. Within Initial CDNI Scope The main function of the Request Routing API is to allow the Request- Routing systems in interconnected CDNs to communicate to facilitate redirection of the request across CDNs. R28 The CDNI Request-Routing architecture and API 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). R29 The CDNI Request-Routing architecture and API 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 API call. R30 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 API (or use information cached from earlier similar queries) to find out how Le Faucheur, et al. Expires July 30, 2011 [Page 12] Internet-Draft CDNI Requirements January 2011 the Downstream CDN wants the request to be redirected, which allows the Upstream CDN to factor this when redirecting the user agent. This approach is referred to as "recursive". 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. The CDNI Request-Routing architecture MUST support recursive request routing. R31 Alternatively, 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 always 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". The CDNI Request-Routing architecture MUST support iterative request routing. R32 The CDNI Request-Routing API SHOULD support request loop detection and prevention (e.g. Prevent request looping in a situation where CDN1 redirects to CDN2 that redirects to CDN3 that would redirect to CDN1). R33 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). R34 The CDNI Request-Routing API SHOULD support optional enforcement of a limit on the number of successive CDN redirections for a given request. R35 The CDNI Request-Routing API 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 about the location of the user-agent that originated the request (e.g. IP address of User Agent in case of HTTP-based Request Routing, DNS Proxy 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) Le Faucheur, et al. Expires July 30, 2011 [Page 13] Internet-Draft CDNI Requirements January 2011 * additional available request information (e.g request headers in case of HTTP-based Request Routing) R36 The CDNI Request-Routing API MAY also allow the Upstream CDN to convey information pointing to CDNI metadata associated with the requested content. R37 The CDNI Request-Routing API 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. In case of rejection, an error code is also provided) * 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) R38 The CDNI Request-Routing architecture MUST support a mechanism by which a Downstream CDN can notify the Upstream CDN when it is unable or unwilling to serve a request, so the Upstream CDN can react accordingly (e.g. Select another Downstream CDN, or serve the request itself). 5.2. Beyond Initial CDNI Scope R39 The CDNI Request-Routing API MUST support request loop detection and prevention (e.g. Prevent request looping in a situation where CDN1 redirects to CDN2 that redirects to CDN3 that would redirect to CDN1). R40 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). R41 The CDNI Request-Routing API MUST support optional enforcement of a limit on the number of successive CDN redirections for a given request. 6. CDNI Metadata API Requirements The primary function of the CDNI Metadata API 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 API is currently discussed as a single "API", further analysis will Le Faucheur, et al. Expires July 30, 2011 [Page 14] Internet-Draft CDNI Requirements January 2011 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 R42 The CDNI Metadata API MUST support a dynamic acquisition model whereby the Upstream CDN provides the Downstream CDN with content distribution metadata (including information about how to acquire content from the Upstream CDN), and whereby the Downstream CDN surrogates acquire content when it is actually requested by endusers. R43 The CDNI Metadata API SHOULD support a pre-positioning model whereby the Upstream CDN requests the Downstream CDN to acquire content and associated distribution metadata (and possibly position those into Downstream CDN surrogates) at an appropriate time (now or a specified future time), before the content is actually requested by endusers. [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]. [Editor's note: this functionality is currently described in draft-jenkins-cdni-problem-statement-01 under the Metadata API. Should it be moved under the Control API (since it is not strictly about exchange of metadata but more about triggering multiple actions in downstream CDN, one of them being possibly to get metadata) ?]. R44 The CDNI Metadata API 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. R45 The CDNI Metadata API MUST/SHOULD/MAY? support a mode where all the relevant Metadata is initially communicated to the Downstream CDN. R46 Whether in the pre-positioning model or a dynamic acquisition model, the CDNI Metadata API MUST provide the necessary information to allow the Downstream CDN to acquire the content from the Upstream CDN (e.g. Acquisition protocol and Uniform Resource Identifier in Upstream CDN- or rules to construct this URI). Le Faucheur, et al. Expires July 30, 2011 [Page 15] Internet-Draft CDNI Requirements January 2011 R47 The CDNI Metadata API MUST also provide the necessary information to allow the Downstream CDN to attempt to acquire the content from the content Origin Server, in case it can not be obtained from the Upstream CDN (e.g. Because of a failure scenario). Note that the content Origin Server may or may not be willing to serve the content to the Downstream CDN since the Content Provider may not have a direct agreement/relationship with the Downstream CDN for delivery of this content. R48 The CDNI Metadata API MUST allow the Upstream CDN to add and modify CDNI Metadata into the Downstream CDN. R49 The CDNI Metadata API 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). R50 The CDNI Metadata API 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. R51 The CDNI Metadata API 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. R52 The CDNI Metadata API 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 API MUST allow the Downstream CDN to provide information about the cause of the rejection. R53 The Metadata that can be distributed by the CDNI Metadata API MUST allow signaling of 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) Le Faucheur, et al. Expires July 30, 2011 [Page 16] Internet-Draft CDNI Requirements January 2011 R54 The Metadata that can be distributed by the CDNI Metadata API 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). R55 If cascaded CDNs are supported by the CDNI solution, the CDNI Metadata API MUST prevent looping of CDNI Metadata distribution across CDNs. 6.2. Beyond Initial CDNI Scope R56 The CDNI Metadata API MUST support a pre-positioning model whereby the Upstream CDN requests the Downstream CDN to acquire content and associated distribution metadata (and possibly position those into Downstream CDN surrogates) at an appropriate time (now or a specified future time), before the content is actually requested by endusers. [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]. [Editor's note: this functionality is currently described in draft-jenkins-cdni-problem-statement-01 under the Metadata API. Should it be moved under the Control API (since it is not strictly about exchange of metadata but more about triggering multiple actions in downstream CDN, one of them being possibly to get metadata) ?]. R57 The Metadata that can be distributed by the CDNI Metadata API 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) R58 The CDNI Metadata API MUST prevent looping of CDNI Metadata distribution across CDNs in the presence of cascaded CDNs. R59 The CDNI Metadata API SHOULD allow signalling of the Virtual CDN identifier to be used in the Downstream CDN for distribution and delivery of the corresponding content (or content set). Le Faucheur, et al. Expires July 30, 2011 [Page 17] Internet-Draft CDNI Requirements January 2011 7. CDNI Logging API Requirements This section identifies the requirements related to the CDNI Logging API. We observe that while the CDNI Logging API is currently discussed as a single "API", further analysis will determine whether the corresponding requirements are to be realised over a single interface and protocol, or over multiple interfaces and protocols. 7.1. Within Initial CDNI Scope R60 The CDNI logging architecture and API MUST ensure reliable, non- repudiable logging of deliveries performed by a Downstream CDN on behalf of an Upstream CDN. R61 The CDNI Logging API MUST provide logging of deliveries to User Agents performed by the Downstream CDN as a result of request redirection by the Upstream CDN. R62 The CDNI Logging API MUST provide logging of distribution performed by the Upstream CDN as a result of acquisition request by the Downstream CDN. R63 The CDNI Logging API MUST support batch/offline exchange of logging records. R64 The CDNI Logging API SHOULD also support additional timing constraints for some types of logging records (e.g. near-real time for monitoring and analytics applications) R65 The CDNI Logging API MUST define a log file format and a set of fields to be exported through the Logging API, with some granularity (e.g. On a per content type basis). R66 The CDNI Logging API MUST define a transport mechanisms to exchange CDNI Logging files. 7.2. Beyond Initial CDNI Scope R67 The CDNI Logging API MUST support real-time exchange of some types of logging records (e.g. For real-time monitoring of deliveries across CDNs). R68 The CDNI Logging API MUST allow a CDN to query another CDN for relevant logging records. Le Faucheur, et al. Expires July 30, 2011 [Page 18] Internet-Draft CDNI Requirements January 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 APIs. 8.1. Within Initial CDNI Scope R69 All the CDNI APIs 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. R70 The CDNI solution MUST provide sufficient protection against Denial of Service attacks. In particular, 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. R71 The CDNI solution MUST 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. R72 The CDNI solution MUST 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. R73 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 R74 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). Le Faucheur, et al. Expires July 30, 2011 [Page 19] Internet-Draft CDNI Requirements January 2011 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. 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 Nivens-Jenkins for his review and comments. 12. References 12.1. Normative References [I-D.bertrand-cdni-use-cases] Bertrand, G. and E. Stephan, "Use Cases for Content Distribution Network Interconnection", draft-bertrand-cdni-use-cases-00 (work in progress), January 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-01 (work in progress), January 2011. [I-D.watson-cdni-use-cases] Watson, G., "CDN Interconnect Use Cases", draft-watson-cdni-use-cases-00 (work in progress), January 2011. [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. Le Faucheur, et al. Expires July 30, 2011 [Page 20] Internet-Draft CDNI Requirements January 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 [Apache-Common] "Apache Common Log File Format (http://www.w3.org/Daemon/ User/Config/Logging.html#common-logfile-format)". [Apache-Format] "Apache LogFormat Directive (http://httpd.apache.org/docs/ 1.3/mod/mod_log_config.html#logformat)". [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. [RFC3040] Cooper, I., Melve, I., and G. Tomlinson, "Internet Web Replication and Caching Taxonomy", RFC 3040, January 2001. [RFC3466] Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model for Content Internetworking (CDI)", RFC 3466, February 2003. [RFC3568] Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known Content Network (CN) Request-Routing Mechanisms", RFC 3568, July 2003. [RFC3570] Rzewski, P., Day, M., and D. Gilletti, "Content Internetworking (CDI) Scenarios", RFC 3570, July 2003. Le Faucheur, et al. Expires July 30, 2011 [Page 21] Internet-Draft CDNI Requirements January 2011 Authors' Addresses 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 Grant Watson BT Email: grant.watson@bt.com Yiu Lee Comcast Email: yiu_lee@cable.comcast.com Le Faucheur, et al. Expires July 30, 2011 [Page 22]