From 4bfd864f10b68b71482b35c818559068ef8d5797 Mon Sep 17 00:00:00 2001 From: Thomas Voss Date: Wed, 27 Nov 2024 20:54:24 +0100 Subject: doc: Add RFC documents --- doc/rfc/rfc8006.txt | 3699 +++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 3699 insertions(+) create mode 100644 doc/rfc/rfc8006.txt (limited to 'doc/rfc/rfc8006.txt') diff --git a/doc/rfc/rfc8006.txt b/doc/rfc/rfc8006.txt new file mode 100644 index 0000000..9e9c522 --- /dev/null +++ b/doc/rfc/rfc8006.txt @@ -0,0 +1,3699 @@ + + + + + + +Internet Engineering Task Force (IETF) B. Niven-Jenkins +Request for Comments: 8006 R. Murray +Category: Standards Track Nokia +ISSN: 2070-1721 M. Caulfield + Cisco Systems + K. Ma + Ericsson + December 2016 + + + Content Delivery Network Interconnection (CDNI) Metadata + +Abstract + + The Content Delivery Network Interconnection (CDNI) Metadata + interface enables interconnected Content Delivery Networks (CDNs) to + exchange content distribution metadata in order to enable content + acquisition and delivery. The CDNI Metadata associated with a piece + of content provides a downstream CDN with sufficient information for + the downstream CDN to service content requests on behalf of an + upstream CDN. This document describes both a base set of CDNI + Metadata and the protocol for exchanging that metadata. + +Status of This Memo + + This is an Internet Standards Track document. + + This document is a product of the Internet Engineering Task Force + (IETF). It represents the consensus of the IETF community. It has + received public review and has been approved for publication by the + Internet Engineering Steering Group (IESG). Further information on + Internet Standards is available in Section 2 of RFC 7841. + + Information about the current status of this document, any errata, + and how to provide feedback on it may be obtained at + http://www.rfc-editor.org/info/rfc8006. + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 1] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +Copyright Notice + + Copyright (c) 2016 IETF Trust and the persons identified as the + document authors. All rights reserved. + + This document is subject to BCP 78 and the IETF Trust's Legal + Provisions Relating to IETF Documents + (http://trustee.ietf.org/license-info) in effect on the date of + publication of this document. Please review these documents + carefully, as they describe your rights and restrictions with respect + to this document. Code Components extracted from this document must + include Simplified BSD License text as described in Section 4.e of + the Trust Legal Provisions and are provided without warranty as + described in the Simplified BSD License. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 2] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +Table of Contents + + 1. Introduction ....................................................5 + 1.1. Terminology ................................................5 + 1.2. Supported Metadata Capabilities ............................6 + 2. Design Principles ...............................................7 + 3. CDNI Metadata Object Model ......................................8 + 3.1. HostIndex, HostMatch, HostMetadata, PathMatch, + PatternMatch, and PathMetadata Objects .....................9 + 3.2. Generic CDNI Metadata Objects .............................11 + 3.3. Metadata Inheritance and Override .........................14 + 4. CDNI Metadata Objects ..........................................15 + 4.1. Definitions of the CDNI Structural Metadata Objects .......16 + 4.1.1. HostIndex ..........................................16 + 4.1.2. HostMatch ..........................................17 + 4.1.3. HostMetadata .......................................18 + 4.1.4. PathMatch ..........................................19 + 4.1.5. PatternMatch .......................................20 + 4.1.6. PathMetadata .......................................21 + 4.1.7. GenericMetadata ....................................23 + 4.2. Definitions of the Initial Set of CDNI + GenericMetadata Objects ...................................24 + 4.2.1. SourceMetadata .....................................24 + 4.2.1.1. Source ....................................25 + 4.2.2. LocationACL Metadata ...............................26 + 4.2.2.1. LocationRule ..............................28 + 4.2.2.2. Footprint .................................29 + 4.2.3. TimeWindowACL ......................................30 + 4.2.3.1. TimeWindowRule ............................31 + 4.2.3.2. TimeWindow ................................32 + 4.2.4. ProtocolACL Metadata ...............................33 + 4.2.4.1. ProtocolRule ..............................34 + 4.2.5. DeliveryAuthorization Metadata .....................35 + 4.2.6. Cache ..............................................35 + 4.2.7. Auth ...............................................37 + 4.2.8. Grouping ...........................................38 + 4.3. CDNI Metadata Simple Data Type Descriptions ...............39 + 4.3.1. Link ...............................................39 + 4.3.1.1. Link Loop Prevention ......................40 + 4.3.2. Protocol ...........................................40 + 4.3.3. Endpoint ...........................................40 + 4.3.4. Time ...............................................41 + 4.3.5. IPv4CIDR ...........................................41 + 4.3.6. IPv6CIDR ...........................................42 + 4.3.7. ASN ................................................42 + 4.3.8. Country Code .......................................42 + 5. CDNI Metadata Capabilities .....................................42 + + + + +Niven-Jenkins, et al. Standards Track [Page 3] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + 6. CDNI Metadata Interface ........................................43 + 6.1. Transport .................................................44 + 6.2. Retrieval of CDNI Metadata Resources ......................44 + 6.3. Bootstrapping .............................................45 + 6.4. Encoding ..................................................46 + 6.5. Extensibility .............................................46 + 6.6. Metadata Enforcement ......................................47 + 6.7. Metadata Conflicts ........................................47 + 6.8. Versioning ................................................48 + 6.9. Media Types ...............................................49 + 6.10. Complete CDNI Metadata Example ...........................50 + 7. IANA Considerations ............................................54 + 7.1. CDNI Payload Types ........................................54 + 7.1.1. CDNI MI HostIndex Payload Type .....................54 + 7.1.2. CDNI MI HostMatch Payload Type .....................55 + 7.1.3. CDNI MI HostMetadata Payload Type ..................55 + 7.1.4. CDNI MI PathMatch Payload Type .....................55 + 7.1.5. CDNI MI PatternMatch Payload Type ..................55 + 7.1.6. CDNI MI PathMetadata Payload Type ..................55 + 7.1.7. CDNI MI SourceMetadata Payload Type ................56 + 7.1.8. CDNI MI Source Payload Type ........................56 + 7.1.9. CDNI MI LocationACL Payload Type ...................56 + 7.1.10. CDNI MI LocationRule Payload Type .................56 + 7.1.11. CDNI MI Footprint Payload Type ....................56 + 7.1.12. CDNI MI TimeWindowACL Payload Type ................57 + 7.1.13. CDNI MI TimeWindowRule Payload Type ...............57 + 7.1.14. CDNI MI TimeWindow Payload Type ...................57 + 7.1.15. CDNI MI ProtocolACL Payload Type ..................57 + 7.1.16. CDNI MI ProtocolRule Payload Type .................57 + 7.1.17. CDNI MI DeliveryAuthorization Payload Type ........58 + 7.1.18. CDNI MI Cache Payload Type ........................58 + 7.1.19. CDNI MI Auth Payload Type .........................58 + 7.1.20. CDNI MI Grouping Payload Type .....................58 + 7.2. "CDNI Metadata Footprint Types" Registry ..................58 + 7.3. "CDNI Metadata Protocol Types" Registry ...................59 + 8. Security Considerations ........................................60 + 8.1. Authentication and Integrity ..............................60 + 8.2. Confidentiality and Privacy ...............................60 + 8.3. Securing the CDNI Metadata Interface ......................61 + 9. References .....................................................62 + 9.1. Normative References ......................................62 + 9.2. Informative References ....................................63 + Acknowledgments ...................................................65 + Contributors ......................................................65 + Authors' Addresses ................................................66 + + + + + + +Niven-Jenkins, et al. Standards Track [Page 4] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +1. Introduction + + Content Delivery Network Interconnection (CDNI) [RFC6707] enables a + downstream Content Delivery Network (dCDN) to service content + requests on behalf of an upstream CDN (uCDN). + + The CDNI Metadata interface (MI) is discussed in [RFC7336] along with + four other interfaces that can be used to compose a CDNI solution + (the CDNI Control interface, the CDNI Request Routing Redirection + interface, the CDNI Footprint & Capabilities Advertisement interface + (FCI), and the CDNI Logging interface). [RFC7336] describes each + interface and the relationships between them. The requirements for + the CDNI Metadata interface are specified in [RFC7337]. + + The CDNI Metadata associated with a piece of content (or with a set + of content) provides a dCDN with sufficient information for servicing + content requests on behalf of a uCDN, in accordance with the policies + defined by the uCDN. + + This document defines a CDNI Metadata interface that enables a dCDN + to obtain CDNI Metadata from a uCDN so that the dCDN can properly + process and respond to: + + o Redirection requests received over the CDNI Request Routing + Redirection interface [RFC7975]. + + o Content requests received directly from User Agents. + + Specifically, this document defines: + + o A data structure for mapping content requests and redirection + requests to CDNI Metadata objects (Sections 3 and 4.1). + + o An initial set of CDNI GenericMetadata objects (Section 4.2). + + o An HTTP web service for the transfer of CDNI Metadata (Section 6). + +1.1. Terminology + + This document reuses the terminology defined in [RFC6707]. + + Additionally, the following terms are used throughout this document + and are defined as follows: + + o Object - a collection of properties. + + o Property - a key and value pair where the key is a property name + and the value is the property value or another object. + + + +Niven-Jenkins, et al. Standards Track [Page 5] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + This document uses the phrase "[Object] A contains [Object] B" for + simplicity when a strictly accurate phrase would be "[Object] A + contains or references (via a Link object) [Object] B". + + The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", + "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this + document are to be interpreted as described in [RFC2119]. + +1.2. Supported Metadata Capabilities + + Only the metadata for a small set of initial capabilities is + specified in this document. This set provides the minimum amount of + metadata for basic CDN interoperability while still meeting the + requirements set forth by [RFC7337]. + + The following high-level functionality can be configured via the CDNI + Metadata objects specified in Section 4: + + o Acquisition Source: Metadata for allowing a dCDN to fetch content + from a uCDN. + + o Delivery Access Control: Metadata for restricting (or permitting) + access to content based on any of the following factors: + + * Location + + * Time window + + * Delivery protocol + + o Delivery Authorization: Metadata for authorizing dCDN User Agent + requests. + + o Cache Control: Metadata for controlling cache behavior of + the dCDN. + + The metadata encoding described by this document is extensible in + order to allow for future additions to this list. + + The set of metadata specified in this document covers the initial + capabilities above. It is only intended to support CDNI for the + delivery of content by a dCDN using HTTP/1.1 [RFC7230] and for a dCDN + to be able to acquire content from a uCDN using either HTTP/1.1 or + HTTP/1.1 over Transport Layer Security (TLS) [RFC2818]. + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 6] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Supporting CDNI for the delivery of content using unencrypted HTTP/2 + [RFC7540] (as well as for a dCDN to acquire content using unencrypted + HTTP/2 or HTTP/2 over TLS) requires the registration of these + protocol names in the "CDNI Metadata Protocol Types" registry + (Section 7.3). + + Delivery of content using HTTP/1.1 over TLS or HTTP/2 over TLS SHOULD + follow the guidelines set forth in [RFC7525]. Offline configuration + of TLS parameters between CDNs is beyond the scope of this document. + +2. Design Principles + + The CDNI Metadata interface was designed to achieve the following + objectives: + + 1. Cacheability of CDNI Metadata objects; + + 2. Deterministic mapping from redirection requests and content + requests to CDNI Metadata properties; + + 3. Support for DNS redirection as well as application-specific + redirection (for example, HTTP redirection); + + 4. Minimal duplication of CDNI Metadata; and + + 5. Leveraging of existing protocols. + + Cacheability can decrease the latency of acquiring metadata while + maintaining its freshness and can therefore decrease the latency of + serving content requests and redirection requests, without + sacrificing accuracy. The CDNI Metadata interface uses HTTP and its + existing caching mechanisms to achieve CDNI Metadata cacheability. + + Deterministic mapping from content to metadata properties eliminates + ambiguity and ensures that policies are applied consistently by all + dCDNs. + + Support for both HTTP and DNS redirection ensures that the CDNI + Metadata meets the same design principles for both HTTP-based and + DNS-based redirection schemes. + + Minimal duplication of CDNI Metadata improves storage efficiency in + the CDNs. + + Leveraging existing protocols avoids reinventing common mechanisms + such as data structure encoding (by leveraging I-JSON (Internet JSON) + [RFC7493]) and data transport (by leveraging HTTP [RFC7230]). + + + + +Niven-Jenkins, et al. Standards Track [Page 7] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +3. CDNI Metadata Object Model + + The CDNI Metadata object model describes a data structure for mapping + redirection requests and content requests to metadata properties. + Metadata properties describe how to acquire content from a uCDN, + authorize access to content, and deliver content from a dCDN. The + object model relies on the assumption that these metadata properties + can be grouped based on the hostname of the content and subsequently + on the resource path (URI) of the content. The object model + associates a set of CDNI Metadata properties with a hostname to form + a default set of metadata properties for content delivered on behalf + of that hostname. That default set of metadata properties can be + overridden by properties that apply to specific paths within a URI. + + Different hostnames and URI paths will be associated with different + sets of CDNI Metadata properties in order to describe the required + behavior when a dCDN Surrogate or request router is processing User + Agent requests for content at that hostname and URI path. As a + result of this structure, significant commonality could exist between + the CDNI Metadata properties specified for different hostnames, + different URI paths within a hostname, and different URI paths on + different hostnames. For example, the definition of which User Agent + IP addresses should be grouped together into a single network or + geographic location is likely to be common for a number of different + hostnames; although a uCDN is likely to have several different + policies configured to express geo-blocking rules, it is likely that + a single geo-blocking policy could be applied to multiple hostnames + delivered through the CDN. + + In order to enable the CDNI Metadata for a given hostname and URI + path to be decomposed into reusable sets of CDNI Metadata properties, + the CDNI Metadata interface splits the CDNI Metadata into separate + objects. Efficiency is improved by enabling a single CDNI Metadata + object (that is shared across hostnames and/or URI paths) to be + retrieved and stored by a dCDN once, even if it is referenced by the + CDNI Metadata for multiple hostnames and/or URI paths. + + Important Note: Any CDNI Metadata object A that contains another CDNI + Metadata object B can include a Link object specifying a URI that can + be used to retrieve object B, instead of embedding object B within + object A. The remainder of this document uses the phrase "[Object] A + contains [Object] B" for simplicity when a strictly accurate phrase + would be "[Object] A contains or references (via a Link object) + [Object] B". It is generally a deployment choice for the uCDN + implementation to decide when to embed CDNI Metadata objects and when + to reference separate resources via Link objects. + + + + + +Niven-Jenkins, et al. Standards Track [Page 8] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Section 3.1 introduces a high-level description of the HostIndex, + HostMatch, HostMetadata, PathMatch, PatternMatch, and PathMetadata + objects, and describes the relationships between them. + + Section 3.2 introduces a high-level description of the CDNI + GenericMetadata object, which represents the level at which CDNI + Metadata override occurs between HostMetadata and PathMetadata + objects. + + Section 4 describes in detail the specific CDNI Metadata objects and + properties specified by this document that can be contained within a + CDNI GenericMetadata object. + +3.1. HostIndex, HostMatch, HostMetadata, PathMatch, PatternMatch, and + PathMetadata Objects + + The relationships between the HostIndex, HostMatch, HostMetadata, + PathMatch, PatternMatch, and PathMetadata objects are described in + Figure 1. + + +---------+ +---------+ +------------+ + |HostIndex+-(*)->|HostMatch+-(1)->|HostMetadata+-------(*)------+ + +---------+ +---------+ +------+-----+ | + | | + (*) | + | V + --> Contains or references V ***************** + (1) One and only one +---------+ *GenericMetadata* + (*) Zero or more +--->|PathMatch| * Objects * + | +----+---++ ***************** + | | | ^ + (*) (1) (1) +------------+ | + | | +->|PatternMatch| | + | V +------------+ | + | +------------+ | + +--+PathMetadata+-------(*)------+ + +------------+ + + Figure 1: Relationships between CDNI Metadata Objects + (Diagram Representation) + + A HostIndex object (see Section 4.1.1) contains an array of HostMatch + objects (see Section 4.1.2) that contain hostnames (and/or IP + addresses) for which content requests might be delegated to the dCDN. + The HostIndex is the starting point for accessing the uCDN CDNI + Metadata data store. It enables the dCDN to deterministically + discover which CDNI Metadata objects it requires in order to deliver + a given piece of content. + + + +Niven-Jenkins, et al. Standards Track [Page 9] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + The HostIndex links hostnames (and/or IP addresses) to HostMetadata + objects (see Section 4.1.3) via HostMatch objects. A HostMatch + object defines a hostname (or IP address) to match against a + requested host and contains a HostMetadata object. + + HostMetadata objects contain the default GenericMetadata objects (see + Section 4.1.7) required to serve content for that host. When looking + up CDNI Metadata, the dCDN looks up the requested hostname (or IP + address) against the HostMatch entries in the HostIndex; from there, + it can find HostMetadata, which describes the default metadata + properties for each host as well as PathMetadata objects (see + Section 4.1.6), via PathMatch objects (see Section 4.1.4). PathMatch + objects define patterns, contained inside PatternMatch objects (see + Section 4.1.5), to match against the requested URI path. + PatternMatch objects contain the pattern strings and flags that + describe the URI path to which a PathMatch applies. PathMetadata + objects contain the GenericMetadata objects that apply to content + requests matching the defined URI path pattern. PathMetadata + properties override properties previously defined in HostMetadata or + less-specific PathMatch paths. PathMetadata objects can contain + additional PathMatch objects to recursively define more-specific URI + paths to which GenericMetadata properties might be applied. + + A GenericMetadata object contains individual CDNI Metadata objects + that define the specific policies and attributes needed to properly + deliver the associated content. For example, a GenericMetadata + object could describe the source from which a CDN can acquire a piece + of content. The GenericMetadata object is an atomic unit that can be + referenced by HostMetadata or PathMetadata objects. + + For example, if "example.com" is a content provider, a HostMatch + object could include an entry for "example.com" with the URI of the + associated HostMetadata object. The HostMetadata object for + "example.com" describes the metadata properties that apply to + "example.com" and could contain PathMatches for + "example.com/movies/*" and "example.com/music/*", which in turn + reference corresponding PathMetadata objects that contain the + properties for those more-specific URI paths. The PathMetadata + object for "example.com/movies/*" describes the properties that apply + to that URI path. It could also contain a PathMatch object for + "example.com/movies/hd/*", which would reference the corresponding + PathMetadata object for the "example.com/movies/hd/" path prefix. + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 10] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + The relationships in Figure 1 are also represented in tabular format + in Table 1 below. + + +--------------+----------------------------------------------------+ + | Data Object | Objects it contains or references | + +--------------+----------------------------------------------------+ + | HostIndex | 0 or more HostMatch objects. | + | | | + | HostMatch | 1 HostMetadata object. | + | | | + | HostMetadata | 0 or more PathMatch objects. 0 or more | + | | GenericMetadata objects. | + | | | + | PathMatch | 1 PatternMatch object. 1 PathMetadata object. | + | | | + | PatternMatch | Does not contain or reference any other objects. | + | | | + | PathMetadata | 0 or more PathMatch objects. 0 or more | + | | GenericMetadata objects. | + +--------------+----------------------------------------------------+ + + Table 1: Relationships between CDNI Metadata Objects + (Table Representation) + +3.2. Generic CDNI Metadata Objects + + The HostMetadata and PathMetadata objects contain other CDNI Metadata + objects that contain properties that describe how User Agent requests + for content should be processed -- for example, where to acquire the + content from, authorization rules that should be applied, + geo-blocking restrictions, and so on. Each such CDNI Metadata object + is a specialization of a CDNI GenericMetadata object. The + GenericMetadata object abstracts the basic information required for + metadata override and metadata distribution, from the specifics of + any given property (i.e., property semantics, enforcement options, + etc.). + + The GenericMetadata object defines the properties contained within it + as well as whether or not the properties are "mandatory-to-enforce". + If the dCDN does not understand or support a mandatory-to-enforce + property, the dCDN MUST NOT serve the content. If the property is + not mandatory-to-enforce, then that GenericMetadata object can be + safely ignored and the content request can be processed in accordance + with the rest of the CDNI Metadata. + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 11] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Although a CDN MUST NOT serve content to a User Agent if a + mandatory-to-enforce property cannot be enforced, it could still be + safe to redistribute that metadata (the "safe-to-redistribute" + property) to another CDN without modification. For example, in the + cascaded CDN case, a transit CDN (tCDN) could convey + mandatory-to-enforce metadata to a dCDN. For metadata that does not + require customization or translation (i.e., metadata that is + safe-to-redistribute), the data representation received off the wire + MAY be stored and redistributed without being understood or supported + by the tCDN. However, for metadata that requires translation, + transparent redistribution of the uCDN metadata values might not be + appropriate. Certain metadata can be safely, though perhaps not + optimally, redistributed unmodified. For example, a source + acquisition address might not be optimal if transparently + redistributed, but it might still work. + + Redistribution safety MUST be specified for each GenericMetadata + property. If a CDN does not understand or support a given + GenericMetadata property that is not safe-to-redistribute, the CDN + MUST set the "incomprehensible" flag to true for that GenericMetadata + object before redistributing the metadata. The "incomprehensible" + flag signals to a dCDN that the metadata was not properly transformed + by the tCDN. A CDN MUST NOT attempt to use metadata that has been + marked as "incomprehensible" by a uCDN. + + tCDNs MUST NOT change the value of mandatory-to-enforce or + safe-to-redistribute when propagating metadata to a dCDN. Although a + tCDN can set the value of "incomprehensible" to true, a tCDN MUST NOT + change the value of "incomprehensible" from true to false. + + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 12] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Table 2 describes the action to be taken by a tCDN for the different + combinations of mandatory-to-enforce ("MtE") and safe-to-redistribute + ("StR") properties when the tCDN either does or does not understand + the metadata in question: + + +-------+-------+------------+--------------------------------------+ + | MtE | StR | Metadata | Action | + | | | Understood | | + | | | by tCDN | | + +-------+-------+------------+--------------------------------------+ + | False | True | True | Can serve and redistribute. | + | | | | | + | False | True | False | Can serve and redistribute. | + | | | | | + | False | False | False | Can serve. MUST set | + | | | | "incomprehensible" to true when | + | | | | redistributing. | + | | | | | + | False | False | True | Can serve. Can redistribute after | + | | | | transforming the metadata (if the | + | | | | CDN knows how to do so safely); | + | | | | otherwise, MUST set | + | | | | "incomprehensible" to true when | + | | | | redistributing. | + | | | | | + | True | True | True | Can serve and redistribute. | + | | | | | + | True | True | False | MUST NOT serve but can redistribute. | + | | | | | + | True | False | True | Can serve. Can redistribute after | + | | | | transforming the metadata (if the | + | | | | CDN knows how to do so safely); | + | | | | otherwise, MUST set | + | | | | "incomprehensible" to true when | + | | | | redistributing. | + | | | | | + | True | False | False | MUST NOT serve. MUST set | + | | | | "incomprehensible" to true when | + | | | | redistributing. | + +-------+-------+------------+--------------------------------------+ + + Table 2: Action to Be Taken by a tCDN for the + Different Combinations of MtE and StR Properties + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 13] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Table 3 describes the action to be taken by a dCDN for the different + combinations of mandatory-to-enforce and "incomprehensible" (Incomp) + properties, when the dCDN either does or does not understand the + metadata in question: + + +-------+--------+--------------+-----------------------------------+ + | MtE | Incomp | Metadata | Action | + | | | Understood | | + | | | by dCDN | | + +-------+--------+--------------+-----------------------------------+ + | False | False | True | Can serve. | + | | | | | + | False | True | True | Can serve but MUST NOT | + | | | | interpret/apply any metadata | + | | | | marked as "incomprehensible". | + | | | | | + | False | False | False | Can serve. | + | | | | | + | False | True | False | Can serve but MUST NOT | + | | | | interpret/apply any metadata | + | | | | marked as "incomprehensible". | + | | | | | + | True | False | True | Can serve. | + | | | | | + | True | True | True | MUST NOT serve. | + | | | | | + | True | False | False | MUST NOT serve. | + | | | | | + | True | True | False | MUST NOT serve. | + +-------+--------+--------------+-----------------------------------+ + + Table 3: Action to Be Taken by a dCDN for the + Different Combinations of MtE and Incomp Properties + +3.3. Metadata Inheritance and Override + + In the metadata object model, a HostMetadata object can contain + multiple PathMetadata objects (via PathMatch objects). Each + PathMetadata object can in turn contain other PathMetadata objects. + HostMetadata and PathMetadata objects form an inheritance tree where + each node in the tree inherits or overrides the property values set + by its parent. + + GenericMetadata objects of a given type override all GenericMetadata + objects of the same type previously defined by any parent object in + the tree. GenericMetadata objects of a given type previously defined + by a parent object in the tree are inherited when no object of the + same type is defined by the child object. For example, if + + + +Niven-Jenkins, et al. Standards Track [Page 14] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + HostMetadata for the host "example.com" contains GenericMetadata + objects of types LocationACL and TimeWindowACL (where "ACL" means + "Access Control List") while a PathMetadata object that applies to + "example.com/movies/*" defines an alternate GenericMetadata object of + type TimeWindowACL, then: + + o The TimeWindowACL defined in the PathMetadata would override the + TimeWindowACL defined in the HostMetadata for all User Agent + requests for content under "example.com/movies/", and + + o The LocationACL defined in the HostMetadata would be inherited for + all User Agent requests for content under "example.com/movies/". + + A single HostMetadata or PathMetadata object MUST NOT contain + multiple GenericMetadata objects of the same type. If an array of + GenericMetadata contains objects of duplicate types, the receiver + MUST ignore all but the first object of each type. + +4. CDNI Metadata Objects + + Section 4.1 provides the definitions of each metadata object type + introduced in Section 3. These metadata objects are described as + structural metadata objects, as they provide the structure for host + and URI path-based inheritance and identify which GenericMetadata + objects apply to a given User Agent content request. + + Section 4.2 provides the definitions for a base set of core metadata + objects that can be contained within a GenericMetadata object. These + metadata objects govern how User Agent requests for content are + handled. GenericMetadata objects can contain other GenericMetadata + objects as properties; these can be referred to as sub-objects. As + with all CDNI Metadata objects, the value of the GenericMetadata + sub-objects can be either a complete serialized representation of the + sub-object or a Link object that contains a URI that can be + dereferenced to retrieve the complete serialized representation of + the property sub-object. + + Section 6.5 discusses the ability to extend the base set of + GenericMetadata objects specified in this document with additional + standards-based or vendor-specific GenericMetadata objects that might + be defined in the future in separate documents. + + dCDNs and tCDNs MUST support the parsing of all CDNI Metadata objects + specified in this document. A dCDN does not have to implement the + underlying functionality represented by non-structural + GenericMetadata objects (though that might restrict the content that + a given dCDN will be able to serve). uCDNs as generators of CDNI + Metadata only need to support generating the CDNI Metadata that they + + + +Niven-Jenkins, et al. Standards Track [Page 15] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + need in order to express the policies required by the content they + are describing. See Section 6.4 for more details on the specific + encoding rules for CDNI Metadata objects. + + Note: In the following sections, the term "mandatory-to-specify" is + used to convey which properties MUST be included for a given + structural or GenericMetadata object. When mandatory-to-specify is + specified as "Yes" for an individual property, it means that if the + object containing that property is included in a metadata response, + then the mandatory-to-specify property MUST also be included + (directly or by reference) in the response. For example, a HostMatch + property object without a host to match against does not make sense; + therefore, the "host" property is mandatory-to-specify inside a + HostMatch object. + +4.1. Definitions of the CDNI Structural Metadata Objects + + The subsections below describe the structural objects introduced in + Section 3.1. + +4.1.1. HostIndex + + The HostIndex object is the entry point into the CDNI Metadata + hierarchy. It contains an array of HostMatch objects. An incoming + content request is checked against the hostname (or IP address) + specified by each of the listed HostMatch objects to find the + HostMatch object that applies to the request. + + Property: hosts + + Description: Array of HostMatch objects. Hosts (HostMatch + objects) MUST be evaluated in the order they appear, and the + first HostMatch object that matches the content request being + processed MUST be used. + + Type: Array of HostMatch objects + + Mandatory-to-Specify: Yes. + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 16] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Example HostIndex object containing two HostMatch objects, where the + first HostMatch object is embedded and the second HostMatch object is + referenced: + + { + "hosts": [ + { + + }, + { + "type": "MI.HostMatch", + "href": "https://metadata.ucdn.example/hostmatch1234" + } + ] + } + +4.1.2. HostMatch + + The HostMatch object contains a hostname or IP address to match + against content requests. The HostMatch object also contains a + HostMetadata object to apply if a match is found. + + Property: host + + Description: Hostname or IP address and optional port to match + against the requested host, i.e., the host and port as + described in [RFC3986]. In order for a hostname or IP address + in a content request to match the hostname or IP address in the + "host" property, the value from the content request when + converted to lowercase MUST be identical to the value of the + "host" property when converted to lowercase. All + implementations MUST support IPv4 addresses encoded as + specified by the "IPv4address" rule in Section 3.2.2 of + [RFC3986]. IPv6 addresses MUST be encoded in one of the IPv6 + address formats specified in [RFC5952], although receivers MUST + support all IPv6 address formats specified in [RFC4291]. + Hostnames MUST conform to the Domain Name System (DNS) syntax + defined in [RFC1034] and [RFC1123]. Internationalized Domain + Names (IDNs) must first be transformed to the A-label form + [RFC5890] as per [RFC5891]. + + Type: Endpoint + + Mandatory-to-Specify: Yes. + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 17] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Property: host-metadata + + Description: CDNI Metadata to apply when delivering content + that matches this host. + + Type: HostMetadata + + Mandatory-to-Specify: Yes. + + Example HostMatch object with an embedded HostMetadata object: + + { + "host": "video.example.com", + "host-metadata": { + + } + } + + Example HostMatch object referencing (via a Link object; see + Section 4.3.1) a HostMetadata object: + + { + "host": "video.example.com", + "host-metadata": { + "type": "MI.HostMetadata", + "href": "https://metadata.ucdn.example/host1234" + } + } + +4.1.3. HostMetadata + + A HostMetadata object contains the CDNI Metadata properties for + content served for a particular host (defined in the HostMatch + object) and possibly child PathMatch objects. + + Property: metadata + + Description: Array of host-related metadata. + + Type: Array of GenericMetadata objects + + Mandatory-to-Specify: Yes. + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 18] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Property: paths + + Description: Path-specific rules. Path patterns (PathMatch + objects) MUST be evaluated in the order they appear, and the + first (and only the first) PathMatch object that matches the + content request being processed MUST be used. + + Type: Array of PathMatch objects + + Mandatory-to-Specify: No. Default is that there are no + more-specific paths to evaluate (i.e., an empty list). + + Example HostMetadata object containing a number of embedded + GenericMetadata objects that will describe the default metadata for + the host and an embedded PathMatch object that contains a path for + which metadata exists that overrides the default metadata for the + host: + + { + "metadata": [ + { + + }, + { + + }, + + ... + + { + + } + ], + "paths": [ + { + + } + ] + } + +4.1.4. PathMatch + + A PathMatch object contains a PatternMatch object with a path to + match against a resource's URI path, as well as how to handle URI + query parameters. The PathMatch object also contains a PathMetadata + object with GenericMetadata to apply if the resource's URI matches + the pattern within the PatternMatch object. + + + + +Niven-Jenkins, et al. Standards Track [Page 19] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Property: path-pattern + + Description: Pattern to match against the requested + resource's URI. + + Type: PatternMatch + + Mandatory-to-Specify: Yes. + + Property: path-metadata + + Description: CDNI Metadata to apply when delivering content + that matches the associated PatternMatch. + + Type: PathMetadata + + Mandatory-to-Specify: Yes. + + Example PathMatch object referencing the PathMetadata object to use + for URIs that match the case-sensitive URI path pattern "/movies/*" + (contained within an embedded PatternMatch object): + + { + "path-pattern": { + "pattern": "/movies/*", + "case-sensitive": true + }, + "path-metadata": { + "type": "MI.PathMetadata", + "href": "https://metadata.ucdn.example/host1234/pathDCE" + } + } + +4.1.5. PatternMatch + + A PatternMatch object contains the pattern string and flags that + describe the pattern expression. + + Property: pattern + + Description: A pattern for matching against the URI path, i.e., + against the path-absolute [RFC3986]. The pattern can contain + the wildcards "*" and "?", where "*" matches any sequence of + pchar [RFC3986] or "/" characters (including the empty string) + and "?" matches exactly one pchar character. The three + literals "$", "*", and "?" MUST be escaped as "$$", "$*", and + "$?" (where "$" is the designated escape character). All other + characters are treated as literals. + + + +Niven-Jenkins, et al. Standards Track [Page 20] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Type: String + + Mandatory-to-Specify: Yes. + + Property: case-sensitive + + Description: Flag indicating whether or not case-sensitive + matching should be used. Note: Case insensitivity applies to + ALPHA characters in the URI path prior to percent-decoding + [RFC3986]. + + Type: Boolean + + Mandatory-to-Specify: No. Default is case-insensitive match + (i.e., a value of False). + + Example PatternMatch object that matches the case-sensitive URI path + pattern "/movies/*": + + { + "pattern": "/movies/*", + "case-sensitive": true + } + +4.1.6. PathMetadata + + A PathMetadata object contains the CDNI Metadata properties for + content requests that match against the associated URI path (defined + in a PathMatch object). + + Note that if DNS-based redirection is employed, then a dCDN will be + unable to evaluate any metadata at the PathMetadata level or below + because only the hostname of the content request is available at + Request Routing time. dCDNs SHOULD still process all PathMetadata + for the host before responding to the redirection request to detect + if any unsupported metadata is specified. If any metadata not + supported by the dCDN is marked as mandatory-to-enforce, the dCDN + SHOULD NOT accept the content redirection request, in order to avoid + receiving content requests that it will not be able to satisfy/serve. + + Property: metadata + + Description: Array of path-related metadata. + + Type: Array of GenericMetadata objects + + Mandatory-to-Specify: Yes. + + + + +Niven-Jenkins, et al. Standards Track [Page 21] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Property: paths + + Description: Path-specific rules. Path patterns (PathMatch + objects) MUST be evaluated in the order they appear, and the + first (and only the first) PathMatch object that matches the + content request being processed MUST be used. + + Type: Array of PathMatch objects + + Mandatory-to-Specify: No. Default is that there are no + more-specific paths to evaluate (i.e., an empty list). + + Example PathMetadata object containing a number of embedded + GenericMetadata objects that describe the metadata to apply for the + URI path defined in the parent PathMatch object, as well as a + more-specific PathMatch object. + + { + "metadata": [ + { + + }, + { + + }, + + ... + + { + + } + ], + "paths": [ + { + + } + ] + } + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 22] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +4.1.7. GenericMetadata + + A GenericMetadata object is a wrapper for managing individual CDNI + Metadata properties in an opaque manner. + + Property: generic-metadata-type + + Description: Case-insensitive CDNI Metadata object type. + + Type: String containing the CDNI Payload Type [RFC7736] of the + object contained in the generic-metadata-value property (see + Table 4). + + Mandatory-to-Specify: Yes. + + Property: generic-metadata-value + + Description: CDNI Metadata object. + + Type: Format/Type is defined by the value of the + generic-metadata-type property above. + Note: generic-metadata-values MUST NOT name any properties + "href" (see Section 4.3.1). + + Mandatory-to-Specify: Yes. + + Property: mandatory-to-enforce + + Description: Flag identifying whether or not the enforcement of + the property metadata is required. + + Type: Boolean + + Mandatory-to-Specify: No. Default is to treat metadata as + mandatory-to-enforce (i.e., a value of True). + + Property: safe-to-redistribute + + Description: Flag identifying whether or not the property + metadata can be safely redistributed without modification. + + Type: Boolean + + Mandatory-to-Specify: No. Default is to allow transparent + redistribution (i.e., a value of True). + + + + + + +Niven-Jenkins, et al. Standards Track [Page 23] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Property: incomprehensible + + Description: Flag identifying whether or not any CDN in the + chain of delegation has failed to understand and/or failed to + properly transform this metadata object. Note: This flag only + applies to metadata objects whose safe-to-redistribute property + has a value of False. + + Type: Boolean + + Mandatory-to-Specify: No. Default is comprehensible (i.e., a + value of False). + + Example GenericMetadata object containing a metadata object that + applies to the applicable URI path and/or host (within a parent + PathMetadata and/or HostMetadata object, respectively): + + { + "mandatory-to-enforce": true, + "safe-to-redistribute": true, + "incomprehensible": false, + "generic-metadata-type": , + "generic-metadata-value": + { + + } + } + +4.2. Definitions of the Initial Set of CDNI GenericMetadata Objects + + The objects defined below are intended to be used in the + GenericMetadata object's generic-metadata-value field as defined in + Section 4.1.7, and their generic-metadata-type property MUST be set + to the appropriate CDNI Payload Type as defined in Table 4. + +4.2.1. SourceMetadata + + Source metadata provides the dCDN with information about content + acquisition, i.e., how to contact a uCDN Surrogate or an origin + server to obtain the content to be served. The sources are not + necessarily the actual origin servers operated by the Content Service + Provider (CSP) but might be a set of Surrogates in the uCDN. + + Property: sources + + Description: Sources from which the dCDN can acquire content, + listed in order of preference. + + + + +Niven-Jenkins, et al. Standards Track [Page 24] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Type: Array of Source objects (see Section 4.2.1.1) + + Mandatory-to-Specify: No. Default is to use static + configuration, out-of-band from the CDNI Metadata interface. + + Example SourceMetadata object (which contains two Source objects) + that describes which servers the dCDN should use for acquiring + content for the applicable URI path and/or host: + + { + "generic-metadata-type": "MI.SourceMetadata", + "generic-metadata-value": + { + "sources": [ + { + "endpoints": [ + "a.service123.ucdn.example", + "b.service123.ucdn.example" + ], + "protocol": "http/1.1" + }, + { + "endpoints": ["origin.service123.example"], + "protocol": "http/1.1" + } + ] + } + } + +4.2.1.1. Source + + A Source object describes the source to be used by the dCDN for + content acquisition (e.g., a Surrogate within the uCDN or an + alternate origin server), the protocol to be used, and any + authentication method to be used when contacting that source. + + Endpoints within a Source object MUST be treated as equivalent/equal. + A uCDN can specify an array of sources, ordered by preference, within + a SourceMetadata object. Then, for each Source object ranked by + preference, a uCDN can specify an array of endpoints that are + equivalent (e.g., a pool of servers that are not behind a load + balancer). + + Property: acquisition-auth + + Description: Authentication method to use when requesting + content from this source. + + + + +Niven-Jenkins, et al. Standards Track [Page 25] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Type: Auth (see Section 4.2.7) + + Mandatory-to-Specify: No. Default is no authentication + required. + + Property: endpoints + + Description: Origins from which the dCDN can acquire content. + If multiple endpoints are specified, they are all equal, i.e., + the list is not ordered by preference. + + Type: Array of Endpoint objects (see Section 4.3.3) + + Mandatory-to-Specify: Yes. + + Property: protocol + + Description: Network retrieval protocol to use when requesting + content from this source. + + Type: Protocol (see Section 4.3.2) + + Mandatory-to-Specify: Yes. + + Example Source object that describes a pair of endpoints (servers) + the dCDN can use for acquiring content for the applicable host and/or + URI path: + + { + "endpoints": [ + "a.service123.ucdn.example", + "b.service123.ucdn.example" + ], + "protocol": "http/1.1" + } + +4.2.2. LocationACL Metadata + + LocationACL metadata defines which locations a User Agent needs to be + in, in order to be able to receive the associated content. + + A LocationACL that does not include a "locations" property results in + an action of "allow all", meaning that delivery can be performed + regardless of the User Agent's location; otherwise, a CDN MUST take + the action from the first footprint to match against the User Agent's + location. If two or more footprints overlap, the first footprint + that matches against the User Agent's location determines the action + + + + +Niven-Jenkins, et al. Standards Track [Page 26] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + a CDN MUST take. If the "locations" property is included but is + empty or if none of the listed footprints match the User Agent's + location, then the result is an action of "deny". + + Although the LocationACL, TimeWindowACL (see Section 4.2.3), and + ProtocolACL (see Section 4.2.4) are independent GenericMetadata + objects, they can provide conflicting information to a dCDN, e.g., a + content request that is simultaneously allowed based on the + LocationACL and denied based on the TimeWindowACL. The dCDN MUST use + the logical AND of all ACLs (where "allow" is true and "deny" is + false) to determine whether or not a request should be allowed. + + Property: locations + + Description: ACL that allows or denies (blocks) delivery based + on the User Agent's location. + + Type: Array of LocationRule objects (see Section 4.2.2.1) + + Mandatory-to-Specify: No. Default is to allow all locations. + + Example LocationACL object that allows the dCDN to deliver content to + any location / IP address: + + { + "generic-metadata-type": "MI.LocationACL", + "generic-metadata-value": + { + } + } + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 27] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Example LocationACL object (which contains a LocationRule object that + in turn contains a Footprint object) that only allows the dCDN to + deliver content to User Agents in the USA: + + { + "generic-metadata-type": "MI.LocationACL", + "generic-metadata-value": + { + "locations": [ + { + "action": "allow", + "footprints": [ + { + "footprint-type": "countrycode", + "footprint-value": ["us"] + } + ] + } + ] + } + } + +4.2.2.1. LocationRule + + A LocationRule contains or references an array of Footprint objects + and the corresponding action. + + Property: footprints + + Description: Array of footprints to which the rule applies. + + Type: Array of Footprint objects (see Section 4.2.2.2) + + Mandatory-to-Specify: Yes. + + Property: action + + Description: Defines whether the rule specifies locations to + allow or deny. + + Type: Enumeration [allow|deny] encoded as a lowercase string + + Mandatory-to-Specify: No. Default is "deny". + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 28] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Example LocationRule object (which contains a Footprint object) that + allows the dCDN to deliver content to clients in the USA: + + { + "action": "allow", + "footprints": [ + { + "footprint-type": "countrycode", + "footprint-value": ["us"] + } + ] + } + +4.2.2.2. Footprint + + A Footprint object describes the footprint to which a LocationRule + can be applied, e.g., an IPv4 address range or a geographic location. + + Property: footprint-type + + Description: Registered footprint type (see Section 7.2). The + footprint types specified by this document are "ipv4cidr" + (IPv4CIDR; see Section 4.3.5), "ipv6cidr" (IPv6CIDR; see + Section 4.3.6), "asn" (Autonomous System Number; see + Section 4.3.7), and "countrycode" (Country Code; see + Section 4.3.8). + + Type: Lowercase string + + Mandatory-to-Specify: Yes. + + Property: footprint-value + + Description: Array of footprint values conforming to the + specification associated with the registered footprint type. + Footprint values can be simple strings (e.g., IPv4CIDR, + IPv6CIDR, ASN, and Country Code); however, other Footprint + objects can be defined in the future, along with a more complex + encoding (e.g., GPS coordinate tuples). + + Type: Array of footprints + + Mandatory-to-Specify: Yes. + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 29] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Example Footprint object describing a footprint covering the USA: + + { + "footprint-type": "countrycode", + "footprint-value": ["us"] + } + + Example Footprint object describing a footprint covering the IP + address ranges 192.0.2.0/24 and 198.51.100.0/24: + + { + "footprint-type": "ipv4cidr", + "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"] + } + + Example Footprint object describing a footprint covering the IP + address ranges 2001:db8::/32: + + { + "footprint-type": "ipv6cidr", + "footprint-value": ["2001:db8::/32"] + } + + Example Footprint object describing a footprint covering the + autonomous system 64496: + + { + "footprint-type": "asn", + "footprint-value": ["as64496"] + } + +4.2.3. TimeWindowACL + + TimeWindowACL metadata defines time-based restrictions. + + A TimeWindowACL that does not include a "times" property results in + an action of "allow all", meaning that delivery can be performed + regardless of the time of the User Agent's request; otherwise, a CDN + MUST take the action from the first window to match against the + current time. If two or more windows overlap, the first window that + matches against the current time determines the action a CDN MUST + take. If the "times" property is included but is empty or if none of + the listed windows match the current time, then the result is an + action of "deny". + + Although the LocationACL (see Section 4.2.2), TimeWindowACL, and + ProtocolACL (see Section 4.2.4) are independent GenericMetadata + objects, they can provide conflicting information to a dCDN, e.g., + + + +Niven-Jenkins, et al. Standards Track [Page 30] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + a content request that is simultaneously allowed based on the + LocationACL and denied based on the TimeWindowACL. The dCDN MUST use + the logical AND of all ACLs (where "allow" is true and "deny" is + false) to determine whether or not a request should be allowed. + + Property: times + + Description: ACL that allows or denies (blocks) delivery based + on the time of a User Agent's request. + + Type: Array of TimeWindowRule objects (see Section 4.2.3.1) + + Mandatory-to-Specify: No. Default is to allow all time + windows. + + Example TimeWindowACL object (which contains a TimeWindowRule object + that in turn contains a TimeWindow object) that only allows the dCDN + to deliver content to clients between 09:00 01/01/2000 UTC and 17:00 + 01/01/2000 UTC: + + { + "generic-metadata-type": "MI.TimeWindowACL", + "generic-metadata-value": + { + "times": [ + { + "action": "allow", + "windows": [ + { + "start": 946717200, + "end": 946746000 + } + ] + } + ] + } + } + +4.2.3.1. TimeWindowRule + + A TimeWindowRule contains or references an array of TimeWindow + objects and the corresponding action. + + Property: windows + + Description: Array of time windows to which the rule applies. + + Type: Array of TimeWindow objects (see Section 4.2.3.2) + + + +Niven-Jenkins, et al. Standards Track [Page 31] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Mandatory-to-Specify: Yes. + + Property: action + + Description: Defines whether the rule specifies time windows to + allow or deny. + + Type: Enumeration [allow|deny] encoded as a lowercase string + + Mandatory-to-Specify: No. Default is "deny". + + Example TimeWindowRule object (which contains a TimeWindow object) + that only allows the dCDN to deliver content to clients between 09:00 + 01/01/2000 UTC and 17:00 01/01/2000 UTC: + + { + "action": "allow", + "windows": [ + { + "start": 946717200, + "end": 946746000 + } + ] + } + +4.2.3.2. TimeWindow + + A TimeWindow object describes a time range that can be applied by a + TimeWindowACL, e.g., start 946717200 (i.e., 09:00 01/01/2000 UTC), + end: 946746000 (i.e., 17:00 01/01/2000 UTC). + + Property: start + + Description: The start time of the window. + + Type: Time (see Section 4.3.4) + + Mandatory-to-Specify: Yes. + + Property: end + + Description: The end time of the window. + + Type: Time (see Section 4.3.4) + + Mandatory-to-Specify: Yes. + + + + + +Niven-Jenkins, et al. Standards Track [Page 32] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Example TimeWindow object that describes a time window from 09:00 + 01/01/2000 UTC to 17:00 01/01/2000 UTC: + + { + "start": 946717200, + "end": 946746000 + } + +4.2.4. ProtocolACL Metadata + + ProtocolACL metadata defines delivery protocol restrictions. + + A ProtocolACL that does not include a protocol-acl property results + in an action of "allow all", meaning that delivery can be performed + regardless of the protocol in the User Agent's request; otherwise, a + CDN MUST take the action from the first protocol to match against the + request protocol. If two or more request protocols overlap, the + first protocol that matches the request protocol determines the + action a CDN MUST take. If the protocol-acl property is included but + is empty or if none of the listed protocols match the request + protocol, then the result is an action of "deny". + + Although the LocationACL (see Section 4.2.2), TimeWindowACL (see + Section 4.2.3), and ProtocolACL are independent GenericMetadata + objects, they can provide conflicting information to a dCDN, e.g., a + content request that is simultaneously allowed based on the + ProtocolACL and denied based on the TimeWindowACL. The dCDN MUST use + the logical AND of all ACLs (where "allow" is true and "deny" is + false) to determine whether or not a request should be allowed. + + Property: protocol-acl + + Description: ACL that allows or denies (blocks) delivery based + on delivery protocol. + + Type: Array of ProtocolRule objects (see Section 4.2.4.1) + + Mandatory-to-Specify: No. Default is to allow all protocols. + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 33] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Example ProtocolACL object (which contains a ProtocolRule object) + that only allows the dCDN to deliver content using HTTP/1.1: + + { + "generic-metadata-type": "MI.ProtocolACL", + "generic-metadata-value": + { + "protocol-acl": [ + { + "action": "allow", + "protocols": ["http/1.1"] + } + ] + } + } + +4.2.4.1. ProtocolRule + + A ProtocolRule contains or references an array of Protocol objects + and the corresponding action. + + Property: protocols + + Description: Array of protocols to which the rule applies. + + Type: Array of Protocol objects (see Section 4.3.2) + + Mandatory-to-Specify: Yes. + + Property: action + + Description: Defines whether the rule specifies protocols to + allow or deny. + + Type: Enumeration [allow|deny] encoded as a lowercase string + + Mandatory-to-Specify: No. Default is "deny". + + Example ProtocolRule object (which contains a Protocol object) that + allows the dCDN to deliver content using HTTP/1.1: + + { + "action": "allow", + "protocols": ["http/1.1"] + } + + + + + + +Niven-Jenkins, et al. Standards Track [Page 34] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +4.2.5. DeliveryAuthorization Metadata + + Delivery authorization defines authorization methods for the delivery + of content to User Agents. + + Property: delivery-auth-methods + + Description: Options for authorizing content requests. + Delivery for a content request is authorized if any one of the + authorization methods in the list is satisfied for that + request. + + Type: Array of Auth objects (see Section 4.2.7) + + Mandatory-to-Specify: No. Default is no authorization + required. + + Example DeliveryAuthorization object (which contains an Auth object): + + { + "generic-metadata-type": "MI.DeliveryAuthorization", + "generic-metadata-value": + { + "delivery-auth-methods": [ + { + "auth-type": , + "auth-value": + { + + } + } + ] + } + } + +4.2.6. Cache + + A Cache object describes the cache control parameters to be applied + to the content by intermediate caches. + + Cache keys are generated from the URI of the content request + [RFC7234]. In some cases, a CDN or content provider might want + certain path segments or query parameters to be excluded from the + cache key generation. The Cache object provides guidance on what + parts of the path and query string to include. + + + + + + +Niven-Jenkins, et al. Standards Track [Page 35] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Property: exclude-path-pattern + + Description: A pattern for matching against the URI path, i.e., + against the path-absolute [RFC3986]. The pattern can contain + the wildcards "*" and "?", where "*" matches any sequence of + pchar [RFC3986] or "/" characters (including the empty string) + and "?" matches exactly one pchar character. The three + literals "$", "*", and "?" MUST be escaped as "$$", "$*", and + "$?" (where "$" is the designated escape character). All other + characters are treated as literals. Cache key generation MUST + only include the portion of the path-absolute that matches the + wildcard portions of the pattern. Note: Inconsistency between + the PatternMatch pattern (Section 4.1.5) and the + exclude-path-pattern can result in inefficient caching. + + Type: String + + Mandatory-to-Specify: No. Default is to use the full URI + path-absolute to generate the cache key. + + Property: include-query-strings + + Description: Allows a Surrogate to specify the URI query string + parameters [RFC3986] to include when comparing the requested + URI against the URIs in its cache for equivalence. Matching + query parameters MUST be case insensitive. If all query + parameters should be ignored, then the list MUST be specified + and MUST be empty. If a query parameter appears multiple times + in the query string, each instance value MUST be aggregated + prior to comparison. For consistent cache key generation, + query parameters SHOULD be evaluated in the order specified in + this array. + + Type: Array of strings + + Mandatory-to-Specify: No. Default is to consider all query + string parameters when comparing URIs. + + Example Cache object that instructs the dCDN to use the full URI path + and ignore all query parameters: + + { + "generic-metadata-type": "MI.Cache", + "generic-metadata-value": + { + "include-query-strings": [] + } + } + + + +Niven-Jenkins, et al. Standards Track [Page 36] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Example Cache object that instructs the dCDN to exclude the "CDNX" + path prefix and only include the (case-insensitive) query parameters + named "mediaid" and "providerid": + + { + "generic-metadata-type": "MI.Cache", + "generic-metadata-value": + { + "exclude-path-pattern": "/CDNX/*", + "include-query-strings": ["mediaid", "providerid"] + } + } + + Example Cache object that instructs the dCDN to exclude the "CDNX" + path prefix but includes all query parameters: + + { + "generic-metadata-type": "MI.Cache", + "generic-metadata-value": + { + "exclude-path-pattern": "/CDNX/*" + } + } + +4.2.7. Auth + + An Auth object defines authentication and authorization methods to be + used during content acquisition and content delivery, respectively. + + Note: This document does not define any Auth methods. Individual + Auth methods are being defined separately (e.g., URI Signing + [CDNI-URI-SIGNING]). The GenericMetadata object that contains Auth + objects is defined herein for convenience and so as not to be + specific to any particular Auth method. + + Property: auth-type + + Description: Auth type (The CDNI Payload Type [RFC7736] of the + GenericMetadata object contained in the auth-value property). + + Type: String + + Mandatory-to-Specify: Yes. + + Property: auth-value + + Description: An object conforming to the specification + associated with the Auth type. + + + +Niven-Jenkins, et al. Standards Track [Page 37] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Type: GenericMetadata object + + Mandatory-to-Specify: Yes. + + Example Auth object: + + { + "generic-metadata-type": "MI.Auth", + "generic-metadata-value": + { + "auth-type": , + "auth-value": + { + + } + } + } + +4.2.8. Grouping + + A Grouping object identifies a group of content to which a given + asset belongs. + + Property: ccid + + Description: Content Collection IDentifier for an application- + specific purpose such as logging aggregation. + + Type: String + + Mandatory-to-Specify: No. Default is not to apply any + grouping. + + Example Grouping object that specifies a Content Collection + IDentifier for the content associated with the Grouping object's + parent HostMetadata and PathMetadata: + + { + "generic-metadata-type": "MI.Grouping", + "generic-metadata-value": + { + "ccid": "ABCD" + } + } + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 38] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +4.3. CDNI Metadata Simple Data Type Descriptions + + This section describes the simple data types that are used for + properties of CDNI Metadata objects. + +4.3.1. Link + + A Link object can be used in place of any of the objects described + above. Link objects can be used to avoid duplication if the same + metadata information is repeated within the metadata tree. When a + Link object replaces another object, its "href" property is set to + the URI of the resource and its "type" property is set to the CDNI + Payload Type of the object it is replacing. + + dCDNs can detect the presence of a Link object by detecting the + presence of a property named "href" within the object. This means + that GenericMetadata types MUST NOT contain a property named "href" + because doing so would conflict with the ability for dCDNs to detect + Link objects being used to reference a GenericMetadata object. + + Property: href + + Description: The URI of the addressable object being + referenced. + + Type: String + + Mandatory-to-Specify: Yes. + + Property: type + + Description: The CDNI Payload Type of the object being + referenced. + + Type: String + + Mandatory-to-Specify: No. If the container specifies the type + (e.g., the HostIndex object contains an array of HostMatch + objects, so a Link object in the list of HostMatch objects must + reference a HostMatch), then it is not necessary to explicitly + specify a type. + + Example Link object referencing a HostMatch object: + + { + "type": "MI.HostMatch", + "href": "https://metadata.ucdn.example/hostmatch1234" + } + + + +Niven-Jenkins, et al. Standards Track [Page 39] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Example Link object referencing a HostMatch object, without an + explicit type, inside a HostIndex object: + + { + "hosts": [ + { + + }, + { + "href": "https://metadata.ucdn.example/hostmatch1234" + } + ] + } + +4.3.1.1. Link Loop Prevention + + When following a link, CDNI Metadata clients SHOULD verify that the + CDNI Payload Type of the object retrieved matches the expected CDNI + Payload Type, as indicated by the Link object or containing property. + For GenericMetadata objects, type checks will prevent self- + references; however, incorrect linking can result in circular + references for structural metadata objects, specifically PathMatch + and PathMetadata objects (Figure 1). To prevent circular references, + CDNI Metadata clients SHOULD verify that no duplicate links occur for + PathMatch or PathMetadata objects. + +4.3.2. Protocol + + Protocol objects are used to specify protocols (from the "CDNI + Metadata Protocol Types" registry; see Section 7.3) for content + acquisition or delivery. + + Type: String + + Example: + + "http/1.1" + +4.3.3. Endpoint + + A hostname (with optional port) or an IP address (with optional + port). + + All implementations MUST support IPv4 addresses encoded as specified + by the "IPv4address" rule in Section 3.2.2 of [RFC3986]. IPv6 + addresses MUST be encoded in one of the IPv6 address formats + specified in [RFC5952], although receivers MUST support all IPv6 + address formats specified in [RFC4291]. Hostnames MUST conform to + + + +Niven-Jenkins, et al. Standards Track [Page 40] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + the Domain Name System (DNS) syntax defined in [RFC1034] and + [RFC1123]. Internationalized Domain Names (IDNs) must first be + transformed to the A-label form [RFC5890] as per [RFC5891]. + + Type: String + + Example hostname: + + "metadata.ucdn.example" + + Example IPv4 address: + + "192.0.2.1" + + Example IPv6 address (with port number): + + "[2001:db8::1]:81" + +4.3.4. Time + + A time value expressed in seconds since the UNIX epoch (i.e., zero + hours, zero minutes, zero seconds, on January 1, 1970) Coordinated + Universal Time (UTC) [POSIX]. + + Type: Integer + + Example time representing 09:00:00 01/01/2000 UTC: + + 946717200 + +4.3.5. IPv4CIDR + + An IPv4address Classless Inter-Domain Routing (CIDR) block encoded as + specified by the "IPv4address" rule in Section 3.2.2 of [RFC3986] + followed by a "/" followed by an unsigned integer representing the + leading bits of the routing prefix (i.e., IPv4 CIDR notation). + Single IP addresses can be expressed as /32. + + Type: String + + Example IPv4CIDR: + + "192.0.2.0/24" + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 41] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +4.3.6. IPv6CIDR + + An IPv6address CIDR block encoded in one of the IPv6 address formats + specified in [RFC5952] followed by a "/" followed by an unsigned + integer representing the leading bits of the routing prefix (i.e., + IPv6 CIDR notation). Single IP addresses can be expressed as /128. + + Type: String + + Example IPv6CIDR: + + "2001:db8::/32" + +4.3.7. ASN + + An ASN value encoded as a string consisting of the characters "as" + (in lowercase) followed by the ASN [RFC6793]. + + Type: String + + Example ASN: + + "as64496" + +4.3.8. Country Code + + An ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase. + + Type: String + + Example Country Code representing the USA: + + "us" + +5. CDNI Metadata Capabilities + + CDNI Metadata is used to convey information pertaining to content + delivery from the uCDN to the dCDN. For optional metadata, it can be + useful for the uCDN to know, prior to delegating any content requests + to a given dCDN, if that dCDN supports the underlying functionality + described by the metadata. If some metadata is mandatory-to-enforce + and the dCDN does not support it, any delegated requests for content + that requires that metadata will fail. The uCDN will likely want to + avoid delegating those requests to that dCDN. Likewise, for any + metadata that might be assigned optional values, it could be useful + for the uCDN to know, prior to delegating any content requests to a + given dCDN, which values that dCDN supports. If the optional value + assigned to a given piece of content's metadata is not supported by + + + +Niven-Jenkins, et al. Standards Track [Page 42] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + the dCDN, any delegated requests for that content can fail, so again + the uCDN is likely to want to avoid delegating those requests to + that dCDN. + + The CDNI Footprint & Capabilities Advertisement interface (FCI) + provides a means of advertising capabilities from the dCDN to the + uCDN [RFC8008]. Support for optional metadata types and values can + be advertised using the FCI. + +6. CDNI Metadata Interface + + This section specifies an interface to enable a dCDN to retrieve CDNI + Metadata objects from a uCDN. + + The interface can be used by a dCDN to retrieve CDNI Metadata objects + in either of two ways: + + o Dynamically, as required by the dCDN to process received requests + -- for example, in response to a query from a uCDN over the CDNI + Request Routing Redirection interface (RI) [RFC7975] or in + response to receiving a request for content from a User Agent. + + o In advance of being required -- for example, in the case of + pre-positioned CDNI Metadata acquisition, initiated through the + "CDNI Control interface / Triggers" (CI/T) interface [RFC8007]. + + The CDNI Metadata interface is built on the principles of HTTP web + services. In particular, this means that requests and responses over + the interface are built around the transfer of representations of + hyperlinked resources. A resource in the context of the CDNI + Metadata interface is any object in the object model (as described in + Sections 3 and 4). + + CDNI Metadata servers (i.e., servers in the uCDN) are free to assign + whatever structure they desire to the URIs for CDNI Metadata objects, + and CDNI Metadata clients MUST NOT make any assumptions regarding the + structure of CDNI Metadata URIs or the mapping between CDNI Metadata + objects and their associated URIs. Any URIs present in the examples + in this document are purely illustrative and are not intended to + impose a definitive structure on CDNI Metadata interface + implementations. + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 43] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +6.1. Transport + + The CDNI Metadata interface uses HTTP as the underlying protocol + transport [RFC7230]. + + The HTTP method in the request defines the operation the request + would like to perform. A server implementation of the CDNI Metadata + interface MUST support the HTTP GET and HEAD methods. + + The corresponding HTTP response returns the status of the operation + in the HTTP status code and returns the current representation of the + resource (if appropriate) in the response body. HTTP responses that + contain a response body SHOULD include an entity-tag (ETag) to enable + validation of cached versions of returned resources. + + As the CDNI Metadata interface builds on top of HTTP, CDNI Metadata + server implementations MAY make use of any HTTP feature when + implementing the CDNI Metadata interface; for example, a CDNI + Metadata server MAY make use of HTTP's caching mechanisms to indicate + that the returned response/representation can be reused without + re-contacting the CDNI Metadata server. + +6.2. Retrieval of CDNI Metadata Resources + + In the general case, a CDNI Metadata server makes CDNI Metadata + objects available via unique URIs; thus, in order to retrieve CDNI + Metadata, a CDNI Metadata client (i.e., a client in the dCDN) first + makes an HTTP GET request for the URI of the HostIndex, which + provides an array of hostnames for which the uCDN can delegate + content delivery to the dCDN. + + In order to retrieve the CDNI Metadata for a particular request, the + CDNI Metadata client processes the received HostIndex object and + finds the corresponding HostMetadata entry (by matching the hostname + in the request against the hostnames listed in the HostMatch + objects). If the HostMetadata is linked (rather than embedded), the + CDNI Metadata client then makes an HTTP GET request for the URI + specified in the "href" property of the Link object, which points to + the HostMetadata object itself. + + In order to retrieve the most specific metadata for a particular + request, the CDNI Metadata client inspects the HostMetadata for + references to more-specific PathMetadata objects (by matching the URI + path in the request against the path-pattern property items in any + PathMatch objects listed in the HostMetadata object). If a + PathMetadata object is found to match (and is linked rather than + embedded), the CDNI Metadata client makes another HTTP GET request + for the PathMetadata. Each PathMetadata object can also include + + + +Niven-Jenkins, et al. Standards Track [Page 44] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + references to additional more-specific metadata. If this is the + case, the CDNI Metadata client continues requesting PathMatch and + PathMetadata objects recursively. The CDNI Metadata client repeats + this approach of processing metadata objects and retrieving (via HTTP + GETs) any linked objects until it has all the metadata objects it + requires in order to process the redirection request from the uCDN or + the content request from a User Agent. + + In cases where a dCDN is not able to retrieve the entire set of CDNI + Metadata associated with a User Agent request, or it has retrieved + that metadata but it is stale according to standard HTTP caching + rules and cannot be revalidated -- for example, because the uCDN is + unreachable or returns an HTTP 4xx or 5xx status in response to some + or all of the dCDN's CDNI Metadata requests -- the dCDN MUST NOT + serve the requested content. + + Where a dCDN is interconnected with multiple uCDNs, the dCDN needs to + determine which uCDN's CDNI Metadata interface should be used to + handle a particular User Agent request. + + When HTTP redirection (e.g., HTTP 302 redirects) is being used + between CDNs, it is expected that the dCDN will be able to determine + the uCDN that redirected a particular request from information + contained in the received request (e.g., via the URI). With + knowledge of which uCDN routed the request, the dCDN can choose the + correct uCDN from which to obtain the HostIndex. Note that the + HostIndexes served by each uCDN can be unique. + + In the case of DNS redirection, there is not always sufficient + information carried in the DNS request from User Agents to determine + the uCDN that redirected a particular request (e.g., when content + from a given host is redirected to a given dCDN by more than one + uCDN); therefore, dCDNs will have to apply local policy when deciding + which uCDN's CDNI Metadata interface to use. + +6.3. Bootstrapping + + The URI for the HostIndex object of a given uCDN needs to be + configured in the dCDN. All other objects/resources are then + discoverable from the HostIndex object by following any links in the + HostIndex object, and through the referenced HostMetadata and + PathMetadata objects and their GenericMetadata sub-objects. + + Manual configuration of the URI for the HostIndex object is outside + the scope of this document. + + + + + + +Niven-Jenkins, et al. Standards Track [Page 45] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +6.4. Encoding + + CDNI Metadata objects MUST be encoded as I-JSON objects [RFC7493] + containing a dictionary of (key,value) pairs where the keys are the + property names and the values are the associated property values. + + The keys of the dictionary are the names of the properties associated + with the object and are therefore dependent on the specific object + being encoded (i.e., dependent on the CDNI Payload Type of the + returned resource). Likewise, the values associated with each + property (dictionary key) are dependent on the specific object being + encoded (i.e., dependent on the CDNI Payload Type of the returned + resource). + + Dictionary keys (properties) in I-JSON are case sensitive. By + convention, any dictionary key (property) defined by this document + (for example, the names of CDNI Metadata object properties) MUST be + lowercase. + +6.5. Extensibility + + The set of GenericMetadata objects can be extended with additional + (standards-based or vendor-specific) metadata objects through the + specification of new GenericMetadata objects. The GenericMetadata + object defined in Section 4.1.7 specifies a type field and a type- + specific value field that allow any metadata to be included in either + the HostMetadata or PathMetadata arrays. + + As with the initial GenericMetadata types defined in Section 4.2, + future GenericMetadata types MUST specify the information necessary + for constructing and decoding the GenericMetadata object. + + Any document that defines a new GenericMetadata type MUST: + + 1. Register the CDNI Payload Type [RFC7736] used to identify the new + GenericMetadata type being specified. + + 2. Define the set of properties associated with the new + GenericMetadata object. GenericMetadata MUST NOT contain a + property named "href" because doing so would conflict with the + ability to detect Link objects (see Section 4.3.1). + + 3. For each property, define a name, description, type, and whether + or not the property is mandatory-to-specify. + + 4. Describe the semantics of the new type, including its purpose, + and provide a use case to which it applies, including an example + encoded in I-JSON. + + + +Niven-Jenkins, et al. Standards Track [Page 46] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + 5. Describe the security and privacy consequences, for both the User + Agent and the CDNs, of the new GenericMetadata object. + + 6. Describe any relation to, conflict with, or obsolescence of other + existing CDNI Metadata objects. + + Note: In the case of vendor-specific extensions, vendor-identifying + CDNI Payload Type names will decrease the possibility of + GenericMetadata type collisions. It is RECOMMENDED that any + vendor-specific extensions use vendor-identifying CDNI Payload Type + names. + +6.6. Metadata Enforcement + + At any given time, the set of GenericMetadata types supported by the + uCDN might not match the set of GenericMetadata types supported by + the dCDN. + + In cases where a uCDN sends metadata containing a GenericMetadata + type that a dCDN does not support, the dCDN MUST enforce the + semantics of the mandatory-to-enforce property. If a dCDN does not + understand or is unable to perform the functions associated with any + mandatory-to-enforce metadata, the dCDN MUST NOT service any requests + for the corresponding content. + + Note: Ideally, uCDNs would not delegate content requests to a dCDN + that does not support the mandatory-to-enforce metadata associated + with the content being requested. However, even if the uCDN has + a priori knowledge of the metadata supported by the dCDN (e.g., via + the FCI or through out-of-band negotiation between CDN operators), + metadata support can fluctuate or be inconsistent (e.g., due to + miscommunication, misconfiguration, or temporary outage). Thus, the + dCDN MUST always evaluate all metadata associated with redirection + and content requests and reject any requests where + mandatory-to-enforce metadata associated with the content cannot be + enforced. + +6.7. Metadata Conflicts + + It is possible that new metadata definitions will obsolete or + conflict with existing GenericMetadata (e.g., a future revision of + the CDNI Metadata interface could redefine the Auth GenericMetadata + object or a custom vendor extension could implement an alternate Auth + metadata option). If multiple metadata (e.g., MI.Auth.v2, + vendor1.Auth, and vendor2.Auth) all conflict with an existing + GenericMetadata object (i.e., MI.Auth) and all are marked as + + + + + +Niven-Jenkins, et al. Standards Track [Page 47] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + mandatory-to-enforce, it could be ambiguous as to which metadata + should be applied, especially in the case of overlapping + functionality. + + As described in Section 3.3, metadata override only applies to + metadata objects of the same exact type found in HostMetadata and + nested PathMetadata structures. The CDNI Metadata interface does not + support enforcement of dependencies between different GenericMetadata + types. It is the responsibility of the CSP and the CDN operators to + ensure that metadata assigned to a given piece of content do not + conflict. + + Note: Because metadata is inherently ordered in HostMetadata and + PathMetadata arrays, as well as in the PathMatch hierarchy, multiple + conflicting metadata types MAY be used; however, metadata hierarchies + SHOULD ensure that independent PathMatch root objects are used to + prevent ambiguous or conflicting metadata definitions. + +6.8. Versioning + + The version of CDNI Metadata objects is conveyed inside the CDNI + Payload Type that is included in either (1) the HTTP Content-Type + header (for example, "Content-Type: application/cdni; + ptype=MI.HostIndex" when retrieved via a link) or (2) in the link + type (Section 4.3.1), generic-metadata-type (Section 4.1.7), or + auth-type (Section 4.2.7) properties in the JSON payload. The CDNI + Payload Type uniquely identifies the specification defining that + object, including any relation to, conflicts with, or obsolescence of + other metadata. There is no explicit version mapping requirement; + however, for ease of understanding, metadata creators SHOULD make new + versions of metadata easily visible via the CDNI Payload Type, e.g., + by appending a version string. Note: A version string is optional on + the first version (e.g., MI.HostIndex) but could be added for + subsequent versions (MI.HostIndex.v2, MI.HostIndex.v3, etc.). + + Except when referenced by a Link object, nested metadata objects + (i.e., structural metadata below the HostIndex; and Source, + LocationRule, TimeWindowRule, ProtocolRule, Footprint, and TimeWindow + objects) can be serialized into a JSON payload without explicit CDNI + Payload Type information. The type is inferred from the outer + structural metadata, GenericMetadata, or Auth object CDNI Payload + Type. To avoid ambiguity when revising nestable metadata objects, + any outer metadata object(s) MUST be reversioned and allocated new + CDNI Payload Type(s) at the same time. For example, the MI.HostIndex + object defined in this document contains an array of MI.HostMatch + objects, each of which in turn contains a MI.HostMetadata object. If + a new MI.HostMetadata.v2 object were required, the outer MI.HostIndex + and MI.HostMatch objects would need to be revised, e.g., to + + + +Niven-Jenkins, et al. Standards Track [Page 48] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + MI.HostIndex.v2 and MI.HostMatch.v2, respectively. Similarly, if a + new MI.TimeWindowRule.v2 object were required, the outer + MI.TimeWindowACL object would need to be revised, e.g., to + MI.TimeWindowACL.v2; however, the MI.TimeWindowRule.v2 object could + still contain MI.TimeWindow objects, if so specified. + + HTTP requests sent to a metadata server SHOULD include an Accept + header with the CDNI Payload Type of the expected object. Metadata + clients can specify multiple CDNI Payload Types in the Accept header; + for example, if a metadata client is capable of processing two + different versions of the same type of object (defined by different + CDNI Payload Types), it might decide to include both in the Accept + header. + +6.9. Media Types + + All CDNI Metadata objects use the media type "application/cdni". The + CDNI Payload Type for each object then contains the object name of + that object as defined by this document, prefixed with "MI.". + Table 4 lists the CDNI Payload Types for the metadata objects + (resources) specified in this document. + + +-----------------------+--------------------------+ + | Data Object | CDNI Payload Type | + +-----------------------+--------------------------+ + | HostIndex | MI.HostIndex | + | HostMatch | MI.HostMatch | + | HostMetadata | MI.HostMetadata | + | PathMatch | MI.PathMatch | + | PatternMatch | MI.PatternMatch | + | PathMetadata | MI.PathMetadata | + | SourceMetadata | MI.SourceMetadata | + | Source | MI.Source | + | LocationACL | MI.LocationACL | + | LocationRule | MI.LocationRule | + | Footprint | MI.Footprint | + | TimeWindowACL | MI.TimeWindowACL | + | TimeWindowRule | MI.TimeWindowRule | + | TimeWindow | MI.TimeWindow | + | ProtocolACL | MI.ProtocolACL | + | ProtocolRule | MI.ProtocolRule | + | DeliveryAuthorization | MI.DeliveryAuthorization | + | Cache | MI.Cache | + | Auth | MI.Auth | + | Grouping | MI.Grouping | + +-----------------------+--------------------------+ + + Table 4: CDNI Payload Types for CDNI Metadata Objects + + + +Niven-Jenkins, et al. Standards Track [Page 49] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +6.10. Complete CDNI Metadata Example + + A dCDN requests the HostIndex and receives the following object with + a CDNI Payload Type of "MI.HostIndex": + + { + "hosts": [ + { + "host": "video.example.com", + "host-metadata": { + "type": "MI.HostMetadata", + "href": "https://metadata.ucdn.example/host1234" + } + }, + { + "host": "images.example.com", + "host-metadata": { + "type": "MI.HostMetadata", + "href": "https://metadata.ucdn.example/host5678" + } + } + ] + } + + If the incoming request has a Host header with "video.example.com", + then the dCDN would fetch the HostMetadata object from + "https://metadata.ucdn.example/host1234" expecting a CDNI Payload + Type of "MI.HostMetadata": + + { + "metadata": [ + { + "generic-metadata-type": "MI.SourceMetadata", + "generic-metadata-value": { + "sources": [ + { + "endpoint": ["acq1.ucdn.example"], + "protocol": "http/1.1" + }, + { + "endpoint": ["acq2.ucdn.example"], + "protocol": "http/1.1" + } + ] + } + }, + + + + + +Niven-Jenkins, et al. Standards Track [Page 50] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + { + "generic-metadata-type": "MI.LocationACL", + "generic-metadata-value": { + "locations": [ + { + "footprints": [ + { + "footprint-type": "ipv4cidr", + "footprint-value": ["192.0.2.0/24"] + }, + { + "footprint-type": "ipv6cidr", + "footprint-value": ["2001:db8::/32"] + }, + { + "footprint-type": "countrycode", + "footprint-value": ["us"] + }, + { + "footprint-type": "asn", + "footprint-value": ["as64496"] + } + ], + "action": "deny" + } + ] + } + }, + { + "generic-metadata-type": "MI.ProtocolACL", + "generic-metadata-value": { + "protocol-acl": [ + { + "protocols": [ + "http/1.1" + ], + "action": "allow" + } + ] + } + } + ], + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 51] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + "paths": [ + { + "path-pattern": { + "pattern": "/videos/trailers/*" + }, + "path-metadata": { + "type": "MI.PathMetadata", + "href": "https://metadata.ucdn.example/host1234/pathABC" + } + }, + { + "path-pattern": { + "pattern": "/videos/movies/*" + }, + "path-metadata": { + "type": "MI.PathMetadata", + "href": "https://metadata.ucdn.example/host1234/pathDEF" + } + } + ] + } + + Suppose that the path of the requested resource matches the + "/videos/movies/*" pattern; the next metadata requested would be for + "https://metadata.ucdn.example/host1234/pathDEF" with an expected + CDNI Payload Type of "MI.PathMetadata": + + { + "metadata": [], + "paths": [ + { + "path-pattern": { + "pattern": "/videos/movies/hd/*" + }, + "path-metadata": { + "type": "MI.PathMetadata", + "href": + "https://metadata.ucdn.example/host1234/pathDEF/path123" + } + } + ] + } + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 52] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Finally, if the path of the requested resource also matches the + "/videos/movies/hd/*" pattern, the dCDN would also fetch the + following object from + "https://metadata.ucdn.example/host1234/pathDEF/path123" with a CDNI + Payload Type of "MI.PathMetadata": + + { + "metadata": [ + { + "generic-metadata-type": "MI.TimeWindowACL", + "generic-metadata-value": { + "times": [ + "windows": [ + { + "start": "1213948800", + "end": "1478047392" + } + ], + "action": "allow" + ] + } + } + ] + } + + The final set of metadata that applies to the requested resource + includes a SourceMetadata, a LocationACL, a ProtocolACL, and a + TimeWindowACL. + + + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 53] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +7. IANA Considerations + +7.1. CDNI Payload Types + + This document requests the registration of the following entries + under the "CDNI Payload Types" registry hosted by IANA: + + +--------------------------+---------------+ + | Payload Type | Specification | + +--------------------------+---------------+ + | MI.HostIndex | RFC 8006 | + | MI.HostMatch | RFC 8006 | + | MI.HostMetadata | RFC 8006 | + | MI.PathMatch | RFC 8006 | + | MI.PatternMatch | RFC 8006 | + | MI.PathMetadata | RFC 8006 | + | MI.SourceMetadata | RFC 8006 | + | MI.Source | RFC 8006 | + | MI.LocationACL | RFC 8006 | + | MI.LocationRule | RFC 8006 | + | MI.Footprint | RFC 8006 | + | MI.TimeWindowACL | RFC 8006 | + | MI.TimeWindowRule | RFC 8006 | + | MI.TimeWindow | RFC 8006 | + | MI.ProtocolACL | RFC 8006 | + | MI.ProtocolRule | RFC 8006 | + | MI.DeliveryAuthorization | RFC 8006 | + | MI.Cache | RFC 8006 | + | MI.Auth | RFC 8006 | + | MI.Grouping | RFC 8006 | + +--------------------------+---------------+ + +7.1.1. CDNI MI HostIndex Payload Type + + Purpose: The purpose of this Payload Type is to distinguish HostIndex + MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.1.1 + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 54] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +7.1.2. CDNI MI HostMatch Payload Type + + Purpose: The purpose of this Payload Type is to distinguish HostMatch + MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.1.2 + +7.1.3. CDNI MI HostMetadata Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + HostMetadata MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.1.3 + +7.1.4. CDNI MI PathMatch Payload Type + + Purpose: The purpose of this Payload Type is to distinguish PathMatch + MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.1.4 + +7.1.5. CDNI MI PatternMatch Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + PatternMatch MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.1.5 + +7.1.6. CDNI MI PathMetadata Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + PathMetadata MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.1.6 + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 55] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +7.1.7. CDNI MI SourceMetadata Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + SourceMetadata MI objects (and any associated capability + advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.1 + +7.1.8. CDNI MI Source Payload Type + + Purpose: The purpose of this Payload Type is to distinguish Source MI + objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.1.1 + +7.1.9. CDNI MI LocationACL Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + LocationACL MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.2 + +7.1.10. CDNI MI LocationRule Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + LocationRule MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.2.1 + +7.1.11. CDNI MI Footprint Payload Type + + Purpose: The purpose of this Payload Type is to distinguish Footprint + MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.2.2 + + + + + + +Niven-Jenkins, et al. Standards Track [Page 56] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +7.1.12. CDNI MI TimeWindowACL Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + TimeWindowACL MI objects (and any associated capability + advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.3 + +7.1.13. CDNI MI TimeWindowRule Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + TimeWindowRule MI objects (and any associated capability + advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.3.1 + +7.1.14. CDNI MI TimeWindow Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + TimeWindow MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.3.2 + +7.1.15. CDNI MI ProtocolACL Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + ProtocolACL MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.4 + +7.1.16. CDNI MI ProtocolRule Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + ProtocolRule MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.4.1 + + + + + +Niven-Jenkins, et al. Standards Track [Page 57] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +7.1.17. CDNI MI DeliveryAuthorization Payload Type + + Purpose: The purpose of this Payload Type is to distinguish + DeliveryAuthorization MI objects (and any associated capability + advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.5 + +7.1.18. CDNI MI Cache Payload Type + + Purpose: The purpose of this Payload Type is to distinguish Cache MI + objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.6 + +7.1.19. CDNI MI Auth Payload Type + + Purpose: The purpose of this Payload Type is to distinguish Auth MI + objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.7 + +7.1.20. CDNI MI Grouping Payload Type + + Purpose: The purpose of this Payload Type is to distinguish Grouping + MI objects (and any associated capability advertisement) + + Interface: MI/FCI + + Encoding: see Section 4.2.8 + +7.2. "CDNI Metadata Footprint Types" Registry + + IANA has created a new "CDNI Metadata Footprint Types" subregistry in + the "Content Delivery Network Interconnection (CDNI) Parameters" + registry. The "CDNI Metadata Footprint Types" namespace defines the + valid Footprint object type values used by the Footprint object + described in Section 4.2.2.2. Additions to the "CDNI Metadata + Footprint Types" namespace conform to the Specification Required + policy as defined in [RFC5226]. The Designated Expert will verify + that new type definitions do not duplicate existing type definitions + + + + +Niven-Jenkins, et al. Standards Track [Page 58] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + and prevent gratuitous additions to the namespace. New registrations + are required to provide a clear description of how to interpret new + footprint types. + + The following table defines the initial values for the "CDNI Metadata + Footprint Types" registry: + + +----------------+--------------------------------+---------------+ + | Footprint Type | Description | Specification | + +----------------+--------------------------------+---------------+ + | ipv4cidr | IPv4 CIDR address block | RFC 8006 | + | ipv6cidr | IPv6 CIDR address block | RFC 8006 | + | asn | Autonomous System Number (ASN) | RFC 8006 | + | countrycode | ISO 3166-1 alpha-2 code | RFC 8006 | + +----------------+--------------------------------+---------------+ + +7.3. "CDNI Metadata Protocol Types" Registry + + IANA has created a new "CDNI Metadata Protocol Types" subregistry in + the "Content Delivery Network Interconnection (CDNI) Parameters" + registry. The "CDNI Metadata Protocol Types" namespace defines the + valid Protocol object values (Section 4.3.2) used by the + SourceMetadata and ProtocolACL objects. Additions to the Protocol + namespace conform to the Specification Required policy as defined in + [RFC5226], where the specification defines the Protocol Type and the + protocol to which it is associated. The Designated Expert will + verify that new protocol definitions do not duplicate existing + protocol definitions and prevent gratuitous additions to the + namespace. + + The following table defines the initial Protocol values corresponding + to the HTTP and HTTPS protocols: + + +-----------+----------------------+---------------+----------------+ + | Protocol | Description | Type | Protocol | + | Type | | Specification | Specifications | + +-----------+----------------------+---------------+----------------+ + | http/1.1 | Hypertext Transfer | RFC 8006 | RFC 7230 | + | | Protocol -- HTTP/1.1 | | | + | | | | | + | https/1.1 | HTTP/1.1 over TLS | RFC 8006 | RFC 7230, | + | | | | RFC 2818 | + +-----------+----------------------+---------------+----------------+ + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 59] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +8. Security Considerations + +8.1. Authentication and Integrity + + A malicious metadata server, proxy server, or attacker impersonating + an authentic uCDN CDNI Metadata interface without being detected + could provide false metadata to a dCDN that either: + + o Denies service for one or more pieces of content to one or more + User Agents; + + o Directs dCDNs to contact malicious origin servers instead of the + actual origin servers, so that malware or slanderous alternate + content may be substituted for legitimate content; or + + o Removes delivery restrictions (e.g., LocationACL, TimeWindowACL, + ProtocolACL, or Auth metadata), allowing access to content that + would otherwise be denied and thus possibly violating license + restrictions and incurring unwarranted delivery costs. + + Unauthorized access to metadata could also enable a malicious + metadata client to continuously issue metadata requests in order to + overload a uCDN's metadata server or servers. + + Unauthorized access to metadata could further result in leakage of + private information. A malicious metadata client could request + metadata in order to gain access to origin servers, as well as + information pertaining to content restrictions. + + An implementation of the CDNI Metadata interface MUST use mutual + authentication and message authentication codes to prevent + unauthorized access to, and undetected modification of, metadata (see + Section 8.3). + +8.2. Confidentiality and Privacy + + Unauthorized viewing of metadata could result in leakage of private + information. Content provider origin and policy information is + conveyed through the CDNI Metadata interface. A third party could + intercept metadata transactions in order to gain access to origin + servers, as well as information pertaining to content restrictions + and usage patterns. + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 60] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + Note: The distribution of metadata by a uCDN to dCDNs could introduce + privacy concerns for some content providers, e.g., dCDNs accepting + content requests for a content provider's content might be able to + obtain additional information and usage patterns relating to the + users of a content provider's services. Content providers with + concerns about divulging information to dCDNs can instruct their uCDN + partners not to use CDNI when delivering their content. + + An implementation of the CDNI Metadata interface MUST use strong + encryption to prevent unauthorized interception or monitoring of + metadata (see Section 8.3). + +8.3. Securing the CDNI Metadata Interface + + An implementation of the CDNI Metadata interface MUST support TLS + transport as per [RFC2818] and [RFC7230]. + + TLS MUST be used by the server side (uCDN) and the client side (dCDN) + of the CDNI Metadata interface, including authentication of the + remote end, unless alternate methods are used for ensuring the + security of the information in the CDNI Metadata interface requests + and responses (such as setting up an IPsec tunnel between the two + CDNs or using a physically secured internal network between two CDNs + that are owned by the same corporate entity). + + The use of TLS for transport of the CDNI Metadata interface messages + allows the dCDN and uCDN to authenticate each other. + + Once the dCDN and uCDN have mutually authenticated each other, TLS + allows: + + o The dCDN and uCDN to authorize each other (to ensure that they are + transmitting/receiving CDNI Metadata requests and responses from + an authorized CDN); + + o CDNI Metadata interface requests and responses to be transmitted + with confidentiality; and + + o The integrity of the CDNI Metadata interface requests and + responses to be protected during the exchange. + + When TLS is used, the general TLS usage guidance in [RFC7525] MUST be + followed. + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 61] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +9. References + +9.1. Normative References + + [ISO3166-1] + The International Organization for Standardization, + "Codes for the representation of names of countries and + their subdivisions -- Part 1: Country codes", + ISO 3166-1:2013, 2013. + + [POSIX] Institute of Electrical and Electronics Engineers, + "Information Technology Portable Operating System + Interface (POSIX) Part 1: System Application Program + Interface (API) [C Language]", IEEE P1003.1, 1990. + + [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", + STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, + . + + [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - + Application and Support", STD 3, RFC 1123, + DOI 10.17487/RFC1123, October 1989, + . + + [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate + Requirement Levels", BCP 14, RFC 2119, + DOI 10.17487/RFC2119, March 1997, + . + + [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform + Resource Identifier (URI): Generic Syntax", STD 66, + RFC 3986, DOI 10.17487/RFC3986, January 2005, + . + + [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing + Architecture", RFC 4291, DOI 10.17487/RFC4291, + February 2006, . + + [RFC5226] Narten, T. and H. Alvestrand, "Guidelines for Writing an + IANA Considerations Section in RFCs", BCP 26, RFC 5226, + DOI 10.17487/RFC5226, May 2008, + . + + [RFC5890] Klensin, J., "Internationalized Domain Names for + Applications (IDNA): Definitions and Document Framework", + RFC 5890, DOI 10.17487/RFC5890, August 2010, + . + + + + +Niven-Jenkins, et al. Standards Track [Page 62] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + [RFC5891] Klensin, J., "Internationalized Domain Names in + Applications (IDNA): Protocol", RFC 5891, + DOI 10.17487/RFC5891, August 2010, + . + + [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 + Address Text Representation", RFC 5952, + DOI 10.17487/RFC5952, August 2010, + . + + [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content + Distribution Network Interconnection (CDNI) Problem + Statement", RFC 6707, DOI 10.17487/RFC6707, + September 2012, . + + [RFC7230] Fielding, R., Ed., and J. Reschke, Ed., "Hypertext + Transfer Protocol (HTTP/1.1): Message Syntax and Routing", + RFC 7230, DOI 10.17487/RFC7230, June 2014, + . + + [RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, + DOI 10.17487/RFC7493, March 2015, + . + + [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, + "Recommendations for Secure Use of Transport Layer + Security (TLS) and Datagram Transport Layer Security + (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, + May 2015, . + +9.2. Informative References + + [CDNI-URI-SIGNING] + van Brandenburg, R., Leung, K., Sorber, P., and M. Miller, + "URI Signing for CDN Interconnection (CDNI)", Work in + Progress, draft-ietf-cdni-uri-signing-10, October 2016. + + [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, + DOI 10.17487/RFC2818, May 2000, + . + + [RFC6793] Vohra, Q. and E. Chen, "BGP Support for Four-Octet + Autonomous System (AS) Number Space", RFC 6793, + DOI 10.17487/RFC6793, December 2012, + . + + + + + + +Niven-Jenkins, et al. Standards Track [Page 63] + +RFC 8006 CDN Interconnection Metadata December 2016 + + + [RFC7234] Fielding, R., Ed., Nottingham, M., Ed., and J. Reschke, + Ed., "Hypertext Transfer Protocol (HTTP/1.1): Caching", + RFC 7234, DOI 10.17487/RFC7234, June 2014, + . + + [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., + "Framework for Content Distribution Network + Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, + August 2014, . + + [RFC7337] Leung, K., Ed., and Y. Lee, Ed., "Content Distribution + Network Interconnection (CDNI) Requirements", RFC 7337, + DOI 10.17487/RFC7337, August 2014, + . + + [RFC7540] Belshe, M., Peon, R., and M. Thomson, Ed., "Hypertext + Transfer Protocol Version 2 (HTTP/2)", RFC 7540, + DOI 10.17487/RFC7540, May 2015, + . + + [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) + Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, + December 2015, . + + [RFC7975] Niven-Jenkins, B., Ed., and R. van Brandenburg, Ed., + "Request Routing Redirection Interface for Content + Delivery Network (CDN) Interconnection", RFC 7975, + DOI 10.17487/RFC7975, October 2016, + . + + [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network + Interconnection (CDNI) Control Interface / Triggers", + RFC 8007, DOI 10.17487/RFC8007, December 2016, + . + + [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, + R., and K. Ma, "Content Delivery Network Interconnection + (CDNI) Request Routing: Footprint and Capabilities + Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, + . + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 64] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +Acknowledgments + + The authors would like to thank David Ferguson, Francois Le Faucheur, + Jan Seedorf, and Matt Miller for their valuable comments and input to + this document. + +Contributors + + The authors would also like to thank Grant Watson and Kent Leung for + their contributions to this document. + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 65] + +RFC 8006 CDN Interconnection Metadata December 2016 + + +Authors' Addresses + + Ben Niven-Jenkins + Nokia + 3 Ely Road + Milton, Cambridge CB24 6DD + United Kingdom + + Email: ben.niven-jenkins@nokia.com + + + Rob Murray + Nokia + 3 Ely Road + Milton, Cambridge CB24 6DD + United Kingdom + + Email: rob.murray@nokia.com + + + Matt Caulfield + Cisco Systems + 1414 Massachusetts Avenue + Boxborough, MA 01719 + United States of America + + Phone: +1-978-936-9307 + Email: mcaulfie@cisco.com + + + Kevin J. Ma + Ericsson + 43 Nagog Park + Acton, MA 01720 + United States of America + + Phone: +1 978-844-5100 + Email: kevin.j.ma@ericsson.com + + + + + + + + + + + + + +Niven-Jenkins, et al. Standards Track [Page 66] + -- cgit v1.2.3