RFC 8008

Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics

📅 published December 2016, from ietf

Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics 🎀

Okay bestie, let's get into it 💅 This is RFC 8008, published by the Internet Engineering Task Force (IETF) in December 2016, with ISSN 2070-1721. It's on the Standards Track, so this is official Internet business, not a group chat. 🌐

There are five authors, all iconic:

J. Seedorf, from HFT Stuttgart - Univ. of Applied Sciences
J. Peterson, from Neustar
S. Previdi, from Cisco
R. van Brandenburg, from TNO
K. Ma, from Ericsson

The title block doesn't list anything it obsoletes or updates, so this one isn't replacing or patching any other RFC. 🫶

Abstract

Okay so the abstract is giving "here's the whole plan" ✨ It explains the "Footprint and Capabilities Advertisement" part of the Content Delivery Network Interconnection (CDNI) Request Routing interface. Basically it nails down what "Footprint" and "Capabilities" should mean in CDNI, and what the "Footprint & Capabilities Advertisement interface (FCI)" is supposed to offer. It also gives guidelines for the CDNI FCI protocol, defines a Base Advertisement Object, sets up the registries needed for capabilities and footprints, and explains how those registries can be extended later on. Iconic planning, honestly 🧚

Status of This Memo

This is an Internet Standards Track document. 🌸

It's a product of the IETF, which means it represents the consensus of the IETF community. It went through public review and got approved for publication by the Internet Engineering Steering Group (IESG). If you want more info on Internet Standards, check out Section 2 of RFC 7841.

For the current status, any errata, and how to send feedback, go to http://www.rfc-editor.org/info/rfc8008. 💖

Copyright Notice

This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) as in effect on the date of publication. Please actually read these, because they spell out your rights and restrictions for this document. 📜

Any Code Components pulled out of this document must include Simplified BSD License text, as described in Section 4.e of the Trust Legal Provisions. They're provided without warranty, as described in the Simplified BSD License. 🙈

   1. Introduction and Scope ..........................................4
      1.1. Terminology ................................................5
   2. Design Decisions for Footprint and Capabilities .................6
      2.1. Advertising Limited Coverage ...............................6
      2.2. Capabilities and Dynamic Data ..............................7
      2.3. Advertisement versus Queries ...............................8
      2.4. Avoiding or Handling "Cheating" dCDNs ......................8
   3. Focusing on Capabilities with Footprint Restrictions ............9
   4. Footprint and Capabilities Extension ............................9
   5. Capability Advertisement Object ................................11
      5.1. Base Advertisement Object .................................12
      5.2. Encoding ..................................................12
      5.3. Delivery Protocol Capability Object .......................13
           5.3.1. Delivery Protocol Capability Object Serialization ..13
      5.4. Acquisition Protocol Capability Object ....................14
           5.4.1. Acquisition Protocol Capability Object
                  Serialization ......................................14
      5.5. Redirection Mode Capability Object ........................15
           5.5.1. Redirection Mode Capability Object Serialization ...15
      5.6. CDNI Logging Capability Object ............................16
           5.6.1. CDNI Logging Capability Object Serialization .......17
      5.7. CDNI Metadata Capability Object ...........................18
           5.7.1. CDNI Metadata Capability Object Serialization ......19
   6. IANA Considerations ............................................20
      6.1. CDNI Payload Types ........................................20
           6.1.1. CDNI FCI DeliveryProtocol Payload Type .............20
           6.1.2. CDNI FCI AcquisitionProtocol Payload Type ..........20
           6.1.3. CDNI FCI RedirectionMode Payload Type ..............20
           6.1.4. CDNI FCI Logging Payload Type ......................21
           6.1.5. CDNI FCI Metadata Payload Type .....................21
      6.2. "CDNI Capabilities Redirection Modes" Registry ............21
   7. Security Considerations ........................................22
   8. References .....................................................23
      8.1. Normative References ......................................23
      8.2. Informative References ....................................24
   Appendix A. Main Use Case to Consider .............................25
   Appendix B. Semantics for Footprint Advertisement .................25
   Appendix C. Semantics for Capabilities Advertisement ..............27
   Acknowledgments ...................................................30
   Authors' Addresses ................................................30

1. Introduction and Scope ✨

The CDNI working group is cooking up a set of protocols so multiple CDNs can connect to each other 🌐 These CDNI protocols can do more than one job, as discussed in [RFC6770]. For example, one use is letting a given CDN reach parts of the network that it doesn't cover on its own. 🦋

The goal of this document is to get everyone on the same page about the semantics of the CDNI Request Routing Footprint & Capabilities Advertisement interface (from now on called the FCI) [RFC7336]. The big question is what type of information a downstream CDN (dCDN) "advertises" about its footprint and capabilities. To settle the fuzzy parts, this document sets a shared understanding of what the FCI needs to offer and accomplish in CDNI. 💅

Picking the actual protocol for the FCI is explicitly out of scope here, bestie 🙅 But we do give guidelines for those FCI protocols. 🎀

We make the following general assumptions in this document:

The CDNs participating in the CDN interconnection have already performed a bootstrap process, i.e., they have connected to each other, either directly or indirectly, and can exchange information amongst each other. 🤝
The upstream CDN (uCDN) receives footprint advertisements and/or capability advertisements from a set of dCDNs. Footprint advertisements and capability advertisements need not use the same underlying protocol. 🧩
The uCDN receives the initial Request Routing message from the endpoint requesting the resource. 📨

The CDNI problem statement [RFC6707] describes the Request Routing interface as "[enabling] a Request Routing function in an Upstream CDN to query a Request Routing function in a Downstream CDN to determine if the Downstream CDN is able (and willing) to accept the delegated Content Request." It also says "the CDNI Request Routing interface is also expected to enable a Downstream CDN to provide to the Upstream CDN (static or dynamic) information (e.g., resources, footprint, load) to facilitate selection of the Downstream CDN by the Upstream CDN Request Routing system when processing subsequent Content Requests from User Agents." So [RFC6707] treats "resources" and "load" as capabilities the dCDN advertises. Iconic, honestly 👑

