CDNI Delivery Metadata

Introduction This specification introduces a set of metadata objects and related footprint and capabilities objects that guide content delivery. The specification includes traffic characterization, downstream CDN (dCDN) selection directives, and request routing related metadata. Without any specific instruction, those metadata objects defined hereafter apply to the configuration associated with a host match and possibly a path match according to .

Cdn Transport The downstream CDN is by default viewed as a unique delivery infrastructure. There are however situations and implementation cases where the delivery infrastructure may differ depending on the content type like real-time (i.e. very low latency) streaming content, file download, multicast (vs unicast) delivery, etc. This document introduces the principle of multiple downstream CDN transport arrangements. A downstream CDN transport arrangement is associated with supported traffic types, capacity limits and transport type (multicast versus unicast). There exists by default one implicit downstream CDN arrangement. Several downstream CDN transport arrangements can be exposed through dedicated new Footprint and Capabilities (FCI) objects and conversely be exploited by uCDN using new configuration objects depicted in this document. Depending on a CDN selection policy indicated by the uCDN, the dCDN may attempt to select the preferred dCDN transport arrangement and if not possible (e.g. no more capacity) may indicate an error or may select a dCDN transport arrangement of its choice.

Request Routing Inter CDN request redirection is possible through iterative and recursive modes of operations. Iterative CDNI Request Redirection is defined in Section 1.1 of and elaborated by examples in Sections 3.2 and 3.4 of . Footprint and capabilities for redirection modes are exposed by the dCDN through FCI objects according to . This includes Iterative redirection modes based on the Domain Name System (DNS) or HTTP redirect. Supporting the mode "I-HTTP" means for the dCDN that the uCDN can perform request routing based on the HTTP redirect method. As mentioned in sections 3.2 (Iterative HTTP Redirect example) of , nothing precludes the dCDN (i.e. operator B in the examples) to support DNS based request routing for inter-CDN request redirection and operates HTTP redirect request routing for dCDN internal request routing. Therefore, when the uCDN operates one particular iterative redirection mode, routing the request to the dCDN, there is no guarantee about what request routing method the dCDN will use internally (e.g. to route the request to one of its surrogate cache). It is neither announced by the dCDN nor can it be forced by the uCDN. The uCDN requires the ability to indicate the preferred request routing method among those supported by the dCDN. This is required in the case where the uCDN would like to delegate the traffic relying on the iterative method but knows the client (i.e. the payer) does not support for instance HTTP redirection. In that case, the uCDN needs a way to force the dCDN to perform request routing based on e.g. DNS redirect but not HTTP redirect.

Traffic Characterization Content delivery networks often apply different infrastructure, network routes, and internal metadata for different types of traffic. Delivery of large static objects (such as software downloads), for example, may use different edge servers and network routes than video stream delivery. In an HTTP adaptive bitrate video service, every video title corresponds to a set of video files and descriptors according to different video protocols, and this is independent of the type of service (video-on-demand, live, catch-up, etc.). The way the video service is consumed by the user agents can vary. For instance, a segment that belongs to a video on demand (VOD) title can be requested for every moment the content is available for the user agents to consume, while a segment of live content will be only requested as long as the time-shift duration is configured for that service. Knowing those differences, a provider can implement specific strategies that will maximize performance and thereby provide more available capacity to the upstream provider. It should be noted that the dCDNs handling of the traffic types is implementation-specific and not prescribed here.

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 .

MI.CdnTransport MI.CdnTransport is a GenericMetadata object that allows the uCDN to indicate a preference to one among multiple dCDN transport arrangements exposed by the dCDN through the FCI.CdnTransport object. Instructs the dCDN to perform delegation operations for a particular dCDN transport arrangement. The MI.CdnTransport configuration object MUST be associated with the metadata configuration objects dedicated to a particular host or a particular path match (see ). The footprint of this object corresponds to the footprint restriction of the FCI.CdnTransportArrangement it references, as defined in Sections 3 and 5.1. Associated with the selected dCDN transport arrangement, there is a default selection policy that is "best-effort", i.e., the dCDN tries its best to fulfill the requested policy without providing guarantees. Note that the dCDN selects a default transport arrangement of its choice if MI.CdnTransport is not used or whenever the transport arrangement selection policy indicates "best-effort" (see below). Note that the MI.CdnTransport object can be used several times associated with a different cdn-transport-name If two or more MI.CdnTransport objects are associated with the same host or path metadata down in the inheritance tree then a MI.CdnTransportobject definition(s) always override the parent object(s) of the same type conforming to Section 3.3. Property: cdn-transport-name

Description: the name of the selected downstream CDN transport arrangement exposed through the FCICdnTransport object associated with a footprint conforming to .
Type: String. Must be one of those dCDN transport arrangement names as exposed by the dCDN through the FCI.CdnTransport object.
Mandatory-to-Specify: Yes.

Property: cdn-transport-selection

