Internet DRAFT - draft-jenkins-cdni-metadata
draft-jenkins-cdni-metadata
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]