The range of footprint definitions and possible capabilities is huge. Trying to write one comprehensive advertisement solution would get out of hand really fast 😭 The CDNI requirements document [RFC7337] lists the specific requirements for the CDNI FCI, so that "footprint" and "capabilities" are clear in the CDNI context. This document defines what those terms mean for CDNI and details how the footprint advertisement mechanism and the capability advertisement mechanism work. 🌈

1.1. Terminology 🧚

This document reuses the terminology defined in [RFC6707]. ✨

On top of that, these terms show up all over the place and are defined like this:

Footprint: a description of a CDN's coverage area, i.e., the area from which client requests may originate for content and to which the CDN is willing to deliver content. Note: There are many ways to describe a footprint, for example by address range (e.g., IPv4 CIDR or IPv6 CIDR (Classless Inter-Domain Routing)), network ID (e.g., Autonomous System Number (ASN)), nation boundaries (e.g., country code), or GPS coordinates. This document does not define or endorse the quality or suitability of any particular footprint description method. It only defines a method for transporting known footprint descriptions in Footprint and Capabilities Advertisement messages. 🗺️
Capability: a feature of a dCDN upon whose support a uCDN relies when making delegation decisions. Support for a given feature can change over time and can be restricted to a limited portion of a dCDN's footprint. Note: There are many possible dCDN features that could be of interest to a uCDN. This document does not presume to define them all. Instead, it describes a scheme for defining new capabilities and how to transport them in Footprint and Capabilities Advertisement messages. 🔥

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 RFC 2119 [RFC2119]. 💜

2. Design Decisions for Footprint and Capabilities ✨

okay bestie, this section is where we figure out what a "footprint" even means 😭 because "coverage" and "reachability" are slippery. CDNs pick strategic spots for their Surrogates, but a Surrogate with a public IPv4 address is reachable by any endpoint on the Internet 🌍, unless some policy enforcement stops it from being used 🙅‍♀️.

Some CDNs want to cover the entire world 🌎. We call these global CDNs 👑. From a coverage or reachability point of view, the footprint a global CDN advertises in the CDNI environment would presumably cover all prefixes 💅. But honestly, the more interesting ones for CDNI are CDNs that claim a more limited coverage area and still want to interconnect with other CDNs, so they can make one CDN fabric that shares resources 🧚✨.

Also, not all capabilities need to be footprint-restricted 🦋. Depending on the use case, it isn't clear what the optimal semantics are for "footprints with capability attributes" vs. "capabilities with footprint restrictions" 🤔.

The key to all of this is understanding why a dCDN would advertise a limited coverage area, and how a uCDN would use those advertisements to decide among several dCDNs 💖. The next section walks through some of the trade-offs and design decisions that need to be made for the CDNI FCI 📝.

2.1. Advertising Limited Coverage

The basic use case that would motivate a dCDN to advertise limited coverage is that the CDN was built to cover only a particular portion of the Internet 🌸. For example, an ISP could purpose-build a CDN that only serves its own customers, by placing Surrogates close (topologically) to high concentrations of subscribers 🏠. The ISP knows the prefixes it has allocated to end users, so it can easily construct a list of the prefixes its Surrogates were positioned to serve 📋.

When a purpose-built CDN like that interconnects with other CDNs and advertises its footprint to a uCDN, though, the original intended coverage might not represent its actual value to the interconnection of CDNs 🤷‍♀️. Picture this: ISP-A and ISP-B both run their own CDNs, and they interconnect them via CDNI 🔗. A user E, who is a customer of ISP-B, might happen to be topologically closer to a Surrogate fielded by ISP-A, if E lives in a region where ISP-B has few customers and ISP-A has many. So in this case, is it ISP-A's CDN that "covers" E? 👀 If ISP-B's CDN has a failure condition, is it up to the uCDN to understand that ISP-A's Surrogates are potentially available as backups? And if so, how does ISP-A advertise itself as a "standby" for E? 😰 What about the case where CDNs advertising to the same uCDN express overlapping coverage, for example by mixing global and limited CDNs? 🌀

The answers to these questions depend a lot on how much information the uCDN wants to use to select a dCDN. If a uCDN has three dCDNs to choose from that "cover" the IP address of user E, the uCDN might be really interested in how optimal the coverage is from each of those dCDNs 🧐. Coverage doesn't have to be binary (that is, either provided or not provided) 🙅‍♀️. dCDNs could advertise a coverage "score", for example, and as long as they all report scores fairly on the same scale, uCDNs could use that information to make their topological optimality decision 📊. Alternately, dCDNs could advertise the IP addresses of their Surrogates rather than prefix "coverage", and let the uCDN decide for itself (based on its own topological intelligence) which dCDN has better resources to serve a given user 🧠.

So, in summary, the semantics of advertising a footprint depend on whether (1) qualitative metrics for expressing a footprint (like the coverage "score" mentioned above) are included as part of the CDNI FCI, or (2) the focus is just on a "binary" footprint 🎀.

2.2. Capabilities and Dynamic Data

In cases where the apparent footprints of dCDNs overlap, uCDNs might also want to rely on other factors to evaluate the respective merits of each dCDN 💅. These include facts about the Surrogates themselves, the network where a Surrogate is deployed, the nature of the resource being sought, and the administrative policies of the respective networks 🗂️.