Description: Enforces the selection of this downstream CDN (dCDN) transport arrangement according to a specified policy.
Type: String. One of "attempt-or-failed", "attempt-or-besteffort", or "best-effort". For either of the first two values, the delegation MUST be attempted according to the dCDN delivery arrangement corresponding to the cdn-transport-name property If this is not possible, it is considered as an error and either fails (i.e. the complete delegation configuration fails) or the dCDN continues with a "best-effort" procedure respectively. The "best-effort" value instructs the dCDN to try its best to fulfill the requested cdn-selection policy with no guarantees. In the case of a failure, the configuration status (see and ) is set to "failed" and the error list must contain the following error description.
- error: "ecdn"
- metadata.urls: The URL of the MI.CdnTransportconfiguration object.
Mandatory-to-Specify: No. The value "best-effort" is the default selection policy.

The following is an example of the MI.CdnTransport object:

MI.RequestRouting MI.RequestRouting is a GenericMetadata object that allows the uCDN to force the dCDN request routing method(s) to be applied when the uCDN operates one of the iterative redirection modes (see and ). Property: request-routing-modes

Description: Instructs the dCDN to perform request routing according to one or more preferred modes among those supported and advertised by the dCDN through the FCI.RequestRouting object. One must understand that forcing (instead of letting the dCDN request router select) one particular request routing mode may trigger some inefficiency in the request routing process.
Type: Array of dCDN request routing modes as specified in the FCI.RequestRouting object .
Mandatory-to-Specify: No. By default, all request routing modes supported by the dCDN can be used by the dCDN as part of its request routing process.

The following example illustrates the uCDN forcing the dCDN to use DNS or HTTP as the method for request routing in case the uCDN performs an iterative delegation (i.e., iterative redirection mode):

MI.TrafficType MI.TrafficType metadata defines a set of descriptors that characterize either the type or usage of the traffic, enabling providers to apply any internal configuration rules without exposing an unnecessary number of internal details. Note that the interpretation of these traffic types and application of rules, such as rate limiting or delivery pacing, are implementation specific. The metadata object applies to the configuration associated with a host match and possibly a path match according to . When used concurrently with the MI.CdnTransport object, the traffic-type property must be coherent with the traffic types associated with the selected transport arrangement announced with the FCI.CdnTransport object. It is possible to declare several MI.TrafficType objects with the same host or path metadata indicating the support of several traffic types. If two or more MI.TrafficType objects are associated with the same host or path metadata down in the inheritance tree then the MI.TrafficType object definition(s) always override the parent object(s) of the same type conforming to Section 3.3. Property: traffic-type

Description: Designates the traffic type. The uCDN will use the literal that is most representative of the traffic being delegated.
Type: String, one of the following traffic types.
- vod: This is streaming of on demand video. The delivery can be rate controlled.
- live: this is streaming live with possible constraints in terms of latency.
- object-download: This is typically file download like WEB objects or VOD files. The delivery can be rate controlled.
Mandatory-to-Specify: Yes

Property: hints

Description: A set of descriptions related to the traffic type. No particular form is imposed. This may be further specified though the uCDN/dCDN pre-arrangement.
Type: Array of strings.
Mandatory-to-Specify: No

The following is an example of MI.TrafficType that designates VOD catch-up TV viewing:

MI.MediaServiceDescription MI.MediaServiceDescription metadata defines a set of descriptors associated with a media service delegated to the dCDN. The metadata object applies to the configuration associated with a host match and possibly a path match according to . A Metadata set associated with a host match or path match SHALL NOT gather more than one MediaServiceDescription metadata object. The uCDN MAY use this metadata object for controlling the bandwidth budget (possibly previously allocated by the dCDN) obtained through the Capacity Insight Interface or possibly offline. This metadata can be used by the dCDN provider to implement specific strategies that will maximize performance. Note that these strategies are implementation specific and not specified in this document. With knowledge of the streaming manifest URL, for example, the dCDN MAY implement segment prefetching strategies. Furthermore, the notion of a media service MAY allow the dCDN provider to track and monitor streaming sessions in a more comprehensive manner. Property: manifestURL

Description: Path of the manifest (e.g. mpd or m3u8) file related to this media service.
Type: String.
Mandatory-to-Specify: No.

Property: mediaServiceName

Description: String describing or identifying the media service. This MAY be used by the uCDN to correlate several configuration metadata objects with a name (e.g. a TV channel name)
Type: String.
Mandatory-to-Specify: No.

Property: maximumBitrate

Description: This is the maximum bitrate in bits per second (bps) attached to the service delivery. If the service includes multiple representations or playlists, this property restricts the bitrate of each representation or playlist with a published bitrate to a value below this property's value. The property's value indicates the maximum bitrate provisioned for the service, regardless of the representations or playlists. This property MUST be set (constrained) according to the maximum bitrate dedicated to the uCDN by the dCDN subject to a pre-agreement or possibly published through the FCI.CapacityLimit or the cdn-transport-capacity-limits property associated with the transport arrangement(s) announced with the FCI.CdnTransport object and possibly selected (MI.CdnTransport)along with this object
Type: integer.
Mandatory-to-Specify: No. If not specified, the uCDN relies entirely on the dCDN for multiple services delivery. It is strongly encouraged to specify a maximum bitrate for allowing the uCDN to operate multicast delivery for several concurrent services.

