Network Working Group M. Caulfield Internet-Draft K. Leung Intended status: Standards Track Cisco Expires: April 26, 2012 October 24, 2011 Content Distribution Network Interconnection (CDNI) Core Metadata draft-caulfield-cdni-metadata-core-00 Abstract The CDNI Metadata Interface enables interconnected CDNs to exchange content distribution metadata for the purpose of content acquisition and delivery. The CDNI metadata associated with a piece of content provides a downstream CDN with the information necessary for the downstream CDN to service content requests on behalf of an upstream CDN in accordance with the delivery policies defined by the upstream CDN. This document describes the core set of CDNI metadata that all interconnected CDNs must support. 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 April 26, 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 Caulfield & Leung Expires April 26, 2012 [Page 1] Internet-Draft CDNI Core Metadata October 2011 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 . . . . . . . . . . . . . . . . . . . . . . . . . 3 2. Core CDNI Metadata . . . . . . . . . . . . . . . . . . . . . . 4 2.1. Acquisition Metadata . . . . . . . . . . . . . . . . . . . 4 2.2. Delivery Metadata . . . . . . . . . . . . . . . . . . . . 5 3. Metadata Encoding . . . . . . . . . . . . . . . . . . . . . . 5 3.1. ContentSource object . . . . . . . . . . . . . . . . . . . 6 3.2. ContentDelivery object . . . . . . . . . . . . . . . . . . 7 3.3. MetadataScope object . . . . . . . . . . . . . . . . . . . 7 3.4. Authentication object . . . . . . . . . . . . . . . . . . 7 3.5. DeliveryCriteria object . . . . . . . . . . . . . . . . . 8 3.6. DeliveryRules object . . . . . . . . . . . . . . . . . . . 8 3.7. Region object . . . . . . . . . . . . . . . . . . . . . . 8 3.8. TimeWindow object . . . . . . . . . . . . . . . . . . . . 9 3.9. Authorization object . . . . . . . . . . . . . . . . . . . 9 3.10. Reference object . . . . . . . . . . . . . . . . . . . . . 9 4. Metadata Transport . . . . . . . . . . . . . . . . . . . . . . 10 5. CDNI Metadata Interface Bootstrapping . . . . . . . . . . . . 10 6. Compliance with CDNI Requirements . . . . . . . . . . . . . . 11 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 11 8. Security Considerations . . . . . . . . . . . . . . . . . . . 11 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 12 10. Normative References . . . . . . . . . . . . . . . . . . . . . 12 Appendix A. Example Metadata . . . . . . . . . . . . . . . . . . 12 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 13 Caulfield & Leung Expires April 26, 2012 [Page 2] Internet-Draft CDNI Core Metadata October 2011 1. Introduction Several types of metadata flow through content delivery networks. For readability, a number of definitions from [I-D.ietf-cdni-problem-statement] related to metadata are quoted below: Content Metadata: This is metadata about Content. Content Metadata comprises: 1. CDNI Metadata: Content Distribution Metadata with inter-CDN scope. For example, CDNI Metadata may 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) and access control mechanisms to be enforced (e.g. URI signature validation). CDNI Metadata may also include information about desired distribution policy (e.g. prepositioned vs dynamic acquisition) and about where/how a CDN can acquire the content. CDNI Metadata may also include content management information (e.g. request for deletion of Content from Surrogates) across interconnected CDNs. that is relevant to the distribution of the content (and therefore relevant to a CDN involved in the delivery of that content). We refer to this type of metadata as "Content Distribution Metadata". See also the definition of Content Distribution Metadata. 2. Metadata that is associated with the actual Content (and not directly relevant to the distribution of that Content) or content representation. For example, such metadata may include information pertaining to the Content's genre, cast, rating, etc as well as information pertaining to the Content representation's resolution, aspect ratio, etc. Content Distribution Metadata: The subset of Content Metadata that is relevant to the distribution of the content. This is the metadata required by a CDN in order to enable and control content distribution and delivery by the CDN. In a CDN Interconnection environment, some of the Content Distribution Metadata may have an intra-CDN scope (and therefore need not be communicated between CDNs), while some of the Content Distribution Metadata have an inter-CDN scope (and therefore needs to be communicated between CDNs). CDNI Metadata: Content Distribution Metadata with inter-CDN scope. For example, CDNI Metadata may include geo-blocking information Caulfield & Leung Expires April 26, 2012 [Page 3] Internet-Draft CDNI Core Metadata October 2011 (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) and access control mechanisms to be enforced (e.g. URI signature validation). CDNI Metadata may also include information about desired distribution policy (e.g. prepositioned vs dynamic acquisition) and about where/how a CDN can acquire the content. CDNI Metadata may also include content management information (e.g. request for deletion of Content from Surrogates) across interconnected CDNs. Interconnecting CDNs necessitates the exchange of the CDNI metadata as defined above. The CDNI metadata associated with a piece of content (or set of contents) provides a downstream CDN with the information necessary for the downstream CDN to service content requests on behalf of an upstream CDN in accordance with the delivery policies defined by the upstream CDN. The CDNI Metadata Interface is introduced by [I-D.ietf-cdni-problem-statement], and discussed in [I-D.davie-cdni-framework], as one of the four required interfaces for CDN interconnection. The requirements for this interface are specified in [I-D.ietf-cdni-requirements]. This document first describes the core set of CDNI metadata that all interconnected CDNs must support. Then the document describes the relationship between the core metadata and the encoding and transport for exchanging that metadata. 2. Core CDNI Metadata Although the CDNI Metadata Interface should be flexible enough to support the exchange of arbitrary pieces of metadata, a CDN implementing the interface must support a set of core metadata. The core CDNI metadata represent common policies for content distribution across CDNs. All CDNI metadata may differ on a per-content-item basis or may be shared by a set of content items. The core CDNI Metadata comprises acquisition metadata and delivery metadata. 2.1. Acquisition Metadata If a downstream CDN receives a request for a content that is not yet cached by that CDN, it will attempt to acquire it from either an upstream CDN or an origin server. The acquisition metadata for a piece of content provides the information needed by a downstream CDN to acquire the missing content. The acquisition metadata includes a prioritized list of content sources. Each content source includes Caulfield & Leung Expires April 26, 2012 [Page 4] Internet-Draft CDNI Core Metadata October 2011 the following: 1. Protocol - acquisition protocol (e.g. HTTP, FTP, ...). 2. URI - either an explicit URI for acquiring the content or a regex rule for converting from the content request URI to the acquisition URI. 3. Authentication - an object describing the authentication type (e.g. HTTP Basic, Digest, etc.) and any parameters for that type (e.g. username and password). 2.2. Delivery Metadata Once a piece of content is acquired, the delivery metadata controls where, when, how, and to whom the downstream CDN may deliver that content. The delivery metadata includes a list of permissible delivery profiles. Each profile includes criteria and rules for delivery. Profile criteria include the following: 1. Protocol - delivery protocol (e.g. HTTP, FTP, RTSP). 2. Region - a geographic region identified by country, AS number, or IP subnet. 3. Time window - a time period including a start time and an end time. If a content request matches all the criteria of a profile, then the rules for that profile should be applied. Profile rules include the following: 1. Allow/deny - flag indicating whether or not the request should be permitted. 2. Authorization - a list of permissible authorization methods and their related parameters (e.g. URL-signing, token-based, etc.). If a content request matches the criteria of multiple profiles in a list, it should use the rules of the first matching profile. 3. Metadata Encoding Metadata is encoded as a hierarchy of objects which in practice may be implemented in JavaScript Object Notation (JSON), Extensible Markup Language (XML), or another variant. This section describes the structure of the data but does not prescribe a particular Caulfield & Leung Expires April 26, 2012 [Page 5] Internet-Draft CDNI Core Metadata October 2011 encoding (such as JSON or XML). The language used below uses generic terms like "lists", "objects", and "fields" to describe the structure of the metadata. Each piece of content is associated with a CDNIMetadata object which has the following fields: 1. acquisitionOptions - an ordered list of ContentSource objects. The content sources are listed in order of priority with the first being the most desirable option. 2. deliveryProfiles - an ordered list of ContentDelivery objects. Like the content sources, the content delivery profiles are listed in order of priority. 3. metadataScope - a single MetadataScope object. The CDNIMetadata object fields may be expanded in the future to include a richer set of optional metadata. Proprietary fields may be added with the "x-" prefix. All fields in the CDNI metadata are optional unless stated otherwise. If a field is missing, its default value should be used. If the value of the field is the default, it need not be included. The default value of a list is the empty list, an object is an empty object, and a string is an empty string unless stated otherwise. 3.1. ContentSource object The ContentSource object describes a single acquisition point that a downstream CDN may contact to acquire the content. This object has the following fields: 1. protocol - a string containing the name of the protocol that may be used to acquire the content (e.g. HTTP, FTP, ...). The default protocol is "http". 2. uriType - a string containing either "explicit" or "regex" which dictates how the uri field should be interpreted. If the type is "explicit", the URI is to be used as is. If the type is "regex" then the uri field specifies a regex substitution that should be performed on the content URL for mapping to the explicit URI. The default uriType is "explicit". 3. uri - a string containing either the URI of the content source or a regex substitution to generate the acquisition URI, depending on the value of uriType. This field is required in a ContentSource object and its value may not be empty. Caulfield & Leung Expires April 26, 2012 [Page 6] Internet-Draft CDNI Core Metadata October 2011 4. auth - a single Authentication object. If the auth field is missing, then authentication is not required for this ContentSource. 3.2. ContentDelivery object The ContentDelivery object describes a permissible delivery profile for the content. This object has the following fields: 1. deliveryCriteria - an ordered list of DeliveryCriteria objects. 2. deliveryRules - a single DeliveryRules object. 3.3. MetadataScope object The MetadataScope object indicates that a CDNIMetadata object applies to more than one content and may be used as an optimization by downstream CDNs to avoid refetching duplicate metadata. If a new content request meets the criteria in this object, then the entire CDNIMetadata object applies to that request and the downstream CDN need not refetch it. The object includes the following fields: 1. host - an optional string containing a regex that could be checked against the Host header of an incoming HTTP request. 2. resource - an optional string containing a regex that could be checked against the requested resource name in an incoming HTTP request, to determine if the metadata object is associated to the requested content item. 3. protocol - an optional string containing a protocol name that may be checked against the client request protocol (e.g. "http" or "ftp"). If the MetadataGroup object is missing from the CDNIMetadata object, then the CDNIMetadata object only applies to the requested content and may not be reused for different content requests. 3.4. Authentication object The Authentication object describes an authentication type and its parameters. It provides information for content acquisition such that the downstream CDN can be authenticated as a client when acquiring content from an upstream CDN or an origin server. The Authentication object contains the following fields: 1. type - a string containing the authentication type "basic" or "digest". The type dictates which optional fields are present Caulfield & Leung Expires April 26, 2012 [Page 7] Internet-Draft CDNI Core Metadata October 2011 and valid in the rest of the object. The "basic" and "digest" types refer to HTTP Basic and Digest access authentication [RFC2617] respectively. 2. username - a string containing the username for "basic" and "digest" types. 3. password - a string containing the password for "basic" and "digest" types. 3.5. DeliveryCriteria object The DeliveryCriteria object specifies a set of criteria to match against incoming content requests including protocol, region, and time window. The object includes the following fields: 1. protocol - a string containing the name of a protocol to match (e.g. "http", "ftp", ...). 2. region - a single Region object. 3. timeWindow - a single TimeWindow object. 3.6. DeliveryRules object The DeliveryRules object describes the rules to apply to a particular content request in order to deliver a piece of content to the user agent on behalf of an upstream CDN. This object includes the following fields: 1. allow - a boolean stating whether or not delivery is permitted. 2. auth - a single Authorization object. 3.7. Region object The Region object specifies a region where the content is either allowed or disallowed. A region may be described in three ways, only one of which needs to be present per Region object. The object includes the following fields: 1. country - a string containing the country code for the region. 2. bgpAs - a number containing the BGP AS identifier of the region. 3. subnet - a string containing a dotted decimal IP address and subnet mask. Caulfield & Leung Expires April 26, 2012 [Page 8] Internet-Draft CDNI Core Metadata October 2011 3.8. TimeWindow object The TimeWindow object specifies a time period when a content is available or not available. The object includes the following fields: 1. startTime - a string containing an ISO 8601 formatted date and time in UTC. 2. endTime - a string containing the same format as startTime. 3.9. Authorization object The Authorization object describes an authorization type and its parameters. It provides information for content delivery such that the user agent can be authenticated as a client when requesting content from a downstream CDN. The Authorization object contains the following fields: 1. type - a string containing the authorization type "url-signing" or "url-token". The type dictates which optional fields are present and valid in the rest of the object. The "url-signing" type refers to URL signing authorization. The "url-token" type refers to token-based authorization. 2. algo - a string containing the signature algorithm (e.g. "md5", "sha-1", etc.). 3. symmetric - a boolean if true, URL signing uses symmetric keys, otherwise asymmetric. 4. key - a number containing the public key for verifying signatures, only valid if "symmetric" field is set to false. [Editor's note: parameters for URL signing and URL token authorization schemes are TBD. Private key provisioning and distribution are outside the scope of the CDNI Metadata Interface. ] 3.10. Reference object In order to avoid refetching large or common objects, any object may be replaced by a Reference object. For example, the ContentSource object could be replaced by a Reference object which points to a URI. The downstream CDN should then request the referenced object in order to complete the metadata. This object includes the following fields: 1. ref - a string containing a URI which points to the actual object. Caulfield & Leung Expires April 26, 2012 [Page 9] Internet-Draft CDNI Core Metadata October 2011 A Reference object may be distinguished from any other type of object by checking for the presence of the "ref" field with a non-empty value. 4. Metadata Transport Metadata objects (JSON, XML, etc.) are assumed to be transported over HTTP. This section describes the relationship between the encoding and transport layers. Given a content request from an end client, when the downstream CDN needs to acquire the metadata associated with that content, the downstream CDN uses an HTTP GET to query the upstream CDN metadata server for the metadata object. The parameters to the query request are identical to the fields of the MetadataScope object discussed earlier. This similarity is intentional and allows the downstream CDN to avoid refetching the same metadata for two different pieces of content (if the metadata is the same). The query parameters are extracted from an incoming content request and are as follows: 1. host - the value of the Host header in an HTTP request. 2. resource - the resource on the request line of the HTTP request. 3. protocol - the protocol of the incoming request. After extracting these fields from the content request, the downstream CDN should first check its existing cache of metadata objects for possible matches (using the MetadataScope object). If no match is found, the downstream CDN should then form a request to the upstream CDN metadata server, appending the host, resource, and protocol as query string parameters. The metadata server will respond with a CDNIMetadata object encoded in JSON, XML, or some other variant. 5. CDNI Metadata Interface Bootstrapping This document makes a number of assumptions regarding the information available to the downstream CDN which is not part of the CDNI Core Metadata. Information such as how a downstream CDN learns the address or hostname of the upstream metadata server is briefly described below. Caulfield & Leung Expires April 26, 2012 [Page 10] Internet-Draft CDNI Core Metadata October 2011 In the simplest case, the Control Interface will provision the URI of the metadata server to the downstream CDN and all metadata requests will be sent directly to this server. The Control Interface could also provision an alternative URI in case the primary server is unreachable. In the case of multiple potential upstream CDNs, the downstream CDN must decide which metadata server should handle its request. It is expected that the downstream CDN will be able to determine the upstream CDN that redirected that particular request from information contained in the received request (e.g. via the URI in case of HTTP redirection across CDNs). With knowledge of which upstream CDN routed the request, the downstream CDN can choose the correct metadata server. 6. Compliance with CDNI Requirements This section reviews compliance of the solution proposed in this document against the relevant set of requirements from [I-D.ietf-cdni-requirements]. [Editor's note: the compliance information will be provided in subsequent versions] 7. IANA Considerations This document makes no request of IANA. Note to RFC Editor: this section may be removed on publication as an RFC. 8. Security Considerations The CDNI Metadata Interface is expected to be secured as a function of the transport protocol (e.g. HTTP authentication). If a malicious metadata server is contacted by a downstream CDN, the malicious server may provide metadata to the downstream CDN which denies service for any piece of content to any user agent. The malicious server may also provide metadata which directs a downstream CDN to a malicious origin server instead of the actual origin server. Caulfield & Leung Expires April 26, 2012 [Page 11] Internet-Draft CDNI Core Metadata October 2011 9. Acknowledgements The authors would like to thank Francois le Faucheur for his input and review. 10. Normative References [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.ietf-cdni-problem-statement] Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", draft-ietf-cdni-problem-statement-00 (work in progress), September 2011. [I-D.ietf-cdni-requirements] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", draft-ietf-cdni-requirements-01 (work in progress), October 2011. [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., Leach, P., Luotonen, A., and L. Stewart, "HTTP Authentication: Basic and Digest Access Authentication", RFC 2617, June 1999. Appendix A. Example Metadata Below is an example of a JSON object encoding a piece of CDNI metadata. This metadata object applies to any content request with a hostname of "origin.example.com" and a resource identifier matching the regular expression "*/movies/*". The "metadataScope" field summarizes these properties. There is a single acquisition option as seen in the "acquisitionOptions" list. The "deliveryProfiles" information restricts users in subnet "10.1.2.0/24" or using RTSP from accessing this content and allows users using HTTP. { "acquisitionOptions" : [ { "protocol" : "http", "uri" : "http://origin.example.com/movies/content.mpg", "auth" : Caulfield & Leung Expires April 26, 2012 [Page 12] Internet-Draft CDNI Core Metadata October 2011 { "type" : "basic", "username" : "abcd", "password" : "pass123" } } ], "deliveryProfiles" : [ { "deliveryCriteria" : [ { "region" : { "subnet" : "10.1.2.0/24" }, }, { "protocol" : "rtsp" } ], "deliveryRules" : { "allow" : false } }, { "deliveryCriteria" : [ { "protocol" : "http" } ], "deliveryRules" : { "allow" : true } } ], "metadataScope" : { "host" : "origin.example.com", "resource" : "*/movies/*" } } Caulfield & Leung Expires April 26, 2012 [Page 13] Internet-Draft CDNI Core Metadata October 2011 Authors' Addresses Matt Caulfield Cisco Systems 1414 Massachusetts Ave Boxborough, MA 01719 USA Phone: +1 978 936 9307 Email: mcaulfie@cisco.com Kent Leung Cisco Systems 3625 Cisco Way San Jose 95134 USA Phone: +1 408 526 5030 Email: kleung@cisco.com Caulfield & Leung Expires April 26, 2012 [Page 14]