Without network-layer impediments to reaching Surrogates, the choice to limit coverage is, by necessity, an administrative policy 📜. Lots of policy has to be agreed upon before CDNs can interconnect, including questions of membership, compensation, volumes, and so on 🤝. A uCDN will definitely factor these kinds of considerations into its decision to select a dCDN, but there's probably little need for dCDNs to actually advertise them through an interface. They'll get settled out-of-band as a precondition for interconnection 💼.

Other facts about the dCDN would be expressed through the interface to the uCDN ✨. Some capabilities of a dCDN are static, and some are highly dynamic 🌊. For example, the total storage built into its Surrogates changes relatively rarely, whereas the amount of storage in use at any given moment is super volatile 💾. Network bandwidth is similar: it could be expressed either as total bandwidth available to a Surrogate, or based on the current state of the network 📶. A Surrogate can lack a particular resource in storage at one moment and then have it the next 😳.

The semantics of the capabilities interface depend on how much of the dCDN state needs to be pushed to the uCDN, and, qualitatively, how often that information needs to be updated 🔁.

2.3. Advertisement versus Queries

In a CDNI environment, each dCDN shares some of its state with the uCDN 🫶. The uCDN uses this information to build a unified picture of all of the dCDNs available to it 🗺️. In architectures that share detailed capability information, the uCDN could perform the entire Request Routing operation, all the way down to selecting a particular Surrogate in the dCDN 🎯. However, when the uCDN needs to deal with many potential dCDNs, this approach doesn't scale, especially for dCDNs with thousands or tens of thousands of Surrogates 😵. The volume of updates to the footprint and capability information becomes onerous 💀.

If the volume of FCI updates from dCDNs were to exceed the volume of requests to the uCDN, it might make more sense for the uCDN to query dCDNs upon receiving requests 🔍. That's how the recursive redirection mode described in [RFC7336] works, and it's the alternative to receiving advertisements and tracking the state of dCDNs. The advantage of querying dCDNs is that much of the dynamic data that dCDNs cannot share with the uCDN would now be factored into the uCDN's decision 🧠. dCDNs wouldn't need to replicate any state to the uCDN, so uCDNs could effectively operate in a stateless mode 🌬️.

The semantics of both footprint advertisements and capability advertisements depend on the service model here. So the question is: are there cases where a synchronous query/response model would work better for the uCDN decision than a state replication model? 🤔💭

2.4. Avoiding or Handling "Cheating" dCDNs

When more than one dCDN is willing to serve a given end user request, it might be tempting for a dCDN to "cheat" 😈. In this sense, cheating means the dCDN provides inaccurate information to the uCDN in order to convince the uCDN to select it over "competing" dCDNs 🙃. So it could be desirable to take away the incentive for dCDNs to cheat in what they advertise, as much as possible 🧹. One option is to make the information a dCDN advertises somehow verifiable for the uCDN 🔐. On the other hand, a "cheating" dCDN might be avoided or handled by the fact that there will be strong contractual agreements between a uCDN and a dCDN, so a dCDN would risk severe penalties or legal consequences when caught cheating ⚖️.

ngl, cheating dCDNs are the villains of this whole story, and the contracts are basically the bodyguards keeping everyone honest 🛡️💀

Overall, the information a dCDN advertises (in the long run) needs to be somehow qualitatively verifiable by the uCDN, though possibly through non-real-time, out-of-band audits 🕵️‍♀️. It's probably an overly strict requirement to mandate that such verification be possible "immediately", i.e., during the Request Routing process itself 🙅‍♀️. If the uCDN can detect a cheating dCDN at a later stage, it might be enough for the uCDN to "de-incentivize" cheating, because cheating would negatively affect the long-term business relationship with that particular dCDN 📉💅.

3. Focusing on Capabilities with Footprint Restrictions 🎀

Given the design considerations from the previous section, it seems reasonable to assume that in most cases it's the uCDN that makes the decision to select a certain dCDN for Request Routing, based on information the uCDN has received from that particular dCDN 🫡. It can be assumed that cheating dCDNs will be dealt with through means outside the scope of CDNI, and that the information advertised between CDNs is accurate 🥰. Also, leaving out qualitative information (e.g., Surrogate proximity, delivery latency, Surrogate load) for predicting the quality of delivery would further simplify the use case 🧸. That lets it focus better on the basic functionality of the FCI 🌟.

Furthermore, since in most cases contractual agreements will define the basic coverage used in delegation decisions, the primary focus of the FCI is on providing updates to the basic capabilities and coverage by the dCDNs 📬. So the FCI has chosen the semantics of "capabilities with footprint restrictions" 👑💖

4. Footprint and Capabilities Extension ✨

Okay so future specs can totally add more optional footprint types, whether they're "coverage/reachability" footprints or "resource" footprints 🗺️. To keep that smooth, there's a clear process for registering optional footprint types in an IANA registry, the "CDNI Metadata Footprint Types" registry (defined in the CDNI Metadata interface document [RFC8006]). iykyk 💅

This doc also registers CDNI Payload Types [RFC7736] for the initial capability types (see Section 6):

Delivery Protocol (for delivering content to the end user)
Acquisition Protocol (for acquiring content from the uCDN or origin server)
Redirection Mode (e.g., DNS redirection vs. HTTP redirection as discussed in [RFC7336])
CDNI Logging (i.e., supported CDNI Logging fields)
CDNI Metadata (i.e., supported GenericMetadata types)

Each Payload Type is prefaced with "FCI." 🎀 Updates to capability objects MUST indicate the version of the capability object in a newly registered Payload Type, e.g., by appending ".v2". Each capability type can have a list of valid values. Future specs that define a given capability MUST define any necessary registries (and the rules for adding new entries to them) for the values advertised for that capability type. Main character energy 👑

Now the logging stuff. The "CDNI Logging record-types" registry [RFC7937] lists every known record-type, including the "mandatory-to-implement" ones. Advertising support for mandatory-to-implement record-types would be redundant, so CDNs SHOULD NOT advertise them 🙈

