Internet-Draft CDNI Delivery Metadata March 2024
Bichot, et al. Expires 5 September 2024 [Page]
Content Delivery Networks Interconnection
Intended Status:
Standards Track
G. Bichot
A. Siloniz
G. Goldstein
Lumen Technologies

CDNI Delivery Metadata


This specification adds to the core set of configuration metadata defined in RFC8006, providing delivery metadata to define traffic types, Open Caching request delegation behavior for Open Caching node selection, and request routing modes of traffic delegation.

Status of This Memo

This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79.

Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet-Drafts is at

Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress."

This Internet-Draft will expire on 5 September 2024.

Table of Contents

1. Introduction

This specification introduces a set of GenericMetadata objects that guide content delivery. This includes traffic types and service descriptions, Open Caching node selection directives, and request routing metadata. For background on the Open Caching standards and interactions between upstream content delivery networks (uCDNs) and downstream content delivery networks (dCDNs) that these configuration settings impact, refer to the Open Caching Request Routing Functional Specification [SVTA2007]

2. Requirements

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].

3. MI.OcnSelection

Configuration metadata is required to permit several levels of Open Caching node (OCN) selection policies. For example, in a mobile network, several physical locations are possible (i.e., candidates) for hosting the OCN that will take charge in the delegation for the uCDN. This is the case when the cache is virtualized and deployed dynamically. Depending on the OCN selection policy, which may be a cost driver, the dCDN may attempt to favor certain types of caches at the edge, for example.

The available types of OpenCaching nodes are announced by the dCDN using the FCI.OCNSelection object. The possible types of OpenCaching nodes are not predefined and might for instance be linked to the network characteristics such as "EDGE" or "average latency< 10ms" (i.e., the property ocn-type can be one of these values). The dCDN can select the node types using the ocn-type property. The uCDN can also configure the delivery type using the ocn-delivery property, and specify for instance whether to use MABR (multicast ABR) over a satellite link or HAS (HTTP Adaptive Streaming) over a cellular network. The default OCN selection policy is "best-effort", i.e., the dCDN tries its best to fulfill the requested policy without providing guarantees.

For more details on Open Caching node selection, refer to the Open Caching Request Routing Functional Specification [SVTA2007]

MI.OcnSelection is a new GenericMetadata object that allows the uCDN to indicate a preference to the dCDN, in terms of OCN selection.

Property: ocn-delivery

Property: ocn-type