The following example of MI.MediaServiceDescription pointing to the manifest of a live channel and associates a name to this channel:

Capabilities Advertisements This section introduces FCI objects that allow a dCDN to advertise its specific capabilities related to delivery.

FCI.CdnTransport This object is used by the dCDN to advertise the supported CDN transport arrangements. Property: cdn-transport-list

Description: A list of supported dCDN network transport arrangements.
Type: Array of FCI.CdnTransportArrangement objects that specify the allowed CDN transport arrangements.
Mandatory-to-Specify: Yes.

FCI.CdnTransportArrangement This sub-object is used to describe a particular dCDN transport arrangement. Property: cdn-transport-name

Description: name of the downstream CDN transport arrangement. A downstream CDN operator may own several transport arrangements which may be the subject of a different delegation. A dCDN transport arrangement is named according to that property. The name is used with the corresponding MI.CdnTransport for pointing out one particular transport arrangement associated with the configuration metadata.
Type: String.
Mandatory-to-Specify: Yes. The name MUST be unique among the list exposed by the cdn-transport-list property of the FCI.CdnTransport object.

Property: cdn-transport-type

Description: Transport type of the downstream CDN transport arrangement.
Type: String. Must be one of these values: "MULTICAST", "UNICAST".
Mandatory-to-Specify: No. The default is unicast. There is always one default dCDN unicast transport arrangement.

Property: cdn-transport-capacity-limits

Description: Exposes some capacity limits associated with that dCDN transport arrangement
Type: An array of FCI.CapacityLimit objects as defined in .
Mandatory-to-Specify: No.

Property: cdn-transport-traffic-types

Description: A set of traffic types supported by this dCDN transport arrangement.
Type: An array of MI.TrafficType objects
Mandatory-to-Specify: No.

Property: cdn-transport-staging

Description: Indicate whether this dCDN transport arrangement corresponds to a staging arrangement.
Type: A boolean. True if this is a staging arrangement. False (default) if this is a production arrangement.
Mandatory-to-Specify: No. By default a production transport arrangement.

The following is an example advertising support for Multicast delivery:

Security Considerations The FCI and MI objects defined in this document are transferred via the interfaces defined in CDNI [RFC8006] which describes how to secure these interfaces by protecting integrity and confidentiality while ensuring the authenticity of the dCDN and uCDN.

IANA Considerations

This document registers the following entries under the "CDNI Payload Types" registry hosted by IANA: CDNI Payload Types

Payload Type	Specification
MI.CdnTransport	RFC this
MI.RequestRouting	RFC this
MI.TrafficType	RFC this
MI.MediaServiceDescription	RFC this
FCI.RequestRouting	RFC this
FCI.CdnTransport	RFC this
FCI.CdnTransportArrangement	RFC this

Purpose: The purpose of this Payload Type is to distinguish CrossoriginPolicy MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: See Section 3

Purpose: The purpose of this Payload Type is to distinguish RequestRouting MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: See Section 4

Purpose: The purpose of this Payload Type is to distinguish TrafficType MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: See Section 5

Purpose: The purpose of this Payload Type is to distinguish MediaServiceDescription MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: See Section 6

Purpose: The purpose of this Payload Type is to distinguish RequestRouting FCI objects Interface: FCI Encoding: See Section 7.1

Purpose: The purpose of this Payload Type is to distinguish CdnSelection FCI objects Interface: FCI Encoding: See Section 7.2

Purpose: The purpose of this Payload Type is to distinguish CdnTransport FCI objects Interface: FCI Encoding: See Section 7.2.1

IANA SHOULD create a new "CDNI Metadata Traffic Types" subregistry in the "Content Delivery Network Interconnection (CDNI) Parameters" registry. The "CDNI Metadata Traffic Types" namespace defines the valid traffic types values used by the traffic-type property of the MI.TrafficType object defined in Section 5. The following table defines the initial values for the "CDNI Metadata Traffic Types" registry: CDNI Metadata Traffic Types

Traffic Type	Description	Specification
vod	This is streaming of on demand video. The delivery can be rate controlled.	RFC this
live	This is streaming live with possible constraints in terms of latency.	RFC this
object	This is typically file download like WEB objects or VOD files. The delivery can be rate controlled.	RFC this

The authors would like to express their gratitude to the members of the Streaming Video Technology Alliance Open Caching Working Group for their guidance / contribution / reviews ...) Particulary the following people contribute in one way or another to the content of this draft:

Christoph Neumann (Broadpeak)
Will Power (Lumen)
Shmuel Asafi (Qwilt)
Yoav Gressel (Qwilt)
Nir Sopher (Qwilt)
Arnon Warshavsky (Qwilt)
Francisco Cano Hila (Telefonica)