The "CDNI Logging Field Names" registry [RFC7937] lists every known CDNI Logging field. Fields can get reused across different record-types, and they can be mandatory-to-implement in some while optional in others. So CDNs MUST advertise support for optional CDNI Logging fields within the context of a specific record-type. For a given record-type, CDNs SHOULD NOT advertise support for mandatory-to-implement CDNI Logging fields. The following CDNI Logging fields are defined as optional for the "cdni_http_request_v1" record-type [RFC7937]:

s-ccid
s-sid

Next, metadata 📦 [RFC8006] requires that CDNs be able to parse all the defined metadata objects, but it does not require dCDNs to enforce non-structural GenericMetadata objects. Advertising support for "mandatory-to-enforce" GenericMetadata types MUST be provided. Advertising support for non-mandatory-to-enforce GenericMetadata types SHOULD be provided. Advertising non-mandatory-to-enforce GenericMetadata may be necessary, e.g., to signal temporary outages and the recovery that follows. Structural metadata is expected to be supported at all times. 🧚

Here's the big one. Optional footprint types and capability types mean that some implementations won't support every kind of footprint or capability. That's why any FCI solution protocol MUST define how support for optional footprint types and capability types gets negotiated between a uCDN and a dCDN using that particular FCI protocol. Specifically, any FCI solution protocol MUST specify how to handle failure cases or non-supported footprint or capability types. No cap, this is the part that keeps things from getting messy 🫶

In general, a uCDN MAY ignore capabilities or footprint types it does not understand. In that case, it only picks a suitable dCDN based on the capability and footprint types it does understand. Similarly, if a dCDN doesn't use an optional capability or footprint that a uCDN does support, that's totally fine for FCI functionality, because the uCDN is the one that decides on the remaining capability and footprint information the dCDN conveys 💖

5. Capability Advertisement Object

To support extensibility, FCI defines a generic base object (similar to the CDNI Metadata interface GenericMetadata object) [RFC8006]. It gives all future FCI objects a uniform set of mandatory parsing requirements, which is so clean 🌸

Future object definitions (e.g., for the CDNI Metadata or CDNI Logging interfaces) will build off the base object defined here, but they'll be specified in separate documents. 🦋

Note: In the following sections, the term "mandatory-to-specify" is used to convey which properties MUST be included when serializing a given capability object. When mandatory-to-specify is defined as "Yes" for an individual property, it means that if the object containing that property is included in an FCI message, then the mandatory-to-specify property MUST also be included. 🎀

5.1. Base Advertisement Object

The FCIBase object is an abstraction for managing individual CDNI capabilities in an opaque manner. 🫧

capability-type
- Description: CDNI capability object type.
- Type: FCI-specific CDNI Payload Type (from the "CDNI Payload Types" registry [RFC7736])
- Mandatory-to-Specify: Yes.
capability-value
- Description: CDNI capability object.
- Type: Format/Type is defined by the value of the capability-type property above.
- Mandatory-to-Specify: Yes.
footprints
- Description: CDNI capability footprint.
- Type: List of CDNI Footprint objects (from the "CDNI Metadata Footprint Types" registry [RFC8006])
- Mandatory-to-Specify: No.

5.2. Encoding

CDNI FCI objects MUST be encoded using JSON [RFC7159] and MUST also follow the recommendations of I-JSON (Internet JSON) [RFC7493]. FCI objects are made of a dictionary of (key, value) pairs, where the keys are the property names and the values are the matching property values. Very organized, very iconic 📋

The keys in the dictionary are the names of the properties on the object, so they depend on the exact object being encoded. That means they depend on the CDNI Payload Type of the capability or the CDNI Metadata Footprint Type of the footprint. The values tied to each key depend on the same thing 🧩

JSON dictionary keys (properties) are case sensitive. By convention, any dictionary key (property) defined by this document MUST be lowercase. Lowercase only, bestie 💅

5.3. Delivery Protocol Capability Object

The Delivery Protocol capability object is used to indicate support for one or more of the protocols listed in the "CDNI Metadata Protocol Types" registry (defined in [RFC8006]). 🚀

delivery-protocols
- Description: List of supported CDNI delivery protocols.
- Type: List of protocol types (from the "CDNI Metadata Protocol Types" registry [RFC8006])
- Mandatory-to-Specify: Yes.

5.3.1. Delivery Protocol Capability Object Serialization

Here's an example of Delivery Protocol capability object serialization for a CDN that only supports HTTP/1.1 without Transport Layer Security (TLS) for content delivery. Simple but serving 🍓

{
  "capabilities": [
    {
      "capability-type": "FCI.DeliveryProtocol",
      "capability-value": {
        "delivery-protocols": [
          "http/1.1",
        ]
      },
      "footprints": [
        <Footprint objects>
      ]
    }
  ]
}

5.4. Acquisition Protocol Capability Object

The Acquisition Protocol capability object is used to indicate support for one or more of the protocols listed in the "CDNI Metadata Protocol Types" registry (defined in [RFC8006]). 📥

acquisition-protocols
- Description: List of supported CDNI acquisition protocols.
- Type: List of protocol types (from the "CDNI Metadata Protocol Types" registry [RFC8006])
- Mandatory-to-Specify: Yes.

5.4.1. Acquisition Protocol Capability Object Serialization

Here's an example of Acquisition Protocol capability object serialization for a CDN that supports HTTP/1.1 with or without TLS for content acquisition. Options are giving flexibility 🦋

{
  "capabilities": [
    {
      "capability-type": "FCI.AcquisitionProtocol",
      "capability-value": {
        "acquisition-protocols": [
          "http/1.1",
          "https/1.1"
        ]
      },
      "footprints": [
        <Footprint objects>
      ]
    }
  ]
}

