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]