Property: ocn-selection

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

  "generic-metadata-type": "MI.OcnSelection",
  "generic-metadata-value": {
    "ocn-delivery": {
      "ocn-medium": "SATELLITE",
      "ocn-transport": "MABR"
    "ocn-type": "EDGE",
    "ocn-selection": "attempt-or-failed"
Figure 1

3.1. MI.OcnDelivery

MI.OcnDelivery is a subobject of MI.OcnSelection that provides details on how the delegated content should be delivered.

Property: ocn-medium

  • Description: Instructs the dCDN to perform delegation operations for a particular medium.

  • Type: String. Must be one of these values: "SATELLITE", "CELLULAR", "BROADBAND", "TERRESTRIAL".

  • Mandatory-to-Specify: No. Either the ocn-medium property or the ocn-transport property MUST be present.

Property: ocn-transport

  • Description: Instructs the dCDN to perform delegation operations for a particular transport arrangement.

  • Type: String. Must be one of these values: "MABR" (Multicast Adaptive Bitrate), or "HAS" (HTTP Adaptive Streaming).

  • Mandatory-to-Specify: No. At least one of the two properties (ocn-medium or ocn-transport) MUST be present.

4. MI.RequestRouting

The uCDN requires the ability to indicate whether Hypertext Transfer Protocol (HTTP) redirect, Domain Name System (DNS) redirect, and manifest rewrite are allowed, and indicate which is preferable. This is REQUIRED in cases where the uCDN would like to delegate the traffic relying on the iterative method but knows the client will not support HTTP redirection. In that case, the uCDN needs a means to force the dCDN to perform request routing based on DNS redirect (or manifest rewrite).

For more details on Open Caching request routing, refer to the Open Caching Request Routing Functional Specification [SVTA2007]

This configuration possibility is useful only if the dCDN can advertise the mode of redirection it supports. There is an ongoing discussion in the IETF CDNI group to understand the semantics behind the redirection modes currently in the Footprint & Capabilities Advertising Interface (I-DNS and I-HTTP). It is not clear whether this indicates that the dCDN supports one or both delegation modes (the request routing performed by the uCDN can only be based on DNS redirect or HTTP redirect, or both), or whether it indicates that the dCDN supports, as its own request routing mode, DNS redirect and/or HTTP redirect. The latter is REQUIRED for this new configuration object to be valid.

MI.RequestRouting is a new GenericMetadata object that allows the uCDN to force the dCDN request routing mode(s) to be applied when working in iterative redirection mode. The list of redirection modes supported by the dCDN is advertised through the FCI.RedirectionMode object. The list of request routing modes supported by the dCDN is advertised through the FCI.RequestRoutingMode object documented in the Capabilities Advertisements (Section 7) section.

Property: request-routing-modes

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):

  "generic-metadata-type": "MI.RequestRouting",
  "generic-metadata-value": {
    "request-routing-modes": [ "DNS", "HTTP" ]
Figure 2

5. MI.TrafficType

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), may, for example, 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 CDN or OCN 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.

MI.TrafficType metadata defines a set of descriptors that characterize either the type or usage of the traffic, enabling CDNs and OCNs 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.

Property: traffic-type

Property: hints

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

  "generic-metadata-type": "MI.TrafficType",
  "generic-metadata-value": {
    "traffic-type": "vod",
    "hints": [ "catch-up" ]
Figure 3

6. MI.MediaServiceDescription

MI.MediaServiceDescription metadata defines a set of descriptors associated with a media service delegated to the dCDN. This metadata can be used by the CDN or OCN 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 CDN or OCN provider to track and monitor streaming sessions in a more comprehensive manner.

Property: manifestURL

Property: mediaServiceName

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

   "generic-metadata-type": "MI.MediaServiceDescription",
   "generic-metadata-value": {
     "manifestURL": "/live/channelXYZ/index.mpd",
     "mediaServiceName": "ChannelXYZ",
Figure 4

7. Capabilities Advertisements

This section introduces FCI objects that allow a dCDN to advertise its specific capabilities related to the MI.OcnSelection and MI.RequestRouting objects.

7.1. FCI.OcnSelection

This object is used by the dCDN to advertise the supported OCN types and/or its transport arrangement, and/or the medium supported by OCNs.

Property: ocn-delivery-list

  • Description: A list of supported medium and/or transport arrangements.

  • Type: Array of MI.OcnDelivery objects that specify the allowed combinations of medium and transport.

  • Mandatory-to-Specify: No

Property: ocn-type-list

  • Description: A list of supported OCN types.

  • Type: Array of strings. Examples include: "HOME" or "EDGE". The possible types are not predefined and can be freely chosen by the dCDN.

  • Mandatory-to-Specify: No

The following is an example advertising support for Satellite Multicast Adaptive Bitrate (MABR) OCN delivery:

  "capabilities": [
      "capability-type": "FCI.OcnSelection",
      "generic-metadata-value": {
        "ocn-delivery-list": [
            "ocn-medium": "SATELLITE",
            "ocn-transport": "MABR"
        "ocn-type-list": [
Figure 5

7.2. FCI.RequestRouting

This object is used by the dCDN to advertise the supported request routing modes. This can be optionally used by the uCDN to further select a subset of those modes when operating one of the iterative delegation modes. See the section MI.RequestRouting (Section 4)

Property: request-routing-modes

  • Description: A list of supported request routing modes by the dCDN. This information is useful when the uCDN decides to perform a delegation in iterative mode.

  • Type: Array of strings. Values are: "DNS", "HTTP-R", or "MANIFEST_REWRITE".

  • Mandatory-to-Specify: No. If the dCDN does not advertise the supported request routing modes, they are all supported by default.

The following example advertises support for all the request routing modes:

  "capabilities": [
      "capability-type": "FCI.RequestRouting",
      "capability-value": {
        "request-routing-modes": [
Figure 6

8. Security Considerations

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

9. IANA Considerations

9.1. CDNI Payload Types

This document requests the registration of the following entries under the "CDNI Payload Types" registry hosted by IANA:

Table 1: CDNI Payload Types
Payload Type Specification
MI.OcnSelection RFCthis
MI.OcnDelivery RFCthis
MI.RequestRouting RFCthis
MI.TrafficType RFCthis
MI.MediaServiceDescription RFCthis
FCI.OcnSelection RFCthis
FCI.RequestRouting RFCthis

10. Acknowledgements

The authors would like to express their gratitude to the members of the Streaming Video Technology Alliance [SVTA] Open Caching Working Group for their guidance / contribution / reviews ...)

Particulary the following people contribute in one or other way to the content of this draft:

11. Normative References

Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, , <>.
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, , <>.

12. Informative References

SVTA, "Streaming Video Technology Alliance Home Page", <>.
SVTA, "Open Caching Request Routing Functional Specification", <>.

Authors' Addresses

Guillaume Bichot
Alfonso Siloniz
Glenn Goldstein
Lumen Technologies
United States of America