5.5. Redirection Mode Capability Object

The Redirection Mode capability object is used to indicate support for one or more of the modes listed in the "CDNI Capabilities Redirection Modes" registry (see Section 6.2). 🔀

redirection-modes
- Description: List of supported CDNI redirection modes.
- Type: List of redirection modes (from the "CDNI Capabilities Redirection Modes" registry, defined in Section 6.2)
- Mandatory-to-Specify: Yes.

5.5.1. Redirection Mode Capability Object Serialization

Here's an example of Redirection Mode capability object serialization for a CDN that only supports iterative (i.e., not recursive) redirection with HTTP and DNS. Fully iterative, fully iconic 🧚

{
  "capabilities": [
    {
      "capability-type": "FCI.RedirectionMode",
      "capability-value": {
        "redirection-modes": [
          "DNS-I",
          "HTTP-I"
        ]
      }
      "footprints": [
        <Footprint objects>
      ]
    }
  ]
}

5.6. CDNI Logging Capability Object

The CDNI Logging capability object is used to indicate support for CDNI Logging record-types, as well as CDNI Logging fields that are marked as optional for the specified record-types [RFC7937]. Logging receipts 📝

record-type
- Description: Supported CDNI Logging record-type.
- Type: String corresponding to an entry from the "CDNI Logging record-types" registry [RFC7937]
- Mandatory-to-Specify: Yes.
fields
- Description: List of supported CDNI Logging fields that are optional for the specified record-type.
- Type: List of strings corresponding to entries from the "CDNI Logging Field Names" registry [RFC7937]
- Mandatory-to-Specify: No. Default is that all optional fields are supported. Omission of this field MUST be interpreted as "all optional fields are supported". An empty list MUST be interpreted as "no optional fields are supported". Otherwise, if a list of fields is provided, the fields in that list MUST be interpreted as "the only optional fields that are supported". 🌈

5.6.1. CDNI Logging Capability Object Serialization

Okay so here's the vibe check 💅 Logging capability serialization, three examples, let's gooo 🎀

First up, a CDN that supports the optional Content Collection ID CDNI Logging field (but NOT the optional Session ID one) for the "cdni_http_request_v1" record-type. It's giving precise and I'm obsessed 🦋

{
  "capabilities": [
    {
      "capability-type": "FCI.Logging",
      "capability-value": {
        "record-type": "cdni_http_request_v1",
        "fields": ["s-ccid"]
      },
      "footprints": [
        <Footprint objects>
      ]
    }
  ]
}

Next, the CDNI Logging capability object serialization for a CDN that supports ALL the optional fields for "cdni_http_request_v1" 🌈 main character energy, no notes.

{
  "capabilities": [
    {
      "capability-type": "FCI.Logging",
      "capability-value": {
        "record-type": "cdni_http_request_v1"
      },
      "footprints": [
        <Footprint objects>
      ]
    }
  ]
}

And the final one 💀 a CDN that supports NONE of the optional fields for "cdni_http_request_v1". Same shape, but the fields list is just empty.

{
  "capabilities": [
    {
      "capability-type": "FCI.Logging",
      "capability-value": {
        "record-type": "cdni_http_request_v1",
        "fields": []
      },
      "footprints": [
        <Footprint objects>
      ]
    }
  ]
}

5.7. CDNI Metadata Capability Object

5.7. CDNI Metadata Capability Object ✨

Okay bestie, the CDNI Metadata capability object is how a CDN says which CDNI GenericMetadata types it supports 🧚 It's referencing [RFC8006] for all the metadata deets.

Property: metadata 🍓

Description: List of supported CDNI GenericMetadata types.

Type: List of strings corresponding to entries from the "CDNI Payload Types" registry [RFC7736] that correspond to CDNI GenericMetadata objects

Mandatory-to-Specify: Yes. An empty list MUST be interpreted as "no GenericMetadata types are supported", i.e., "only structural metadata and simple types are supported"; otherwise, the list must be interpreted as containing "the only GenericMetadata types that are supported" (in addition to structural metadata and simple types) [RFC8006].

Heads up, this one's a big deal 💖 An empty list MUST be read as "no GenericMetadata types are supported", which means only structural metadata and simple types. Otherwise the list is read as "the only GenericMetadata types that are supported" (plus structural metadata and simple types) [RFC8006]. No skipping this, periodt.

5.7.1. CDNI Metadata Capability Object Serialization

Okay so the first example is a CDN that supports ONLY the SourceMetadata GenericMetadata type. It can acquire and deliver content, but it can't enforce any security policies (like time, location, or protocol Access Control Lists (ACLs)) 🔥

{
  "capabilities": [
    {
      "capability-type": "FCI.Metadata",
      "capability-value": {
        "metadata": ["MI.SourceMetadata"]
      },
      "footprints": [
        <Footprint objects>
      ]
    }
  ]
}

And the next one is a CDN that supports only structural metadata. It can parse metadata as a transit CDN, but it can't enforce security policies or deliver content 🌸

{
  "capabilities": [
    {
      "capability-type": "FCI.Metadata",
      "capability-value": {
        "metadata": []
      },
      "footprints": [
        <Footprint objects>
      ]
    }
  ]
}

6. IANA Considerations 🎀

6.1. CDNI Payload Types

Bestie, this document registers the following CDNI Payload Types under the IANA "CDNI Payload Types" registry 🦋

+-------------------------+---------------+
| Payload Type            | Specification |
+-------------------------+---------------+
| FCI.DeliveryProtocol    | RFC 8008      |
| FCI.AcquisitionProtocol | RFC 8008      |
| FCI.RedirectionMode     | RFC 8008      |
| FCI.Logging             | RFC 8008      |
| FCI.Metadata            | RFC 8008      |
+-------------------------+---------------+

