CDNI Delivery Metadata

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 https://datatracker.ietf.org/drafts/current/.¶

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 20 April 2026.¶

Copyright Notice

Copyright (c) 2025 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 (https://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 Revised BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Revised BSD License.¶

Table of Contents

1. 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 [RFC8006].¶

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

MI.CdnSelection is a GenericMetadata object that allows the uCDN to indicate a preference to one of multiple dCDN transport arrangements..¶

Configuration metadata is required to select the dCDN arrangement among a set of possibilities exposed by the dCDN through the Footprint and Capability Interface (the FCI.CdnSelection object). Associated with the dCDN delivery network, 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.¶

Property: cdn-name¶

• Description: Instructs the dCDN to perform delegation operations for a particular dCDN transport arrangement. The MI.CdnSelection configuration object MUST be associated with the metadata configuration objects dedicated to a particular host or a particular path match (see [RFC8006])¶

• Type: String. Must be one of those dCDN transport arrangement names as exposed by the dCDN through the FCI.CdnTransportSelection 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-name property . If this is not possible, it is considered as an error and either fails (configuration failure) 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..¶

• Mandatory-to-Specify: No. The value "best-effort" is the default selection policy.¶

The following is an example of the MI.CdnSelection object:¶

{
  "generic-metadata-type": "MI.CdnSelection",
  "generic-metadata-value": {
    "cdn-name": "MULTICAST",
    "cdn-selection": "attempt-or-failed"
  }
}

4. MI.RequestRouting

MI.RequestRouting is a GenericMetadata object that allows the uCDN to force the dCDN request routing method(s) to be applied when working in iterative redirection mode.¶

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 iterative request routing modes. The values are: "DNS", "HTTP", or "MANIFEST_REWRITE".¶

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

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

5. 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 [RFC8006]. It is possible to declare several MI.TrafficType objects indicating the support of several traffic types.¶

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 (vod | live | object-download)¶

  • 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: Other traffic characteristics that the uCDN can indicate to the dCDN as suggestions for service optimization. Some other specifications may impose some well-defined values [SVTA2065]¶

• Type: Array of strings¶

• Mandatory-to-Specify: No¶

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"]
  }
}

6. 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 [RFC8006]. 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 [SVTA2049] 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 according to the maximum bitrate dedicated to the uCDN by the dCDN and published through the FCI.CdnDelivery (limit type "ingress") and/or the FCI.CapacityLimit (limit type "ingress").¶

• 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 serv.¶

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",
     "maximumBitRate": 5000000,
   }
}

7. Capabilities Advertisements

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

{
  "capabilities": [
    {
      "capability-type": "FCI.CdnSelection",
      "capability-value": {
        "cdn-transport-list": [
          {
            "cdn-name": "MULTICAST",
            "cdn-transport-type": "MULTICAST",
            "cdn-capacity-limit": [
              {
                "id": "capacity_limit_multicast",
                "limit-type": "ingress",
                "maximum-hard": 50000000,
                "maximum-soft": 40000000,
                "current": 15000000
              },
              {
                "id": "capacity_limit_multicast",
                "limit-type": "egress",
                "maximum-hard": 5000000,
                "maximum-soft": 4000000
              }
            ],
            "cdn-traffic-types": [
              {
                "traffic-type": "live"
              }
            ]
          }
        ]
      }
    }
  ]
}

8. Security Considerations

9. IANA Considerations

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

• Person 1 (Company 1)¶

Authors' Addresses