Professional Documents
Culture Documents
8006
8006
Niven-Jenkins
Request for Comments: 8006 R. Murray
Category: Standards Track Nokia
ISSN: 2070-1721 M. Caulfield
Cisco Systems
K. Ma
Ericsson
December 2016
Abstract
Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the
document authors. All rights reserved.
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
1. Introduction
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.
o An HTTP web service for the transfer of CDNI Metadata (Section 6).
1.1. Terminology
o Property - a key and value pair where the key is a property name
and the value is the property value or another object.
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].
* Location
* Time window
* Delivery protocol
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
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.
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.
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.
+--------------+----------------------------------------------------+
| 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. |
+--------------+----------------------------------------------------+
+-------+-------+------------+--------------------------------------+
| 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. |
+-------+-------+------------+--------------------------------------+
+-------+--------+--------------+-----------------------------------+
| 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. |
+-------+--------+--------------+-----------------------------------+
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.
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
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
Mandatory-to-Specify: Yes.
{
"hosts": [
{
<Properties of embedded HostMatch object>
},
{
"type": "MI.HostMatch",
"href": "https://metadata.ucdn.example/hostmatch1234"
}
]
}
4.1.2. HostMatch
Property: host
Type: Endpoint
Mandatory-to-Specify: Yes.
Property: host-metadata
Type: HostMetadata
Mandatory-to-Specify: Yes.
{
"host": "video.example.com",
"host-metadata": {
<Properties of embedded HostMetadata object>
}
}
{
"host": "video.example.com",
"host-metadata": {
"type": "MI.HostMetadata",
"href": "https://metadata.ucdn.example/host1234"
}
}
4.1.3. HostMetadata
Property: metadata
Mandatory-to-Specify: Yes.
Property: paths
{
"metadata": [
{
<Properties of first embedded GenericMetadata object>
},
{
<Properties of second embedded GenericMetadata object>
},
...
{
<Properties of Nth embedded GenericMetadata object>
}
],
"paths": [
{
<Properties of embedded PathMatch object>
}
]
}
4.1.4. PathMatch
Property: path-pattern
Type: PatternMatch
Mandatory-to-Specify: Yes.
Property: path-metadata
Type: PathMetadata
Mandatory-to-Specify: Yes.
{
"path-pattern": {
"pattern": "/movies/*",
"case-sensitive": true
},
"path-metadata": {
"type": "MI.PathMetadata",
"href": "https://metadata.ucdn.example/host1234/pathDCE"
}
}
4.1.5. PatternMatch
Property: pattern
Type: String
Mandatory-to-Specify: Yes.
Property: case-sensitive
Type: Boolean
{
"pattern": "/movies/*",
"case-sensitive": true
}
4.1.6. PathMetadata
Property: metadata
Mandatory-to-Specify: Yes.
Property: paths
{
"metadata": [
{
<Properties of first embedded GenericMetadata object>
},
{
<Properties of second embedded GenericMetadata object>
},
...
{
<Properties of Nth embedded GenericMetadata object>
}
],
"paths": [
{
<Properties of embedded PathMatch object>
}
]
}
4.1.7. GenericMetadata
Property: generic-metadata-type
Mandatory-to-Specify: Yes.
Property: generic-metadata-value
Mandatory-to-Specify: Yes.
Property: mandatory-to-enforce
Type: Boolean
Property: safe-to-redistribute
Type: Boolean
Property: incomprehensible
Type: Boolean
{
"mandatory-to-enforce": true,
"safe-to-redistribute": true,
"incomprehensible": false,
"generic-metadata-type": <CDNI Payload Type of this metadata object>,
"generic-metadata-value":
{
<Properties of this metadata object>
}
}
4.2.1. SourceMetadata
Property: sources
{
"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
Property: acquisition-auth
Property: endpoints
Mandatory-to-Specify: Yes.
Property: protocol
Mandatory-to-Specify: Yes.
{
"endpoints": [
"a.service123.ucdn.example",
"b.service123.ucdn.example"
],
"protocol": "http/1.1"
}
Property: locations
{
"generic-metadata-type": "MI.LocationACL",
"generic-metadata-value":
{
}
}
{
"generic-metadata-type": "MI.LocationACL",
"generic-metadata-value":
{
"locations": [
{
"action": "allow",
"footprints": [
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
}
]
}
]
}
}
4.2.2.1. LocationRule
Property: footprints
Mandatory-to-Specify: Yes.
Property: action
{
"action": "allow",
"footprints": [
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
}
]
}
4.2.2.2. Footprint
Property: footprint-type
Mandatory-to-Specify: Yes.
Property: footprint-value
Mandatory-to-Specify: Yes.
{
"footprint-type": "countrycode",
"footprint-value": ["us"]
}
{
"footprint-type": "ipv4cidr",
"footprint-value": ["192.0.2.0/24", "198.51.100.0/24"]
}
{
"footprint-type": "ipv6cidr",
"footprint-value": ["2001:db8::/32"]
}
{
"footprint-type": "asn",
"footprint-value": ["as64496"]
}
4.2.3. TimeWindowACL
Property: times
{
"generic-metadata-type": "MI.TimeWindowACL",
"generic-metadata-value":
{
"times": [
{
"action": "allow",
"windows": [
{
"start": 946717200,
"end": 946746000
}
]
}
]
}
}
4.2.3.1. TimeWindowRule
Property: windows
Mandatory-to-Specify: Yes.
Property: action
{
"action": "allow",
"windows": [
{
"start": 946717200,
"end": 946746000
}
]
}
4.2.3.2. TimeWindow
Property: start
Mandatory-to-Specify: Yes.
Property: end
Mandatory-to-Specify: Yes.
{
"start": 946717200,
"end": 946746000
}
Property: protocol-acl
{
"generic-metadata-type": "MI.ProtocolACL",
"generic-metadata-value":
{
"protocol-acl": [
{
"action": "allow",
"protocols": ["http/1.1"]
}
]
}
}
4.2.4.1. ProtocolRule
Property: protocols
Mandatory-to-Specify: Yes.
Property: action
{
"action": "allow",
"protocols": ["http/1.1"]
}
Property: delivery-auth-methods
{
"generic-metadata-type": "MI.DeliveryAuthorization",
"generic-metadata-value":
{
"delivery-auth-methods": [
{
"auth-type": <CDNI Payload Type of this Auth object>,
"auth-value":
{
<Properties of this Auth object>
}
}
]
}
}
4.2.6. Cache
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.
Property: exclude-path-pattern
Type: String
Property: include-query-strings
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": []
}
}
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
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
Type: String
Mandatory-to-Specify: Yes.
Property: auth-value
Mandatory-to-Specify: Yes.
{
"generic-metadata-type": "MI.Auth",
"generic-metadata-value":
{
"auth-type": <CDNI Payload Type of this Auth object>,
"auth-value":
{
<Properties of this Auth object>
}
}
}
4.2.8. Grouping
Property: ccid
Type: String
{
"generic-metadata-type": "MI.Grouping",
"generic-metadata-value":
{
"ccid": "ABCD"
}
}
This section describes the simple data types that are used for
properties of CDNI Metadata objects.
4.3.1. Link
Property: href
Type: String
Mandatory-to-Specify: Yes.
Property: type
Type: String
{
"type": "MI.HostMatch",
"href": "https://metadata.ucdn.example/hostmatch1234"
}
{
"hosts": [
{
<Properties of embedded HostMatch object>
},
{
"href": "https://metadata.ucdn.example/hostmatch1234"
}
]
}
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
Type: String
Example:
"http/1.1"
4.3.3. Endpoint
Type: String
Example hostname:
"metadata.ucdn.example"
"192.0.2.1"
"[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
946717200
4.3.5. IPv4CIDR
Type: String
Example IPv4CIDR:
"192.0.2.0/24"
4.3.6. IPv6CIDR
Type: String
Example IPv6CIDR:
"2001:db8::/32"
4.3.7. ASN
Type: String
Example ASN:
"as64496"
Type: String
"us"
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.
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.
6.1. Transport
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.
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.
6.3. Bootstrapping
6.4. Encoding
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).
6.5. Extensibility
1. Register the CDNI Payload Type [RFC7736] used to identify the new
GenericMetadata type being specified.
5. Describe the security and privacy consequences, for both the User
Agent and the CDNs, of the new GenericMetadata object.
6.8. Versioning
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 |
+-----------------------+--------------------------+
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"
}
}
]
}
{
"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"
}
]
}
},
{
"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"
}
]
}
}
],
"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"
}
}
]
}
{
"metadata": [],
"paths": [
{
"path-pattern": {
"pattern": "/videos/movies/hd/*"
},
"path-metadata": {
"type": "MI.PathMetadata",
"href":
"https://metadata.ucdn.example/host1234/pathDEF/path123"
}
}
]
}
{
"metadata": [
{
"generic-metadata-type": "MI.TimeWindowACL",
"generic-metadata-value": {
"times": [
"windows": [
{
"start": "1213948800",
"end": "1478047392"
}
],
"action": "allow"
]
}
}
]
}
7. IANA Considerations
+--------------------------+---------------+
| 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 |
+--------------------------+---------------+
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
Interface: MI/FCI
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 |
+----------------+--------------------------------+---------------+
+-----------+----------------------+---------------+----------------+
| 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 |
+-----------+----------------------+---------------+----------------+
8. Security Considerations
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);
When TLS is used, the general TLS usage guidance in [RFC7525] MUST be
followed.
9. 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.
[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493,
DOI 10.17487/RFC7493, March 2015,
<http://www.rfc-editor.org/info/rfc7493>.
[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.
Acknowledgments
Contributors
The authors would also like to thank Grant Watson and Kent Leung for
their contributions to this document.
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