draft-ietf-cdni-metadata-01.txt   draft-ietf-cdni-metadata-02.txt 
Network Working Group B. Niven-Jenkins Network Working Group B. Niven-Jenkins
Internet-Draft R. Murray Internet-Draft R. Murray
Intended status: Standards Track G. Watson Intended status: Standards Track G. Watson
Expires: August 29, 2013 Velocix (Alcatel-Lucent) Expires: January 16, 2014 Velocix (Alcatel-Lucent)
M. Caulfield M. Caulfield
K. Leung K. Leung
Cisco Systems Cisco Systems
K. Ma K. Ma
Azuki Systems, Inc. Azuki Systems, Inc.
February 25, 2013 July 15, 2013
CDN Interconnect Metadata CDN Interconnect Metadata
draft-ietf-cdni-metadata-01 draft-ietf-cdni-metadata-02
Abstract Abstract
The CDNI Metadata Interface enables interconnected CDNs to exchange The CDNI Metadata Interface enables interconnected CDNs to exchange
content distribution metadata in order to enable content acquisition content distribution metadata in order to enable content acquisition
and delivery. The CDNI metadata associated with a piece of content and delivery. The CDNI metadata associated with a piece of content
provides a downstream CDN with sufficient information for the provides a downstream CDN with sufficient information for the
downstream CDN to service content requests on behalf of an upstream downstream CDN to service content requests on behalf of an upstream
CDN. This document describes both the core set of CDNI metadata and CDN. This document describes both the core set of CDNI metadata and
the protocol for exchanging that metadata. the protocol for exchanging that metadata.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
document are to be interpreted as described in RFC 2119 [RFC2119]. document are to be interpreted as described in RFC 2119 [RFC2119].
Status of this Memo Status of This Memo
This Internet-Draft is submitted in full conformance with the This Internet-Draft is submitted in full conformance with the
provisions of BCP 78 and BCP 79. provisions of BCP 78 and BCP 79.
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on August 29, 2013. This Internet-Draft will expire on January 16, 2014.
Copyright Notice Copyright Notice
Copyright (c) 2013 IETF Trust and the persons identified as the Copyright (c) 2013 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . . 4 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4 2. Design Principles . . . . . . . . . . . . . . . . . . . . . . 4
3. CDNI Metadata Data Model . . . . . . . . . . . . . . . . . . . 5 3. CDNI Metadata Data Model . . . . . . . . . . . . . . . . . . 5
3.1. HostIndex, HostMetadata & PathMetadata objects . . . . . . 6 3.1. HostIndex, HostMetadata & PathMetadata objects . . . . . 6
3.2. Generic CDNI Metadata Object Properties . . . . . . . . . 9 3.2. Generic CDNI Metadata Object Properties . . . . . . . . . 9
3.3. Metadata Inheritance and Override . . . . . . . . . . . . 10 3.3. Metadata Inheritance and Override . . . . . . . . . . . . 10
3.4. Metadata Naming . . . . . . . . . . . . . . . . . . . . . 11 3.4. Metadata Naming . . . . . . . . . . . . . . . . . . . . . 10
4. Encoding-Independent CDNI Metadata Object Descriptions . . . . 11 4. Encoding-Independent CDNI Metadata Object Descriptions . . . 11
4.1. CDNI Metadata Structural Object Descriptions . . . . . . . 12 4.1. CDNI Metadata Structural Object Descriptions . . . . . . 12
4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 12 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . . 12 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 13
4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 13
4.1.5. PathMetadata . . . . . . . . . . . . . . . . . . . . . 13 4.1.5. PathMetadata . . . . . . . . . . . . . . . . . . . . 14
4.1.6. PatternMatch . . . . . . . . . . . . . . . . . . . . . 14 4.1.6. PatternMatch . . . . . . . . . . . . . . . . . . . . 14
4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 14 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 15
4.2. CDNI Metadata Property Object Descriptions . . . . . . . . 15 4.2. CDNI Metadata Property Object Descriptions . . . . . . . 16
4.2.1. Source Metadata . . . . . . . . . . . . . . . . . . . 15 4.2.1. Source Metadata . . . . . . . . . . . . . . . . . . . 16
4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . . 15 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . . 15 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 17
4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . . 16 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 17
4.2.2.2. Location . . . . . . . . . . . . . . . . . . . . . 16 4.2.2.2. Location . . . . . . . . . . . . . . . . . . . . 17
4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . . 16 4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . 18
4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . . 17 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 18
4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . . 17 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 19
4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . . 17 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 19
4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . . 17 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 19
4.2.5. Authorization Metadata . . . . . . . . . . . . . . . . 18 4.2.5. Authorization Metadata . . . . . . . . . . . . . . . 20
4.2.6. Auth . . . . . . . . . . . . . . . . . . . . . . . . . 18 4.2.6. Auth . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.7. Cache . . . . . . . . . . . . . . . . . . . . . . . . 19 4.2.7. Cache . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.8. Logging . . . . . . . . . . . . . . . . . . . . . . . 19 4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 21
4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 19 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 22
4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . . 19 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 22
4.3.3. RedirectionMethod . . . . . . . . . . . . . . . . . . 20 4.3.3. RedirectionMethod . . . . . . . . . . . . . . . . . . 23
4.3.4. Endpoint . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.4. Endpoint . . . . . . . . . . . . . . . . . . . . . . 23
4.3.5. IPRange . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.5. IPRange . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.6. URI . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.6. URI . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.7. Time . . . . . . . . . . . . . . . . . . . . . . . . . 20 4.3.7. Time . . . . . . . . . . . . . . . . . . . . . . . . 23
5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . . 21 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 24
5.1. Protocol ACL Capabilities . . . . . . . . . . . . . . . . 21 5.1. Protocol ACL Capabilities . . . . . . . . . . . . . . . . 24
5.2. Authorization Metadata Capabilities . . . . . . . . . . . 22 5.2. Authorization Metadata Capabilities . . . . . . . . . . . 25
5.3. Host Metadata Capabilities . . . . . . . . . . . . . . . . 22 5.3. Host Metadata Capabilities . . . . . . . . . . . . . . . 25
6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 22 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 25
6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 23 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 26
6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . . 23 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 27
6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 24 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 28
6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . . 25 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . . 25 6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 28
6.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . . 26 6.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . 29
6.4.2.1. JSON Example . . . . . . . . . . . . . . . . . . . 26 6.4.2.1. JSON Example . . . . . . . . . . . . . . . . . . 30
6.4.3. XML Encoding of Objects . . . . . . . . . . . . . . . 30 6.4.3. XML Encoding of Objects . . . . . . . . . . . . . . . 33
6.4.3.1. XML Example . . . . . . . . . . . . . . . . . . . 30 6.4.3.1. XML Example . . . . . . . . . . . . . . . . . . . 34
6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 33 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 36
6.5.1. Metadata Enforcement . . . . . . . . . . . . . . . . . 33 6.5.1. Metadata Enforcement . . . . . . . . . . . . . . . . 36
6.5.2. Metadata Override . . . . . . . . . . . . . . . . . . 34 6.5.2. Metadata Override . . . . . . . . . . . . . . . . . . 37
6.6. Versioning . . . . . . . . . . . . . . . . . . . . . . . . 34 6.6. Versioning . . . . . . . . . . . . . . . . . . . . . . . 37
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38
8. Security Considerations . . . . . . . . . . . . . . . . . . . 35 8. Security Considerations . . . . . . . . . . . . . . . . . . . 38
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 35 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38
10. References . . . . . . . . . . . . . . . . . . . . . . . . . . 35 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . . 35 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . . 36 10.2. Informative References . . . . . . . . . . . . . . . . . 39
Appendix A. Relationship to the CDNI Requirements . . . . . . . . 36 Appendix A. Relationship to the CDNI Requirements . . . . . . . 40
Appendix B. Metadata Rewriting . . . . . . . . . . . . . . . . . 37 Appendix B. Metadata Rewriting . . . . . . . . . . . . . . . . . 40
B.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 38 B.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 38 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
CDNI enables a downstream CDN to service content requests on behalf CDNI enables a downstream CDN to service content requests on behalf
of an upstream CDN. The CDNI metadata associated with a piece of of an upstream CDN. The CDNI metadata associated with a piece of
content (or with a set of contents) provides a downstream CDN with content (or with a set of contents) provides a downstream CDN with
sufficient information for servicing content requests on behalf of an sufficient information for servicing content requests on behalf of an
upstream CDN in accordance with the policies defined by the upstream upstream CDN in accordance with the policies defined by the upstream
CDN. CDN.
skipping to change at page 5, line 32 skipping to change at page 5, line 31
Support for both HTTP and DNS redirection ensures that the CDNI Support for both HTTP and DNS redirection ensures that the CDNI
Metadata Interface can be used for HTTP and DNS redirection and also Metadata Interface can be used for HTTP and DNS redirection and also
meets the same design principles for both HTTP and DNS based meets the same design principles for both HTTP and DNS based
redirection schemes. redirection schemes.
Minimal duplication of CDNI metadata provides space efficiency on Minimal duplication of CDNI metadata provides space efficiency on
storage in the CDNs, on caches in the network, and across the network storage in the CDNs, on caches in the network, and across the network
between CDNs. between CDNs.
Leveraging existing protocols avoids reinventing common mechanisms Leveraging existing protocols avoids reinventing common mechanisms
such as data structure encoding (e.g. XML, JSON) and data transport such as data structure encoding (e.g. XML, JSON) and data transport
(e.g. HTTP). (e.g. HTTP).
3. CDNI Metadata Data Model 3. CDNI Metadata Data Model
The CDNI Metadata Model describes a data structure for mapping The CDNI Metadata Model describes a data structure for mapping
redirection requests and content requests to metadata properties. redirection requests and content requests to metadata properties.
Metadata properties describe how to acquire, authorize, and deliver Metadata properties describe how to acquire, authorize, and deliver
content from a downstream CDN. The data model relies on the content from a downstream CDN. The data model relies on the
assumption that these metadata properties may be aggregated based on assumption that these metadata properties may be aggregated based on
the hostname of the content and subsequently on the resource path of the hostname of the content and subsequently on the resource path of
the content. The data model associates a set of CDNI Metadata the content. The data model associates a set of CDNI Metadata
skipping to change at page 7, line 25 skipping to change at page 7, line 23
pattern defined in that PathMatch object. pattern defined in that PathMatch object.
For the purposes of retrieving CDNI Metadata all other required CDNI For the purposes of retrieving CDNI Metadata all other required CDNI
Metadata objects and their properties are discoverable from the Metadata objects and their properties are discoverable from the
appropriate HostMetadata, PathMatch and PathMetadata objects for the appropriate HostMetadata, PathMatch and PathMetadata objects for the
requested content. requested content.
The relationships between the HostIndex, HostMatch, HostMetadata, The relationships between the HostIndex, HostMatch, HostMetadata,
PathMatch and PathMetadata objects are described in Figure 1. PathMatch and PathMetadata objects are described in Figure 1.
+---------+ +---------+ +------------+ +---------+ +---------+ +------------+
|HostIndex+-(*)->|HostMatch|-(1)->|HostMetadata+-------(*)------+ |HostIndex+-(*)->|HostMatch|-(1)->|HostMetadata+-------(*)------+
+---------+ +---------+ +------+-----+ | +---------+ +---------+ +------+-----+ |
| | | |
(*) | (*) |
| | | |
(1) One and only one +---------+ ************************** --> References V V
(*) Zero or more +--->|PathMatch| *Generic Metadata Objects* (1) One and only one +---------+ **************************
| +---------+ ************************** (*) Zero or more +--->|PathMatch| *Generic Metadata Objects*
| | ^ | +---------+ **************************
(*) (1) | | | ^
| | | (*) (1) |
| V | | | |
| +------------+ | | V |
+--|PathMetadata+-------(*)------+ | +------------+ |
+------------+ +--|PathMetadata+-------(*)------+
+------------+
Key: ----> = References Key: ----> = References
Figure 1: Relationships between the HostIndex, HostMetadata & Figure 1: Relationships between the HostIndex, HostMetadata &
PathMetadata CDNI Metadata Objects PathMetadata CDNI Metadata Objects
The relationships in Figure 1 are summarised in Table 1 below. The relationships in Figure 1 are summarised in Table 1 below.
+--------------+----------------------------------------------------+ +--------------------+----------------------------------------------+
| Data Object | Objects it References | | Data Object | Objects it References |
+--------------+----------------------------------------------------+ +--------------------+----------------------------------------------+
| HostIndex | 0 or more HostMatch objects. | | HostIndex | 0 or more HostMatch objects. |
| HostMatch | 1 HostMetadata object. | | HostMatch | 1 HostMetadata object. |
| HostMetadata | 0 or more PathMatch objects. 0 or more | | HostMetadata | 0 or more PathMatch objects. 0 or more |
| | GenericMetadata objects. | | | GenericMetadata objects. |
| PathMatch | 1 PathMetadata object. | | PathMatch | 1 PathMetadata object. |
| PathMetadata | 0 or more PathMatch objects. 0 or more | | PathMetadata | 0 or more PathMatch objects. 0 or more |
| | GenericMetadata objects. | | | GenericMetadata objects. |
+--------------+----------------------------------------------------+ +--------------------+----------------------------------------------+
Table 1: Relationships between CDNI Metadata Objects Table 1: Relationships between CDNI Metadata Objects
The table below describes the HostIndex, HostMetadata and The table below describes the HostIndex, HostMetadata and
PathMetadata objects in more detail. PathMetadata objects in more detail.
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| Data Object | Description | | Data Object | Description |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
| HostIndex | A HostIndex object lists HostMatch objects | | HostIndex | A HostIndex object lists HostMatch objects |
| HostMatch | A HostMatch object defines a hostname to match | | HostMatch | A HostMatch object defines a hostname to match |
| | against a requested host, and contains or | | | against a requested host, and contains or |
| | references a HostMetadata object which contains | | | references a HostMetadata object which contains |
| | CDNI Metadata objects to be applied when a | | | CDNI Metadata objects to be applied when a |
| | request matches against the hostname. For | | | request matches against the hostname. For |
| | example, if "example.com" is a content | | | example, if "example.com" is a content |
| | provider, a HostMatch object may include an | | | provider, a HostMatch object may include an |
| | entry for "example.com" with the URI of the | | | entry for "example.com" with the URI of the |
| | associated HostMetadata object. | | | associated HostMetadata object. |
| HostMetadata | A HostMetadata object contains (or references) | | HostMetadata | A HostMetadata object contains (or references) |
| | the default CDNI Metadata objects for content | | | the default CDNI Metadata objects for content |
| | served from that host, i.e. the CDNI Metadata | | | served from that host, i.e. the CDNI Metadata |
| | objects for content requests that do not match | | | objects for content requests that do not match |
| | any of the PathMatch objects contained or | | | any of the PathMatch objects contained or |
| | referenced by that HostMetadata object. For | | | referenced by that HostMetadata object. For |
| | example, a HostMetadata object may describe the | | | example, a HostMetadata object may describe the |
| | metadata properties which apply to | | | metadata properties which apply to |
| | "example.com" and may contain PathMatches for | | | "example.com" and may contain PathMatches for |
| | "example.com/movies/*" and | | | "example.com/movies/*" and |
| | "example.com/music/*" which reference | | | "example.com/music/*" which reference |
| | corresponding PathMetadata objects that contain | | | corresponding PathMetadata objects that contain |
| | the CDNI Metadata objects for those more | | | the CDNI Metadata objects for those more |
| | specific URI paths. | | | specific URI paths. |
| PathMatch | A PathMatch object defines a pattern to match | | PathMatch | A PathMatch object defines a pattern to match |
| | against the requested URI path, and contains or | | | against the requested URI path, and contains or |
| | references a PathMetadata object which contains | | | references a PathMetadata object which contains |
| | (or references) the CDNI Metadata objects to be | | | (or references) the CDNI Metadata objects to be |
| | applied when a content request matches against | | | applied when a content request matches against |
| | the defined URI path pattern. | | | the defined URI path pattern. |
| PathMetadata | A PathMetadata object contains the CDNI | | PathMetadata | A PathMetadata object contains the CDNI |
| | GenericMetadata objects for content served with | | | GenericMetadata objects for content served with |
| | the associated URI path (defined in a PathMatch | | | the associated URI path (defined in a PathMatch |
| | object). A PathMetadata object may also | | | object). A PathMetadata object may also contain |
| | contain PathMatch objects in order to | | | PathMatch objects in order to recursively |
| | recursively define more specific URI paths that | | | define more specific URI paths that require |
| | require different (e.g. more specific) CDNI | | | different (e.g. more specific) CDNI Metadata to |
| | Metadata to this one. For example, the | | | this one. For example, the PathMetadata object |
| | PathMetadata object which applies to | | | which applies to "example.com/movies/*" may |
| | "example.com/movies/*" may describe CDNI | | | describe CDNI Metadata which apply to that |
| | Metadata which apply to that resource path and | | | resource path and may contain a PathMatch |
| | may contain a PathMatch object for | | | object for "example.com/movies/hd/*" which |
| | "example.com/movies/hd/*" which would reference | | | would reference the corresponding PathMetadata |
| | the corresponding PathMetadata object for the | | | object for the "example.com/movies/hd/" path |
| | "example.com/movies/hd/" path prefix. | | | prefix. |
| GenericMetadata | A GenericMetadata object contains individual | | GenericMetadata | A GenericMetadata object contains individual |
| | CDNI Metadata objects which define the specific | | | CDNI Metadata objects which define the specific |
| | policies and attributes needed to properly | | | policies and attributes needed to properly |
| | deliver the associated content. | | | deliver the associated content. |
+-----------------+-------------------------------------------------+ +-----------------+-------------------------------------------------+
Table 2: HostIndex, HostMetadata and PathMetadata CDNI Metadata Table 2: HostIndex, HostMetadata and PathMetadata CDNI Metadata
Objects Objects
3.2. Generic CDNI Metadata Object Properties 3.2. Generic CDNI Metadata Object Properties
skipping to change at page 16, line 45 skipping to change at page 18, line 25
[Ed: Location as specified above only supports the Class 1a names [Ed: Location as specified above only supports the Class 1a names
described in [I-D.jenkins-cdni-names]. Need to add support for Class described in [I-D.jenkins-cdni-names]. Need to add support for Class
1b names to a later version.] 1b names to a later version.]
4.2.3. TimeWindowACL Metadata 4.2.3. TimeWindowACL Metadata
TimeWindowACL Metadata defines time-based restrictions. TimeWindowACL Metadata defines time-based restrictions.
Property: times Property: times
Description: Access control list which applies restrictions to Description: Access control list which applies restrictions to
delivery based on request time. delivery based on request time.
Type: List of TimeWindowRule objects Type: List of TimeWindowRule objects
Mandatory-to-Specify: No. Default is allow all time windows. Mandatory-to-Specify: No. Default is allow all time windows.
4.2.3.1. TimeWindowRule 4.2.3.1. TimeWindowRule
A TimeWindowRule contains or references a list of TimeWindow objects A TimeWindowRule contains or references a list of TimeWindow objects
and the corresponding action. and the corresponding action.
Property: times Property: times
Description: List of time windows to which the rule applies. Description: List of time windows to which the rule applies.
Type: List of TimeWindow objects Type: List of TimeWindow objects
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: action Property: action
Description: Defines whether the rule specifies time windows to Description: Defines whether the rule specifies time windows to
allow or deny. allow or deny.
Type: Enumeration [allow|deny] Type: Enumeration [allow|deny]
Mandatory-to-Specify: No. Default is deny. Mandatory-to-Specify: No. Default is deny.
4.2.3.2. TimeWindow 4.2.3.2. TimeWindow
A TimeWindow object describes a time range which may be applied by an 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 ACLRule, e.g. Start 09:00AM 01/01/2000 UTC End 17:00PM 01/01/2000
UTC. UTC.
Property: start Property: start
Description: The start time of the window. Description: The start time of the window.
Type: Time Type: Time
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: end Property: end
Description: The end time of the window. Description: The end time of the window.
Type: Time Type: Time
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
4.2.4. ProtocolACL Metadata 4.2.4. ProtocolACL Metadata
ProtocolACL Metadata defines delivery protocol restrictions. ProtocolACL Metadata defines delivery protocol restrictions.
Property: protocols Property: protocols
Description: Access control list which applies restrictions to Description: Access control list which applies restrictions to
delivery based on delivery protocol. delivery based on delivery protocol.
Type: List of ProtocolRule objects Type: List of ProtocolRule objects
Mandatory-to-Specify: No. Default is allow all protocols. Mandatory-to-Specify: No. Default is allow all protocols.
4.2.4.1. ProtocolRule 4.2.4.1. ProtocolRule
A ProtocolRule contains or references a list of Protocol objects. A ProtocolRule contains or references a list of Protocol objects.
ProtocolRule objects are used to construct a ProtocolACL to apply ProtocolRule objects are used to construct a ProtocolACL to apply
restrictions to content acquisition or delivery. restrictions to content acquisition or delivery.
Property: protocols Property: protocols
Description: List of protocols to which the rule applies. Description: List of protocols to which the rule applies.
Type: List of protocol objects Type: List of protocol objects
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: action Property: action
Description: Defines whether the rule specifies protocols to Description: Defines whether the rule specifies protocols to
allow or deny. allow or deny.
Type: Enumeration [allow|deny]
Type: Enumeration [allow|deny]+
Mandatory-to-Specify: No. Default is allow all protocols. Mandatory-to-Specify: No. Default is allow all protocols.
Property: direction Property: direction
Description: Defines whether the ProtocolRule specifies Description: Defines whether the ProtocolRule specifies
protocols for acquisition or delivery. protocols for acquisition or delivery.
Type: Enumeration [acquisition|delivery] Type: Enumeration [acquisition|delivery]
Mandatory-to-Specify: No. Default is to apply the rule to both Mandatory-to-Specify: No. Default is to apply the rule to both
acquisition and delivery. acquisition and delivery.
4.2.5. Authorization Metadata 4.2.5. Authorization Metadata
Authorization Metadata define content authorization methods. Authorization Metadata define content authorization methods.
Property: methods Property: methods
Description: Options for authenticating content requests. All Description: Options for authenticating content requests. All
options in the list are equally valid. options in the list are equally valid.
Type: List of Auth objects Type: List of Auth objects
Mandatory-to-Specify: No. Default is no authorization Mandatory-to-Specify: No. Default is no authorization
required. required.
4.2.6. Auth 4.2.6. Auth
An Auth object defines authentication and authorization methods to be An Auth object defines authentication and authorization methods to be
used during content delivery and content acquisition, e.g. methods used during content delivery and content acquisition, e.g. methods
such as tokenization and URL Signing. such as tokenization and URL Signing.
[Ed. Need to synchronize authentication configuration with CDNI URL [Ed. Need to synchronize authentication configuration with CDNI URL
skipping to change at page 18, line 45 skipping to change at page 21, line 4
used during content delivery and content acquisition, e.g. methods used during content delivery and content acquisition, e.g. methods
such as tokenization and URL Signing. such as tokenization and URL Signing.
[Ed. Need to synchronize authentication configuration with CDNI URL [Ed. Need to synchronize authentication configuration with CDNI URL
signing draft definitions.] signing draft definitions.]
[Ed. Need to consider how to separate protocol specific method [Ed. Need to consider how to separate protocol specific method
configuration (e.g., HTTP basic/digest authentication), which must configuration (e.g., HTTP basic/digest authentication), which must
match the HostMatch protocol, from protocol agnostic method match the HostMatch protocol, from protocol agnostic method
configurations (e.g., URL signing/tokenization).] configurations (e.g., URL signing/tokenization).]
Property: direction Property: direction
Description: Defines whether the Auth object applies to Description: Defines whether the Auth object applies to
acquisition or delivery requests. acquisition or delivery requests.
Type: Enumeration [acquisition|delivery] Type: Enumeration [acquisition|delivery]
Mandatory-to-Specify: No. Default is to apply the rule to both Mandatory-to-Specify: No. Default is to apply the rule to both
acquisition and delivery. acquisition and delivery.
4.2.7. Cache 4.2.7. Cache
[Ed. note: placeholder for cache control metadata - TBD] A Cache object describes the cache control parameters to be applied
to the content by intermediate caches.
4.2.8. Logging Property: ignore-query-string
[Ed. note: placeholder for logging metadata - TBD] Description: Allows a cache to ignore URI query string
parameters while comparing URIs for equivalence.
Type: Boolean
Mandatory-to-Specify: No. Default is to consider query string
parameters when comparing URIs.
4.2.8. Grouping
A Grouping object identifies a large group of content to which this
content belongs.
Property: ccid
Description: Content Collection identifier for an application-
specific purpose such as logging.
Type: String
Mandatory-to-Specify: No. Default is an empty string.
Property: sid
Description: Session identifier for an application-specific
purpose such as logging.
Type: String
Mandatory-to-Specify: No. Default is an empty string.
4.3. CDNI Metadata Simple Data Type Descriptions 4.3. CDNI Metadata Simple Data Type Descriptions
This section describes the simpler data types that are used for This section describes the simpler data types that are used for
properties of CDNI Metadata objects. properties of CDNI Metadata objects.
4.3.1. Link 4.3.1. Link
A link object may be used in place of any of the objects or A link object may be used in place of any of the objects or
properties described above. Links can be used to avoid duplication properties described above. Links can be used to avoid duplication
skipping to change at page 24, line 31 skipping to change at page 27, line 36
PathMetadata match the request (and are linked rather than embedded), PathMetadata match the request (and are linked rather than embedded),
the CDNI metadata client makes another GET request for the the CDNI metadata client makes another GET request for the
PathMetadata. Each PathMetadata object may also include references PathMetadata. Each PathMetadata object may also include references
to yet more specific metadata. If this is the case, the CDNI to yet more specific metadata. If this is the case, the CDNI
metadata client continues requesting PathMetadata recursively. metadata client continues requesting PathMetadata recursively.
Where a downstream CDN is interconnected with multiple upstream CDNs, Where a downstream CDN is interconnected with multiple upstream CDNs,
the downstream CDN must decide which upstream CDN's CDNI metadata the downstream CDN must decide which upstream CDN's CDNI metadata
should be used to handle a particular User Agent request. should be used to handle a particular User Agent request.
When application level redirection (e.g. HTTP 302 redirects) is When application level redirection (e.g. HTTP 302 redirects) is being
being used between CDNs, it is expected that the downstream CDN will used between CDNs, it is expected that the downstream CDN will be
be able to determine the upstream CDN that redirected a particular able to determine the upstream CDN that redirected a particular
request from information contained in the received request (e.g. via request from information contained in the received request (e.g. via
the URI). With knowledge of which upstream CDN routed the request, the URI). With knowledge of which upstream CDN routed the request,
the downstream CDN can choose the correct metadata server from which the downstream CDN can choose the correct metadata server from which
to obtain the HostIndex. Note that the HostIndex served by each uCDN to obtain the HostIndex. Note that the HostIndex served by each uCDN
may be unique. may be unique.
In the case of DNS redirection there is not always sufficient In the case of DNS redirection there is not always sufficient
information carried in the DNS request from User Agents to determine information carried in the DNS request from User Agents to determine
the upstream CDN that redirected a particular request (e.g. when the upstream CDN that redirected a particular request (e.g. when
content from a given host is redirected to a given downstream CDN by content from a given host is redirected to a given downstream CDN by
skipping to change at page 29, line 16 skipping to change at page 32, line 31
}, },
"links": [{ "links": [{
"rel": "pathmetadata", "rel": "pathmetadata",
"type": "application/cdni.PathMetadata", "type": "application/cdni.PathMetadata",
"href": "http://metadata.ucdn.example.com/videos/movies" "href": "http://metadata.ucdn.example.com/videos/movies"
}] }]
} }
] ]
} }
Suppose the path of the requested resource matches the "/video/ Suppose the path of the requested resource matches the "/video/movies
movies/*" pattern, the next metadata requested would be for /*" pattern, the next metadata requested would be for "http://
"http://metadata.ucdn.example.com/video/movies" with an expected type metadata.ucdn.example.com/video/movies" with an expected type of
of "application/cdni.PathMetadata": "application/cdni.PathMetadata":
{ {
"metadata": [], "metadata": [],
"paths": [ "paths": [
{ {
"path-pattern": { "path-pattern": {
"pattern": "/videos/movies/hd/*" "pattern": "/videos/movies/hd/*"
}, },
"links": [{ "links": [{
"rel": "pathmetadata", "rel": "pathmetadata",
"type": "application/cdni.PathMetadata", "type": "application/cdni.PathMetadata",
"href": "http://metadata.ucdn.example.com/videos/movies/hd" "href": "http://metadata.ucdn.example.com/videos/movies/hd"
}] }]
} }
] ]
} }
Finally, if the path of the requested resource also matches the "/
Finally, if the path of the requested resource also matches the videos/movies/hd/*" pattern, the downstream CDN would also fetch the
"/videos/movies/hd/*" pattern, the downstream CDN would also fetch following object from "http://metadata.ucdn.example.com/videos/movies
the following object from /hd" with MIME type "application/cdni.PathMetadata":
"http://metadata.ucdn.example.com/videos/movies/hd" with MIME type
"application/cdni.PathMetadata":
{ {
"metadata": [ "metadata": [
{ {
"type": "application/cdni.TimeWindowACL", "type": "application/cdni.TimeWindowACL",
"value": { "value": {
"times": [ "times": [
"times": [ "times": [
{ {
"start": "1213948800", "start": "1213948800",
skipping to change at page 32, line 28 skipping to change at page 35, line 35
</path> </path>
<path> <path>
<path-pattern> <path-pattern>
<pattern>/videos/movies/*"</pattern> <pattern>/videos/movies/*"</pattern>
</path-pattern> </path-pattern>
<link rel="path-metadata" type="application/cdni.PathMetadata" <link rel="path-metadata" type="application/cdni.PathMetadata"
href="http://metadata.ucdn.example.com/videos/movies"/> href="http://metadata.ucdn.example.com/videos/movies"/>
</path> </path>
</HostMetadata> </HostMetadata>
Suppose the path of the requested resource matches the "/video/ Suppose the path of the requested resource matches the "/video/movies
movies/*" pattern, the next metadata requested would be for /*" pattern, the next metadata requested would be for "http://
"http://metadata.ucdn.example.com/video/movies" with an expected type metadata.ucdn.example.com/video/movies" with an expected type of
of "application/cdni.PathMetadata": "application/cdni.PathMetadata":
<PathMetadata> <PathMetadata>
<path> <path>
<path-pattern> <path-pattern>
<pattern>/videos/movies/hd/*</pattern> <pattern>/videos/movies/hd/*</pattern>
</path-pattern> </path-pattern>
<link rel="path-metadata" type="application/cdni.PathMetadata" <link rel="path-metadata" type="application/cdni.PathMetadata"
href="http://metadata.ucdn.example.com/videos/movies/hd"/> href="http://metadata.ucdn.example.com/videos/movies/hd"/>
</path> </path>
</PathMetadata> </PathMetadata>
Finally, if the path of the requested resource also matches the "/
Finally, if the path of the requested resource also matches the videos/movies/hd/*" pattern, the downstream CDN would also fetch the
"/videos/movies/hd/*" pattern, the downstream CDN would also fetch following object from "http://metadata.ucdn.example.com/videos/movies
the following object from /hd" with MIME type "application/cdni.PathMetadata":
"http://metadata.ucdn.example.com/videos/movies/hd" with MIME type
"application/cdni.PathMetadata":
<PathMetadata> <PathMetadata>
<metadata> <metadata>
<type>application/cdni.TimeWindowACL</type> <type>application/cdni.TimeWindowACL</type>
<value> <value>
<time> <time>
<time> <time>
<start>1213948800</start> <start>1213948800</start>
<end>1327393200</end> <end>1327393200</end>
</time> </time>
skipping to change at page 34, line 37 skipping to change at page 37, line 44
that Metadata assigned to a given content do not conflict. that Metadata assigned to a given content do not conflict.
Note: Because Metadata is inherently ordered in GenericMetadata Note: Because Metadata is inherently ordered in GenericMetadata
lists, as well as in the PathMetadata hierarchy and PathMatch lists, lists, as well as in the PathMetadata hierarchy and PathMatch lists,
multiple conflicting Metadata types MAY be used, however, Metadata multiple conflicting Metadata types MAY be used, however, Metadata
hierarchies MUST ensure that independent PathMatch root objects are hierarchies MUST ensure that independent PathMatch root objects are
used to prevent ambiguous or conflicting Metadata definitions. used to prevent ambiguous or conflicting Metadata definitions.
6.6. Versioning 6.6. Versioning
The first version of the CDNI Metadata interface does not include The version of CDNI Metadata Structural objects is specified by the
version numbering. Subsequent versions will incorporate a syntax for HTTP Content-Type header. Upon responding to a request for an
versioning. 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".
7. IANA Considerations 7. IANA Considerations
This document requests the registration of the "application/cdni" This document requests the registration of the "application/cdni"
MIME Media Type under the IANA MIME Media Type registry MIME Media Type under the IANA MIME Media Type registry (http://
(http://www.iana.org/assignments/media-types/index.html). www.iana.org/assignments/media-types/index.html).
[Ed. Need to consider a registry for Metadata type identifiers.] [Ed. Need to consider a registry for Metadata type identifiers.]
8. Security Considerations 8. Security Considerations
The CDNI Metadata Interface is expected to be secured as a function The CDNI Metadata Interface is expected to be secured as a function
of the transport protocol (e.g. HTTP authentication [RFC2617], HTTPS of the transport protocol (e.g. HTTP authentication [RFC2617], HTTPS
[RFC2818], or inter-domain IPSec). [RFC2818], or inter-domain IPSec).
If a malicious metadata server is contacted by a downstream CDN, the If a malicious metadata server is contacted by a downstream CDN, the
malicious server may provide metadata to the downstream CDN which malicious server may provide metadata to the downstream CDN which
denies service for any piece of content to any user agent. The denies service for any piece of content to any user agent. The
malicious server may also provide metadata which directs a downstream malicious server may also provide metadata which directs a downstream
CDN to a malicious origin server instead of the actual origin server. CDN to a malicious origin server instead of the actual origin server.
The dCDN is expected to authenticate the server to prevent this The dCDN is expected to authenticate the server to prevent this
situation (e.g. by using HTTPS and validating the server's situation (e.g. by using HTTPS and validating the server's
certificate). certificate).
skipping to change at page 36, line 14 skipping to change at page 39, line 27
10.2. Informative References 10.2. Informative References
[I-D.ietf-cdni-framework] [I-D.ietf-cdni-framework]
Peterson, L. and B. Davie, "Framework for CDN Peterson, L. and B. Davie, "Framework for CDN
Interconnection", draft-ietf-cdni-framework-03 (work in Interconnection", draft-ietf-cdni-framework-03 (work in
progress), February 2013. progress), February 2013.
[I-D.ietf-cdni-requirements] [I-D.ietf-cdni-requirements]
Leung, K. and Y. Lee, "Content Distribution Network Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", Interconnection (CDNI) Requirements", draft-ietf-cdni-
draft-ietf-cdni-requirements-05 (work in progress), requirements-05 (work in progress), February 2013.
February 2013.
[I-D.zyp-json-schema] [I-D.zyp-json-schema]
Zyp, K. and G. Court, "A JSON Media Type for Describing Zyp, K. and G. Court, "A JSON Media Type for Describing
the Structure and Meaning of JSON Documents", the Structure and Meaning of JSON Documents", draft-zyp-
draft-zyp-json-schema-03 (work in progress), json-schema-03 (work in progress), November 2010.
November 2010.
[RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform
Resource Identifier (URI): Generic Syntax", STD 66, Resource Identifier (URI): Generic Syntax", STD 66, RFC
RFC 3986, January 2005. 3986, January 2005.
[RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", [RFC4151] Kindberg, T. and S. Hawke, "The 'tag' URI Scheme", RFC
RFC 4151, October 2005. 4151, October 2005.
[RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom [RFC4287] Nottingham, M., Ed. and R. Sayre, Ed., "The Atom
Syndication Format", RFC 4287, December 2005. Syndication Format", RFC 4287, December 2005.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
[XML-BASE] [XML-BASE]
Marsh, J., Ed. and R. Tobin, Ed., "XML Base (Second Marsh, J., Ed. and R. Tobin, Ed., "XML Base (Second
 End of changes. 63 change blocks. 
161 lines changed or deleted 231 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/