Network Working Group B. Niven-Jenkins Internet-Draft D. Ferguson Intended status: Standards Track Velocix (Alcatel-Lucent) Expires: March 15, 2012 G. Watson BT September 12, 2011 CDN Interconnect Metadata draft-jenkins-cdni-metadata-00 Abstract This document focuses on the CDNI Metadata interface, which enables the CDNI Metadata function in a Downstream CDN to obtain CDNI Metadata from an Upstream CDN so that the Downstream CDN can properly process and respond to Redirection Requests received over the CDNI Request Routing protocol and Request Routing and Content Requests received directly from User Agents. 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/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on March 15, 2012. Copyright Notice Copyright (c) 2011 IETF Trust and the persons identified as the document authors. All rights reserved. Niven-Jenkins, et al. Expires March 15, 2012 [Page 1] Internet-Draft CDN Interconnect Metadata September 2011 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. Niven-Jenkins, et al. Expires March 15, 2012 [Page 2] Internet-Draft CDN Interconnect Metadata September 2011 Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 2. CDNI Metadata Data Model . . . . . . . . . . . . . . . . . . . 5 3. CDNI Metadata Addressable Data Object Descriptions . . . . . . 6 3.1. SiteFeed . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.2. Site . . . . . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. SelectionACL . . . . . . . . . . . . . . . . . . . . . . . 9 3.4. DeliveryACL . . . . . . . . . . . . . . . . . . . . . . . 9 3.5. Location . . . . . . . . . . . . . . . . . . . . . . . . . 10 4. CDNI Metadata Embedded Data Objects Descriptions . . . . . . . 10 4.1. DeliveryGlob . . . . . . . . . . . . . . . . . . . . . . . 11 5. CDNI Metadata Simple Data Type Descriptions . . . . . . . . . 11 5.1. Protocol . . . . . . . . . . . . . . . . . . . . . . . . . 11 5.2. Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.3. IPRange . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.4. Pattern . . . . . . . . . . . . . . . . . . . . . . . . . 12 5.5. PatternFlags . . . . . . . . . . . . . . . . . . . . . . . 13 5.6. URI . . . . . . . . . . . . . . . . . . . . . . . . . . . 13 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 13 6.1. MIME Media Types . . . . . . . . . . . . . . . . . . . . . 14 6.2. JSON Encoding of Objects . . . . . . . . . . . . . . . . . 15 6.3. JSON Encoding of Embedded Types . . . . . . . . . . . . . 16 6.3.1. PatternFlags . . . . . . . . . . . . . . . . . . . . . 16 6.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . 17 6.3.3. Relationship / Link . . . . . . . . . . . . . . . . . 17 6.4. Retrieval of CDNI Metadata resources . . . . . . . . . . . 17 6.4.1. Bulk Retrieval of CDNI Metadata resources . . . . . . 18 6.5. Examples . . . . . . . . . . . . . . . . . . . . . . . . . 19 6.5.1. SiteFeed . . . . . . . . . . . . . . . . . . . . . . . 20 6.5.2. Site . . . . . . . . . . . . . . . . . . . . . . . . . 20 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 8. Security Considerations . . . . . . . . . . . . . . . . . . . 22 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 22 10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 22 10.1. Normative References . . . . . . . . . . . . . . . . . . . 22 10.2. Informative References . . . . . . . . . . . . . . . . . . 23 Appendix A. Relationship to the CDNI Requirements . . . . . . . . 24 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 24 Niven-Jenkins, et al. Expires March 15, 2012 [Page 3] Internet-Draft CDN Interconnect Metadata September 2011 1. Introduction [I-D.jenkins-cdni-problem-statement] introduces the Problem scope for CDN Interconnection (CDNI) and lists the four categories of interfaces that may be used to compose a CDNI solution (Control, Metadata, Request Routing, Logging). [I-D.davie-cdni-framework] expands on the information provided in [I-D.jenkins-cdni-problem-statement] and describes each of the interfaces and the relationships between them in more detail. This document focuses on the CDNI Metadata interface, which enables the CDNI Metadata function in a Downstream CDN to obtain CDNI Metadata from an Upstream CDN so that the Downstream CDN can properly process and respond to: o Redirection Requests received over the CDNI Request Routing protocol. o Request Routing and Content Requests received directly from User Agents. Specifically this document proposes: o A set of data objects that are used to describe the different aspects of CDNI Metadata along with a Data Model for CDNI Metadata that expresses the relationships between the CDNI Metadata objects (Section 2). o An initial set of properties for the data objects in the CDNI Metadata data model (Section 3 through Section 5). o A RESTful web service for the transfer of CDNI Metadata data objects (i.e. the CDNI Metadata interface) (Section 6). Note: In order to make this document more accessible, it does not attempt to articulate all the CDNI Metadata that would be required to satisfy all CDNI use cases. Rather, a smaller set of properties are proposed. These should be sufficient to implement a minimal interconnect of basic HTTP delivery. Readers are encouraged to focus on the overall structure of the protocol rather than on the details or omission of particular properties. Additional properties may be added in future drafts or may be better placed in separate documents that focus on the CDNI Metadata required to interconnect delivery of individual end-user protocols. 1.1. Terminology This document reuses the terminology defined in [I-D.jenkins-cdni-problem-statement]. Niven-Jenkins, et al. Expires March 15, 2012 [Page 4] Internet-Draft CDN Interconnect Metadata September 2011 2. CDNI Metadata Data Model The CDNI Metadata interface specified in this document utilizes two types of Data Object: o Addressable Data Objects, which are resources that may be retrieved via their own URIs. o Embedded Data Objects, which are contained within a property of an Addressable Data Object. Table 1 below defines the addressable data objects used by the CDNI Metadata interface. +--------------+----------------------------------------------------+ | Data Object | Description | +--------------+----------------------------------------------------+ | SiteFeed | A SiteFeed object lists the Sites that may be | | | delegated to the Downstream CDN. | | Site | A Site object represents a customer-facing | | | hostname that is used to serve content through | | | including the rules for serving that content. | | SelectionACL | A SelectionACL object restricts the Surrogates | | | that can provide service for the associated Site | | | to Surrogates in thre listed Locations. | | DeliveryACL | A DeliveryACL object restricts the User Agent IP | | | addresses that can access the associated Site or a | | | URI pattern with the associated Site to User | | | Agents in the listed Locations. | | Location | A Location object represents a set of IP Address | | | ranges. | +--------------+----------------------------------------------------+ Table 1: Content Distribution Metadata Data Objects The only embedded data object defined is the DeliveryGlob object within a Site object, which describes the rules to apply for particular pattern based path matches within a Site. The relationships between the different addressable CDNI Content Distribution Metadata objects are described in Figure 1 and Table 2 below and the properties of each object are described in Section 3. Niven-Jenkins, et al. Expires March 15, 2012 [Page 5] Internet-Draft CDN Interconnect Metadata September 2011 +------------+ |SelectionACL+----------+ +------------+ | ^ | | | | v +--------+ +--+-+ +--------+ |SiteFeed+--------->|Site| |Location| +--------+ +--+-+ +--------+ | ^ | | v | +-----------+ | |DeliveryACL+----------+ +-----------+ Key: ----> = References Figure 1: Relationships between CDNI Metadata Objects +--------------+----------------------------------------------------+ | Data Object | Objects it References | +--------------+----------------------------------------------------+ | SiteFeed | 0 or more Site objects. | | Site | 0 or 1 SelectionACL objects. 0 or 1 DeliveryACL | | | objects. | | SelectionACL | 1 or more Location objects. | | DeliveryACL | 1 or more Location objects. | | Location | None. | +--------------+----------------------------------------------------+ Table 2: Relationships between CDNI Metadata Objects 3. CDNI Metadata Addressable Data Object Descriptions Each of the sub-sections below describes the properties associated with the data objects defined in Table 1. The definition of each object is split into an ordered list of relationships and an unordered set of properties. Relationships are to other addressable data objects that are retrievable via the CDNI Metadata interface. The only exception is the DeliveryProtocol relationship which is to an 'opaque' URI representing the particular feature set of a delivery protocol defined in a specification and implemented in code. Note: The names used for relationships (for example DeliveryProtocol) are illustrative and selected for readability and intuitive Niven-Jenkins, et al. Expires March 15, 2012 [Page 6] Internet-Draft CDN Interconnect Metadata September 2011 understanding of their meaning. If retained, a future version of this document should list them out in the IANA considerations section and request they are registered in the Link registry. 3.1. SiteFeed Relationship: Lists Description: A Site that the Upstream CDN may delegate the delivery of to a Downstream CDN. Allowed Target Types: Site Cardinality: 0..* Properties: None 3.2. Site Relationship: DeliveryProtocol Description: The Protocol to use for delivering this Site's content. Allowed Target Types: Protocol Cardinality: 1 Relationship: RestrictsDelivery Description: The DeliveryACL is used to restrict which End User IP addresses are allowed access to the content of this Site. If not present, there are no restrictions on which End Users may receive the associated content (i.e. any End User IP address can access the content). Allowed Target Types: DeliveryACL Cardinality: 0..1 Relationship: RestrictsSelection Description: The SelectionACL is used to restrict which Surrogates are allowed to serve the content of this Site. If not present, there are no restrictions on which Surrogates may deliver the associated content (i.e. any server can serve the content). Allowed Target Types: SelectionACL Cardinality: 0..1 Property: active Description: Whether delivery should be enabled for this Site. Type: Boolean Mandatory: No (default True) Property: delivery.globs Niven-Jenkins, et al. Expires March 15, 2012 [Page 7] Internet-Draft CDN Interconnect Metadata September 2011 Description: Path specific rules. First match applies. Type: List of DeliveryGlob Mandatory: No (default apply the properties defined in the Site object to all paths) Property: delivery.hostname Description: The customer facing hostname for this site. Type: Hostname Mandatory: Yes Property: delivery.query.remove Description: A list of query parameter names. The listed query parameters must be removed before checking for presence in the cache or forwarding the request to the origin Type: List of Strings Mandatory: No (default pass full URI through) Property: origin.basic.active Description: Whether to use HTTP Basic authentication to the Origin. Type: Boolean Mandatory: No (default False) Property: origin.basic.password Description: HTTP Basic auth password. Required if origin.basic.active is true. Type: String Mandatory: No (default no password) Property: origin.basic.username Description: HTTP Basic auth username. Required if origin.basic.active is true. Type: String Mandatory: No (default no username) Property: origin.cookie.active Description: Whether to use cookie-based authentication when contacting the Origin server. Type: Boolean Mandatory: No (default False) Property: origin.cookie.value Description: Cookie value to be returned to origin for cookie- based authentication. Required if origin.cookie.active is True. Type: String Niven-Jenkins, et al. Expires March 15, 2012 [Page 8] Internet-Draft CDN Interconnect Metadata September 2011 Mandatory: No (default no cookie value) Property: origin.endpoints Description: Origins from which the Downstream CDN can acquire content. These are not necessarily the actual origin servers operated by the CSP but might be a set of Surrogates/servers in the Upstream CDN. Type: Set of Endpoints Mandatory: Yes 3.3. SelectionACL Relationship: SelectionAllow Description: Surrogates in the referenced Location are allowed to serve the content of this Site. Allowed Target Types: Location Cardinality: 0..* Relationship: SelectionDeny Description: Surrogates in the referenced Location are not allowed to serve the content of this Site. Allowed Target Types: Location Cardinality: 0..* Properties: None Note: The order of Relationships within a SelectionACL is the order in which the ACL MUST be processed. If a SelectionACL object does not contain any of the above relationships (i.e. the object is empty) the result is the equivalent of matching against a SelectionDeny entry (i.e. any server is allowed to serve the associated content). If the end of a SelectionACL is reached without matching any of its entries the result is the equivalent of matching against a SelectionDeny entry (i.e. no Surrogates are allowed to serve the content of the Site). 3.4. DeliveryACL Relationship: DeliveryAllow Description: User Agents in the referenced Location are allowed to receive the content of this Site/DeliveryGlob. Allowed Target Types: Location Cardinality: 0..* Relationship: DeliveryDeny Description: User Agents in the referenced Location are not allowed to receive the content of this Site/DeliveryGlob. Niven-Jenkins, et al. Expires March 15, 2012 [Page 9] Internet-Draft CDN Interconnect Metadata September 2011 Allowed Target Types: Location Cardinality: 0..* Relationship: DeliveryAuth Description: The referenced URI represents an Authorisation Server that must be queried to determine whether or not to allow clients to receive the content of this Site/DeliveryGlob. Allowed Target Types: URI Cardinality: 0..1 Properties: None Note: The order of Relationships within a DeliveryACL is the order in which the ACL MUST be processed. If a DeliveryACL object does not contain any of the above relationships (i.e. the object is empty) the result is the equivalent of matching against a DeliveryDeny entry (i.e. any User Agent IP address is allowed to receive the associated content). If the end of an DeliveryACL is reached with matching any of its entries the result is the equivalent of matching against a DeliveryDeny entry (i.e. Delivery to the User Agent is not allowed). 3.5. Location Relationships: None Property: location.ip Description: A set of IP Addresses. Type: List of IPRange. Mandatory: Yes [Editor's Note: Location as specified above only supports the Class 1a names described in [I-D.jenkins-cdni-names]. Need to add support for Class 1b names to a later version.] 4. CDNI Metadata Embedded Data Objects Descriptions Each of the sub-sections below describes the data objects that are embedded within one or more of the data objects described in Section 3. As in the previous section, the definition of each object is split into its properties and its relationships. Relationships may be to other objects that are retrievable via the CDNI Metadata interface. Niven-Jenkins, et al. Expires March 15, 2012 [Page 10] Internet-Draft CDN Interconnect Metadata September 2011 4.1. DeliveryGlob Relationship: RestrictsDelivery Description: The DeliveryACL is used to restrict which End User IP addresses are allowed access to the content matched by this DeliveryGlob. If not present, there are no restrictions on which End Users may receive the associated content (i.e. any End User IP address can access the content). Allowed Target Types: DeliveryACL Cardinality: 0..1 Property: pattern.string Description: String to match against the requested path, i.e. a [RFC3986] path-absolute. Type: Pattern. Mandatory: Yes Property: pattern.flags Description: Flags to control the pattern match. Type: PatternFlags. Mandatory: No (default Case-sensitive infix matching) Property: delivery.proxy Description: If set to True then this pattern should be proxied and not cached. Type: Boolean. Mandatory: No (default False) 5. CDNI Metadata Simple Data Type Descriptions This section describes the simpler data types that are used for properties of Addressable Data Objects and Embedded Data Objects. 5.1. Protocol This type only appears in links. Links with this type are not machine readable but rather represent particular feature sets of a protocol defined in a specification and implemented in code. The URI contained in the link needs to be defined for each delivery protocol with an associated interoperable feature set. The following examples are illustrative: o http://url.cdni.ietf.example/protocol/delivery/http/rfcABCD o http://url.cdni.ietf.example/protocol/delivery/rtmp/rfcEFGH Niven-Jenkins, et al. Expires March 15, 2012 [Page 11] Internet-Draft CDN Interconnect Metadata September 2011 o http://url.vendorY.ietf.example/protocol/delivery/rtmp/releaseP.Q [Editor's Note: It may be more appropriate to use the 'tag' URI scheme [RFC4151] for these URIs.] 5.2. Endpoint A hostname (with optional port) or an IP address (with optional port). Note: Client implementations MUST support IPv4 addresses encoded as specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and MUST support all IPv6 address formats specified in [RFC4291]. Server implementations SHOULD use IPv6 address formats specified in [RFC5952]. 5.3. IPRange One of: o A range of consecutive IP addresses (IPv4 or IPv6) expressed as Address1-Address2 which does not have to be to power of two aligned, for example the range 192.0.2.1-192.0.2.10 is valid. The first Address in the range MUST be 'lower' than the final address in the range. o A valid IP subnet (IPv4 or IPv6) expressed using CIDR notation. o A single IP address (IPv4 or IPv6). Note: Client implementations MUST support IPv4 addresses encoded as specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and MUST support all IPv6 address formats specified in [RFC4291]. Server implementations SHOULD use IPv6 address formats specified in [RFC5952]. 5.4. Pattern A pattern for string matching. The string may contain the wildcards * and ?: o * matches any sequence of characters (including the empty string). o ? matches exactly one character. Escaping: The three literals \ , * and ? should be escaped as \\, \* and \? Niven-Jenkins, et al. Expires March 15, 2012 [Page 12] Internet-Draft CDN Interconnect Metadata September 2011 5.5. PatternFlags A set of flags indicating how a pattern match is made. The flags are: o Case-insensitive - Perform a case insensitive match (absence indicates case-sensitive match). o Prefix - Match against the start of the string (absence indicates that a match may start anywhere in the string). o Suffix - Match against the end of the string (absence indicates that a match may end anywhere in the string). Absence of both Prefix and Suffix results in a match against any part of the string (infix). 5.6. URI A URI as specified in [RFC3986]. 6. CDNI Metadata interface This section specifies an interface to enable a Downstream CDN to retrieve CDNI Metadata objects from an Upstream CDN. The CDNI Metadata interface is built on the principles of RESTful web services, in particular the use of hypermedia as the engine of application state, and follows patterns established in The Atom Syndication Format [RFC4287]. This means that requests and responses over the interface are built around the transfer of representations of hyperlinked resources. A resource in the context of the CDNI Metadata interface is an Addressable Object in the Data Model (as described in Section 2 through Section 3). Requests are made over HTTP. The HTTP Method defines the operation the request would like to perform. Servers implementing the CDNI Metadata interface MUST support the HTTP GET and HEAD methods. The corresponding HTTP Response returns the status of the operation in the HTTP Status Code and returns the current representation of the resource (if appropriate) in the Response Body. HTTP Responses from servers implementing the CDNI Metadata interface that contain a response body SHOULD include an ETag to enable validation of cached versions of returned resources. The CDNI Metadata interface specified in this document is a read-only interface. Therefore support for other HTTP methods such as PUT, POST and DELETE etc. is not specified. Server implementations of this interface SHOULD reject all methods other than GET and HEAD. Niven-Jenkins, et al. Expires March 15, 2012 [Page 13] Internet-Draft CDN Interconnect Metadata September 2011 The only representation specified in this document is JSON. The interface can be used by a Downstream CDN to retrieve CDNI Metadata objects either dynamically as required by the Downstream CDN to process received requests (for example in response to receiving a CDNI Request Routing request from an Upstream CDN or in response to receiving a request for content from a User Agent) or in advance of being required. In the general case a CDNI Metadata server makes each instance of an addressable CDNI Metadata object available via a unique URI that returns a representation of that instance of that CDNI Metadata object. When an object needs to reference another addressable CDNI Metadata object (for example a Site object referencing a DeliveryACL object) it does so by including a link to the referenced object. The URI for the SiteFeed object needs to be either discovered by or configured in the downstream CDN. All other objects/resources are then discoverable from the SiteFeed object by following the links in the SiteFeed object and the referenced Site objects. CDNI Metadata servers are therefore free to assign whatever structure they desire to the URIs for CDNI Metadata objects and CDNI Metadata clients MUST NOT make any assumptions regarding the structure of CDNI Metadata URIs or the mapping between CDNI Metadata objects and their associated URIs. Therefore any URIs present in the examples below are purely illustrative and are not intended impose a definitive structure on CDNI Metadata interface implementations. As the CDNI Metadata interface builds on top of HTTP, CDNI Metadata servers may make use of any HTTP feature when implementing the CDNI Metadata interface, for example a CDNI Metadata server may make use of HTTP's caching mechanisms to indicate that the returned response/ representation can be reused without re-contacting the CDNI Metadata server. 6.1. MIME Media Types Table 3 lists the MIME Media Type for each object (resource) that is retrievable through the CDNI Metadata interface as well as the MIME Media Type for the DeliveryProtocol relationship. Note: A prefix of "vnd.cdni" is used, however it is expected that a more appropriate prefix will be used if this document is accepted by the CDNI WG. Niven-Jenkins, et al. Expires March 15, 2012 [Page 14] Internet-Draft CDN Interconnect Metadata September 2011 +------------------+------------------------------------------------+ | Data Object | MIME Media Type | +------------------+------------------------------------------------+ | SiteFeed | application/vnd.cdni.metadata.site.feed+json | | Site | application/vnd.cdni.metadata.site+json | | SelectionACL | application/ | | | vnd.cdni.metadata.acl.selection+json | | DeliveryACL | application/ | | | vnd.cdni.metadata.acl.delivery+json | | Location | application/vnd.cdni.metadata.location+json | | DeliveryProtocol | application/vnd.cdni.metadata.protocol+json | +------------------+------------------------------------------------+ Table 3: MIME Media Types for CDNI Metadata resources 6.2. JSON Encoding of Objects The "base" encoding for a CDNI Metadata object is a JSON object containing a dictionary of (key,value) pairs where the keys are the property names and the values are the associated property values. The keys of the dictionary are the names of the properties associated with the object and are therefore dependent on the specific object being encoded (i.e. dependent on the MIME Media Type of the returned resource). Likewise, the values associated with each key are dependent on the specific object being encoded (i.e. dependent on the MIME Media Type of the returned resource). Dictionary keys in JSON are case sensitive and therefore any dictionary key defined by this document (for example the names of CDNI Metadata object properties) MUST always be represented in lowercase. In addition to the properties of the object, the following three additional keys defined below may be present. Key: base Description: Provides a prefix for any relative URLs in the object. This is similar to the XML base tag [XML-BASE]. If absent, all URLs in the remainder of the document must be absolute URLs. Type: URI Mandatory: No Key: links Description: The relationships of this object to other addressable objects. Niven-Jenkins, et al. Expires March 15, 2012 [Page 15] Internet-Draft CDN Interconnect Metadata September 2011 Type: List of Relationships. Mandatory: Yes Key: inline Description: Dictionary containing additional objects that are inlined within this object. The keys in the dictionary are then then used to generate URI fragments which are used to refer to inlined objects and the value is the Object itself. Type: Dictionary of Objects. Mandatory: No Example SiteFeed Object: { "base": "http://metadata.cdni.example.com/sites/", "links": [ { "title": "videos.example.net", "href": "example1", "rel": "Lists", "type": "application/vnd.cdni.metadata.site+json" }, { "title": "trailers.example.net", "href": "http://metadata2.cdni.example.com/sites/example2", "rel": "Lists", "type": "application/vnd.cdni.metadata.site+json" } ], } 6.3. JSON Encoding of Embedded Types 6.3.1. PatternFlags JSON: A number calculated by adding together the values associated with each flag that is set: o 1 - Case-insensitive o 2 - Prefix o 4 - Suffix Example of case-insensitive prefix match: "pattern.flags": 3 Niven-Jenkins, et al. Expires March 15, 2012 [Page 16] Internet-Draft CDN Interconnect Metadata September 2011 6.3.2. Protocol TBD 6.3.3. Relationship / Link JSON: A dictionary with the following keys: o href - The URI of the of the addressable object being referenced. o rel - The Relationship between the referring object and the object it is referencing. o type - The MIME Media Type of the referenced object. See Section 6.1 for the MIME Media Types of objects specified in this document. o title - An title for the for the Relationship/link. For the "Lists" Relationships contained in a SiteFeed object the title key MUST be present and MUST be the value of delivery.hostname for the referenced Site object. For all other Relationships/links the title key is optional. Note: The above structure follows the pattern of atom:link in [RFC4287]. Example Relationship to a CDNI Metadata location within a SelectionACL object: { "href": "http://metadata.cdni.example.com/locations/everywhere", "rel": "SelectionAllow", "type": "application/vnd.cdni.metadata.location+json" } 6.4. Retrieval of CDNI Metadata resources In the general case a CDNI Metadata server makes each instance of an addressable CDNI Metadata object available via a unique URI and therefore in order to retrieve CDNI Metadata, a CDNI Metadata client first makes a HTTP GET request for the URI of the SiteFeed which provides the CDNI Metadata client with a list of Sites (along with their public facing hostnames) that the upstream CDN may delegate to the downstream CDN. In order to retrieve the CDNI Metadata for a particular Site the CDNI Metadata client processes the received SiteFeed object and finds the corresponding entry (using the title key to match against the required public facing hostname if required) in the SiteFeed for the Site it requires and can then can make a GET request for the URI specified in the href key of that Site's entry in the SiteFeed. Niven-Jenkins, et al. Expires March 15, 2012 [Page 17] Internet-Draft CDN Interconnect Metadata September 2011 In order to retrieve the SelectionACLs and DeliveryACLs associated with that Site the CDNI Metadata client processes the received Site object (as well as any DeliveryGlob objects embedded in the Site's delivery.globs key) and can then can make a GET request for the URIs specified in the href key of links within that Site or its DeliveryGlobs that have a Relationship of RestrictsSelection and RestrictsDelivery respectively. Finally in order to retrieve the Locations associated with each ACL the CDNI Metadata client processes the received ACL object(s) and can then can make a GET request for the URIs specified in the href key of links within that ACL that have a Relationship of Location. 6.4.1. Bulk Retrieval of CDNI Metadata resources In addition to the general case where a CDNI Metadata server makes each instance of an addressable CDNI Metadata object available via a unique URI, in response to a request for a CDNI Metadata object a CDNI Metadata Servers MAY include one or more of the addressable objects referenced by the requested object inside the inline dictionary of the referenced objects. Inlined objects are referenced using a link in the normal way with the exception that the href component of the link begins with # and follows the fragment resolution protocol defined in [I-D.zyp-json-schema]. Use of the inline dictionary to include multiple addressable objects has the advantage of reducing the number of requests a CDNI Metadata client needs to make (and therefore reduces the additional latency introduced by making multiple requests) in order to retrieve all the CDNI Metadata it requires to process CDNI Request Routing requests and User Agent requests for content. However use of the inline dictionary has the disadvantage that the cacheability of any inlined objects are tied to the cacheability of the object they are inlined in. Some objects (for example Locations) may not change very often and therefore could be cached for a longer period of time than the objects that reference them. Or an object (for example a SelectionACL) may be referenced by multiple other objects and benefit from being cached separately in order to reduce the size of the responses to requests for objects that reference it. Example of an inline dictionary containing a DeliveryACL object: Niven-Jenkins, et al. Expires March 15, 2012 [Page 18] Internet-Draft CDN Interconnect Metadata September 2011 "inline": { "deliveryeverywhereacl": { "links": [ { "href": "http://metadata.cdni.example.com/locations/everywhere", "rel": "DeliveryAllow", "type": "application/vnd.cdni.metadata.location+json" } ] } } Example of an inline dictionary containing a DeliveryACL object where the Location referenced by the DeliveryACL is also inlined: "inline": { "deliveryeverywhereacl": { "links": [ { "href": "#/inline/everywhere", "rel": "DeliveryAllow", "type": "application/vnd.cdni.metadata.location+json" } ] }, "everywhere": { "location.ip": ["0.0.0.0", "::/0"] } } Note: An alternative to using an inline key as described above would be for the CDNI Metadata server to return a multipart/mixed response. Using a multipart/mixed response would have the advantage that inlined objects would not have to be tied to the cacheability of the object they are inlined in (as they could have their own Cache- Control headers) and could be cached separately from the object they are inlined with (as they could have their own Location header). However, using a multipart/mixed response would have the disadvantage of requiring more complex processing by the CDNI Metadata client. 6.5. Examples The following sections provide examples of different CDNI Metadata objects encoded as JSON. Niven-Jenkins, et al. Expires March 15, 2012 [Page 19] Internet-Draft CDN Interconnect Metadata September 2011 6.5.1. SiteFeed Example SiteFeed: { "base": "http://metadata.cdni.example.com/sites/", "links": [ { "title": "videos.example.net", "href": "example1", "rel": "Lists", "type": "application/vnd.cdni.metadata.site+json" }, { "title": "trailers.example.net", "href": "http://metadata2.cdni.example.com/sites/example2", "rel": "Lists", "type": "application/vnd.cdni.metadata.site+json" } ], } 6.5.2. Site Example Site with inlined objects: { "base": "http://metadata.cdni.example.com/", "links": [ { "href": "http://url.cdni.ietf.org/protocol/delivery/http/1.1", "rel": "DeliveryProtocol", "type": "application/vnd.cdni.metadata.protocol+json" }, { "href": "#/inline/delivereverywhereacl", "rel": "RestrictsDelivery", "type": "application/vnd.cdni.acl.delivery+json" }, { "href": "#/inline/servefromanywhereacl", "rel": "RestrictsSelection", "type": "application/vnd.cdni.acl.selection+json" } ], "active": "true", "delivery.hostname": "videos.example.net" "origin.hostnames": ["origin.videos.example.net.cdni.example.com", Niven-Jenkins, et al. Expires March 15, 2012 [Page 20] Internet-Draft CDN Interconnect Metadata September 2011 "origin.example.net"], "delivery.globs": [ { "links": [ { "href": "#/inline/qaonlyacl", "rel": "RestrictsDelivery", "type": "application/vnd.cdni.acl.delivery+json" } ], "pattern.string": "*/test_files/*", "pattern.flags": 1, "delivery.proxy": false } ], "inline": { "deliveryeverywhereacl": { "links": [ { "href": "#/inline/everywhere", "rel": "DeliveryAllow", "type": "application/vnd.cdni.metadata.location+json" } ] }, "servefromanywhereacl": { "links": [ { "href": "#/inline/everywhere", "rel": "SelectionAllow", "type": "application/vnd.cdni.metadata.location+json" } ] }, "qaonlyacl": { "links": [ { "href": "#/inline/qa1", "rel": "DeliveryAllow", "type": "application/vnd.cdni.metadata.location+json" }, { "href": "#/inline/qa2", "rel": "DeliveryAllow", "type": "application/vnd.cdni.metadata.location+json" }, { "href": "#/inline/everywhere", Niven-Jenkins, et al. Expires March 15, 2012 [Page 21] Internet-Draft CDN Interconnect Metadata September 2011 "rel": "DeliveryDeny", "type": "application/vnd.cdni.metadata.location+json" } ] }, "everywhere": { "location.ip": ["0.0.0.0", "::/0"] }, "qa1": { "location.ip": ["192.0.2.1-192.0.2.10"] }, "qa2": { "location.ip": ["198.51.100.1-198.51.100.15", "198.51.100.200-198.51.100.254"] } } } 7. IANA Considerations TBD. 8. Security Considerations TBD. 9. Acknowledgements TBD. 10. References 10.1. Normative References [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, February 2006. [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, August 2010. Niven-Jenkins, et al. Expires March 15, 2012 [Page 22] Internet-Draft CDN Interconnect Metadata September 2011 10.2. Informative 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.jenkins-cdni-names] Niven-Jenkins, B., "Thoughts on Naming and Referencing of Data Objects within Content Distribution Network Interconnection (CDNI) solutions", draft-jenkins-cdni-names-00 (work in progress), February 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. [I-D.lefaucheur-cdni-requirements] Leung, K., Lee, Y., Faucheur, F., Viveganandhan, M., and G. Watson, "Content Distribution Network Interconnection (CDNI) Requirements", draft-lefaucheur-cdni-requirements-02 (work in progress), July 2011. [I-D.zyp-json-schema] Zyp, K. and G. Court, "A JSON Media Type for Describing the Structure and Meaning of JSON Documents", draft-zyp-json-schema-03 (work in progress), November 2010. [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, January 2005. [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC 4151, October 2005. [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom Syndication Format", RFC 4287, December 2005. [XML-BASE] Marsh, J., Ed. and R. Tobin, Ed., "XML Base (Second Edition) - http://www.w3.org/TR/xmlbase/", January 2009. Niven-Jenkins, et al. Expires March 15, 2012 [Page 23] Internet-Draft CDN Interconnect Metadata September 2011 Appendix A. Relationship to the CDNI Requirements Section 6 of [I-D.lefaucheur-cdni-requirements] lists the requirements for the CDNI Metadata Distribution interface. This section outlines which of those requirements are met by the CDNI Metadata interface specified in this document. Requirements R49 through R57 (inclusive) and R61 through R63 (inclusive) are directly met by the interface specified in this document. Requirements R59 and R60 can be trivally met by defining additional properties for the CDNI Metadata objects defined in this document. It is the opinion of the authors that requirement R58 is better handled at Request Routing time by the CDNI Request Routing interface, rather than directly being met by the CDNI Metadata interface. Authors' Addresses Ben Niven-Jenkins Velocix (Alcatel-Lucent) 326 Cambridge Science Park Milton Road, Cambridge CB4 0WG UK Email: ben@velocix.com David Ferguson Velocix (Alcatel-Lucent) 326 Cambridge Science Park Milton Road, Cambridge CB4 0WG UK Email: david@velocix.com Grant Watson BT pp GDC 1 PP14, Orion Building, Adastral Park Martlesham, Ipswich IP5 3RE UK Email: grant.watson@bt.com Niven-Jenkins, et al. Expires March 15, 2012 [Page 24]