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