draft-ietf-cdni-metadata-02.txt   draft-ietf-cdni-metadata-03.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: January 16, 2014 Velocix (Alcatel-Lucent) Expires: April 24, 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.
July 15, 2013 October 21, 2013
CDN Interconnect Metadata CDN Interconnect Metadata
draft-ietf-cdni-metadata-02 draft-ietf-cdni-metadata-03
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.
skipping to change at page 1, line 48 skipping to change at page 1, line 48
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 January 16, 2014. This Internet-Draft will expire on April 24, 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
skipping to change at page 2, line 31 skipping to change at page 2, line 31
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 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 . . . . . . . . . . . . . . . . . . . . . 10 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 . . . . . . 11
4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 12 4.1.1. HostIndex . . . . . . . . . . . . . . . . . . . . . . 12
4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 12 4.1.2. HostMatch . . . . . . . . . . . . . . . . . . . . . . 12
4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 13 4.1.3. HostMetadata . . . . . . . . . . . . . . . . . . . . 13
4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 13 4.1.4. PathMatch . . . . . . . . . . . . . . . . . . . . . . 13
4.1.5. PathMetadata . . . . . . . . . . . . . . . . . . . . 14 4.1.5. PathMetadata . . . . . . . . . . . . . . . . . . . . 14
4.1.6. PatternMatch . . . . . . . . . . . . . . . . . . . . 14 4.1.6. PatternMatch . . . . . . . . . . . . . . . . . . . . 14
4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 15 4.1.7. GenericMetadata . . . . . . . . . . . . . . . . . . . 15
4.2. CDNI Metadata Property Object Descriptions . . . . . . . 16 4.2. CDNI Metadata Property Object Descriptions . . . . . . . 16
4.2.1. Source Metadata . . . . . . . . . . . . . . . . . . . 16 4.2.1. Source Metadata . . . . . . . . . . . . . . . . . . . 16
4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 16 4.2.1.1. Source . . . . . . . . . . . . . . . . . . . . . 16
4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 17 4.2.2. LocationACL Metadata . . . . . . . . . . . . . . . . 17
4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 17 4.2.2.1. LocationRule . . . . . . . . . . . . . . . . . . 17
4.2.2.2. Location . . . . . . . . . . . . . . . . . . . . 17 4.2.2.2. Footprint . . . . . . . . . . . . . . . . . . . . 17
4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . 18 4.2.3. TimeWindowACL Metadata . . . . . . . . . . . . . . . 18
4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 18 4.2.3.1. TimeWindowRule . . . . . . . . . . . . . . . . . 18
4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 19 4.2.3.2. TimeWindow . . . . . . . . . . . . . . . . . . . 19
4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 19 4.2.4. ProtocolACL Metadata . . . . . . . . . . . . . . . . 19
4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 19 4.2.4.1. ProtocolRule . . . . . . . . . . . . . . . . . . 19
4.2.5. Authorization Metadata . . . . . . . . . . . . . . . 20 4.2.5. Authorization Metadata . . . . . . . . . . . . . . . 20
4.2.6. Auth . . . . . . . . . . . . . . . . . . . . . . . . 20 4.2.6. Auth . . . . . . . . . . . . . . . . . . . . . . . . 20
4.2.6.1. Credentials Auth Type . . . . . . . . . . . . . . 21
4.2.7. Cache . . . . . . . . . . . . . . . . . . . . . . . . 21 4.2.7. Cache . . . . . . . . . . . . . . . . . . . . . . . . 21
4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 21 4.2.8. Grouping . . . . . . . . . . . . . . . . . . . . . . 22
4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 22 4.3. CDNI Metadata Simple Data Type Descriptions . . . . . . . 22
4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 22 4.3.1. Link . . . . . . . . . . . . . . . . . . . . . . . . 22
4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 22 4.3.2. Protocol . . . . . . . . . . . . . . . . . . . . . . 23
4.3.3. RedirectionMethod . . . . . . . . . . . . . . . . . . 23 4.3.3. Endpoint . . . . . . . . . . . . . . . . . . . . . . 23
4.3.4. Endpoint . . . . . . . . . . . . . . . . . . . . . . 23 4.3.4. URI . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.5. IPRange . . . . . . . . . . . . . . . . . . . . . . . 23 4.3.5. Time . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.6. URI . . . . . . . . . . . . . . . . . . . . . . . . . 23
4.3.7. Time . . . . . . . . . . . . . . . . . . . . . . . . 23
5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 24 5. CDNI Metadata Capabilities . . . . . . . . . . . . . . . . . 24
5.1. Protocol ACL Capabilities . . . . . . . . . . . . . . . . 24 5.1. Protocol ACL Capabilities . . . . . . . . . . . . . . . . 24
5.2. Authorization Metadata Capabilities . . . . . . . . . . . 25 5.2. Authorization Metadata Capabilities . . . . . . . . . . . 24
5.3. Host Metadata Capabilities . . . . . . . . . . . . . . . 25
6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 25 6. CDNI Metadata interface . . . . . . . . . . . . . . . . . . . 25
6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 26 6.1. Transport . . . . . . . . . . . . . . . . . . . . . . . . 25
6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 27 6.2. Retrieval of CDNI Metadata resources . . . . . . . . . . 26
6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 28 6.3. Bootstrapping . . . . . . . . . . . . . . . . . . . . . . 27
6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 28 6.4. Encoding . . . . . . . . . . . . . . . . . . . . . . . . 28
6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 28 6.4.1. MIME Media Types . . . . . . . . . . . . . . . . . . 28
6.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . 29 6.4.2. JSON Encoding of Objects . . . . . . . . . . . . . . 28
6.4.2.1. JSON Example . . . . . . . . . . . . . . . . . . 30 6.4.2.1. JSON Example . . . . . . . . . . . . . . . . . . 29
6.4.3. XML Encoding of Objects . . . . . . . . . . . . . . . 33 6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 33
6.4.3.1. XML Example . . . . . . . . . . . . . . . . . . . 34 6.5.1. Metadata Enforcement . . . . . . . . . . . . . . . . 33
6.5. Extensibility . . . . . . . . . . . . . . . . . . . . . . 36 6.5.2. Metadata Override . . . . . . . . . . . . . . . . . . 33
6.5.1. Metadata Enforcement . . . . . . . . . . . . . . . . 36 6.6. Versioning . . . . . . . . . . . . . . . . . . . . . . . 34
6.5.2. Metadata Override . . . . . . . . . . . . . . . . . . 37 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 34
6.6. Versioning . . . . . . . . . . . . . . . . . . . . . . . 37 7.1. GenericMetadata Type Registry . . . . . . . . . . . . . . 34
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 38 7.1.1. GenericMetadata Sub-Registries . . . . . . . . . . . 35
8. Security Considerations . . . . . . . . . . . . . . . . . . . 38 7.1.1.1. Footprint Sub-Registry . . . . . . . . . . . . . 35
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 38 7.1.1.2. Protocol Sub-Registry . . . . . . . . . . . . . . 36
7.1.1.3. Authentication Sub-Registry . . . . . . . . . . . 37
8. Security Considerations . . . . . . . . . . . . . . . . . . . 37
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 37
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 38
10.1. Normative References . . . . . . . . . . . . . . . . . . 38 10.1. Normative References . . . . . . . . . . . . . . . . . . 38
10.2. Informative References . . . . . . . . . . . . . . . . . 39 10.2. Informative References . . . . . . . . . . . . . . . . . 38
Appendix A. Relationship to the CDNI Requirements . . . . . . . 40 Appendix A. Relationship to the CDNI Requirements . . . . . . . 39
Appendix B. Metadata Rewriting . . . . . . . . . . . . . . . . . 40 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 39
B.1. Example . . . . . . . . . . . . . . . . . . . . . . . . . 41
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 11, line 22 skipping to change at page 11, line 22
Examples of GenericMetadata object type names: Examples of GenericMetadata object type names:
LocationACL LocationACL
ext.vendor1.featurex ext.vendor1.featurex
ext.vendor1.featurey ext.vendor1.featurey
ext.vendor2.featurex ext.vendor2.featurex
[Ed. It is intended that Metadata capability advertisements will
allow either individual Metadata names or Metadata bundle identifiers
to be used. Need to have a procedure for defining and distributing
bundle information to be used in Metadata capability advertisement.]
4. Encoding-Independent CDNI Metadata Object Descriptions 4. Encoding-Independent CDNI Metadata Object Descriptions
Section 4.1 provides the definitions of each object type declared in Section 4.1 provides the definitions of each object type declared in
Section 3. These objects are described as structural objects as they Section 3. These objects are described as structural objects as they
provide the structure for the inheritance tree and identifying which provide the structure for the inheritance tree and identifying which
specific properties apply to a given User Agent content request. specific properties apply to a given User Agent content request.
Section 4.2 provides the definitions for the set of core metadata Section 4.2 provides the definitions for the set of core metadata
objects which may be contained within a GenericMetadata object. objects which may be contained within a GenericMetadata object.
These objects are described as property objects as they define the These objects are described as property objects as they define the
skipping to change at page 13, line 28 skipping to change at page 13, line 28
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: paths Property: paths
Description: Path specific rules. First match applies. Description: Path specific rules. First match applies.
Type: List of PathMatch objects Type: List of PathMatch objects
Mandatory-to-Specify: No. Mandatory-to-Specify: No.
Property: modes
Description: Defines which redirection methods are supported.
Type: List of RedirectionMethod
Mandatory-to-Specify: Yes.
4.1.4. PathMatch 4.1.4. PathMatch
The PathMatch object contains an expression given as a PatternMatch The PathMatch object contains an expression given as a PatternMatch
object to match against a resource URI path and Metadata objects to object to match against a resource URI path and Metadata objects to
apply if a match is found. apply if a match is found.
Property: path-pattern Property: path-pattern
Description: Pattern to match against the requested path, i.e. Description: Pattern to match against the requested path, i.e.
against the [RFC3986] path-absolute. against the [RFC3986] path-absolute.
skipping to change at page 15, line 11 skipping to change at page 15, line 4
Type: String Type: String
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: case-sensitive Property: case-sensitive
Description: Flag indicating whether or not case-sensitive Description: Flag indicating whether or not case-sensitive
matching should be used. matching should be used.
Type: Boolean Type: Boolean
Mandatory-to-Specify: No. Default is case-insensitive match. Mandatory-to-Specify: No. Default is case-insensitive match.
Property: match-query-string Property: ignore-query-string
Description: Flag indicating whether or not the query string Description: List of query parameters which should be ignored
should be included in the pattern match. when searching for a pattern match. If all query parameters
should be ignored then the list MUST be empty.
Type: Boolean Type: List of String
Mandatory-to-Specify: No. Default is not to include query Mandatory-to-Specify: No. Default is to include query strings
strings when matching. when matching.
4.1.7. GenericMetadata 4.1.7. GenericMetadata
A GenericMetadata object is a abstraction for managing individual A GenericMetadata object is a abstraction for managing individual
CDNI Metadata properties in an opaque manner. CDNI Metadata properties in an opaque manner.
Property: type Property: type
Description: CDNI Metadata property object type. Description: CDNI Metadata property object type.
skipping to change at page 17, line 4 skipping to change at page 16, line 48
Description: Authentication method to use when requesting Description: Authentication method to use when requesting
content from this source. content from this source.
Type: Auth Type: Auth
Mandatory-to-Specify: No. Default is no authentication is Mandatory-to-Specify: No. Default is no authentication is
required. required.
Property: endpoints Property: endpoints
Description: Origins from which the dCDN can acquire content. Description: Origins from which the dCDN can acquire content.
Type: List of EndPoint objects Type: List of EndPoint objects
Mandatory-to-Specify: Yes.
Property: protocol
Description: Network retrieval protocol to use when requesting
content from this source.
Type: Protocol
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
4.2.2. LocationACL Metadata 4.2.2. LocationACL Metadata
LocationACL Metadata defines location-based restrictions. LocationACL Metadata defines location-based restrictions.
Property: locations Property: locations
Description: Access control list which applies restrictions to Description: Access control list which applies restrictions to
skipping to change at page 17, line 28 skipping to change at page 17, line 33
Type: List of LocationRule objects Type: List of LocationRule objects
Mandatory-to-Specify: No. Default is allow all locations. Mandatory-to-Specify: No. Default is allow all locations.
4.2.2.1. LocationRule 4.2.2.1. LocationRule
A LocationRule contains or references a list of Location objects and A LocationRule contains or references a list of Location objects and
the corresponding action. the corresponding action.
Property: locations Property: footprints
Description: List of locations to which the rule applies. Description: List of footprints to which the rule applies.
Type: List of Location objects Type: List of Footprint objects
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
[Ed: reusing locations as a property name is confusing and should
likely be changed]
Property: action Property: action
Description: Defines whether the rule specifies locations to Description: Defines whether the rule specifies locations 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.2.2. Location 4.2.2.2. Footprint
A Location object describes a Location which may be applied by a A Footprint object describes the footprint to which a LocationRule
LocationRule, e.g. a Location may be an IPv4 address range or a may be applied by, e.g. an IPv4 address range or a geographic
geographic location. location.
Property: iprange Property: type
Description: A set of IP Addresses. Description: Registered footprint type (see Section 7.1.1.1).
Type: List of IPRange objects Type: String
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
[Ed: Location as specified above only supports the Class 1a names Property: value
described in [I-D.jenkins-cdni-names]. Need to add support for Class
1b names to a later version.] Description: Footprint object conforming to the specification
associated with the registered footprint type.
Type: String
Mandatory-to-Specify: Yes.
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.
skipping to change at page 20, line 42 skipping to change at page 20, line 49
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.
such as tokenization and URL Signing.
[Ed. Need to synchronize authentication configuration with CDNI URL Property: type
signing draft definitions.] Description: Registered Auth type (see Section 7.1.1.3).
[Ed. Need to consider how to separate protocol specific method Type: String
configuration (e.g., HTTP basic/digest authentication), which must
match the HostMatch protocol, from protocol agnostic method
configurations (e.g., URL signing/tokenization).]
Property: direction
Description: Defines whether the Auth object applies to Mandatory-to-Specify: Yes.
acquisition or delivery requests.
Type: Enumeration [acquisition|delivery] Property: value
Mandatory-to-Specify: No. Default is to apply the rule to both Description: Auth object conforming to the specification
acquisition and delivery. associated with the registered Auth type.
Type: String
Mandatory-to-Specify: Yes.
4.2.6.1. Credentials Auth Type
Credentials Auth is a type of Auth object with type "credentials"
(see Section 7.1.1.3). The CredentialsAuth object contains the
following properties:
Property: username
Description: Identification of user.
Type: String
Mandatory-to-Specify: Yes.
Property: password
Description: Password for user identified by username property.
Type: String
Mandatory-to-Specify: Yes.
4.2.7. Cache 4.2.7. Cache
A Cache object describes the cache control parameters to be applied A Cache object describes the cache control parameters to be applied
to the content by intermediate caches. to the content by intermediate caches.
Property: ignore-query-string Property: ignore-query-string
Description: Allows a cache to ignore URI query string Description: Allows a cache to ignore URI query string
parameters while comparing URIs for equivalence. 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: Boolean Type: List of String
Mandatory-to-Specify: No. Default is to consider query string Mandatory-to-Specify: No. Default is to consider query string
parameters when comparing URIs. parameters when comparing URIs or to rely on other properties
of the Cache object.
4.2.8. Grouping 4.2.8. Grouping
A Grouping object identifies a large group of content to which this A Grouping object identifies a large group of content to which this
content belongs. content belongs.
Property: ccid Property: ccid
Description: Content Collection identifier for an application- Description: Content Collection identifier for an application-
specific purpose such as logging. specific purpose such as logging.
skipping to change at page 22, line 27 skipping to change at page 23, line 7
property it is replacing, and its type property is set to the type of property it is replacing, and its type property is set to the type of
the object it is replacing. the object it is replacing.
Property: href Property: href
Description: The URI of the of the addressable object being Description: The URI of the of the addressable object being
referenced. referenced.
Type: URI Type: URI
Mandatory: Yes Mandatory-to-Specify: Yes
Property: rel Property: rel
Description: The Relationship between the referring object and Description: The Relationship between the referring object and
the object it is referencing. the object it is referencing.
Type: String Type: String
Mandatory: Yes Mandatory-to-Specify: Yes
Property: type Property: type
Description: The type of the object being referenced. Description: The type of the object being referenced.
Type: String Type: String
Mandatory: Yes Mandatory-to-Specify: Yes
4.3.2. Protocol 4.3.2. Protocol
Protocol objects are used to specify registered protocols for content Protocol objects are used to specify registered protocols for content
acquisition or delivery. acquisition or delivery (see Section 7.1.1.2).
[Ed. Need to reference protocol registry.]
Type: Enumeration [HTTP|RTSP|RTMP]
4.3.3. RedirectionMethod
RedirectionMethod objects are used to specify registered content
redirection modes.
[Ed. Need to reference redirection method registry.] Type: String
Type: Enumeration [HTTP-I|HTTP-R|DNS-I|DNS-R] Mandatory-to-Specify: Yes
4.3.4. Endpoint 4.3.3. Endpoint
A hostname (with optional port) or an IP address (with optional A hostname (with optional port) or an IP address (with optional
port). port).
Note: All implementations MUST support IPv4 addresses encoded as Note: All implementations MUST support IPv4 addresses encoded as
specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and
MUST support all IPv6 address formats specified in [RFC4291]. Server MUST support all IPv6 address formats specified in [RFC4291]. Server
implementations SHOULD use IPv6 address formats specified in implementations SHOULD use IPv6 address formats specified in
[RFC5952]. [RFC5952].
4.3.5. IPRange 4.3.4. URI
One of:
o A range of consecutive IP addresses (IPv4 or IPv6) expressed as
Address1-Address2 which does not have to be to power of two
aligned, for example the range 192.0.2.1-192.0.2.10 is valid. The
first Address in the range MUST be 'lower' than the final address
in the range.
o A valid IP subnet (IPv4 or IPv6) expressed using CIDR notation.
o A single IP address (IPv4 or IPv6).
Note: Client implementations MUST support IPv4 addresses encoded as
specified by the 'IPv4address' rule in Section 3.2.2 of [RFC3986] and
MUST support all IPv6 address formats specified in [RFC4291]. Server
implementations SHOULD use IPv6 address formats specified in
[RFC5952].
4.3.6. URI
A URI as specified in [RFC3986]. A URI as specified in [RFC3986].
4.3.7. Time 4.3.5. Time
A time value expressed in seconds since Unix epoch in the UTC A time value expressed in seconds since Unix epoch in the UTC
timezone. timezone.
5. CDNI Metadata Capabilities 5. CDNI Metadata Capabilities
CDNI Metadata is used to convey information pertaining to content CDNI Metadata is used to convey information pertaining to content
delivery from uCDN to dCDN. For optional metadata, it may be useful 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 for the uCDN to know if the dCDN supports the metadata, prior to
delegating any content requests to the dCDN. If optional-to- delegating any content requests to the dCDN. If optional-to-
implement metadata is mandatory-to-enforce and the dCDN does not implement metadata is mandatory-to-enforce and the dCDN does not
skipping to change at page 24, line 50 skipping to change at page 24, line 50
ProtocolRules are defined for either acquisition or delivery. For ProtocolRules are defined for either acquisition or delivery. For
some CDNs, certain combinations of acquisition and delivery protocols some CDNs, certain combinations of acquisition and delivery protocols
may not make sense (e.g., RTSP acquisition for HTTP delivery), while may not make sense (e.g., RTSP acquisition for HTTP delivery), while
other CDNs may support customized protocol adaptation. ProtocolACL other CDNs may support customized protocol adaptation. ProtocolACL
capabilities are not intended to define which combinations of capabilities are not intended to define which combinations of
protocols should be used. ProtocolACL capabilties are only intended protocols should be used. ProtocolACL capabilties are only intended
to describe which protocols the dCDN does or does not support. to describe which protocols the dCDN does or does not support.
Protocol combination restrictions are specified in the metadata Protocol combination restrictions are specified in the metadata
itself and associated with specific groups of content assets. itself and associated with specific groups of content assets.
[Ed. Need to register delivery protocol capability ID.]
[Ed. Need to reference protocol registry, and discuss specification
of overlapping protocol values.]
5.2. Authorization Metadata Capabilities 5.2. Authorization Metadata Capabilities
The Authorization object contains a list of Auth values. The dCDN The Authorization object contains a list of Auth values. The dCDN
MUST advertise which authorization algorithms it supports so that the MUST advertise which authorization algorithms it supports so that the
uCDN knows what type of content requests it can redirect to the dCDN. uCDN knows what type of content requests it can redirect to the dCDN.
If the dCDN does not support a given authorization algorithm, the If the dCDN does not support a given authorization algorithm, the
uCDN should not delegate requests requiring that algorithm to 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 dCDN as the dCDN will not be able to properly acquire the content or
enforce delivery restrictions. enforce delivery restrictions.
[Ed. Need to register authorization algorithm capability ID.]
[Ed. Need to reference auth registry, and discuss specification of
overlapping auth values.]
5.3. Host Metadata Capabilities
The HostMetadata object contains a list of redirection method values.
The dCDN MUST advertise which redirection modes it supports so that
the uCDN knows how to redirect content requests to the dCDN. If the
dCDN does not support a given redirection method, the uCDN should not
delegate requests to the dCDN using that method as the dCDN will not
be able to properly handle the redirection.
[Ed. Need to register redirection method capability ID.]
[Ed. Need to reference redirection method registry.]
6. CDNI Metadata interface 6. CDNI Metadata interface
This section specifies an interface to enable a Downstream CDN to This section specifies an interface to enable a Downstream CDN to
retrieve CDNI Metadata objects from an Upstream CDN. retrieve CDNI Metadata objects from an Upstream CDN.
The interface can be used by a Downstream CDN to retrieve CDNI The interface can be used by a Downstream CDN to retrieve CDNI
Metadata objects either dynamically as required by the Downstream CDN Metadata objects either dynamically as required by the Downstream CDN
to process received requests (for example in response to receiving a to process received requests (for example in response to receiving a
CDNI Request Routing request from an Upstream CDN or in response to 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 receiving a request for content from a User Agent) or in advance of
skipping to change at page 28, line 40 skipping to change at page 28, line 27
generally a deployment choice for the uCDN implementation to decide generally a deployment choice for the uCDN implementation to decide
when and which CDNI Metadata objects to embed and which are when and which CDNI Metadata objects to embed and which are
separately addressable. separately addressable.
6.4.1. MIME Media Types 6.4.1. MIME Media Types
All MIME types are prefixed with "application/cdni." The MIME type All MIME types are prefixed with "application/cdni." The MIME type
for each object matches the type name of that object as defined by for each object matches the type name of that object as defined by
this document. Table 3 lists a few examples of the MIME Media Type this document. Table 3 lists a few examples of the MIME Media Type
for each object (resource) that is retrievable through the CDNI for each object (resource) that is retrievable through the CDNI
Metadata interface. The MIME type suffix depends on the metadata Metadata interface.
encoding, either "+xml" or "+json".
+--------------+-------------------------------+ +--------------+-------------------------------+
| Data Object | MIME Media Type | | Data Object | MIME Media Type |
+--------------+-------------------------------+ +--------------+-------------------------------+
| HostIndex | application/cdni.HostIndex | | HostIndex | application/cdni.HostIndex |
| HostMatch | application/cdni.HostMatch | | HostMatch | application/cdni.HostMatch |
| HostMetadata | application/cdni.HostMetadata | | HostMetadata | application/cdni.HostMetadata |
| PathMatch | application/cdni.PathMatch | | PathMatch | application/cdni.PathMatch |
| PathMetadata | application/cdni.PathMetadata | | PathMetadata | application/cdni.PathMetadata |
+--------------+-------------------------------+ +--------------+-------------------------------+
Table 3: Example MIME Media Types for CDNI Metadata objects Table 3: Example MIME Media Types for CDNI Metadata objects
See http://www.iana.org/assignments/media-types/index.html for See http://www.iana.org/assignments/media-types/index.html for
reference. reference.
6.4.2. JSON Encoding of Objects 6.4.2. JSON Encoding of Objects
One possible encoding for a CDNI Metadata object is a JSON object CDNI Metadata objects are encoded as JSON objects containing a
containing a dictionary of (key,value) pairs where the keys are the dictionary of (key,value) pairs where the keys are the property names
property names and the values are the associated property values. and the values are the associated property values.
The keys of the dictionary are the names of the properties associated The keys of the dictionary are the names of the properties associated
with the object and are therefore dependent on the specific object with the object and are therefore dependent on the specific object
being encoded (i.e. dependent on the MIME Media Type of the returned being encoded (i.e. dependent on the MIME Media Type of the returned
resource). Likewise, the values associated with each key are resource). Likewise, the values associated with each key are
dependent on the specific object being encoded (i.e. dependent on the dependent on the specific object being encoded (i.e. dependent on the
MIME Media Type of the returned resource). MIME Media Type of the returned resource).
Dictionary keys in JSON are case sensitive and therefore by Dictionary keys in JSON are case sensitive and therefore by
convention any dictionary key defined by this document (for example convention any dictionary key defined by this document (for example
skipping to change at page 33, line 26 skipping to change at page 33, line 4
{ {
"start": "1213948800", "start": "1213948800",
"end": "1327393200" "end": "1327393200"
} }
], ],
"type": "allow" "type": "allow"
] ]
} }
} }
] ]
}
6.4.3. XML Encoding of Objects
Another possible encoding for a CDNI Metadata object is an XML
document containing elements with tag names which match property
names and values which match the associated property values.
Tag names of elements 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 element are
dependent on the specific object being encoded (i.e. dependent on the
MIME Media Type of the returned resource).
Lists are encoded by repeating the singular form of a property name.
For example the "hosts" property is a list of "HostMatch" objects.
This list would be encoded as multiple "host" elements.
Link objects are a special case. If a Link object replaces a
property then a "link" element replaces the expected element. The
properties of the Link object are encoded as XML attributes. The
type attribute is set to the MIME type of the target object. The
href attribute is set to the URI of the target object. The rel
attribute is set to the name of the element being replaced.
6.4.3.1. XML Example
A downstream CDN may request the HostIndex and receive the following
object of type "application/cdni.HostIndex+xml":
<HostIndex>
<host>
<host>video.example.com</host>
<link rel="host-metadata" type="application/cdni.HostMetadata"
href="http://metadata.ucdn.example.com/video"/>
</host>
<host>
<host>images.example.com</host>
<link rel="host-metadata" type="application/cdni.HostMetadata"
href="http://metadata.ucdn.example.com/images"/>
</host>
</HostIndex>
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+xml":
<HostMetadata>
<metadata>
<type>application/cdni.SourceMetadata</type>
<value>
<sources>
<link rel="auth" type="application/cdni.Auth"
href="http://metadata.ucdn.example.com/auth1234"/>
<endpoint>acq1.ucdn.example.com</endpoint>
<protocol>ftp</protocol>
</source>
<source>
<link rel="auth" type="application/cdni.Auth"
href="http://metadata.ucdn.example.com/auth1234"/>
<endpoint>acq2.ucdn.example.com</endpoint>
<protocol>http</protocol>
</source>
</value>
</metadata>
<metadata>
<type>application/cdni.LocationACL</type>
<value>
<location>
<location>
<iprange>192.168.0.0/16</iprange>
</location>
<action>deny</type>
</location>
</value>
</metadata>
<metadata>
<type>application/cdni.ProtocolACL</type>
<value>
<protocol>
<protocol>ftp</protocol>
<action>deny</action>
</protocol>
</value>
</metadata>
<path>
<path-pattern>
<pattern>/videos/trailers/*"</pattern>
</path-pattern>
<link rel="path-metadata" type="application/cdni.PathMetadata"
href="http://metadata.ucdn.example.com/videos/trailers"/>
</path>
<path>
<path-pattern>
<pattern>/videos/movies/*"</pattern>
</path-pattern>
<link rel="path-metadata" type="application/cdni.PathMetadata"
href="http://metadata.ucdn.example.com/videos/movies"/>
</path>
</HostMetadata>
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":
<PathMetadata> }
<path>
<path-pattern>
<pattern>/videos/movies/hd/*</pattern>
</path-pattern>
<link rel="path-metadata" type="application/cdni.PathMetadata"
href="http://metadata.ucdn.example.com/videos/movies/hd"/>
</path>
</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":
<PathMetadata>
<metadata>
<type>application/cdni.TimeWindowACL</type>
<value>
<time>
<time>
<start>1213948800</start>
<end>1327393200</end>
</time>
<type>allow</type>
</time>
</metadata>
</PathMetadata>
6.5. Extensibility 6.5. Extensibility
The set of property Metadata may be extended with proprietary and/or The set of property Metadata may be extended with proprietary and/or
custom property Metadata. The GenericMetadata object defined in custom property Metadata. The GenericMetadata object defined in
Section 4.1.7 allows any Metadata property to be included in either Section 4.1.7 allows any Metadata property to be included in either
the HostMetadata or PathMetadata lists. As described in Section 3.4, the HostMetadata or PathMetadata lists. As described in Section 3.4,
any proprietary and/or custom property Metadata SHOULD be identified any proprietary and/or custom property Metadata SHOULD be identified
by the "ext." prefix in an appropriately descriptive type which by the "ext." prefix in an appropriately descriptive type which
conveys the organization defining the property Metadata and the conveys the organization defining the property Metadata and the
skipping to change at page 37, line 5 skipping to change at page 33, line 35
At any given time, the set of property Metadata supported by the uCDN 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. may not match the set of property Metadata supported by the dCDN.
The uCDN may or may not know which property Metadata 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 supports. In cases where the uCDN supports Metadata that the dCDN
does not, the dCDN MUST be aware of any Metadata marked as 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 "mandatory-to-enforce". If a CDN does not understand or is unable to
perform the functions associated with any "mandatory-to-enforce" perform the functions associated with any "mandatory-to-enforce"
Metadata, the CDN MUST NOT service any requests for the corresponding Metadata, the CDN MUST NOT service any requests for the corresponding
content. content.
Any standard which defines a new GenericMetadata Type SHOULD also
define whether or not the new metadata is mandatory-to-enforce.
Note: Ideally, uCDNs would not delegate content requests to a dCDN Note: Ideally, uCDNs would not delegate content requests to a dCDN
which does not support the mandatory-to-enforce Metadata associated which does not support the mandatory-to-enforce Metadata associated
with the content being requested. However, even if the uCDN has a 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 priori knowledge of the Metadata supported by the dCDN (e.g., via the
CDNI capabilities interface or through out-of-band negotiation CDNI capabilities interface or through out-of-band negotiation
between CDN operators) Metadata support may fluctuate or be between CDN operators) Metadata support may fluctuate or be
inconsistent (e.g., due to mis-communication, mis-configuration, or inconsistent (e.g., due to mis-communication, mis-configuration, or
temporary outage). Thus, the dCDN MUST evaluate all Metadata temporary outage). Thus, the dCDN MUST evaluate all Metadata
associated with content requests and reject any requests where associated with content requests and reject any requests where
"mandatory-to-enforce" Metadata associated with the content cannot be "mandatory-to-enforce" Metadata associated with the content cannot be
skipping to change at page 38, line 17 skipping to change at page 34, line 50
include a version. Any document which defines a new type of include a version. Any document which defines a new type of
GenericMetadata should specify the version number which it describes. GenericMetadata should specify the version number which it describes.
For example: "application/cdni.Location.v1". 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 (http:// MIME Media Type under the IANA MIME Media Type registry (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.] 7.1. GenericMetadata Type Registry
CDNI Metadata is distributed as a list of GenericMetadata objects
which specify a type field and a type-specific value field, as
described in Section 4.1.7. 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. As described in
Section 4.1.7 and Section 6.5, the vendor defined namespace partition
SHOULD use a namespace prefix of "ext.", while the standard namespace
partition MUST NOT.
The standard namespace partition MUST conform to the "RFC Required"
policy as defined in [RFC5226]. The vendor defined namespace
partition should be further partitioned into vendor specific
partitions with the prefix "ext.vendor_name.". The vendor defined
partition SHOULD conform to the "Expert Review" policy as defined in
[RFC5226]. The expert review is simply to prevent namespace
hoarding. The vendor specific partitions MAY conform to the "First
Come First Served" policy as defined in [RFC5226], however, vendors
defining new GenericMetadata types which conflict with other
GenericMetadata types SHOULD follow the guidelines for the
"Specification Required" policy as defined in [RFC5226].
The following table defines the initial values for the standard
partition:
+----------------+---------------+
| type name | Specification |
+----------------+---------------+
| SourceMetadata | RFCthis |
| LocationACL | RFCthis |
| TimeWindowACL | RFCthis |
| ProtocolACL | RFCthis |
| Auth | RFCthis |
| Cache | RFCthis |
| Grouping | RFCthis |
+----------------+---------------+
7.1.1. GenericMetadata Sub-Registries
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.
7.1.1.1. Footprint Sub-Registry
The "CDNI Metadata Footprint Types" namespace defines the valid
Footprint object type values used by the Footprint object in
Section 4.2.2.2. Additions to the Footprint type namespace MUST
conform to the "Expert Review" policy as defined in [RFC5226]. 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 name | definition |
+---------------+---------------------------------------------------+
| IPv4 | Single IPv4 address |
| IPv6 | Single IPv6 address |
| IPv4Range | List of contiguous IPv4 addresses denoted by a |
| | start address and an end address separated by a |
| | dash (e.g., 192.168.0.1-192.168.0.20), inclusive. |
| IPv6Range | List of contiguous IPv6 addresses denoted by a |
| | start address and an end address separated by a |
| | dash (e.g., fc80::0001-fc80::0014), inclusive. |
| IPv4CIDR | IPv4 address block using slash prefix length |
| | notation (e.g., 192.168.0.16/28). |
| IPv6CIDR | IPv6 address block using slash prefix length |
| | notation (e.g., fc80::0010/124). |
| ASN | Autonomous System (AS) Number |
| CountryCode | ISO 3166-1 alpha-2 code |
| DVDRegion | DVD Region code (i.e., integer in the range 0-6). |
+---------------+---------------------------------------------------+
7.1.1.2. Protocol Sub-Registry
The "CDNI Metadata Protocols" namespace defines the valid Protocol
object values in Section 4.3.2, used by the SourceMetadata and
ProtocolACL objects. Additions to the Protocol namespace MUST
conform to the "Expert Review" policy as defined in [RFC5226]. 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:
+---------------+------------+
| protocol name | definition |
+---------------+------------+
| HTTP | TBD |
| HTTPS | TBD |
| RTSP | TBD |
| RTMP | TBD |
+---------------+------------+
7.1.1.3. Authentication Sub-Registry
The "CDNI Metadata Auth" namespace defines the valid Auth object
types used by the Auth object in Section 4.2.6. Additions to the
Footprint type namespace MUST conform to the "Expert Review" policy
as defined in [RFC5226]. 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 name | definition |
+------------------+------------------------------------------------+
| credentials | Simple username and password authentication as |
| | defined by Section 4.2.6.1. |
+------------------+------------------------------------------------+
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
skipping to change at page 39, line 15 skipping to change at page 38, line 24
[RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S., [RFC2617] Franks, J., Hallam-Baker, P., Hostetler, J., Lawrence, S.,
Leach, P., Luotonen, A., and L. Stewart, "HTTP Leach, P., Luotonen, A., and L. Stewart, "HTTP
Authentication: Basic and Digest Access Authentication", Authentication: Basic and Digest Access Authentication",
RFC 2617, June 1999. RFC 2617, June 1999.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing
Architecture", RFC 4291, February 2006. Architecture", RFC 4291, February 2006.
[RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an
IANA Considerations Section in RFCs", BCP 26, RFC 5226,
May 2008.
[RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6
Address Text Representation", RFC 5952, August 2010. Address Text Representation", RFC 5952, August 2010.
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.
skipping to change at page 40, line 33 skipping to change at page 39, line 47
Requirement META-7 relating to modification of metadata by the Requirement META-7 relating to modification of metadata by the
upstream CDN is met both by allowing timeouts on the cacheability of upstream CDN is met both by allowing timeouts on the cacheability of
metadata objects and by allowing other CDNI interfaces to initiate a metadata objects and by allowing other CDNI interfaces to initiate a
refetch or purge of metadata. refetch or purge of metadata.
Requirement META-18 relating to surrogate cache behavior parameters Requirement META-18 relating to surrogate cache behavior parameters
is supported via extensibility. However, the example parameters in is supported via extensibility. However, the example parameters in
META-18 are not described in this document. META-18 are not described in this document.
Appendix B. Metadata Rewriting
For some use cases, one CDN in a chain of interconnected CDNs must be
able to rewrite CDNI Metadata received from its upstream CDN before
presenting that CDNI Metadata to its downstream CDN.
The CDN which is performing the metadata rewriting is referred to as
the 'Transit' CDN (tCDN), its upstream CDN as the uCDN and its
downstream CDN as the dCDN.
Two (non-exhaustive) examples of when rewriting are:
Allowing the dCDN is to acquire content from the tCDN instead of
(or as well as) the uCDN. The tCDN must modify the appropriate
CDNI Source Metadata objects to include itself as a possible
source for the content.
If the tCDN is transforming the original URI as part of CDNI
request redirection on-route to the dCDN, the tCDN may need to
modify the PatternMatch objects in any PathMetadata to take
account of any URI path transformation it has performed.
When performing HTTP redirection between CDNs, the dCDN must be able
to map an UA request to a host and path which are meaningful to the
tCDN. The dCDN needs only to identify its immediate upstream
neighbor and does not need to map (or understand) the entire chain of
CDNs that precede the tCDN.
A dCDN may encode the identity of the tCDN in the URI it returns to
the UA as part of request redirection (either directly or via the
CDNI Request Routing Redirection interface). The exact method the
dCDN uses to encode the information it requires is a local
implementation decision provided it enables the dCDN to identify the
correct upstream CDN (tCDN) and to map the request to the appropriate
host and path so that the dCDN can find and retrieve the correct CDNI
Metadata from tCDN.
B.1. Example
The example in this section is not necessarily representative of URL
rewriting in practice.
The UA requests the following URI from the uCDN:
http://video.example/foo/bar
The uCDN makes a CDNI Request Routing Redirection request to tCDN and
tCDN returns a redirection URI of:
http://tcdn.example/tcdn-prefix/foo/bar
The tcdn-prefix/ encodes sufficient information for tCDN to identify
uCDN as its upstream CDN neighbor. The tCDN makes a CDNI Request
Routing Redirection request to dCDN and dCDN returns a redirection
URI of:
http://dcdn.example/dcdn-prefix/tcdn-prefix/foo/bar
Therefore when dCDN receives a request for:
http://dcdn.example/dcdn-prefix/tcdn-prefix/foo/bar
The dCDN can use /dcdn-prefix/ to identify tCDN as its upstream CDN
neighbor and reconstruct the URI tCDN expects. The tCDN can in turn
use /tcdn-prefix/ to identify uCDN as its upstream CDN neighbour and
reconstruct the URI uCDN expects.
Authors' Addresses Authors' Addresses
Ben Niven-Jenkins Ben Niven-Jenkins
Velocix (Alcatel-Lucent) Velocix (Alcatel-Lucent)
3 Ely Road 3 Ely Road
Milton, Cambridge CB24 6AA Milton, Cambridge CB24 6AA
UK UK
Email: ben@velocix.com Email: ben@velocix.com
Rob Murray Rob Murray
Velocix (Alcatel-Lucent) Velocix (Alcatel-Lucent)
 End of changes. 61 change blocks. 
356 lines changed or deleted 244 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/