One document matched: draft-ietf-cdni-metadata-05.xml
<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="4"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<rfc category="std" docName="draft-ietf-cdni-metadata-05" ipr="trust200902">
<front>
<title abbrev="CDN Interconnect Metadata">CDN Interconnect
Metadata</title>
<author fullname="Ben Niven-Jenkins" initials="B" surname="Niven-Jenkins">
<organization>Velocix (Alcatel-Lucent)</organization>
<address>
<postal>
<street>3 Ely Road</street>
<city>Milton</city>
<region>Cambridge</region>
<code>CB24 6AA</code>
<country>UK</country>
</postal>
<email>ben@velocix.com</email>
</address>
</author>
<author fullname="Rob Murray" initials="R" surname="Murray">
<organization>Velocix (Alcatel-Lucent)</organization>
<address>
<postal>
<street>3 Ely Road</street>
<city>Milton</city>
<region>Cambridge</region>
<code>CB24 6AA</code>
<country>UK</country>
</postal>
<email>rmurray@velocix.com</email>
</address>
</author>
<author fullname="Grant Watson" initials="G" surname="Watson">
<organization>Velocix (Alcatel-Lucent)</organization>
<address>
<postal>
<street>3 Ely Road</street>
<city>Milton</city>
<region>Cambridge</region>
<code>CB24 6AA</code>
<country>UK</country>
</postal>
<email>gwatson@velocix.com</email>
</address>
</author>
<author fullname="Matt Caulfield" initials="M" surname="Caulfield">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>1414 Massachusetts Avenue</street>
<city>Boxborough</city>
<region>MA</region>
<code>01719</code>
<country>USA</country>
</postal>
<phone>+1 978 936 9307</phone>
<email>mcaulfie@cisco.com</email>
</address>
</author>
<author fullname="Kent Leung" initials="K" surname="Leung">
<organization>Cisco Systems</organization>
<address>
<postal>
<street>3625 Cisco Way</street>
<city>San Jose</city>
<code>95134</code>
<country>USA</country>
</postal>
<phone>+1 408 526 5030</phone>
<email>kleung@cisco.com</email>
</address>
</author>
<author fullname="Kevin J. Ma" initials="K.J." surname="Ma">
<organization>Azuki Systems, Inc.</organization>
<address>
<postal>
<street>43 Nagog Park</street>
<city>Acton</city>
<region>MA</region>
<code>01720</code>
<country>USA</country>
</postal>
<phone>+1 978-844-5100</phone>
<email>kevin.ma@azukisystems.com</email>
</address>
</author>
<date />
<abstract>
<t>The CDNI Metadata Interface enables interconnected CDNs to exchange
content distribution metadata in order to enable content acquisition and
delivery. The CDNI metadata associated with a piece of content provides
a downstream CDN with sufficient information for the downstream CDN to
service content requests on behalf of an upstream CDN. This document
describes both the core set of CDNI metadata and the protocol for
exchanging that metadata.</t>
</abstract>
<note title="Requirements Language">
<t>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 <xref
target="RFC2119">RFC 2119</xref>.</t>
</note>
</front>
<middle>
<section title="Introduction">
<t>CDNI enables a downstream CDN to service content requests on behalf
of an upstream CDN. The CDNI metadata associated with a piece of content
(or with a set of contents) provides a downstream CDN with sufficient
information for servicing content requests on behalf of an upstream CDN
in accordance with the policies defined by the upstream CDN.</t>
<t>The CDNI Metadata Interface is introduced by <xref
target="RFC6707"></xref> along with three other interfaces that may be
used to compose a CDNI solution (Control, Request Routing and Logging).
<xref target="I-D.ietf-cdni-framework"></xref> expands on the
information provided in <xref target="RFC6707"></xref> and describes
each interface, and the relationships between them, in more detail. The
requirements for the CDNI metadata interface are specified in <xref
target="I-D.ietf-cdni-requirements"></xref>.</t>
<t>This document focuses on the CDNI Metadata interface which enables a
downstream CDN to obtain CDNI Metadata from an upstream CDN so that the
downstream CDN can properly process and respond to:</t>
<t><list style="symbols">
<t>Redirection Requests received over the CDNI Request Routing
protocol.</t>
<t>Content Requests received directly from User Agents.</t>
</list></t>
<t>Specifically, this document proposes:</t>
<t><list style="symbols">
<t>A data structure for mapping content requests to CDNI Metadata
properties (<xref target="data-model"></xref>).</t>
<t>An initial set of CDNI Metadata properties (<xref
target="property-objects"></xref>).</t>
<t>A RESTful web service for the transfer of CDNI Metadata (<xref
target="metadata-interface"></xref>).</t>
</list></t>
<section anchor="terminology" title="Terminology">
<t>This document reuses the terminology defined in <xref
target="RFC6707"></xref>.</t>
<t>Additionally, the following terms are used throughout this document
and are defined as follows:<list style="symbols">
<t>Object - a collection of properties</t>
<t>Property - a key and value pair where the key is a property
name and the value is the property value or an object.</t>
</list></t>
</section>
</section>
<section title="Design Principles">
<t>The proposed CDNI Metadata Interface was designed to achieve the
following objectives:</t>
<t><list style="numbers">
<t>Cacheability of CDNI metadata objects</t>
<t>Deterministic mapping from redirection and content requests to
CDNI metadata properties</t>
<t>Support for DNS redirection as well as application-specific
redirection (for example HTTP redirection)</t>
<t>Minimal duplication of CDNI metadata</t>
<t>Leverage existing protocols</t>
</list></t>
<t>Cacheability improves the latency of acquiring metadata while
maintaining its freshness and therefore improves the latency of serving
content requests. The CDNI Metadata Interface uses HTTP to achieve
cacheability.</t>
<t>Deterministic mappings from content to metadata properties eliminates
ambiguity and ensures that policies are applied consistently by all
downstream CDNs.</t>
<t>Support for both HTTP and DNS redirection ensures that the CDNI
Metadata Interface can be used for HTTP and DNS redirection and also
meets the same design principles for both HTTP and DNS based redirection
schemes.</t>
<t>Minimal duplication of CDNI metadata provides space efficiency on
storage in the CDNs, on caches in the network, and across the network
between CDNs.</t>
<t>Leveraging existing protocols avoids reinventing common mechanisms
such as data structure encoding (e.g. XML, JSON) and data transport
(e.g. HTTP).</t>
</section>
<section anchor="data-model" title="CDNI Metadata Data Model">
<t>The CDNI Metadata Model describes a data structure for mapping
redirection requests and content requests to metadata properties.
Metadata properties describe how to acquire content from an upstream CDN,
authorize access to content, and deliver
content from a downstream CDN. The data model relies on the assumption
that these metadata properties may be aggregated based on the hostname
of the content and subsequently on the resource path of the content. The
data model associates a set of CDNI Metadata properties with a Hostname
to form a default set of metadata properties for content delivered on behalf of
that Hostname. That default set of metadata properties can be overridden
by properties that apply to specific paths within a URI.</t>
<t>Different Hostnames and URI paths will be associated with different
sets of CDNI Metadata properties in order to describe the required
behaviour when a dCDN surrogate is processing User Agent requests for
content at that Hostname or URI path. As a result of this structure,
significant commonality may exist between the CDNI Metadata properties
specified for different Hostnames, different URI paths within a Hostname
and different URI paths on different Hostnames. For example the
definition of which User Agent IP addresses should be treated as being
grouped together into a single network or geographic location is likely
to be common for a number of different Hostnames. Another example is
that although a uCDN is likely to have several different policies
configured to express geo-blocking rules, it is likely that a single
geo-blocking policy would be applied to multiple Hostnames delivered
through the CDN.</t>
<t>In order to enable the CDNI Metadata for a given Hostname or URI Path
to be decomposed into sets of CDNI Metadata properties that can be
reused by multiple Hostnames and URI Paths, the CDNI Metadata interface
specified in this document splits the CDNI Metadata into a number of
objects. Efficiency is improved by enabling a single CDNI Metadata
object (that is shared across Hostname and/or URI paths) to be retrieved
by a dCDN once, even if it is referenced by the CDNI Metadata of
multiple Hostnames.</t>
<t><xref target="hostindex-intro"></xref> introduces a high level
description of the HostIndex, HostMetadata and PathMetadata objects and
describes the relationships between those objects.</t>
<t><xref target="other-objects-intro"></xref> introduces a high level
description of the CDNI GenericMetadata object which represents the
level at which CDNI Metadata override occurs between HostMetadata and
PathMetadata objects.</t>
<t><xref target="abstract-metadata-description"></xref> describes in
detail the specific CDNI Metadata objects and properties which may be
contained within a CDNI GenericMetadata object.</t>
<section anchor="hostindex-intro"
title="HostIndex, HostMetadata & PathMetadata objects">
<t>A HostIndex object contains a list of Hostnames (and/or IP
addresses) for which content requests may be delegated to the
downstream CDN. The HostIndex is the starting point for accessing the
uCDN's CDNI Metadata data store. It enables surrogates in the dCDN to
deterministically discover, on receipt of a User Agent request for
content, which other CDNI Metadata objects it requires in order to
deliver the requested content.</t>
<t>The HostIndex links Hostnames (and/or IP addresses) to HostMetadata
objects via HostMatch objects. HostMetadata objects contain (or
reference) the default CDNI Metadata required to serve content for
that host. When looking up CDNI Metadata, the downstream CDN looks up
the requested Hostname (or IP address) in the HostIndex, from there it
can find HostMetadata which describes properties for a host and
PathMetadata which may override those properties for given URI paths
within the host.</t>
<t>Besides containing the default CDNI Metadata for the specified
Hostname, HostMetadata and PathMetadata objects may also contain
PathMatch objects which in turn contain PathMetadata objects.
PathMatch objects override the CDNI Metadata in the HostMetadata
object or one or more preceding PathMetadata objects with more
specific CDNI Metadata that applies to content requests matching the
pattern defined in that PathMatch object.</t>
<t>For the purposes of retrieving CDNI Metadata all other required
CDNI Metadata objects and their properties are discoverable from the
appropriate HostMetadata, PathMatch and PathMetadata objects for the
requested content.</t>
<t>The relationships between the HostIndex, HostMatch, HostMetadata,
PathMatch and PathMetadata objects are described in <xref
target="metadata-model-figure-top"></xref>.</t>
<t><figure anchor="metadata-model-figure-top"
title="Relationships between the HostIndex, HostMetadata & PathMetadata CDNI Metadata Objects">
<artwork><![CDATA[
+---------+ +---------+ +------------+
|HostIndex+-(*)->|HostMatch|-(1)->|HostMetadata+-------(*)------+
+---------+ +---------+ +------+-----+ |
| |
(*) |
| |
--> References V V
(1) One and only one +---------+ **************************
(*) Zero or more +--->|PathMatch| *Generic Metadata Objects*
| +---------+ **************************
| | ^
(*) (1) |
| | |
| V |
| +------------+ |
+--|PathMetadata+-------(*)------+
+------------+
]]></artwork>
</figure></t>
<t>The relationships in <xref
target="metadata-model-figure-top"></xref> are summarised in <xref
target="metadata-model-table"></xref> below.</t>
<texttable anchor="metadata-model-table"
title="Relationships between CDNI Metadata Objects">
<ttcol>Data Object</ttcol>
<ttcol>Objects it References</ttcol>
<c>HostIndex</c>
<c>0 or more HostMatch objects.</c>
<c>HostMatch</c>
<c>1 HostMetadata object.</c>
<c>HostMetadata</c>
<c>0 or more PathMatch objects. 0 or more GenericMetadata
objects.</c>
<c>PathMatch</c>
<c>1 PathMetadata object.</c>
<c>PathMetadata</c>
<c>0 or more PathMatch objects. 0 or more GenericMetadata
objects.</c>
</texttable>
<t>The table below describes the HostIndex, HostMetadata and
PathMetadata objects in more detail.</t>
<texttable anchor="hostindex-objects-table"
title="HostIndex, HostMetadata and PathMetadata CDNI Metadata Objects">
<ttcol>Data Object</ttcol>
<ttcol>Description</ttcol>
<c>HostIndex</c>
<c>A HostIndex object lists HostMatch objects</c>
<c>HostMatch</c>
<c>A HostMatch object defines a hostname to match against a
requested host, and contains or references a HostMetadata object
which contains CDNI Metadata objects to be applied when a request
matches against the hostname. For example, if "example.com" is a
content provider, a HostMatch object may include an entry for
"example.com" with the URI of the associated HostMetadata
object.</c>
<c>HostMetadata</c>
<c>A HostMetadata object contains (or references) the default CDNI
Metadata objects for content served from that host, i.e. the CDNI
Metadata objects for content requests that do not match any of the
PathMatch objects contained or referenced by that HostMetadata
object. For example, a HostMetadata object may describe the metadata
properties which apply to "example.com" and may contain PathMatches
for "example.com/movies/*" and "example.com/music/*" which reference
corresponding PathMetadata objects that contain the CDNI Metadata
objects for those more specific URI paths.</c>
<c>PathMatch</c>
<c>A PathMatch object defines a pattern to match against the
requested URI path, and contains or references a PathMetadata object
which contains (or references) the CDNI Metadata objects to be
applied when a content request matches against the defined URI path
pattern. For example, a PathMatch object may include a pattern
for the path "/movies/*" and may reference a PathMetadata object which
contains the CDNI Metadata for content with that path.</c>
<c>PathMetadata</c>
<c>A PathMetadata object contains the CDNI GenericMetadata objects
for content served with the associated URI path (defined in a
PathMatch object). A PathMetadata object may also contain PathMatch
objects in order to recursively define more specific URI paths that
require different (e.g. more specific) CDNI Metadata to this one.
For example, the PathMetadata object which applies to
"example.com/movies/*" may describe CDNI Metadata which apply to
that resource path and may contain a PathMatch object for
"example.com/movies/hd/*" which would reference the corresponding
PathMetadata object for the "example.com/movies/hd/" path
prefix.</c>
<c>GenericMetadata</c>
<c>A GenericMetadata object contains individual CDNI Metadata
objects which define the specific policies and attributes needed to
properly deliver the associated content. For example, a GenericMetadata
object may describe the source from which a CDN may acquire a piece of
content.</c>
</texttable>
<t></t>
</section>
<section anchor="other-objects-intro"
title="Generic CDNI Metadata Object Properties">
<t>The HostMetadata and PathMetadata objects contain or can reference
other CDNI Metadata objects that contain properties which describe how
User Agent requests for content should be processed, for example where
to acquire the content, authorization rules that should be applied,
delivery location restrictions and so on. Each such CDNI Metadata
object is a specialization of a CDNI GenericMetadata object. The
GenericMetadata object abstracts the basic information required for
Metadata override and Metadata distribution, from the specifics
of any given property (e.g., property semantics, enforcement options,
etc.).</t>
<t>The GenericMetadata object defines the type of properties contained
within it as well as whether or not the properties are mandatory to
enforce. If the dCDN does not understand or support the property type
and the property type is mandatory to enforce, the dCDN MUST NOT serve
the content to the User Agent. If the dCDN does not understand or
support the property type it is also not going to be able to properly
propagate the Metadata for cascaded distribution. If the dCDN does not
understand or support the property type and the property type is not
mandatory to enforce, then the GenericMetadata object may be safely
ignored.</t>
<t>Although a CDN cannot serve content to a User Agent if a mandatory
property cannot be enforced, it may be safe to redistribute that
metadata to another CDN without modification. For example, in the
cascaded CDN case, a transit CDN may pass through mandatory-to-enforce
metadata to the delivery CDN. For Metadata which does not require
customization, the data representation received off the wire MAY be
stored and redistributed without being natively understood or
supported by the transit CDN. However, for Metadata which require
translations, transparent redistribution of the uCDN Metadata values
may not be appropriate. Certain Metadata may be safely, though
possibly not optimially, redistributed unmodified, e.g., source
acquisition address may not be optimal if transparently redistributed,
but may still work. Redistribution safety MUST be specified for each
GenericMetadata.</t>
</section>
<section anchor="metadata-inheritance"
title="Metadata Inheritance and Override">
<t>In the data model, a HostMetadata object may contain (or reference)
multiple PathMetadata objects (via PathMatch objects). Each
PathMetadata object may in turn contain (or reference) other
PathMetadata objects. HostMetadata and PathMetadata objects form an
inheritance tree where each node in the tree inherits or overrides the
property values set by its parent.</t>
<t>GenericMetadata objects of a given type override all
GenericMetadata objects of the same type previously defined by any
parent object in the tree. GenericMetadata objects of a given type
previously defined by a parent object in the tree are inherited when
no object of the same type is defined by the child object. For
example, if HostMetadata for the host "example.com" contains
GenericMetadata objects of type LocationACL and TimeWindowACL, while a
PathMetadata object which applies to "example.com/movies/*" defines an
alternate GenericMetadata object of type TimeWindowACL, then: <list>
<t>the TimeWindowACL defined in the PathMetadata would override
the TimeWindowACL defined in the HostMetadata</t>
<t>the LocationACL defined in the HostMetadata would be inherited
for all User Agent requests for content under
"example.com/movies".</t>
</list>The PathMetadata defined TimeWindowACL would override the
TimeWindowACL defined in the HostMetadata for all User Agent requests
for movies.</t>
</section>
<section anchor="metadata-naming" title="Metadata Naming">
<t>GenericMetadata objects are identified by their type. The type
SHOULD be descriptive, and MAY be hierarchical to support aggregating
groups of properties for the purpose of readability and for avoiding
name conflicts between vendor extensions. A dotted alpha-numeric
notation is suggested for human readability.</t>
<t>Metadata types defined by this document are not hierarchical.</t>
</section>
</section>
<section anchor="abstract-metadata-description"
title="Encoding-Independent CDNI Metadata Object Descriptions">
<t><xref target="structural-objects"></xref> provides the definitions of
each object type declared in <xref target="data-model"></xref>. These
objects are described as structural objects as they provide the
structure for the inheritance tree and identifying which specific
properties apply to a given User Agent content request.</t>
<t><xref target="property-objects"></xref> provides the definitions for
the set of core metadata objects which may be contained within a
GenericMetadata object. These objects are described as property objects
as they define the semantics, enforcement options, and serialization
rules for specific properties. These properties govern how User Agent
requests for content are handled. Property objects may be composed of or
contain references to other objects. In those cases the value of the
property can be either an object of that type (the object is embedded)
or a Link object that contains a URI and relationship that can be
dereferenced to retrieve the CDNI Metadata object that represents the
value of that property.</t>
<t>Note: In the following sections, the term "mandatory-to-specify" is
used to convey which objects or properties must be specified for a given
parent object or property. When mandatory-to-specify is set to true, it
implies that if the parent object is specified, then the defined object
or property MUST also be specified, e.g., a HostMatch object without a
host to match against does not make sense, therefore, the host is
mandatory-to-specify inside a parent HostMatch object.</t>
<section anchor="structural-objects"
title="CDNI Metadata Structural Object Descriptions">
<t>Each of the sub-sections below describe the structural objects
defined in <xref target="hostindex-objects-table"></xref>.</t>
<section anchor="HostIndex" title="HostIndex">
<t>The HostIndex object is the entry point into the CDNI Metadata
hierarchy. It contains a list of HostMatch objects. An incoming
content request is matched against the hostname inside of each of
the listed HostMatch objects to find the HostMatch object which
applies to the request.</t>
<t><list style="empty">
<t>Property: hosts<list style="empty">
<t>Description: List of HostMatch objects, in priority
order.</t>
<t>Type: List of HostMatch objects</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
</section>
<section anchor="HostMatch" title="HostMatch">
<t>The HostMatch object contains a hostname or IP address to match
against content requests. The HostMatch object also contains a
reference to Metadata objects to apply if a match is found.</t>
<t><list style="empty">
<t>Property: host<list style="empty">
<t>Description: String (hostname or IP address) to match
against the requested host.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: host-metadata<list style="empty">
<t>Description: CDNI Metadata to apply when delivering
content that matches this host.</t>
<t>Type: HostMetadata</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
</section>
<section anchor="HostMetadata" title="HostMetadata">
<t>The HostMetadata object contains both Metadata that applies to
content requests for a particular host and a list of pattern matches
for finding more specific Metadata based on the resource path in a
content request.</t>
<t><list style="empty">
<t>Property: metadata<list style="empty">
<t>Description: List of host related metadata.</t>
<t>Type: List of GenericMetadata objects</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: paths<list style="empty">
<t>Description: Path specific rules. First match
applies.</t>
<t>Type: List of PathMatch objects</t>
<t>Mandatory-to-Specify: No.</t>
</list></t>
</list></t>
</section>
<section anchor="PathMatch" title="PathMatch">
<t>The PathMatch object contains an expression given as a
PatternMatch object to match against a resource URI path and
Metadata objects to apply if a match is found.</t>
<t><list style="empty">
<t>Property: path-pattern<list style="empty">
<t>Description: Pattern to match against the requested path,
i.e. against the <xref target="RFC3986"></xref>
path-absolute.</t>
<t>Type: PatternMatch</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: path-metadata<list style="empty">
<t>Description: CDNI Metadata to apply when delivering
content that matches this pattern.</t>
<t>Type: PathMetadata</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
</section>
<section anchor="PathMetadata" title="PathMetadata">
<t>A PathMetadata object contains the CDNI Metadata properties for
content served with the associated URI path (defined in a PathMatch
object). Note that if CDNI metadata is used as an input to CDNI
request routing and DNS-based redirection is employed, then any
metadata at the PathMetadata level or below will be inaccessible at
request routing time.</t>
<t><list style="empty">
<t>Property: metadata<list style="empty">
<t>Description: List of path related metadata.</t>
<t>Type: List of GenericMetadata objects</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: paths<list style="empty">
<t>Description: Path specific rules. First match
applies.</t>
<t>Type: List of PathMatch objects</t>
<t>Mandatory-to-Specify: No.</t>
</list></t>
</list></t>
</section>
<section title="PatternMatch">
<t>A PatternMatch object contains the pattern string and flags that
describe the PathMatch expression.</t>
<t><list style="empty">
<t>Property: pattern<list style="empty">
<t>Description: A pattern for string matching. The pattern
may contain the wildcards * and ?, where * matches any
sequence of characters (including the empty string) and ?
matches exactly one character. The three literals \ , * and
? should be escaped as \\, \* and \?. All other characters
are treated as literals.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: case-sensitive<list style="empty">
<t>Description: Flag indicating whether or not
case-sensitive matching should be used.</t>
<t>Type: Boolean</t>
<t>Mandatory-to-Specify: No. Default is case-insensitive
match.</t>
</list></t>
</list><list style="empty">
<t>Property: ignore-query-string<list style="empty">
<t>Description: List of query parameters which should be
ignored when searching for a pattern match. If all query
parameters should be ignored then the list MUST be
empty.</t>
<t>Type: List of String</t>
<t>Mandatory-to-Specify: No. Default is to include query
strings when matching.</t>
</list></t>
</list></t>
</section>
<section anchor="generic-metadata" title="GenericMetadata">
<t>A GenericMetadata object is a abstraction for managing individual
CDNI Metadata properties in an opaque manner.</t>
<t><list style="empty">
<t>Property: type<list style="empty">
<t>Description: CDNI Metadata property object type.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: value<list style="empty">
<t>Description: CDNI Metadata property object.</t>
<t>Type: matches the type property above</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: mandatory-to-enforce<list style="empty">
<t>Description: Flag identifying whether or not the
enforcement of the property Metadata is required.</t>
<t>Type: Boolean</t>
<t>Mandatory-to-Specify: No. Default is to treat metadata as
mandatory to enforce.</t>
</list></t>
</list><list style="empty">
<t>Property: safe-to-redistribute<list style="empty">
<t>Description: Flag identifying whether or not the property
Metadata may be safely redistributed without
modification.</t>
<t>Type: Boolean</t>
<t>Mandatory-to-Specify: No. Default is allow transparent
redistribution.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="property-objects"
title="CDNI Metadata Property Object Descriptions">
<t>The property objects defined below are intended to be used in the
GenericMetadata object value field as defined in <xref
target="generic-metadata"></xref>. All of the objects defined below
are considered both mandatory to enforce and safe to redistribute.</t>
<section anchor="SourceMetadata" title="Source Metadata">
<t>Source Metadata provides the dCDN information about content
acquisition e.g. how to contact an uCDN Surrogate or an Origin
Server to obtain the content to be served. The sources are not
necessarily the actual Origin Servers operated by the CSP but might
be a set of Surrogates in the uCDN.</t>
<t><list style="empty">
<t>Property: sources<list style="empty">
<t>Description: Sources from which the dCDN can acquire
content, listed in priority order.</t>
<t>Type: List of Source objects</t>
<t>Mandatory-to-Specify: No. Default is to use static
configuration, out of band of the metadata interface.</t>
</list></t>
</list></t>
<section anchor="Source" title="Source">
<t>A Source object describes the Source which should be used by
the dCDN for content acquisition, e.g. a Surrogate within the uCDN
or an alternate Origin Server, the protocol to be used and any
authentication method.</t>
<t><list style="empty">
<t>Property: auth<list style="empty">
<t>Description: Authentication method to use when
requesting content from this source.</t>
<t>Type: Auth</t>
<t>Mandatory-to-Specify: No. Default is no authentication
is required.</t>
</list></t>
</list><list style="empty">
<t>Property: endpoints<list style="empty">
<t>Description: Origins from which the dCDN can acquire
content.</t>
<t>Type: List of EndPoint objects</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: protocol<list style="empty">
<t>Description: Network retrieval protocol to use when
requesting content from this source.</t>
<t>Type: Protocol</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="LocationACL" title="LocationACL Metadata">
<t>LocationACL Metadata defines location-based restrictions.</t>
<t><list style="empty">
<t>Property: locations<list style="empty">
<t>Description: Access control list which applies
restrictions to delivery based on client location.</t>
<t>Type: List of LocationRule objects</t>
<t>Mandatory-to-Specify: No. Default is allow all
locations.</t>
</list></t>
</list></t>
<section anchor="LocationRule" title="LocationRule">
<t>A LocationRule contains or references a list of Footprint
objects and the corresponding action.</t>
<t><list style="empty">
<t>Property: footprints<list style="empty">
<t>Description: List of footprints to which the rule
applies.</t>
<t>Type: List of Footprint objects</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: action<list style="empty">
<t>Description: Defines whether the rule specifies
locations to allow or deny.</t>
<t>Type: Enumeration [allow|deny]</t>
<t>Mandatory-to-Specify: No. Default is deny.</t>
</list></t>
</list></t>
</section>
<section anchor="Footprint" title="Footprint">
<t>A Footprint object describes the footprint to which a
LocationRule may be applied by, e.g. an IPv4 address range or a
geographic location.</t>
<t><list style="empty">
<t>Property: type<list style="empty">
<t>Description: Registered footprint type (see <xref
target="FootprintReg"></xref>).</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: value<list style="empty">
<t>Description: Footprint object conforming to the
specification associated with the registered footprint
type.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="TimeWindowACL" title="TimeWindowACL Metadata">
<t>TimeWindowACL Metadata defines time-based restrictions.</t>
<t><list style="empty">
<t>Property: times<list style="empty">
<t>Description: Access control list which applies
restrictions to delivery based on request time.</t>
<t>Type: List of TimeWindowRule objects</t>
<t>Mandatory-to-Specify: No. Default is allow all time
windows.</t>
</list></t>
</list></t>
<section anchor="TimeWindowRule" title="TimeWindowRule">
<t>A TimeWindowRule contains or references a list of TimeWindow
objects and the corresponding action.</t>
<t><list style="empty">
<t>Property: times<list style="empty">
<t>Description: List of time windows to which the rule
applies.</t>
<t>Type: List of TimeWindow objects</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: action<list style="empty">
<t>Description: Defines whether the rule specifies time
windows to allow or deny.</t>
<t>Type: Enumeration [allow|deny]</t>
<t>Mandatory-to-Specify: No. Default is deny.</t>
</list></t>
</list></t>
</section>
<section anchor="TimeWindow" title="TimeWindow">
<t>A TimeWindow object describes a time range which may be applied
by an ACLRule, e.g. Start 09:00AM 01/01/2000 UTC End 17:00PM
01/01/2000 UTC.</t>
<t><list style="empty">
<t>Property: start<list style="empty">
<t>Description: The start time of the window.</t>
<t>Type: Time</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: end<list style="empty">
<t>Description: The end time of the window.</t>
<t>Type: Time</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="ProtocolACL" title="ProtocolACL Metadata">
<t>ProtocolACL Metadata defines delivery protocol restrictions.</t>
<t><list style="empty">
<t>Property: protocols<list style="empty">
<t>Description: Access control list which applies
restrictions to delivery based on delivery protocol.</t>
<t>Type: List of ProtocolRule objects</t>
<t>Mandatory-to-Specify: No. Default is allow all
protocols.</t>
</list></t>
</list></t>
<section anchor="ProtocolRule" title="ProtocolRule">
<t>A ProtocolRule contains or references a list of Protocol
objects. ProtocolRule objects are used to construct a ProtocolACL
to apply restrictions to content acquisition or delivery.</t>
<t><list style="empty">
<t>Property: protocols<list style="empty">
<t>Description: List of protocols to which the rule
applies.</t>
<t>Type: List of protocol objects</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: action<list style="empty">
<t>Description: Defines whether the rule specifies
protocols to allow or deny.</t>
<t>Type: Enumeration [allow|deny]+</t>
<t>Mandatory-to-Specify: No. Default is allow all
protocols.</t>
</list></t>
</list><list style="empty">
<t>Property: direction<list style="empty">
<t>Description: Defines whether the ProtocolRule specifies
protocols for acquisition or delivery.</t>
<t>Type: Enumeration [acquisition|delivery]</t>
<t>Mandatory-to-Specify: No. Default is to apply the rule
to both acquisition and delivery.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="Authorization" title="Authorization Metadata">
<t>Authorization Metadata define content authorization methods.</t>
<t><list style="empty">
<t>Property: methods<list style="empty">
<t>Description: Options for authenticating content requests.
All options in the list are equally valid.</t>
<t>Type: List of Auth objects</t>
<t>Mandatory-to-Specify: No. Default is no authorization
required.</t>
</list></t>
</list></t>
</section>
<section anchor="Auth" title="Auth">
<t>An Auth object defines authentication and authorization methods
to be used during content delivery and content acquisition.</t>
<t><list style="empty">
<t>Property: type<list style="empty">
<t>Description: Registered Auth type (see <xref
target="AuthReg"></xref>).</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list><list style="empty">
<t>Property: value<list style="empty">
<t>Description: Auth object conforming to the specification
associated with the registered Auth type.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
<section anchor="CredentialsAuth" title="Credentials Auth Type">
<t>Credentials Auth is a type of Auth object with type
"credentials" (see <xref target="AuthReg"></xref>). The
CredentialsAuth object contains the following properties:</t>
<t><list style="empty">
<t>Property: username<list style="empty">
<t>Description: Identification of user.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
<t>Property: password<list style="empty">
<t>Description: Password for user identified by username
property.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: Yes.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="Cache" title="Cache">
<t>A Cache object describes the cache control parameters to be
applied to the content by intermediate caches.</t>
<t><list style="empty">
<t>Property: ignore-query-string<list style="empty">
<t>Description: Allows a cache to ignore URI query string
parameters while comparing URIs for equivalence. Each query
parameter to ignore is specified in the list. If all query
parameters should be ignored, then the list MUST be
empty.</t>
<t>Type: List of String</t>
<t>Mandatory-to-Specify: No. Default is to consider query
string parameters when comparing URIs or to rely on other
properties of the Cache object.</t>
</list></t>
</list></t>
</section>
<section anchor="Grouping" title="Grouping">
<t>A Grouping object identifies a large group of content to which
this content belongs.</t>
<t><list style="empty">
<t>Property: ccid<list style="empty">
<t>Description: Content Collection identifier for an
application-specific purpose such as logging.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: No. Default is an empty string.</t>
</list></t>
</list><list style="empty">
<t>Property: sid<list style="empty">
<t>Description: Session identifier for an
application-specific purpose such as logging.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: No. Default is an empty string.</t>
</list></t>
</list></t>
</section>
</section>
<section anchor="simple-data-types"
title="CDNI Metadata Simple Data Type Descriptions">
<t>This section describes the simpler data types that are used for
properties of CDNI Metadata objects.</t>
<section anchor="Link" title="Link">
<t>A link object may be used in place of any of the objects or
properties described above. Links can be used to avoid duplication
if the same metadata information is repeated within the metadata
tree. When a link replaces an object, its href property is set to
the URI of the resource and its type property is set to the type
of the object it is replacing.</t>
<t><list style="empty">
<t>Property: href<list style="empty">
<t>Description: The URI of the of the addressable object
being referenced.</t>
<t>Type: URI</t>
<t>Mandatory-to-Specify: Yes</t>
</list></t>
</list><list style="empty">
<t>Property: type<list style="empty">
<t>Description: The type of the object being referenced.</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: No</t>
</list></t>
</list></t>
</section>
<section anchor="Protocol" title="Protocol">
<t>Protocol objects are used to specify registered protocols for
content acquisition or delivery (see <xref
target="ProtocolReg"></xref>).</t>
<t>Type: String</t>
<t>Mandatory-to-Specify: Yes</t>
</section>
<section title="Endpoint">
<t>A hostname (with optional port) or an IP address (with optional
port).</t>
<t>Note: All implementations MUST support IPv4 addresses encoded as
specified by the 'IPv4address' rule in Section 3.2.2 of <xref
target="RFC3986"></xref> and MUST support all IPv6 address formats
specified in <xref target="RFC4291"></xref>. Server implementations
SHOULD use IPv6 address formats specified in <xref
target="RFC5952"></xref>.</t>
</section>
<section title="URI">
<t>A URI as specified in <xref target="RFC3986"></xref>.</t>
</section>
<section title="Time">
<t>A time value expressed in seconds since Unix epoch in the UTC
timezone.</t>
</section>
</section>
</section>
<section anchor="metadata-capabilities" title="CDNI Metadata Capabilities">
<t>CDNI Metadata is used to convey information pertaining to content
delivery from uCDN to dCDN. For optional metadata, it may be useful for
the uCDN to know if the dCDN supports the metadata, prior to delegating
any content requests to the dCDN. If optional-to-implement metadata is
mandatory-to-enforce and the dCDN does not support it, any delegated
requests for that content will fail, so there is no reason to delegate
those requests. Likewise, for any metadata which may be assigned
optional values, it may be useful for the uCDN to know which values the
dCDN supports, prior to delegating any content requests to the dCDN. If
a the optional value assigned to a given piece of content's metadata is
not supported by the dCDN, any delegated requests for that content may
fail, so there is likely no reason to delegate those requests.</t>
<t>The CDNI Footprint and Capabilities Interface provides a means of
advertising capabilities from dCDN to uCDN. Support for optional
metadata and support for optional metadata values may be advertised
using the capabilities interface. This section describes the
capabilities advertisement requirements for the metadata defined in
<xref target="property-objects"></xref></t>
<section anchor="ProtocolACLCapabilities"
title="Protocol ACL Capabilities">
<t>The ProtoclACL object contains a list of Protocol values. The dCDN
MUST advertise which delivery protocols it supports so that the uCDN
knows what type of content requests it can redirect to the dCDN. If
the dCDN does not support a given acquisition or delivery protocol,
the uCDN should not delegate requests requiring those protocols to the
dCDN as the dCDN will not be able to properly acquire or deliver the
content.</t>
<t>ProtocolRules are defined for either acquisition or delivery. For
some CDNs, certain combinations of acquisition and delivery protocols
may not make sense (e.g., RTSP acquisition for HTTP delivery), while
other CDNs may support customized protocol adaptation. ProtocolACL
capabilities are not intended to define which combinations of
protocols should be used. ProtocolACL capabilties are only intended to
describe which protocols the dCDN does or does not support. Protocol
combination restrictions are specified in the metadata itself and
associated with specific groups of content assets.</t>
</section>
<section anchor="AuthorizationCapabilities"
title="Authorization Metadata Capabilities">
<t>The Authorization object contains a list of Auth values. The dCDN
MUST advertise which authorization algorithms it supports so that the
uCDN knows what type of content requests it can redirect to the dCDN.
If the dCDN does not support a given authorization algorithm, the uCDN
should not delegate requests requiring that algorithm to the dCDN as
the dCDN will not be able to properly acquire the content or enforce
delivery restrictions.</t>
</section>
</section>
<section anchor="metadata-interface" title="CDNI Metadata interface">
<t>This section specifies an interface to enable a Downstream CDN to
retrieve CDNI Metadata objects from an Upstream CDN.</t>
<t>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
(for example in case of prepositioned CDNI Metadata acquisition).</t>
<t>The CDNI Metadata interface is built on the principles of RESTful web
services. 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 any object in
the Data Model (as described in <xref target="data-model"></xref>
through <xref target="abstract-metadata-description"></xref>).</t>
<t>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 HostIndex object referencing a HostMetadata object) it does so
by including a link to the referenced object.</t>
<t>CDNI Metadata servers are 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 to impose a definitive structure on
CDNI Metadata interface implementations.</t>
<section title="Transport">
<t>The CDNI Metadata interface uses HTTP as the underlying protocol
transport.</t>
<t>The HTTP Method in the request defines the operation the request
would like to perform. Servers implementing the CDNI Metadata
interface MUST support the HTTP GET and HEAD methods.</t>
<t>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.</t>
<t>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.</t>
<t>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.</t>
</section>
<section title="Retrieval of CDNI Metadata resources">
<t>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 HostIndex which
provides the CDNI Metadata client with a list of Hostnames for which
the upstream CDN may delegate content delivery to the downstream
CDN.</t>
<t>In order to retrieve the CDNI Metadata for a particular request the
CDNI Metadata client processes the received HostIndex object and finds
the corresponding HostMetadata entry (by matching the hostname in the
request against the hostnames in the HostMatch). If the HostMetadata
is linked (rather than embedded), the CDNI metadata client then makes
a GET request for the URI specified in the href property of the Link
object which points to the HostMetadata object itself.</t>
<t>In order to retrieve the most specific metadata for a particular
request, the CDNI metadata client inspects the HostMetadata for
references to more specific PathMetadata objects. If any PathMetadata
match the request (and are linked rather than embedded), the CDNI
metadata client makes another GET request for the PathMetadata. Each
PathMetadata object may also include references to yet more specific
metadata. If this is the case, the CDNI metadata client continues
requesting PathMetadata recursively.</t>
<t>Where a downstream CDN is interconnected with multiple upstream
CDNs, the downstream CDN must decide which upstream CDN's CDNI
metadata should be used to handle a particular User Agent request.</t>
<t>When application level redirection (e.g. HTTP 302 redirects) is
being used between CDNs, it is expected that the downstream CDN will
be able to determine the upstream CDN that redirected a particular
request from information contained in the received request (e.g. via
the URI). With knowledge of which upstream CDN routed the request, the
downstream CDN can choose the correct metadata server from which to
obtain the HostIndex. Note that the HostIndex served by each uCDN may
be unique.</t>
<t>In the case of DNS redirection there is not always sufficient
information carried in the DNS request from User Agents to determine
the upstream CDN that redirected a particular request (e.g. when
content from a given host is redirected to a given downstream CDN by
more than one upstream CDN) and therefore downstream CDNs may have to
apply local policy when deciding which upstream CDN's metadata to
apply.</t>
</section>
<section title="Bootstrapping">
<t>The URI for the HostIndex object of a given upstream CDN needs to
be either discovered by or configured in the downstream CDN. All other
objects/resources are then discoverable from the HostIndex object by
following the links in the HostIndex object and the referenced
HostMetadata and PathMetadata objects.</t>
<t>If the URI for the HostIndex object is not manually configured in
the downstream CDN then the HostIndex URI could be discovered. A
mechanism allowing the downstream CDN to discover the URI of the
HostIndex is outside the scope of this document.</t>
</section>
<section title="Encoding">
<t>Object are resources that may be:</t>
<t><list style="symbols">
<t>Addressable, where the object is a resource that may be
retrieved or referenced via its own URI.</t>
<t>Embedded, where the object is contained (or inlined) within a
property of an addressable object.</t>
</list></t>
<t>In the descriptions of objects we use the term "X contains Y" to
mean either Y is directly embedded in X or that Y is linked to by X.
It is generally a deployment choice for the uCDN implementation to
decide when and which CDNI Metadata objects to embed and which are
separately addressable.</t>
<section anchor="media-types" title="MIME Media Types">
<t>All MIME types are prefixed with "application/cdni." The MIME
type for each object matches the type name of that object as defined
by this document. The object type name is followed by ".v" and the version
number of the object type (e.g. “.v1”). Finally, the encoding
type "+json" is appended. <xref target="metadata-media-types-table"></xref>
lists a few examples of the MIME Media Type for each object
(resource) that is retrievable through the CDNI Metadata
interface. </t>
<texttable anchor="metadata-media-types-table"
title="Example MIME Media Types for CDNI Metadata objects">
<ttcol>Data Object</ttcol>
<ttcol>MIME Media Type</ttcol>
<c>HostIndex</c>
<c>application/cdni.HostIndex.v1+json</c>
<c>HostMatch</c>
<c>application/cdni.HostMatch.v1+json</c>
<c>HostMetadata</c>
<c>application/cdni.HostMetadata.v1+json</c>
<c>PathMatch</c>
<c>application/cdni.PathMatch.v1+json</c>
<c>PathMetadata</c>
<c>application/cdni.PathMetadata.v1+json</c>
<c>Source</c>
<c>application/cdni.Source.v1+json</c>
<c>LocationACL</c>
<c>application/cdni.LocationACL.v1+json</c>
<c>LocationRule</c>
<c>application/cdni.LocationRule.v1+json</c>
</texttable>
<t>See http://www.iana.org/assignments/media-types/index.html for
reference.</t>
</section>
<section title="JSON Encoding of Objects">
<t>CDNI Metadata objects are encoded as JSON objects containing a
dictionary of (key,value) pairs where the keys are the property
names and the values are the associated property values.</t>
<t>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).</t>
<t>Dictionary keys in JSON are case sensitive and therefore by
convention any dictionary key defined by this document (for example
the names of CDNI Metadata object properties) MUST be represented in
lowercase.</t>
<t>In addition to the properties specific to each object type, the
keys defined below may be present in any object.</t>
<t><list style="empty">
<t>Key: base<list style="empty">
<t>Description: Provides a prefix for any relative URLs in
the object. This is similar to the XML base tag <xref
target="XML-BASE"></xref>. If absent, all URLs in the
remainder of the document must be absolute URLs.</t>
<t>Type: URI</t>
<t>Mandatory: No</t>
</list></t>
</list></t>
<t><list style="empty">
<t>Key: _links<list style="empty">
<t>Description: The links of this object to other
addressable objects. Any property may be replaced by a link
to an object with the same type as the property it
replaces. The keys of the _links dictionary are the names of
the properties being replaced. The values of the dictionary are
Link objects with href set to the URI of the object and type
set to the MIME type of the object being replaced.</t>
<t>Type: Dictionary object of Link objects</t>
<t>Mandatory: Yes</t>
</list></t>
</list></t>
<section title="JSON Example">
<t>A downstream CDN may request the HostIndex and receive the
following object of type "application/cdni.HostIndex.v1+json":</t>
<t><figure>
<artwork><![CDATA[{
"hosts": [
{
"host": "video.example.com",
"_links": {
"host-metadata" : {
"type": "application/cdni.HostMetadata.v1+json",
"href": "http://metadata.example.ucdn.com/video"
}
}
},
{
"host": "images.example.com",
"_links": {
"host-metadata" : {
"type": "application/cdni.HostMetadata.v1+json",
"href": "http://metadata.example.ucdn.com/images"
}
}
}
]
}]]></artwork>
</figure></t>
<t>If the incoming request has a Host header with
"video.example.com" then the downstream CDN would fetch the
next metadata object from "http://metadata.ucdn.example.com/video"
expecting a MIME type of "application/cdni.HostMetadata.v1+json":</t>
<t><figure>
<artwork><![CDATA[{
"metadata": [
{
"type": "application/cdni.SourceMetadata.v1+json",
"value": {
"sources": [
{
"_links": {
"auth": {
"type": "application/cdni.Auth.v1+json",
"href": "http://metadata.ucdn.example.com/auth1234"
}
},
"endpoint": "acq1.ucdn.example.com",
"protocol": "ftp"
},
{
"_links": {
"auth": {
"type": "application/cdni.Auth.v1+json",
"href": "http://metadata.ucdn.example.com/auth1234"
}
},
"endpoint": "acq2.ucdn.example.com",
"protocol": "http"
}
]
}
},
{
"type": "application/cdni.LocationACL.v1+json",
"value": {
"locations": [
{
"locations": [
{ "iprange": "192.168.0.0/16" }
],
"action": "deny"
}
]
}
},
{
"type": "application/cdni.ProtocolACL.v1+json",
"value": {
"protocols": [
{
"protocols": [
"ftp"
],
"action": "deny"
}
]
}
}
],
"paths": [
{
"path-pattern": {
"pattern": "/videos/trailers/*"
},
"_links": {
"path-metadata": {
"type": "application/cdni.PathMetadata.v1+json",
"href": "http://metadata.ucdn.example.com/videos/trailers"
}
}
},
{
"path-pattern": {
"pattern": "/videos/movies/*"
},
"_links": {
"pathmetadata": {
"type": "application/cdni.PathMetadata.v1+json",
"href": "http://metadata.ucdn.example.com/videos/movies"
}
}
}
]
}]]></artwork>
</figure></t>
<t>Suppose the path of the requested resource matches the
"/video/movies/*" pattern, the next metadata requested would be
for "http://metadata.ucdn.example.com/video/movies" with an
expected type of "application/cdni.PathMetadata.v1+json":</t>
<t><figure>
<artwork><![CDATA[{
"metadata": [],
"paths": [
{
"path-pattern": {
"pattern": "/videos/movies/hd/*"
},
"_links": {
"pathmetadata": {
"type": "application/cdni.PathMetadata.v1+json",
"href": "http://metadata.ucdn.example.com/videos/movies/hd"
}
}
}
]
}]]></artwork>
</figure></t>
<t>Finally, if the path of the requested resource also matches the
"/videos/movies/hd/*" pattern, the downstream CDN would also fetch
the following object from
"http://metadata.ucdn.example.com/videos/movies/hd" with MIME type
"application/cdni.PathMetadata.v1+json":</t>
<t><figure>
<artwork><![CDATA[{
"metadata": [
{
"type": "application/cdni.TimeWindowACL.v1+json",
"value": {
"times": [
"times": [
{
"start": "1213948800",
"end": "1327393200"
}
],
"type": "allow"
]
}
}
]
}]]></artwork>
</figure></t>
</section>
</section>
</section>
<section anchor="extensibility" title="Extensibility">
<t>The set of property Metadata may be extended with proprietary
and/or custom property Metadata. The GenericMetadata object defined in
<xref target="generic-metadata"></xref> allows any Metadata property
to be included in either the HostMetadata or PathMetadata lists.</t>
<t>Note: Identification of the property Metadata defining organization
in the property Metadata type decreases the possibility of property
Metadata type collision. The fully-qualified domain name of the
organization in reverse order may be used for this purpose.</t>
<section title="Metadata Enforcement">
<t>At any given time, the set of property Metadata supported by the
uCDN may not match the set of property Metadata supported by the
dCDN. The uCDN may or may not know which property Metadata the dCDN
supports. In cases where the uCDN supports Metadata that the dCDN
does not, the dCDN MUST be aware of any Metadata marked as
"mandatory-to-enforce". If a CDN does not understand or is unable to
perform the functions associated with any "mandatory-to-enforce"
Metadata, the CDN MUST NOT service any requests for the
corresponding content.</t>
<t>Any standard which defines a new GenericMetadata Type MUST also
define whether or not the new metadata is mandatory-to-enforce.</t>
<t>Note: Ideally, uCDNs would not delegate content requests to a
dCDN which does not support the mandatory-to-enforce Metadata
associated with the content being requested. However, even if the
uCDN has a priori knowledge of the Metadata supported by the dCDN
(e.g., via the CDNI capabilities interface or through out-of-band
negotiation between CDN operators) Metadata support may fluctuate or
be inconsistent (e.g., due to mis-communication, mis-configuration,
or temporary outage). Thus, the dCDN MUST evaluate all Metadata
associated with content requests and reject any requests where
"mandatory-to-enforce" Metadata associated with the content cannot
be enforced.</t>
</section>
<section title="Metadata Override">
<t>It is possible that new Metadata definitions may obsolete or
override existing property Metadata (e.g., a future revision of the
CDNI Metadata interface may redefine the Auth Metadata or a custom
vendor extension may implement an alternate Auth Metadata option).
If multiple Metadata (e.g., cdni.v2.Auth, vendor1.Auth, and
vendor2.Auth) all override an existing Metadata (e.g., cdni.Auth)
and all are marked as "mandatory-to-enforce", it may be ambiguous
which Metadata should be applied, especially if the functionality of
the Metadata conflict.</t>
<t>As described in <xref target="metadata-inheritance"></xref>,
Metadata override only applies to Metadata objects of the same exact
type, found in HostMetadata and nested PathMetadata structures. The
CDNI Metadata interface does not support enforcement of dependencies
between different Metadata types. It is the responsibility of the
CSP and the CDN operators to ensure that Metadata assigned to a
given content do not conflict.</t>
<t>Note: Because Metadata is inherently ordered in GenericMetadata
lists, as well as in the PathMetadata hierarchy and PathMatch lists,
multiple conflicting Metadata types MAY be used, however, Metadata
hierarchies MUST ensure that independent PathMatch root objects are
used to prevent ambiguous or conflicting Metadata definitions.</t>
</section>
</section>
<section title="Versioning">
<t>The version of CDNI Metadata Structural objects is specified by the
HTTP Content-Type header. Upon responding to a request for an object,
a metadata server MUST include a Content-Type header with the
MIME-type and version number of the object. HTTP requests sent to a
metadata server SHOULD include an Accept header with the MIME-type and
version of the expected object. Unless stated otherwise, the version
of each object defined by this document is version 1. For example:
"Content-Type: application/cdni.HostIndex.v1+json".</t>
<t>GenericMetadata objects include a "type" property which specifies
the MIME-type of the GenericMetadata value. This MIME-type should also
include a version. Any document which defines a new type of
GenericMetadata should specify the version number which it describes.
For example: "application/cdni.Location.v1+json".</t>
</section>
</section>
<section anchor="IANA" title="IANA Considerations">
<t>This document requests the registration of the prefix "application/cdni"
MIME Media Type under the IANA MIME Media Type registry
(http://www.iana.org/assignments/media-types/index.html).</t>
<section title="GenericMetadata Type Registry">
<t>CDNI Metadata is distributed as a list of GenericMetadata objects
which specify a type field and a type-specific value field, as
described in <xref target="generic-metadata"></xref>. In order to
prevent namespace collisions for GenericMetadata object types a new
IANA registry is requested for "CDNI GenericMetadata Types" namespace.
The namespace shall be split into two partitions: standard and vendor
defined.</t>
<t>The standard namespace partition is intended to contain mandatory
to implement capabilities and MUST conform to the "IETF Review" policy
as defined in <xref target="RFC5226"></xref>. The registry SHALL
contain the generic metadata type name, the RFC number of the
specification defining the metadata type, the version number of the
GenericMetadata set to which the standard capability applies, and
boolean values indicating whether or not the new type is considered
mandatory-to-enforce or safe-to-redistribute (as defined in <xref
target="generic-metadata"></xref>).</t>
<t>The following table defines the initial values for the standard
partition:</t>
<texttable>
<ttcol align="left">Type name</ttcol>
<ttcol align="left">Specification</ttcol>
<ttcol align="left">Version</ttcol>
<ttcol align="left">MTE</ttcol>
<ttcol align="left">STR</ttcol>
<c>SourceMetadata</c>
<c>RFCthis</c>
<c>1</c>
<c>true</c>
<c>true</c>
<c>LocationACL</c>
<c>RFCthis</c>
<c>1</c>
<c>true</c>
<c>true</c>
<c>TimeWindowACL</c>
<c>RFCthis</c>
<c>1</c>
<c>true</c>
<c>true</c>
<c>ProtocolACL</c>
<c>RFCthis</c>
<c>1</c>
<c>true</c>
<c>true</c>
<c>Auth</c>
<c>RFCthis</c>
<c>1</c>
<c>true</c>
<c>true</c>
<c>Cache</c>
<c>RFCthis</c>
<c>1</c>
<c>true</c>
<c>true</c>
<c>Grouping</c>
<c>RFCthis</c>
<c>1</c>
<c>true</c>
<c>true</c>
</texttable>
<t>The initial MI version number is set to 1. All of the initial
GenericMetadata types are considered mandatory to implement for
version 1. The version field should be incremented when new
GenericMetadata type sets are added to the registry.</t>
<t>The "vendor defined" namespace partition SHOULD conform to the
"Expert Review" policy as defined in <xref target="RFC5226"></xref>.
The expert review is intended to prevent namespace hoarding and to
prevent the definition of redundant GenericMetadata types. Vendors
defining new GenericMetadata types which conflict with existing
GenericMetadata types SHOULD follow the guidelines for the
"Specification Required" policy as defined in <xref
target="RFC5226"></xref>. The Version field in the registry MUST be
set to "-1" (negative one) for non-standard GenericMetadata types.</t>
<t>As with the initial GenericMetadata types defined in <xref
target="property-objects"></xref>, future GenericMetadata type
registrations SHOULD specify the information necessary for
constructing and decoding the GenericMetadata object. This information
SHOULD include the list of properties contained within the
GenericMetadata object, and for each property, the specification
should include a description, a type, and whether or not the given
property is mandatory to specify.</t>
<t>Any document which defines a new GenericMetadata type MUST:<list
style="numbers">
<t>Allocate a new type in the <xref target="IANA">GenericMetadata
Type Registry</xref>.</t>
<t>Define the set of properties associated with the new type.</t>
<t>For each property, define a name, description, type, and
whether or not the property is mandatory-to-specify.</t>
<t>Specify whether or not the new type is mandatory-to-enforce (vs
optional-to-enforce).</t>
<t>Describe the semantics of the new type including its purpose
and example of a use case to which it applies.</t>
</list></t>
<section title="GenericMetadata Sub-Registries">
<t>Some of the initial standard GenericMetadata objects contain
enumerated types which require registration (i.e., LocationACL
footprint types, ProtocolACL protocols, and Auth protocols). The
following sections define the initial values for these
GenericMetadata type sub-registries.</t>
<section anchor="FootprintReg" title="Footprint Sub-Registry">
<t>The "CDNI Metadata Footprint Types" namespace defines the valid
Footprint object type values used by the Footprint object in <xref
target="Footprint"></xref>. Additions to the Footprint type
namespace MUST conform to the "Expert Review" policy as defined in
<xref target="RFC5226"></xref>. The expert review should verify
that new type definitions do not duplicate existing type
definitions and prevent gratuitous additions to the namespace.</t>
<t>The following table defines the initial Footprint type
values:</t>
<texttable>
<ttcol align="left">Type name</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Specification</ttcol>
<c>IPv4</c>
<c>Single IPv4 address</c>
<c>RFCthis</c>
<c>IPv6</c>
<c>Single IPv6 address</c>
<c>RFCthis</c>
<c>IPv4Range</c>
<c>List of contiguous IPv4 addresses denoted by a start address
and an end address separated by a dash (e.g.,
192.168.0.1-192.168.0.20), inclusive.</c>
<c>RFCthis</c>
<c>IPv6Range</c>
<c>List of contiguous IPv6 addresses denoted by a start address
and an end address separated by a dash (e.g.,
fc80::0001-fc80::0014), inclusive.</c>
<c>RFCthis</c>
<c>IPv4CIDR</c>
<c>IPv4 address block using slash prefix length notation (e.g.,
192.168.0.16/28).</c>
<c>RFCthis</c>
<c>IPv6CIDR</c>
<c>IPv6 address block using slash prefix length notation (e.g.,
fc80::0010/124).</c>
<c>RFCthis</c>
<c>ASN</c>
<c>Autonomous System (AS) Number</c>
<c>RFCthis</c>
<c>CountryCode</c>
<c>ISO 3166-1 alpha-2 code</c>
<c>RFCthis</c>
<c>DVDRegion</c>
<c>DVD Region code (i.e., integer in the range 0-6).</c>
<c>RFCthis</c>
</texttable>
</section>
<section anchor="ProtocolReg" title="Protocol Sub-Registry">
<t>The "CDNI Metadata Protocols" namespace defines the valid
Protocol object values in <xref target="Protocol"></xref>, used by
the SourceMetadata and ProtocolACL objects. Additions to the
Protocol namespace MUST conform to the "Expert Review" policy as
defined in <xref target="RFC5226"></xref>. The expert review
should verify that new type definitions do not duplicate existing
type definitions and prevent gratuitous additions to the
namespace.</t>
<t>The following table defines the initial Protocol values:</t>
<texttable>
<ttcol align="left">Protocol</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Specification</ttcol>
<c>HTTP</c>
<c>Hypertext Transfer Protocol -- HTTP/1.1</c>
<c>RFC2616</c>
<c>HTTPS</c>
<c>HTTP Over TLS</c>
<c>RFC2818</c>
<c>RTSP</c>
<c>Real Time Streaming Protocol</c>
<c>RFC2326</c>
<c>RTMP</c>
<c>Real-Time Messaging Protocol</c>
<c>http://www.adobe.com/devnet/rtmp.html</c>
<c>FTP</c>
<c>FILE TRANSFER PROTOCOL</c>
<c>RFC959</c>
<c>SFTP</c>
<c>SSH File Transfer Protocol</c>
<c>N/A</c>
<c>SCP</c>
<c>Secure Copy</c>
<c>N/A</c>
<c>fasp</c>
<c>Aspera fast, adaptive, secure protocol</c>
<c>N/A</c>
</texttable>
</section>
<section anchor="AuthReg" title="Authentication Sub-Registry">
<t>The "CDNI Metadata Auth" namespace defines the valid Auth
object types used by the Auth object in <xref
target="Auth"></xref>. Additions to the Auth namespace MUST
conform to the "Expert Review" policy as defined in <xref
target="RFC5226"></xref>. The expert review should verify that new
type definitions do not duplicate existing type definitions and
prevent gratuitous additions to the namespace.</t>
<t>The following table defines the initial Auth type values:</t>
<texttable>
<ttcol align="left">Type name</ttcol>
<ttcol align="left">Description</ttcol>
<ttcol align="left">Specification</ttcol>
<c>credentials</c>
<c>Simple username and password authentication as defined by
<xref target="CredentialsAuth"></xref>.</c>
<c>RFCthis</c>
</texttable>
</section>
</section>
</section>
</section>
<section anchor="Security" title="Security Considerations">
<t>The CDNI Metadata Interface is expected to be secured as a function
of the transport protocol (e.g. <xref target="RFC2617">HTTP
authentication</xref>, <xref target="RFC2818">HTTPS</xref>, or
inter-domain IPSec).</t>
<t>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. The dCDN is expected
to authenticate the server to prevent this situation (e.g. by using
HTTPS and validating the server's certificate).</t>
<t>A malicious metadata client could request metadata for a piece of
content from an upstream CDN. The metadata information may then be used
to glean information regarding the uCDN or to contact an upstream origin
server. The uCDN is expected to authenticate client requests to prevent
this situation.</t>
</section>
<section anchor="Acknowledgements" title="Acknowledgements">
<t>The authors would like to thank David Ferguson and Francois le
Faucheur for their valuable comments and input to this document.</t>
</section>
</middle>
<back>
<references title="Normative References">
<?rfc include="reference.RFC.2119" ?>
<?rfc include="reference.RFC.2617" ?>
<?rfc include="reference.RFC.5226" ?>
<?rfc include="reference.RFC.4291" ?>
<?rfc include="reference.RFC.2818" ?>
<?rfc include="reference.RFC.5952" ?>
</references>
<references title="Informative References">
<?rfc include="reference.I-D.ietf-cdni-requirements"?>
<?rfc include="reference.I-D.ietf-cdni-framework"?>
<?rfc include="reference.RFC.6707" ?>
<?rfc include="reference.RFC.3986" ?>
<reference anchor="XML-BASE">
<front>
<title>XML Base (Second Edition) -
http://www.w3.org/TR/xmlbase/</title>
<author fullname="Jonathan" initials="J" role="editor"
surname="Marsh">
<organization></organization>
</author>
<author fullname="Richard" initials="R" role="editor"
surname="Tobin">
<organization></organization>
<address>
<postal>
<street></street>
<city></city>
<region></region>
<code></code>
<country></country>
</postal>
<phone></phone>
<facsimile></facsimile>
<email></email>
<uri></uri>
</address>
</author>
<date day="28" month="January" year="2009" />
</front>
</reference>
</references>
<section title="Relationship to the CDNI Requirements">
<t>Section 6 of <xref target="I-D.ietf-cdni-requirements"></xref> 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.</t>
<t>All metadata requirements are met either directly or indirectly by
the CDNI Metadata Interface described in this document, with the
clarifications or exceptions described in the following paragraphs.</t>
<t>Requirements related to pre-positioning of metadata are met by this
document on the assumption that other CDNI Interfaces are to be used by
the upstream CDN to trigger the pre-positioning of metadata by the
downstream CDN via the CDNI Metadata Interface. Triggering metadata
pre-positioning is beyond the scope of the CDNI Metadata interface.
However, the interface as described by this document supports pulling
metadata on-demand for the purpose of pre-positioning.</t>
<t>Requirement META-7 relating to modification of metadata by the
upstream CDN is met both by allowing timeouts on the cacheability of
metadata objects and by allowing other CDNI interfaces to initiate a
refetch or purge of metadata.</t>
<t>Requirement META-18 relating to surrogate cache behavior parameters
is supported via extensibility. However, the example parameters in
META-18 are not described in this document.</t>
</section>
</back>
</rfc>
| PAFTECH AB 2003-2026 | 2026-04-24 01:08:36 |