CDN Interconnect
MetadataVelocix (Alcatel-Lucent)3 Ely RoadMiltonCambridgeCB24 6AAUKben@velocix.comVelocix (Alcatel-Lucent)3 Ely RoadMiltonCambridgeCB24 6AAUKrmurray@velocix.comVelocix (Alcatel-Lucent)3 Ely RoadMiltonCambridgeCB24 6AAUKgwatson@velocix.comCisco Systems1414 Massachusetts AvenueBoxboroughMA01719USA+1 978 936 9307mcaulfie@cisco.comCisco Systems3625 Cisco WaySan Jose95134USA+1 408 526 5030kleung@cisco.comAzuki Systems, Inc.43 Nagog ParkActonMA01720USA+1 978-844-5100kevin.ma@azukisystems.comThe 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.The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119.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.The CDNI Metadata Interface is introduced by along with three other interfaces that may be
used to compose a CDNI solution (Control, Request Routing and Logging).
expands on the
information provided in and describes
each interface, and the relationships between them, in more detail. The
requirements for the CDNI metadata interface are specified in .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:Redirection Requests received over the CDNI Request Routing
protocol.Content Requests received directly from User Agents.Specifically this document proposes:A data structure for mapping content requests to CDNI Metadata
properties ().An initial set of CDNI Metadata properties ().A RESTful web service for the transfer of CDNI Metadata ().This document reuses the terminology defined in .Additionally, the following terms are used throughout this document
and are defined as follows:Object - a collection of propertiesProperty - a key and value pair where the key is a property
name and the value is the property value or an object.The proposed CDNI Metadata Interface was designed to achieve the
following objectives:Cacheability of CDNI metadata objectsDeterministic mapping from redirection and content requests to
CDNI metadata propertiesSupport for DNS redirection as well as application-specific
redirection (for example HTTP redirection)Minimal duplication of CDNI metadataLeverage existing protocolsCacheability 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.Deterministic mappings from content to metadata properties eliminates
ambiguity and ensures that policies are applied consistently by all
downstream CDNs.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.Minimal duplication of CDNI metadata provides space efficiency on
storage in the CDNs, on caches in the network, and across the network
between CDNs.Leveraging existing protocols avoids reinventing common mechanisms
such as data structure encoding (e.g. XML, JSON) and data transport
(e.g. HTTP).The CDNI Metadata Model describes a data structure for mapping
redirection requests and content requests to metadata properties.
Metadata properties describe how to acquire, authorize, 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 for
that Hostname. That default set of metadata properties can be overridden
by properties that apply to specific paths within a URI.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.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. introduces a high level
description of the HostIndex, HostMetadata and PathMetadata objects and
describes the relationships between those objects. 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. describes in
detail the specific CDNI Metadata objects and properties which may be
contained within a CDNI GenericMetadata object.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.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.As well as 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.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.The relationships between the HostIndex, HostMatch, HostMetadata,
PathMatch and PathMetadata objects are described in .The relationships in are summarised in below.Data ObjectObjects it ReferencesHostIndex0 or more HostMatch objects.HostMatch1 HostMetadata object.HostMetadata0 or more PathMatch objects. 0 or more GenericMetadata
objects.PathMatch1 PathMetadata object.PathMetadata0 or more PathMatch objects. 0 or more GenericMetadata
objects.The table below describes the HostIndex, HostMetadata and
PathMetadata objects in more detail.Data ObjectDescriptionHostIndexA HostIndex object lists HostMatch objectsHostMatchA 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.HostMetadataA 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.PathMatchA 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.PathMetadataA 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.GenericMetadataA GenericMetadata object contains individual CDNI Metadata
objects which define the specific policies and attributes needed to
properly deliver the associated content.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 opaque Metadata distribution, from the specifics
of any given property (e.g., property semantics, enforcement options,
etc.).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.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.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.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: the TimeWindowACL defined in the PathMetadata would override
the TimeWindowACL defined in the HostMetadatathe LocationACL defined in the HostMetadata would be inherited
for all User Agent requests for content under
"example.com/movies".The PathMetadata defined TimeWindowACL would override the
TimeWindowACL defined in the HostMetadata for all User Agent requests
for movies.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.Metadata types defined by this document are not hierarchical. provides the definitions of
each object type declared in . 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. 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.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.Each of the sub-sections below describe the structural objects
defined in .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.Property: hostsDescription: List of HostMatch objects, in priority
order.Type: List of HostMatch objectsMandatory-to-Specify: Yes.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.Property: hostDescription: String (hostname or IP address) to match
against the requested host.Type: StringMandatory-to-Specify: Yes.Property: host-metadataDescription: CDNI Metadata to apply when delivering
content that matches this host.Type: HostMetadataMandatory-to-Specify: Yes.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.Property: metadataDescription: List of host related metadata.Type: List of GenericMetadata objectsMandatory-to-Specify: Yes.Property: pathsDescription: Path specific rules. First match
applies.Type: List of PathMatch objectsMandatory-to-Specify: No.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.Property: path-patternDescription: Pattern to match against the requested path,
i.e. against the
path-absolute.Type: PatternMatchMandatory-to-Specify: Yes.Property: path-metadataDescription: CDNI Metadata to apply when delivering
content that matches this pattern.Type: PathMetadataMandatory-to-Specify: Yes.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.Property: metadataDescription: List of path related metadata.Type: List of GenericMetadata objectsMandatory-to-Specify: Yes.Property: pathsDescription: Path specific rules. First match
applies.Type: List of PathMatch objectsMandatory-to-Specify: No.A PatternMatch object contains the pattern string and flags that
describe the PathMatch expression.Property: patternDescription: 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 \?Type: StringMandatory-to-Specify: Yes.Property: case-sensitiveDescription: Flag indicating whether or not
case-sensitive matching should be used.Type: BooleanMandatory-to-Specify: No. Default is case-insensitive
match.Property: ignore-query-stringDescription: 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.Type: List of StringMandatory-to-Specify: No. Default is to include query
strings when matching.A GenericMetadata object is a abstraction for managing individual
CDNI Metadata properties in an opaque manner.Property: typeDescription: CDNI Metadata property object type.Type: StringMandatory-to-Specify: Yes.Property: valueDescription: CDNI Metadata property object.Type: matches the type property aboveMandatory-to-Specify: Yes.Property: mandatory-to-enforceDescription: Flag identifying whether or not the
enforcement of the property Metadata is required.Type: BooleanMandatory-to-Specify: No. Default is to treat metadata as
mandatory to enforce.Property: safe-to-redistributeDescription: Flag identifying whether or not the property
Metadata may be safely redistributed without
modification.Type: BooleanMandatory-to-Specify: No. Default is allow transparent
redistribution.The property objects defined below are intended to be used in the
GenericMetadata object value field as defined in . All of the objects defined below
are considered both mandatory to enforce and safe to redistribute.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.Property: sourcesDescription: Sources from which the dCDN can acquire
content, listed in priority order.Type: List of Source objectsMandatory-to-Specify: No. Default is to use static
configuration, out of band of the metadata interface.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.Property: authDescription: Authentication method to use when
requesting content from this source.Type: AuthMandatory-to-Specify: No. Default is no authentication
is required.Property: endpointsDescription: Origins from which the dCDN can acquire
content.Type: List of EndPoint objectsMandatory-to-Specify: Yes.Property: protocolDescription: Network retrieval protocol to use when
requesting content from this source.Type: ProtocolMandatory-to-Specify: Yes.LocationACL Metadata defines location-based restrictions.Property: locationsDescription: Access control list which applies
restrictions to delivery based on client location.Type: List of LocationRule objectsMandatory-to-Specify: No. Default is allow all
locations.A LocationRule contains or references a list of Location
objects and the corresponding action.Property: footprintsDescription: List of footprints to which the rule
applies.Type: List of Footprint objectsMandatory-to-Specify: Yes.Property: actionDescription: Defines whether the rule specifies
locations to allow or deny.Type: Enumeration [allow|deny]Mandatory-to-Specify: No. Default is deny.A Footprint object describes the footprint to which a
LocationRule may be applied by, e.g. an IPv4 address range or a
geographic location.Property: typeDescription: Registered footprint type (see ).Type: StringMandatory-to-Specify: Yes.Property: valueDescription: Footprint object conforming to the
specification associated with the registered footprint
type.Type: StringMandatory-to-Specify: Yes.TimeWindowACL Metadata defines time-based restrictions.Property: timesDescription: Access control list which applies
restrictions to delivery based on request time.Type: List of TimeWindowRule objectsMandatory-to-Specify: No. Default is allow all time
windows.A TimeWindowRule contains or references a list of TimeWindow
objects and the corresponding action.Property: timesDescription: List of time windows to which the rule
applies.Type: List of TimeWindow objectsMandatory-to-Specify: Yes.Property: actionDescription: Defines whether the rule specifies time
windows to allow or deny.Type: Enumeration [allow|deny]Mandatory-to-Specify: No. Default is deny.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.Property: startDescription: The start time of the window.Type: TimeMandatory-to-Specify: Yes.Property: endDescription: The end time of the window.Type: TimeMandatory-to-Specify: Yes.ProtocolACL Metadata defines delivery protocol restrictions.Property: protocolsDescription: Access control list which applies
restrictions to delivery based on delivery protocol.Type: List of ProtocolRule objectsMandatory-to-Specify: No. Default is allow all
protocols.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.Property: protocolsDescription: List of protocols to which the rule
applies.Type: List of protocol objectsMandatory-to-Specify: Yes.Property: actionDescription: Defines whether the rule specifies
protocols to allow or deny.Type: Enumeration [allow|deny]+Mandatory-to-Specify: No. Default is allow all
protocols.Property: directionDescription: Defines whether the ProtocolRule specifies
protocols for acquisition or delivery.Type: Enumeration [acquisition|delivery]Mandatory-to-Specify: No. Default is to apply the rule
to both acquisition and delivery.Authorization Metadata define content authorization methods.Property: methodsDescription: Options for authenticating content requests.
All options in the list are equally valid.Type: List of Auth objectsMandatory-to-Specify: No. Default is no authorization
required.An Auth object defines authentication and authorization methods
to be used during content delivery and content acquisition.Property: typeDescription: Registered Auth type (see ).Type: StringMandatory-to-Specify: Yes.Property: valueDescription: Auth object conforming to the specification
associated with the registered Auth type.Type: StringMandatory-to-Specify: Yes.Credentials Auth is a type of Auth object with type
"credentials" (see ). The
CredentialsAuth object contains the following properties:Property: usernameDescription: Identification of user.Type: StringMandatory-to-Specify: Yes.Property: passwordDescription: Password for user identified by username
property.Type: StringMandatory-to-Specify: Yes.A Cache object describes the cache control parameters to be
applied to the content by intermediate caches.Property: ignore-query-stringDescription: 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.Type: List of StringMandatory-to-Specify: No. Default is to consider query
string parameters when comparing URIs or to rely on other
properties of the Cache object.A Grouping object identifies a large group of content to which
this content belongs.Property: ccidDescription: Content Collection identifier for an
application-specific purpose such as logging.Type: StringMandatory-to-Specify: No. Default is an empty string.Property: sidDescription: Session identifier for an
application-specific purpose such as logging.Type: StringMandatory-to-Specify: No. Default is an empty string.This section describes the simpler data types that are used for
properties of CDNI Metadata objects.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, its rel property is set to the name of the
property it is replacing, and its type property is set to the type
of the object it is replacing.Property: hrefDescription: The URI of the of the addressable object
being referenced.Type: URIMandatory-to-Specify: YesProperty: relDescription: The Relationship between the referring
object and the object it is referencing.Type: StringMandatory-to-Specify: YesProperty: typeDescription: The type of the object being referenced.Type: StringMandatory-to-Specify: YesProtocol objects are used to specify registered protocols for
content acquisition or delivery (see ).Type: StringMandatory-to-Specify: YesA hostname (with optional port) or an IP address (with optional
port).Note: All implementations MUST support IPv4 addresses encoded as
specified by the 'IPv4address' rule in Section 3.2.2 of and MUST support all IPv6 address formats
specified in . Server implementations
SHOULD use IPv6 address formats specified in .A URI as specified in .A time value expressed in seconds since Unix epoch in the UTC
timezone.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.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
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.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.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.This section specifies an interface to enable a Downstream CDN to
retrieve CDNI Metadata objects from an Upstream CDN.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).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
through ).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.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.The CDNI Metadata interface uses HTTP as the underlying protocol
transport.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.The corresponding HTTP Response returns the status of the operation
in the HTTP Status Code and returns the current representation of the
resource (if appropriate) in the Response Body. HTTP Responses from
servers implementing the CDNI Metadata interface that contain a
response body SHOULD include an ETag to enable validation of cached
versions of returned resources.The CDNI Metadata interface specified in this document is a
read-only interface. Therefore support for other HTTP methods such as
PUT, POST and DELETE etc. is not specified. Server implementations of
this interface SHOULD reject all methods other than GET and HEAD.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.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.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.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.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.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.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.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.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.Object are resources that may be:Addressable, where the object is a resource that may be
retrieved or referenced via its own URI.Embedded, where the object is contained (or inlined) within a
property of an addressable object.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.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.
lists a few examples of the MIME Media Type for each object
(resource) that is retrievable through the CDNI Metadata
interface.Data ObjectMIME Media TypeHostIndexapplication/cdni.HostIndexHostMatchapplication/cdni.HostMatchHostMetadataapplication/cdni.HostMetadataPathMatchapplication/cdni.PathMatchPathMetadataapplication/cdni.PathMetadataSee http://www.iana.org/assignments/media-types/index.html for
reference.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.The keys of the dictionary are the names of the properties
associated with the object and are therefore dependent on the
specific object being encoded (i.e. dependent on the MIME Media Type
of the returned resource). Likewise, the values associated with each
key are dependent on the specific object being encoded (i.e.
dependent on the MIME Media Type of the returned resource).Dictionary keys in JSON are case sensitive and therefore by
convention any dictionary key defined by this document (for example
the names of CDNI Metadata object properties) MUST be represented in
lowercase.In addition to the properties specific to each object type, the
keys defined below may be present in any object.Key: baseDescription: Provides a prefix for any relative URLs in
the object. This is similar to the XML base tag . If absent, all URLs in the
remainder of the document must be absolute URLs.Type: URIMandatory: NoKey: linksDescription: 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.Type: List of Link objectsMandatory: YesA downstream CDN may request the HostIndex and receive the
following object of type "application/cdni.HostIndex+json":If the incoming request has a Host header with
"video.example.com" then the downstream CDN would fetch from the
next metadata object from "http://metadata.ucdn.example.com/video"
expecting a MIME type of "application/cdni.HostMetadata+json":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":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":The set of property Metadata may be extended with proprietary
and/or custom property Metadata. The GenericMetadata object defined in
allows any Metadata property
to be included in either the HostMetadata or PathMetadata lists.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.Any document which defines a new GenericMetadata object MUST:Allocate a new type in the GenericMetadata
Type Registry.Define the set of properties associated with the new type.For each property, define a name, description, type, and
whether or not the property is mandatory-to-specify.Specify whether or not the new type is mandatory-to-enforce (vs
optional-to-enforce).Describe the semantics of the new type including its purpose
and example of a use case to which it applies.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.Any standard which defines a new GenericMetadata Type MUST also
define whether or not the new metadata is mandatory-to-enforce.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.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.As described in ,
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.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.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 verison 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 verison
of each object defined by this document is version 1. For example:
"Content-Type: application/cdni.HostIndex.v1":.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".This document requests the registration of the "application/cdni"
MIME Media Type under the IANA MIME Media Type registry
(http://www.iana.org/assignments/media-types/index.html).CDNI Metadata is distributed as a list of GenericMetadata objects
which specify a type field and a type-specific value field, as
described in . 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.The standard namespace partition is intended to contain mandatory
to implement capabilities and MUST conform to the "IETF Review" policy
as defined in . 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 ).The following table defines the initial values for the standard
partition:Type nameSpecificationVersionMTESTRSourceMetadataRFCthis1truetrueLocationACLRFCthis1truetrueTimeWindowACLRFCthis1truetrueProtocolACLRFCthis1truetrueAuthRFCthis1truetrueCacheRFCthis1truetrueGroupingRFCthis1truetrueThe 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.The "vendor defined" namespace partition SHOULD conform to the
"Expert Review" policy as defined in .
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 . The Version field in the registry MUST be
set to "-1" (negative one) for non-standard GenericMetadata types.As with the initial GenericMetadata types defined in , 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.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.The "CDNI Metadata Footprint Types" namespace defines the valid
Footprint object type values used by the Footprint object in . Additions to the Footprint type
namespace MUST conform to the "Expert Review" policy as defined in
. The expert review should verify
that new type definitions do not duplicate existing type
definitions and prevent gratuitous additions to the namespace.The following table defines the initial Footprint type
values:Type nameDescriptionSpecificationIPv4Single IPv4 addressRFCthisIPv6Single IPv6 addressRFCthisIPv4RangeList 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.RFCthisIPv6RangeList of contiguous IPv6 addresses denoted by a start address
and an end address separated by a dash (e.g.,
fc80::0001-fc80::0014), inclusive.RFCthisIPv4CIDRIPv4 address block using slash prefix length notation (e.g.,
192.168.0.16/28).RFCthisIPv6CIDRIPv6 address block using slash prefix length notation (e.g.,
fc80::0010/124).RFCthisASNAutonomous System (AS) NumberRFCthisCountryCodeISO 3166-1 alpha-2 codeRFCthisDVDRegionDVD Region code (i.e., integer in the range 0-6).RFCthisThe "CDNI Metadata Protocols" namespace defines the valid
Protocol object values in , used by
the SourceMetadata and ProtocolACL objects. Additions to the
Protocol namespace MUST conform to the "Expert Review" policy as
defined in . The expert review
should verify that new type definitions do not duplicate existing
type definitions and prevent gratuitous additions to the
namespace.The following table defines the initial Protocol values:ProtocolDescriptionSpecificationHTTPHypertext Transfer Protocol -- HTTP/1.1RFC2616HTTPSHTTP Over TLSRFC2818RTSPReal Time Streaming ProtocolRFC2326RTMPReal-Time Messaging Protocolhttp://www.adobe.com/devnet/rtmp.htmlFTPFILE TRANSFER PROTOCOLRFC959SFTPSSH File Transfer ProtocolN/ASCPSecure CopyN/AfaspAspera fast, adaptive, secure protocolN/AThe "CDNI Metadata Auth" namespace defines the valid Auth
object types used by the Auth object in . Additions to the Auth namespace MUST
conform to the "Expert Review" policy as defined in . The expert review should verify that new
type definitions do not duplicate existing type definitions and
prevent gratuitous additions to the namespace.The following table defines the initial Auth type values:Type nameDescriptionSpecificationcredentialsSimple username and password authentication as defined by
.RFCthisThe CDNI Metadata Interface is expected to be secured as a function
of the transport protocol (e.g. HTTP
authentication, HTTPS, or
inter-domain IPSec).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).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.The authors would like to thank David Ferguson and Francois le
Faucheur for their valuable comments and input to this document.XML Base (Second Edition) -
http://www.w3.org/TR/xmlbase/Section 6 of 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.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.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.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.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.