6.1.1. CDNI FCI DeliveryProtocol Payload Type

Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported delivery protocols 🧚

Interface: FCI

Encoding: see Section 5.3

6.1.2. CDNI FCI AcquisitionProtocol Payload Type

Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported acquisition protocols 💜

Interface: FCI

Encoding: see Section 5.4

6.1.3. CDNI FCI RedirectionMode Payload Type

Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported redirection modes ✨

Interface: FCI

Encoding: see Section 5.5

6.1.4. CDNI FCI Logging Payload Type

Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported CDNI Logging record-types and optional CDNI Logging field names 🌈

Interface: FCI

Encoding: see Section 5.6

6.1.5. CDNI FCI Metadata Payload Type

Purpose: The purpose of this Payload Type is to distinguish FCI advertisement objects for supported CDNI GenericMetadata types 🫶

Interface: FCI

Encoding: see Section 5.7

6.2. "CDNI Capabilities Redirection Modes" Registry

Okay so IANA made a brand new "CDNI Capabilities Redirection Modes" registry inside the "Content Delivery Network Interconnection (CDNI) Parameters" registry 👑 The "CDNI Capabilities Redirection Modes" namespace defines the valid redirection modes that a CDN can advertise as supported. Additions to it conform to the IETF Review policy as defined in [RFC5226].

The initial redirection modes are in this table 💅

+------------------+----------------------------------+----------+
| Redirection Mode | Description                      | RFC      |
+------------------+----------------------------------+----------+
| DNS-I            | Iterative DNS-based Redirection  | RFC 8008 |
| DNS-R            | Recursive DNS-based Redirection  | RFC 8008 |
| HTTP-I           | Iterative HTTP-based Redirection | RFC 8008 |
| HTTP-R           | Recursive HTTP-based Redirection | RFC 8008 |
+------------------+----------------------------------+----------+

7. Security Considerations 💀🚨

Okay bestie, this one is SERIOUS so pay attention 😭 This specification describes the semantics for capabilities and footprint advertisement objects across interconnected CDNs. It does NOT, however, specify a concrete protocol for transporting those objects. Specific security mechanisms can only be selected for concrete protocols that instantiate these semantics. This document does, however, place some high-level security constraints on such protocols.

All protocols that implement these capabilities and footprint advertisement objects are REQUIRED to provide integrity and authentication services. Without authentication and integrity, an attacker could trivially deny service by forging a footprint advertisement from a dCDN that claims the network has no footprint or capability. That would stop the uCDN from delegating any requests to the dCDN 🙈 Since a preexisting relationship between all dCDNs and uCDNs is assumed by CDNI, the exchange of any necessary credentials could be conducted before the FCI is brought online. The authorization decision to accept advertisements would also follow this preexisting relationship and any contractual obligations that it stipulates.

All protocols that implement these capabilities and footprint advertisement objects are REQUIRED to provide confidentiality services. Some dCDNs are willing to share information about their footprints or capabilities with a uCDN but NOT with other, competing dCDNs. For example, if a dCDN has an outage that temporarily reduces footprint coverage, that event could be information the dCDN would want to share confidentially with the uCDN 🫣

As specified in this document, the security requirements of the FCI could be met by transport-layer security mechanisms coupled with domain certificates as credentials (e.g., TLS transport for HTTP as per [RFC2818] and [RFC7230], with usage guidance from [RFC7525]) between CDNs. There is no apparent need for further object-level security in this framework, as the trust relationships it defines are bilateral relationships between uCDNs and dCDNs rather than transitive relationships 🤝

8. References 📚

8.1. Normative References

[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, <http://www.rfc-editor.org/info/rfc2119>.

[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, <http://www.rfc-editor.org/info/rfc5226>.

[RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 2014, <http://www.rfc-editor.org/info/rfc7159>.

[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, <http://www.rfc-editor.org/info/rfc7336>.

[RFC7493] Bray, T., Ed., "The I-JSON Message Format", RFC 7493, DOI 10.17487/RFC7493, March 2015, <http://www.rfc-editor.org/info/rfc7493>.

[RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., and R. Peterkofsky, "Content Distribution Network Interconnection (CDNI) Logging Interface", RFC 7937, DOI 10.17487/RFC7937, August 2016, <http://www.rfc-editor.org/info/rfc7937>.

[RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, <http://www.rfc-editor.org/info/rfc8006>.

8.2. Informative References ✨

Okay these ones are the background reading, bestie 📚 Not required to get the core ideas, but they're the good context.

[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/RFC2818, May 2000, <http://www.rfc-editor.org/info/rfc2818>.
[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, <http://www.rfc-editor.org/info/rfc6707>.
[RFC6770] Bertrand, G., Ed., Stephan, E., Burbridge, T., Eardley, P., Ma, K., and G. Watson, "Use Cases for Content Delivery Network Interconnection", RFC 6770, DOI 10.17487/RFC6770, November 2012, <http://www.rfc-editor.org/info/rfc6770>.
[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, <http://www.rfc-editor.org/info/rfc7230>.
[RFC7337] Leung, K., Ed., and Y. Lee, Ed., "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, DOI 10.17487/RFC7337, August 2014, <http://www.rfc-editor.org/info/rfc7337>.
[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, <http://www.rfc-editor.org/info/rfc7525>.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, <http://www.rfc-editor.org/info/rfc7736>.

Appendix A. Main Use Case to Consider 🎀

Okay so focusing on one main use case helps a ton! Pick a scenario that's simple but still a little tricky, realistic, and easy to imagine, and suddenly the CDNI FCI requirements get way easier to pin down 💅 This simplified use case makes the meaning of footprints and capabilities for CDNI super clear. The real goal is figuring out what info needs to go over the CDNI FCI, which types of info must be supported (mandatory 👑) and which are optional, and what info needs updating compared to the CDNI contracts that were already set up ahead of time.

Use case: A uCDN has a bunch of dCDNs 🌸 It picks one dCDN for delivery protocol A and footprint 1, and a different dCDN for delivery protocol B and footprint 1. That protocol B dCDN has its own further, transitive (level-2) dCDN that serves delivery protocol B, but only in a subset of footprint 1, the part the first-level dCDN can't cover for protocol B itself. So what happens if capabilities change in that transitive level-2 dCDN and it might mess with how the uCDN picks its level-1 dCDN? Like, what if the level-2 dCDN can't serve protocol B anymore 😭 How do those changes get conveyed back to the uCDN? And what info does the uCDN actually need to pick a brand-new first-level dCDN, whether that's for all of footprint 1 or just the subset the level-2 dCDN was covering on behalf of the first-level dCDN? 🧚

Appendix B. Semantics for Footprint Advertisement 🦋

Roughly speaking, a "footprint" is a dCDN's "ability and willingness to serve" 🌈 But the uCDN might want more info before it picks a dCDN, like "how well" that dCDN can actually serve a given end user request. The dCDN's ability and willingness to serve SHOULD be kept separate from that subjective, qualitative "how well" measurement. You can picture that extra info being implicitly tied to a footprint through contracts, Service Level Agreements (SLAs), business relationships, or past perceptions of dCDN quality. Or it could be explicitly included right alongside the footprint, which is also a valid option ✨

Here's the thing: a big chunk of the footprint advertisement is probably going to happen out-of-band, before any CDNI FCI advertisement even starts, with footprints defined in the contracts between the participating CDNs 📜 That makes sense, because any contract will likely spell out the specific dCDN coverage (footprint) it applies to. Extra info about delivery quality for a footprint might also live in those contracts, outside the CDNI FCI. And honestly, the dCDN quality agreements in those contracts will probably be built on high-level, aggregated statistics, so they won't be super detailed 🙈

Since so much of the footprint advertisement lives in contracts, the real question becomes: what still needs to be advertised by the CDNI FCI? For example, updates about temporary failures of part of a footprint can be super useful to send over the CDNI Request Routing interface 💀 Those updates just change info that was already agreed on in the contracts between the participating CDNs. So in other words, the CDNI FCI is how a dCDN shares changes and updates about a footprint it already agreed to serve in a contract with a uCDN 💖

Generally speaking, a dCDN can advertise two categories of footprints:

A footprint could be defined based on coverage/reachability, where "coverage/reachability" refers to a set of prefixes, a geographic region, or similar boundary. The dCDN claims that it can cover/reach "end user requests coming from this footprint".
A footprint could be defined based on resources, where "resources" refers to Surrogates a dCDN claims to have (e.g., the location of Surrogates/resources). The dCDN claims that "from this footprint" it can serve incoming end user requests.

For each of these footprint types, there are capabilities attached to a given footprint:

capabilities such as delivery protocol, redirection mode, and metadata, which are supported in the coverage area for a footprint that is defined by coverage/reachability, or
capabilities of resources, such as delivery protocol, redirection mode, and metadata, which apply to a footprint that is defined by resources.

Resource footprint types are more specific than coverage/reachability footprint types, since the actual coverage and reachability get extrapolated from the resource location (e.g., a netmask applied to a resource IP address to derive an IP prefix) 🦋 How you extrapolate coverage/reachability from the resource location is beyond the scope of this document. In the degenerate case, the resource address could just be specified as a coverage/reachability footprint type, so no extrapolation is needed. Heads up though: resource footprint types could expose the internal structure of a CDN, and that could be undesirable 👀 Because of that, resource footprint types are not considered mandatory to support for CDNI.

Footprints work as constraints for delegating requests to a dCDN. A dCDN footprint advertisement tells the uCDN the limits for delegating a request to that dCDN. For IP prefixes or ASN(s), the footprint signals that the uCDN should only consider the dCDN a candidate if the IP address of the Request Routing source falls within the prefix set (or the ASN, respectively). The CDNI specifications don't define how a given uCDN figures out which address ranges belong to a particular ASN, so that's on the uCDN 🤷‍♀️ Same deal for country codes: a uCDN should only consider the dCDN a candidate if it covers the country of the Request Routing source. The CDNI specifications also don't define how a uCDN determines the country of the Request Routing source. And multiple footprint constraints are additive, meaning advertising different footprint types narrows the dCDN's candidacy cumulatively 🔥

No matter what type of footprint it is, a footprint might also include the connectivity of a given dCDN to other CDNs that can serve content to users on behalf of that dCDN. That's how cases with cascaded CDNs get covered 🧩 Also, the dCDN needs to be able to express its footprint to an interested uCDN in a comprehensive form, like a data set containing the complete footprint. That said, making incremental updates to express dynamic changes in state is also desirable, because nobody wants to resend the whole thing every time something shifts 💜

Appendix C. Semantics for Capabilities Advertisement ✨

okay so bestie, this appendix is all about what a dCDN can tell a uCDN about what it can actually do 💅 general capabilities like "can I do HTTP or HTTPS?" are the main vibe here, and they can be footprint-specific too 🗺️ like, the dCDN might be HTTPS-ready almost everywhere but not in one particular area because of maintenance or because the Surrogates there just can't deliver that type of service. so sometimes a footprint and its capabilities are literally joined at the hip and you can't read one without the other 🔗 in those cases, it could be beneficial to combine footprint advertisement and capabilities advertisement. iykyk 🫶

the rough semantic is this 🌸: capabilities are the bits of info that let a uCDN figure out whether a dCDN is able (and willing) to accept (and properly handle) a delegated content request. and the iconic part is that capabilities can change over time based on the state of the network or Surrogates 🔄

now, a bunch of categories sound useful at first glance 👀 but advertising stuff that changes super dynamically (think real-time delivery performance metrics, CDN resource load, or other highly dynamic QoS info) is out of scope for the CDNI FCI 🙅‍♀️ two reasons: first, nobody can agree on which metrics to use from the giant pile of options 😭 and second, specifying highly dynamic capabilities and their metrics in a reasonable time frame seems infeasible 💀

useful capabilities are the ones that don't change highly dynamically and are often absolutely necessary for picking a dCDN for a given end user request 🎯 example: if someone wants a video file delivered with a certain protocol, the uCDN needs to know if the dCDN can support that delivery protocol. no cap, that's the whole point 🎬

similar to footprint advertisement 🗺️, a significant chunk of the actual resource capabilities advertisement is expected to happen out-of-band, before any CDNI FCI advertisement, with capabilities defined in contractual agreements between the participating CDNs 📜 so the role of capability advertisement is more like keeping the uCDN updated on changes since the contract was set up 🔔 for example, a new delivery protocol suddenly gets added to a dCDN's supported list, or a protocol suddenly stops being supported because of failures 💥 so "capabilities advertisement" basically means conveying info about changes or updates to certain capabilities with respect to a given contract 🫧

okay now the tricky part 🥺 it needs to be decided which exact capabilities are useful and how they get expressed. the details of CDNI contracts weren't known when this was written (and the CDNI interface is better off staying agnostic to them anyway), so it remains to be seen which capabilities get used in practice 🤷‍♀️ one implication for standardization could be to initially specify only a very limited set of mandatory capabilities for advertisement, and then have a flexible data model on top that lets CDNs exchange extra capabilities when needed 🧩 still, the CDNs need to reach agreement on which capabilities (if any) are mandatory among them 🤝

it's not feasible to list every possible option for the mandatory capabilities above (like all the potential delivery protocols or metadata options) or predict every future need for more capabilities 😵‍💫 so FCI object extensibility is necessary to support future capabilities, plus a generic protocol for conveying any capability information 🎀 (with common encoding, error handling, and security mechanisms 🔐). further requirements for the CDNI FCI are listed in [RFC7337] 📚 periodt.

Acknowledgments 🫶

Jan Seedorf is partially supported by the GreenICN project (GreenICN: Architecture and Applications of Green Information Centric Networking) 🌿, a research project supported jointly by the European Commission under its 7th Framework Program (contract no. 608518) and the National Institute of Information and Communications Technology (NICT) in Japan (contract no. 167). the views and conclusions contained herein are those of the authors and should not be interpreted as necessarily representing the official policies or endorsements, either expressed or implied, of the GreenICN project, the European Commission, or NICT 💜

Martin Stiemerling provided initial input to this document and valuable comments to the ongoing discussions among the authors of this document 🦋. Thanks to Francois Le Faucheur and Scott Wainner for providing valuable comments and suggestions for the text 🌈 they're literally the MVPs 👑

Authors' Addresses 📮

Jan Seedorf HFT Stuttgart - University of Applied Sciences Stuttgart Schellingstrasse 24 Stuttgart 70174 Germany

Phone: +49-0711-8926-2801 Email: jan.seedorf@hft-stuttgart.de

Jon Peterson NeuStar 1800 Sutter St. Suite 570 Concord, CA 94520 United States of America

Email: jon.peterson@neustar.biz

Stefano Previdi Cisco Systems Via Del Serafico 200 Rome 0144 Italy

Email: sprevidi@cisco.com

Ray van Brandenburg TNO Anna van Buerenplein 1 The Hague 2595DA The Netherlands

Phone: +31-88-866-7000 Email: ray.vanbrandenburg@tno.nl

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

📦 where this page comes from

ietf: rfc8008 2016-12
💖 girlified by claude-haiku-5-5 on 2026-10-18: a language model's rewrite of the original, under its terms

RFC 8008

Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics 🎀

Abstract

Status of This Memo

Copyright Notice

Table of Contents

1. Introduction and Scope ✨

1.1. Terminology 🧚

2. Design Decisions for Footprint and Capabilities ✨

2.1. Advertising Limited Coverage

2.2. Capabilities and Dynamic Data

2.3. Advertisement versus Queries

2.4. Avoiding or Handling "Cheating" dCDNs

3. Focusing on Capabilities with Footprint Restrictions 🎀

4. Footprint and Capabilities Extension ✨

5. Capability Advertisement Object

5.1. Base Advertisement Object

5.2. Encoding

5.3. Delivery Protocol Capability Object

5.3.1. Delivery Protocol Capability Object Serialization

5.4. Acquisition Protocol Capability Object

5.4.1. Acquisition Protocol Capability Object Serialization

5.5. Redirection Mode Capability Object

5.5.1. Redirection Mode Capability Object Serialization

5.6. CDNI Logging Capability Object

5.7. CDNI Metadata Capability Object

5.7. CDNI Metadata Capability Object ✨

5.7.1. CDNI Metadata Capability Object Serialization

6. IANA Considerations 🎀

6.1. CDNI Payload Types

6.1.1. CDNI FCI DeliveryProtocol Payload Type

6.1.2. CDNI FCI AcquisitionProtocol Payload Type

6.1.3. CDNI FCI RedirectionMode Payload Type

6.1.4. CDNI FCI Logging Payload Type

6.1.5. CDNI FCI Metadata Payload Type

6.2. "CDNI Capabilities Redirection Modes" Registry

7. Security Considerations 💀🚨

8. References 📚

8.1. Normative References

8.2. Informative References ✨

Appendix A. Main Use Case to Consider 🎀

Appendix B. Semantics for Footprint Advertisement 🦋

Appendix C. Semantics for Capabilities Advertisement ✨

Acknowledgments 🫶

Authors' Addresses 📮