RFC 9241

Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO)

📅 published July 2022, from ietf

1. Introduction ✨

okay so bestie, this is part 1 of 8 and it's already giving main character energy 💅 Let's get into the RFC 9241 vibes 🦋

Title block first, so you know the tea 🫶: this is an Internet Standards Track doc, published July 2022 by the IETF, with authors J. Seedorf (HFT Stuttgart), Y. Yang (Yale University), K. Ma (Ericsson), J. Peterson (NeuStar), and J. Zhang (Tongji University). It's titled "Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO)" 🎀. Its ISSN is 2070-1721, and it's RFC 9241. 🌸

Abstract vibes: the CDNI framework in RFC 6707 lets CDNs team up to hit goals like extending their reach 🌈. One piece they need is a CDNI Request Routing Footprint & Capabilities Advertisement interface (FCI). RFC 8008 explains what FCI means and gives guidelines, but it never nails down the exact protocol 😭. So this doc defines a new ALTO service called "CDNI Advertisement Service" that implements FCI, following those RFC 8008 guidelines 🔥.

Status of This Memo

This is an Internet Standards Track document 💜.

It's an IETF product and represents the consensus of the IETF community. It got public review and was approved for publication by the Internet Engineering Steering Group (IESG). More info on Internet Standards is in Section 2 of RFC 7841. You can check the current status, errata, and leave feedback at https://www.rfc-editor.org/info/rfc9241 🍓.

Copyright (c) 2022 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. Please read those carefully, because they spell out your rights and restrictions. Code Components pulled out of this doc must include Revised BSD License text as described in Section 4.e of the Trust Legal Provisions, and they come without warranty as described in the Revised BSD License 🙈.

Table of Contents

1.  Introduction
2.  Terminology and Background
  2.1.  Terminology
  2.2.  Semantics of FCI Advertisement
  2.3.  ALTO Background and Benefits
3.  CDNI Advertisement Service
  3.1.  Media Type
  3.2.  HTTP Method
  3.3.  Accept Input Parameters
  3.4.  Capabilities
  3.5.  Uses
  3.6.  Response
  3.7.  Examples
    3.7.1.  IRD
    3.7.2.  A Basic Example
    3.7.3.  Incremental Updates
4.  CDNI Advertisement Service Using ALTO Network Map
  4.1.  Network Map Footprint Type: altopid
  4.2.  Examples
    4.2.1.  ALTO Network Map for CDNI Advertisements
    4.2.2.  ALTO PID Footprints in CDNI Advertisements
    4.2.3.  Incremental Updates
5.  Filtered CDNI Advertisement Using CDNI Capabilities
  5.1.  Media Type
  5.2.  HTTP Method
  5.3.  Accept Input Parameters
  5.4.  Capabilities
  5.5.  Uses
  5.6.  Response
  5.7.  Examples
    5.7.1.  A Basic Example
    5.7.2.  Incremental Updates
6.  Query Footprint Properties Using ALTO Property Map Service
  6.1.  Representing Footprint Objects as Property Map Entities
    6.1.1.  ASN Domain
    6.1.2.  COUNTRYCODE Domain
  6.2.  Representing CDNI Capabilities as Property Map Entity
        Properties
    6.2.1.  Defining Information Resource Media Type for Property
            Type cdni-capabilities
    6.2.2.  Intended Semantics of Property Type cdni-capabilities
  6.3.  Examples
    6.3.1.  Property Map
    6.3.2.  Filtered Property Map
    6.3.3.  Incremental Updates
7.  IANA Considerations
  7.1.  application/alto-cdni+json Media Type
  7.2.  application/alto-cdnifilter+json Media Type
  7.3.  CDNI Metadata Footprint Types Registry
  7.4.  ALTO Entity Domain Types Registry
  7.5.  ALTO Entity Property Types Registry
8.  Security Considerations
9.  References
  9.1.  Normative References
  9.2.  Informative References
Acknowledgments
Contributors
Authors' Addresses

1. Introduction ✨

1.1 Why CDNs need to team up 🌸

Okay so the ability to interconnect multiple content delivery networks (CDNs) is seriously iconic 🌈. It brings increased coverage, capability, and reliability all at once. The CDNI framework [RFC6707] defines four interfaces for this: (1) the CDNI Request Routing Interface, (2) the CDNI Metadata Interface, (3) the CDNI Logging Interface, and (4) the CDNI Control Interface 💖.

Out of those four, the CDNI Request Routing Interface does the key jobs, as [RFC6707] lays out:

The CDNI Request Routing interface enables 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 allows the Downstream CDN to control what should be returned to the User Agent in the redirection message by the upstream Request Routing function.

So basically the Request Routing Interface has two main tasks 🧚: (1) figuring out if the dCDN (downstream CDN) is willing to accept a delegated Content Request, and (2) redirecting the Content Request from a uCDN (upstream CDN) to the right entry point or entity in the dCDN 👑.

That Request Routing Interface splits into two parts: (1) the CDNI Footprint & Capabilities Advertisement interface (FCI) from [RFC8008], and (2) the CDNI Request Routing Redirection interface (RI) from [RFC7975]. This document focuses on the first one, CDNI FCI 🦋.

1.2 What FCI actually does 💅

CDNI FCI allows two things: an Advertisement from a dCDN to a uCDN (that's a push 📣), and a query from a uCDN to a dCDN (that's a pull 🔍). Either way, the uCDN learns whether it can redirect a particular user request to that dCDN 🫶.

A huge part of FCI is defining the objects that describe a dCDN's footprints and capabilities. Those objects are already specified in Section 5 of [RFC8008]. The catch? No protocol exists to transport and update those objects between a uCDN and a dCDN 😭.

So this doc fixes that 💖. It specifies an extension of the Application-Layer Traffic Optimization (ALTO) Protocol [RFC7285] by introducing a new ALTO service called "CDNI Advertisement Service" 🎀.

Section 2.3 talks about the perks of using ALTO as a transport protocol 🌟.

1.3 Heads up, this is a big one 🍓

Your bestie is a keyword hoarder 🙈: the key words used in this document are only normative when they appear in ALL CAPS, like they do in the spec itself.

2. Terminology and Background ✨

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in BCP 14 [RFC2119] [RFC8174] when, and only when, they appear in all capitals, as shown here 💜.

The design of CDNI FCI transport using ALTO assumes you already understand both FCI semantics and ALTO. So this document kicks off with a non-normative review of both 🧚.

2.1. Terminology 🌸

This doc uses the CDNI terms defined in [RFC6707], [RFC8006], and [RFC8008]. It also uses the ALTO terms defined in [RFC7285] and [RFC9240]. Here are the abbreviations it uses 💅:

ALTO:   Application-Layer Traffic Optimization

ASN:    Autonomous System Number

CDN:    Content Delivery Network

CDNI:   CDN Interconnection

dCDN:   Downstream CDN

FCI:    CDNI FCI, CDNI Request Routing Footprint & Capabilities
        Advertisement interface

IRD:    Information Resource Directory in ALTO

PID:    Provider-defined Identifier in ALTO

uCDN:   Upstream CDN

That's the first chunk of RFC 9241, bestie 🦋. Part 2 is coming up next, so stay tuned 💜✨

2.2. Semantics of FCI Advertisement

okay so [RFC8008] is the one that spells out what CDNI FCI means 🎀 It explains what footprint and capabilities mean in a CDNI context, and it sets the requirements for the CDNI FCI transport protocol 💅 The definitions in [RFC8008] lean on [RFC8006], so they're a package deal 🫶 Below is a non-normative review of the key points from [RFC8008] and [RFC8006]. For the full details and the normative spec, the reader should go read those two RFCs 📚

  • Multiple types of mandatory-to-implement footprints (ipv4cidr, ipv6cidr, asn, and countrycode) are defined in [RFC8006] 🌸 A "set of IP prefixes" can hold both full IP addresses (a /32 for IPv4 or a /128 for IPv6) and IP prefixes with an arbitrary prefix length 🦋 There must also be support for multiple IP address versions, IPv4 and IPv6, in that footprint ✨
  • Multiple initial types of capabilities are defined in [RFC8008] 💜 They are: (1) Delivery Protocol, (2) Acquisition Protocol, (3) Redirection Mode, (4) capabilities related to CDNI Logging, and (5) capabilities related to CDNI Metadata 🧚 They're required in all cases, so they count as mandatory-to-implement capabilities for every CDNI FCI implementation 💖
  • Footprint and capabilities are defined together, and you can't interpret one without the other 🍓 [RFC8008] pairs them using an approach called "capabilities with footprint restrictions", which means capabilities get expressed on a per footprint basis 👑
  • Footprints work as constraints for delegating requests to a dCDN 🔥 A dCDN footprint advertisement tells the uCDN the limits for handing a request over to that dCDN. For IP prefixes or Autonomous System Numbers (ASNs), the footprint tells the uCDN to consider the dCDN a candidate only if the IP address of the Request Routing source falls within that prefix set or ASN. The CDNI specs don't define how a uCDN figures out which address ranges belong to a particular ASN 🤷‍♀️ 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 specs also don't define how a uCDN works out the country of that source 🌍 You can stack different footprint constraints to narrow down dCDN candidacy. The uCDN should consider the dCDN a candidate only if the request routing source satisfies all the types of footprint constraints in the advertisement 💅
  • The semantics question is basically: what exactly still needs to be advertised by the CDNI FCI? 🤔 A big chunk of footprint and capabilities advertising happens through contracts, so the real job is handling updates. For example, news about temporary failures in part of a footprint is super useful to pass along through the CDNI FCI 🚨 That kind of info updates what the participating CDNs already agreed to in their contracts. In other words, the CDNI FCI is how a dCDN shares changes and updates about a footprint and/or capabilities it previously agreed to serve for a uCDN 🦋 So server push and incremental encoding will be necessary techniques 🫶

2.3. ALTO Background and Benefits

okay bestie, Application-Layer Traffic Optimization (ALTO) [RFC7285] is an approach for sharing network-layer (topology) information so it can "guide" the resource provider selection process in distributed applications 🗺️ Those apps can pick from several candidate resource providers when they want to grab a given resource. Usually the assumption is that an ALTO server shares info that these apps can't measure, or have a hard time measuring, on their own [RFC5693] 🔍

ALTO was originally motivated by optimizing cross-ISP traffic from peer-to-peer apps [RFC5693] 🌈 But it's also useful for improving Request Routing in CDNs 💖 In particular, Section 5 of [RFC7971] explicitly calls out ALTO as a candidate protocol for improving the selection of a CDN surrogate or origin ✨

Here's why ALTO is such a strong candidate for dCDN selection as part of CDNI Request Routing, and in particular for an FCI protocol 👑

  • Application-Layer-oriented: ALTO is designed to improve application-layer traffic (and application-layer connections among hosts on the Internet) by giving apps extra info they couldn't easily get themselves 🔥 That matches CDNI perfectly, since a uCDN wants to improve application-layer CDN request routing using info from a dCDN that it couldn't easily get otherwise 💅 So ALTO can help a uCDN pick a proper dCDN by first providing the dCDNs' capabilities and footprints (see Section 3), and then providing the costs of surrogates in a dCDN through ALTO cost maps 🧚
  • Security: Identification between uCDNs and dCDNs is a big requirement (see Section 8) 🔐 ALTO maps can be signed, which gives inherent origin protection. For the detailed protection strategies, see Section 15.1.2 of [RFC7285] 🛡️
  • RESTful design: The ALTO Protocol went through extensive revisions to get a RESTful design for the client-server interaction 🌸 It's flexible and extensible enough to handle existing and future data formats defined by CDNI. It can also give other existing CDNI interfaces, or potential future extensions, one consistent client-server interaction model, which cuts down the learning curve for users and developers 🎀 Those other interfaces aren't in the scope of this document, though. A CDNI FCI interface based on ALTO would inherit this RESTful design. See Section 3 🦋
  • Error handling: The ALTO Protocol has thorough error handling across the whole request and response process (see Section 8.5 of [RFC7285]) 🙈 A CDNI FCI interface based on ALTO would inherit that error-handling framework too. See Section 5 🫶
  • Map Service: The semantics of an ALTO network map are an exact match for the info needed to convey a dCDN's footprint, especially when that footprint is expressed as IP prefix ranges 🍓 See Section 4 ✨
  • Filtered Map Service: The ALTO map filtering service lets a uCDN query only parts of an ALTO map 🔍 For example, the ALTO filtered property Map Service can help a uCDN query properties of part of a footprint efficiently 💜 See Section 6 💅
  • Server-initiated notifications and incremental updates: When a dCDN's footprint or capabilities change in a way that's unexpected from the uCDN's point of view, server-initiated notifications let the dCDN tell the uCDN about it directly 🚨 Picture this: due to a failure, part of the dCDN's footprint isn't working, so the CDN can't serve content to those clients with reasonable QoS 😭 Without server-initiated notifications, the uCDN might keep using a recent network and cost map from the dCDN and keep redirecting requests to a dCDN that can't serve them 💀 Incremental updates make it efficient to convey these status changes (or similar ones) from the dCDN to the uCDN 🌸 The newest design of ALTO supports server-pushed incremental updates [RFC8895] 🎀
  • Content availability on hosts: A dCDN might want to express its CDN capabilities in terms of certain content types, like codecs and/or formats, or content from certain content providers 🎬 ALTO Entity Property Map [RFC9240] lets a dCDN make that info available to a uCDN 🧚 That way, the uCDN can check whether a dCDN has the capabilities for a given type of requested content 💖
  • Resource availability on hosts or links: The capabilities on links (like maximum bandwidth) or caches (like average load) could be super useful for a uCDN doing optimized dCDN selection 🌈 For instance, if a uCDN gets a streaming request for content with a certain bitrate, it needs to know whether a dCDN can probably fulfill that stringent application-level requirement (meaning it can be expected to have enough consistent bandwidth) before redirecting the request 🏎️ In general, if ALTO could convey that info via ALTO Entity Property Map [RFC9240], it would enable more sophisticated dCDN selection with ALTO 👑 The ALTO Path Vector extension [ALTO-PATH-VECTOR] is designed to let ALTO clients query info like capacity regions for a given set of flows ✨

3. CDNI Advertisement Service

the ALTO Protocol runs on the ALTO information service framework, which is made up of multiple services 🧩 All ALTO services are "provided through a common transport protocol; messaging structure and encoding; and transaction model" [RFC7285] 💅 The ALTO Protocol spec defines multiple initial services, like the ALTO Network Map Service and Cost Map Service 🗺️

This document defines a new ALTO service called "CDNI Advertisement Service" 🎀 It carries JSON [RFC8259] objects of media type application/alto-cdni+json 💜 These JSON objects are used to transport BaseAdvertisementObject objects defined in [RFC8008] 🧚 This document specifies how to transport those BaseAdvertisementObject objects via the ALTO Protocol with the ALTO CDNI Advertisement Service ✨ Like other ALTO services, this document defines the ALTO information resource for the CDNI Advertisement Service as follows 🦋

Heads up: the encoding of BaseAdvertisementObject reuses the one defined in [RFC8008], so it also follows the recommendations of I-JSON (Internet JSON) [RFC7493], which [RFC8008] requires 🫶

3.1. Media Type

the media type of the CDNI Advertisement resource is application/alto-cdni+json (see Section 7) 🍓

3.2. HTTP Method

a CDNI Advertisement resource is requested using the HTTP GET method 🌸

3.3. Accept Input Parameters

there are no applicable Accept Input parameters 🙈

3.4. Capabilities

there are no applicable capabilities 🤷‍♀️

3.5. Uses

the uses field MUST NOT appear unless the CDNI Advertisement resource depends on other ALTO information resources. If the CDNI Advertisement resource has dependent resources, the resource IDs of its dependent resources MUST be included in the uses field. 🚨

this document only defines one potential dependent resource for the CDNI Advertisement resource 🧚 See Section 4 for details of when and how to use it. Future documents may extend the CDNI Advertisement resource and allow other dependent resources 🌈

3.6. Response 💖

okay so the "meta" field of a CDNI Advertisement response MUST include the "vtag" field from Section 10.3 of [RFC7285] 🫶 this tells you the version of the retrieved CDNI FCI resource, so you always know which version you're looking at ✨

if a CDNI Advertisement response depends on other ALTO information resources, it MUST include the "dependent-vtags" field too 🎀 its value is an array of the version tags for those resources, and each resource is listed in "uses" of its Information Resource Directory (IRD) entry 🧚

the data component of an ALTO CDNI Advertisement response is called "cdni-advertisement" 💅 it's a JSON object of type CDNIAdvertisementData:

    object {
      CDNIAdvertisementData cdni-advertisement;
    } InfoResourceCDNIAdvertisement : ResponseEntityBase;

    object {
      BaseAdvertisementObject capabilities-with-footprints<0..*>;
    } CDNIAdvertisementData;

so a CDNIAdvertisementData object is a JSON object with just one property, "capabilities-with-footprints", and its value is an array of BaseAdvertisementObject objects 🦋 these tell the uCDN which capabilities come with footprint restrictions, which is how it picks a dCDN 🌸 if that array is empty, the dCDN can't provide any mandatory-to-implement CDNI capabilities for any footprints 🙈

the syntax and semantics of BaseAdvertisementObject are fully defined in Section 5.1 of [RFC8008] 📚 each one has several properties, like "capability-type", "capability-value", and "footprints", and "footprints" is defined in Section 4.2.2.2 of [RFC8006] 💜

there's also an equivalent description in ALTO-style notation (see Section 8.2 of [RFC7285]) that makes BaseAdvertisementObject self-contained 🍓 but as mentioned above, the normative specification is still [RFC8008] 🔥

    object {
      JSONString capability-type;
      JSONValue capability-value;
      Footprint footprints<0..*>;
    } BaseAdvertisementObject;

    object {
      JSONString footprint-type;
      JSONString footprint-value<1..*>;
    } Footprint;

now the rules for the ALTO client 👑 for each BaseAdvertisementObject, the ALTO client MUST interpret "footprints" appearing multiple times as if it appeared only once 🫶 and if "footprints" in a BaseAdvertisementObject is null or empty, or doesn't appear at all, the ALTO client MUST understand that those capabilities have the "global" coverage 🌈 aka the corresponding dCDN can provide them for any Request Routing source, no cap 😭

Note: Further optimization of BaseAdvertisementObjects to effectively provide the advertisement of capabilities with footprint restrictions is certainly possible. For example, these two examples below both describe that the dCDN can provide capabilities ["http/1.1", "https/1.1"] for the same footprints. However, the latter one is smaller in its size.

EXAMPLE 1

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

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

EXAMPLE 2

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

these optimizations aren't needed for basic CDN interconnection 🧚 so the details of those mechanisms are out of scope for this doc 🌸

and finally, the only thing this document asks of the ALTO server is that it provides the initial FCI-specific CDNI Payload Types defined in [RFC8008] as its mandatory-to-implement CDNI capabilities 💅✨

3.7. Examples 🎀

3.7.1. IRD 🧚

okay here's the IRD of a simple, example ALTO server 🍓 it provides both base ALTO information resources (like network maps) and CDNI FCI-related information resources (like CDNI Advertisement resources), so you get one integrated environment, periodt 💖

specifically, the IRD announces nine information resources:

  • two network maps,
  • one CDNI Advertisement resource without dependency,
  • one CDNI Advertisement resource depending on a network map,
  • one filtered CDNI Advertisement resource to be defined in Section 5,
  • one property map including "cdni-capabilities" as its entity property,
  • one filtered property map including "cdni-capabilities" and "pid" as its entity properties, and
  • two update stream services:
    • one for updating CDNI Advertisement resources,
    • one for updating property maps
    GET /directory HTTP/1.1
    Host: alto.example.com
    Accept: application/alto-directory+json,application/alto-error+json

    HTTP/1.1 200 OK
    Content-Length: 3531
    Content-Type: application/alto-directory+json

    {
      "meta": {
        "default-alto-network-map": "my-default-network-map"
      },
      "resources": {
        "my-default-network-map": {
          "uri": "https://alto.example.com/networkmap",
          "media-type": "application/alto-networkmap+json"
        },
        "my-eu-netmap": {
          "uri": "https://alto.example.com/myeunetmap",
          "media-type": "application/alto-networkmap+json"
        },
        "my-default-cdnifci": {
          "uri": "https://alto.example.com/cdnifci",
          "media-type": "application/alto-cdni+json"
        },
        "my-cdnifci-with-pid-footprints": {
          "uri": "https://alto.example.com/networkcdnifci",
          "media-type": "application/alto-cdni+json",
          "uses": [ "my-eu-netmap" ]
        },
        "my-filtered-cdnifci": {
          "uri": "https://alto.example.com/cdnifci/filtered",
          "media-type": "application/alto-cdni+json",
          "accepts": "application/alto-cdnifilter+json"
        },
        "cdnifci-property-map": {
          "uri": "https://alto.example.com/propmap/full/cdnifci",
          "media-type": "application/alto-propmap+json",
          "uses": [ "my-default-cdni" ],
          "capabilities": {
            "mappings": {
              "ipv4": [ "my-default-cdni.cdni-capabilities" ],
              "ipv6": [ "my-default-cdni.cdni-capabilities" ],
              "countrycode": [
                "my-default-cdni.cdni-capabilities" ],
              "asn": [ "my-default-cdni.cdni-capabilities" ]
            }
          }
        },
        "filtered-cdnifci-property-map": {
          "uri": "https://alto.example.com/propmap/lookup/cdnifci-pid",
          "media-type": "application/alto-propmap+json",
          "accepts": "application/alto-propmapparams+json",
          "uses": [ "my-default-cdni", "my-default-network-map" ],
          "capabilities": {
            "mappings": {
              "ipv4": [ "my-default-cdni.cdni-capabilities",
                        "my-default-network-map.pid" ],
              "ipv6": [ "my-default-cdni.cdni-capabilities",
                        "my-default-network-map.pid" ],
              "countrycode": [
                "my-default-cdni.cdni-capabilities" ],
              "asn": [ "my-default-cdni.cdni-capabilities" ]
            }
          }
        },
        "update-my-cdni-fci": {
          "uri": "https://alto.example.com/updates/cdnifci",
          "media-type": "text/event-stream",
          "accepts": "application/alto-updatestreamparams+json",
          "uses": [
            "my-default-network-map",
            "my-eu-netmap",
            "my-default-cdnifci",
            "my-filtered-cdnifci",
            "my-cdnifci-with-pid-footprints"
          ],
          "capabilities": {
            "incremental-change-media-types": {
             "my-default-network-map": "application/json-patch+json",
             "my-eu-netmap": "application/json-patch+json",
             "my-default-cdnifci":
             "application/merge-patch+json,application/json-patch+json",
             "my-filtered-cdnifci":
             "application/merge-patch+json,application/json-patch+json",
             "my-cdnifci-with-pid-footprints":
             "application/merge-patch+json,application/json-patch+json"
            }
          }
        },
        "update-my-props": {
          "uri": "https://alto.example.com/updates/properties",
          "media-type": "text/event-stream",
          "uses": [
            "cdnifci-property-map",
            "filtered-cdnifci-property-map"
          ],
          "capabilities": {
            "incremental-change-media-types": {
             "cdnifci-property-map":
             "application/merge-patch+json,application/json-patch+json",
             "filtered-cdnifci-property-map":
             "application/merge-patch+json,application/json-patch+json"
            }
          }
        }
      }
    }

3.7.2. A Basic Example

okay bestie, this one is the simplest example ever 🧚 It's a CDNI Advertisement resource that doesn't depend on any other resources, so it's very chill. There are three BaseAdvertisementObjects in here, and their capabilities are the "http/1.1" delivery protocol, the ["http/1.1", "https/1.1"] delivery protocol, and the "https/1.1" acquisition protocol, in that order 💖

GET /cdnifci HTTP/1.1
Host: alto.example.com
Accept: application/alto-cdni+json,application/alto-error+json

HTTP/1.1 200 OK
Content-Length: 1411
Content-Type: application/alto-cdni+json

{
  "meta": {
    "vtag": {
      "resource-id": "my-default-cdnifci",
      "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
    }
  },
  "cdni-advertisement": {
    "capabilities-with-footprints": [
      {
        "capability-type": "FCI.DeliveryProtocol",
        "capability-value": {
          "delivery-protocols": [
            "http/1.1"
          ]
        },
        "footprints": [
          {
            "footprint-type": "ipv4cidr",
            "footprint-value": [ "192.0.2.0/24" ]
          },
          {
            "footprint-type": "ipv6cidr",
            "footprint-value": [ "2001:db8::/32" ]
          }
        ]
      },
      {
        "capability-type": "FCI.DeliveryProtocol",
        "capability-value": {
          "delivery-protocols": [
            "https/1.1",
            "http/1.1"
          ]
        },
        "footprints": [
          {
            "footprint-type": "ipv4cidr",
            "footprint-value": [ "198.51.100.0/24" ]
          }
        ]
      },
      {
        "capability-type": "FCI.AcquisitionProtocol",
        "capability-value": {
          "acquisition-protocols": [
            "https/1.1"
          ]
        },
        "footprints": [
          {
            "footprint-type": "ipv4cidr",
            "footprint-value": [ "203.0.113.0/24" ]
          }
        ]
      }
    ]
  }
}

3.7.3. Incremental Updates

ok this one is my fave 😭 A big perk of using ALTO to serve CDNI Advertisement resources is that they can be updated with ALTO incremental updates [RFC8895]. Below is an example that also shows why it's so iconic to have both JSON merge patch and JSON patch for encoding updates 🦋

So first, an ALTO client asks for updates to "my-default-cdnifci", and the ALTO server sends back the "control-uri" followed by the full CDNI Advertisement response 🌸 Then things change: the "delivery-protocols" loses "http/1.1", going from ["http/1.1", "https/1.1"] to just "https/1.1", because the "http/1.1" clusters are getting maintenance. The ALTO server regenerates the new CDNI Advertisement resource and pushes the full replacement to the client. Later on, the server lets the client know that "192.0.2.0/24" got added to the "ipv4" footprint object for the "https/1.1" delivery protocol. This change is sent as a JSON patch 💅

POST /updates/cdnifci HTTP/1.1
Host: alto.example.com
Accept: text/event-stream,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json
Content-Length: 94

{
  "add": {
    "my-cdnifci-stream": {
      "resource-id": "my-default-cdnifci"
    }
  }
}

HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream

event: application/alto-updatestreamcontrol+json
data: {"control-uri":
data: "https://alto.example.com/updates/streams/3141592653589"}

event: application/alto-cdni+json,my-cdnifci-stream
data: { ... full CDNI Advertisement resource ... }

event: application/alto-cdni+json,my-cdnifci-stream
data: {
data:   "meta": {
data:     "vtag": {
data:       "tag": "dasdfa10ce8b059740bddsfasd8eb1d47853716"
data:     }
data:   },
data:   "cdni-advertisement": {
data:     "capabilities-with-footprints": [
data:       {
data:         "capability-type": "FCI.DeliveryProtocol",
data:         "capability-value": {
data:           "delivery-protocols": [
data:             "https/1.1"
data:           ]
data:         },
data:         "footprints": [
data:           { "footprint-type": "ipv4cidr",
data:             "footprint-value": [ "203.0.113.0/24" ]
data:           }
data:         ]
data:       },
data:       { ... other CDNI advertisement object ... }
data:     ]
data:   }
data: }

event: application/json-patch+json,my-cdnifci-stream
data: [
data:   { "op": "replace",
data:     "path": "/meta/vtag/tag",
data:     "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
data:   },
data:   { "op": "add",
data:     "path": "/cdni-advertisement/capabilities-with-footprints
/0/footprints/0/footprint-value/-",
data:     "value": "192.0.2.0/24"
data:   }
data: ]

4. CDNI Advertisement Service Using ALTO Network Map ✨

4.1. Network Map Footprint Type: altopid

okay so the ALTO Protocol has this concept called Provider-defined Identifier (PID) 🗺️ A PID stands for a group of IPv4 or IPv6 addresses that all get the same management policy. A PID is an alternative to the predefined CDNI footprint types, which are "ipv4cidr", "ipv6cidr", "asn", and "countrycode" 💜

To make use of this, this document defines a brand-new CDNI Footprint Type called "altopid" 🦋 A CDNI Advertisement resource can depend on an ALTO network map resource and use "altopid" footprints to compress its CDNI Footprint Payload. That's so compact, it's giving efficiency 🔥

Here's the deal: the "altopid" footprint type says that the matching footprint value is a list of PIDNames, as defined in [RFC7285]. These PIDNames are references to PIDs in a network map resource. So a CDNI Advertisement resource that uses "altopid" footprints depends on a network map. For that kind of CDNI Advertisement resource, the resource ID of its dependent network map MUST be included in the "uses" field of its IRD entry. Also, a dependent-vtags field that points to this network map MUST be included in its response (see the example in Section 4.2.2) 🫶

4.2. Examples

The following examples use the same IRD given in Section 3.7.1 🎀

4.2.1. ALTO Network Map for CDNI Advertisements

Here's a sample network map whose resource ID is "my-eu-netmap" 🗺️ The CDNI Advertisement example in Section 4.2.2 references this map 💅

GET /myeunetmap HTTP/1.1
Host: alto.example.com
Accept: application/alto-networkmap+json,application/alto-error+json

HTTP/1.1 200 OK
Content-Length: 344
Content-Type: application/alto-networkmap+json

{
  "meta": {
    "vtag": [
      { "resource-id": "my-eu-netmap",
        "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
      }
    ]
  },
  "network-map": {
    "south-france" : {
      "ipv4": [ "192.0.2.0/24", "198.51.100.0/25" ],
      "ipv6": [ "2001:db8::/32" ]
    },
    "germany": {
      "ipv4": [ "203.0.113.0/24" ]
    }
  }
}

4.2.2. ALTO PID Footprints in CDNI Advertisements

this example is a CDNI Advertisement resource that depends on the network map from Section 4.2.1 🌈

GET /networkcdnifci HTTP/1.1
Host: alto.example.com
Accept: application/alto-cdni+json,application/alto-error+json

HTTP/1.1 200 OK
Content-Length: 736
Content-Type: application/alto-cdni+json

{
  "meta": {
    "dependent-vtags": [
      {
        "resource-id": "my-eu-netmap",
        "tag": "3ee2cb7e8d63d9fab71b9b34cbf764436315542e"
      }
    ]
  },
  "cdni-advertisement": {
    "capabilities-with-footprints": [
      { "capability-type": "FCI.DeliveryProtocol",
        "capability-value": [ "https/1.1" ],
        "footprints": [
          { "footprint-type": "altopid",
            "footprint-value": [ "south-france" ]
          }
        ]
      },
      { "capability-type": "FCI.AcquisitionProtocol",
        "capability-value": [ "https/1.1" ],
        "footprints": [
          { "footprint-type": "altopid",
            "footprint-value": [ "germany", "south-france" ]
          }
        ]
      }
    ]
  }
}

4.2.3. Incremental Updates

in this one, the ALTO client cares about changes to my-cdnifci-with-pid-footprints and its dependent network map my-eu-netmap 👀 There are two changes. The first one changes the footprints of the "https/1.1" delivery protocol capability. The second one removes the "south-france" PID from the footprints of the "https/1.1" acquisition protocol capability. ngl this is a lot of moving parts, but it's so satisfying 😭

POST /updates/cdnifci HTTP/1.1
Host: alto.example.com
Accept: text/event-stream,application/alto-error+json
Content-Type: application/alto-updatestreamparams+json
Content-Length: 185

{
  "add": {
    "my-eu-netmap-stream": {
      "resource-id": "my-eu-netmap"
    },
    "my-netmap-cdnifci-stream": {
      "resource-id": "my-cdnifci-with-pid-footprints"
    }
  }
}

HTTP/1.1 200 OK
Connection: keep-alive
Content-Type: text/event-stream

event: application/alto-updatestreamcontrol+json
data: {"control-uri":
data: "https://alto.example.com/updates/streams/3141592653590"}

event: application/alto-networkmap+json,my-eu-netmap-stream
data: { ... full Network Map of my-eu-netmap ... }

event: application/alto-cdnifci+json,my-netmap-cdnifci-stream
data: { ... full CDNI Advertisement resource ... }

event: application/json-patch+json,my-netmap-cdnifci-stream
data: [
data:   { "op": "replace",
data:     "path": "/meta/vtag/tag",
data:     "value": "dasdfa10ce8b059740bddsfasd8eb1d47853716"
data:   },
data:   { "op": "add",
data:     "path":
data:     "/cdni-advertisement/capabilities-with-footprints
/0/footprints/0/footprint-value/-",
data:     "value": "germany"
data:   }
data: ]

event: application/json-patch+json,my-netmap-cdnifci-stream
data: [
data:   { "op": "replace",
data:     "path": "/meta/vtag/tag",
data:     "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
data:   },
data:   { "op": "remove",
data:     "path":
data:     "/cdni-advertisement/capabilities-with-footprints
/1/footprints/0/footprint-value/1"
data:   }
data: ]

5. Filtered CDNI Advertisement Using CDNI Capabilities 🧁

okay so Sections 3 and 4 cover the CDNI Advertisement Service, which lets a uCDN get capabilities with footprint restrictions from dCDNs 🌍 But always pulling full CDNI Advertisement resources from dCDNs is super inefficient, so this document introduces a new service called "Filtered CDNI Advertisement Service" 💖 It lets a client filter a CDNI Advertisement resource using a set of CDNI capabilities that the client gives it. For each entry in the CDNI Advertisement response, an entry only comes back to the client if it has at least one of those client-given CDNI capabilities 🎀 The relationship between a filtered CDNI Advertisement resource and a CDNI Advertisement resource is kind of like the relationship between a filtered network/cost map and a network/cost map. Totally the same energy ✨

5.1. Media Type

a filtered CDNI Advertisement resource uses the same media type that was defined for the CDNI Advertisement resource in Section 3.1: "application/alto-cdni+json" 📦

5.2. HTTP Method ✨

Okay so a filtered CDNI Advertisement resource gets requested with the HTTP POST method 💌

5.3. Accept Input Parameters 🎀

The input parameters for a filtered CDNI Advertisement resource get sent in the entity body of the POST request 📦 This document describes them with the media type application/alto-cdnifilter+json, which is a JSON object of type ReqFilteredCDNIAdvertisement. The shape looks like this:

object {
    JSONString capability-type;
    JSONValue capability-value;
} CDNICapability;

object {
    CDNICapability cdni-capabilities<0..*>;
} ReqFilteredCDNIAdvertisement;

Here are the fields:

  • capability-type: The same as the Base Advertisement Object's "capability-type" defined in Section 5.1 of [RFC8008].
  • capability-value: The same as the Base Advertisement Object's "capability-value" defined in Section 5.1 of [RFC8008].
  • cdni-capabilities: A list of CDNI capabilities defined in Section 5.1 of [RFC8008] for which footprints are to be returned. If this list is empty, the ALTO server MUST interpret it as a request for the full CDNI Advertisement resource. The ALTO server MUST interpret entries appearing in this list multiple times as if they appeared only once. If the ALTO server does not define any footprints for a CDNI capability, it MUST omit this capability from the response.

5.4. Capabilities 🙅

There are no applicable capabilities, so nothing to see here 💅

5.5. Uses 🧺

The same rules as for the "uses" field of the CDNI Advertisement resource apply (see Section 3.5). Same vibes, same rules 🫶

5.6. Response 💌

If the request is invalid, the response MUST indicate an error using ALTO Protocol error handling specified in Section 8.5 of [RFC7285].

Specifically, a filtered CDNI Advertisement request is invalid if:

  • the value of "capability-type" is null;
  • the value of "capability-value" is null; or
  • the value of "capability-value" is inconsistent with "capability-type".

When a request is invalid, the ALTO server MUST return an "E_INVALID_FIELD_VALUE" error defined in Section 8.5.2 of [RFC7285], and the "value" field of the error message SHOULD indicate this CDNI capability. 😭

The ALTO server returns a filtered CDNI Advertisement resource for a valid request. The format of a filtered CDNI Advertisement resource is the same as a full CDNI Advertisement resource (see Section 3.6). Twins, honestly 👯‍♀️

The returned filtered CDNI Advertisement resource MUST contain all the BaseAdvertisementObject objects satisfying the following condition: the CDNI capability object of each included BaseAdvertisementObject object MUST follow two constraints:

  • The "cdni-capabilities" field of the input includes a CDNI capability object X having the same "capability-type" as it.
  • All the mandatory properties in its "capability-value" is a superset of mandatory properties in "capability-value" of X semantically.

See Section 5.7.1 for a concrete example 👀

The version tag included in the "vtag" field of the response MUST correspond to the full CDNI Advertisement resource from which the filtered CDNI Advertisement resource is provided. This ensures that a single, canonical version tag is used independently of any filtering that is requested by an ALTO client. One tag to rule them all 👑

5.7. Examples 🌈

The following examples use the same IRD example as in Section 3.7.1.

5.7.1. A Basic Example 🦋

This example filters the full CDNI Advertisement resource in Section 3.7.2 by selecting only the "http/1.1" delivery protocol capability. Only the second BaseAdvertisementObject in the full resource will be returned, because the second object's capability is "http/1.1" and "https/1.1" delivery protocols, which is the superset of the "https/1.1" delivery protocol. Superset energy 🔥

  POST /cdnifci/filtered HTTP/1.1
  Host: alto.example.com
  Accept: application/alto-cdni+json
  Content-Type: application/cdnifilter+json
  Content-Length: 176

  {
    "cdni-capabilities": [
      {
        "capability-type": "FCI.DeliveryProtocol",
        "capability-value": {
          "delivery-protocols": [ "https/1.1" ]
        }
      }
    ]
  }

  HTTP/1.1 200 OK
  Content-Length: 570
  Content-Type: application/alto-cdni+json

  {
    "meta": {
      "vtag": {
        "resource-id": "my-filtered-cdnifci",
        "tag": "da65eca2eb7a10ce8b059740b0b2e3f8eb1d4785"
      }
    },
    "cdni-advertisement": {
      "capabilities-with-footprints": [
        {
          "capability-type": "FCI.DeliveryProtocol",
          "capability-value": {
            "delivery-protocols": [
              "https/1.1",
              "http/1.1"
            ]
          },
          "footprints": [
            {
              "footprint-type": "ipv4cidr",
              "footprint-value": [ "198.51.100.0/24" ]
            }
          ]
        }
      ]
    }
  }

5.7.2. Incremental Updates 🍓

In this example, the ALTO client only cares about the updates of one advertisement object for a delivery protocol capability whose value includes "https/1.1". So it adds that limitation to the capabilities in the "input" field of the POST request. Narrowing it down, bestie 🎯

  POST /updates/cdnifci HTTP/1.1
  Host: fcialtoupdate.example.com
  Accept: text/event-stream,application/alto-error+json
  Content-Type: application/alto-updatestreamparams+json
  Content-Length: 346

  {
    "add": {
      "my-filtered-fci-stream": {
        "resource-id": "my-filtered-cdnifci",
        "input": {
          "cdni-capabilities": [
            {
              "capability-type": "FCI.DeliveryProtocol",
              "capability-value": {
                "delivery-protocols": [ "https/1.1" ]
              }
            }
          ]
        }
      }
    }
  }

  HTTP/1.1 200 OK
  Connection: keep-alive
  Content-Type: text/event-stream

  event: application/alto-updatestreamcontrol+json
  data: {"control-uri":
  data: "https://alto.example.com/updates/streams/3141592653590"}

  event: application/alto-cdni+json,my-filtered-fci-stream
  data: { ... filtered CDNI Advertisement resource ... }

  event: application/json-patch+json,my-filtered-fci-stream
  data: [
  data:   {
  data:     "op": "replace",
  data:     "path": "/meta/vtag/tag",
  data:     "value": "a10ce8b059740b0b2e3f8eb1d4785acd42231bfe"
  data:   },
  data:   { "op": "add",
  data:     "path":
  data:     "/cdni-advertisement/capabilities-with-footprints
  /0/footprints/0/footprint-value/-",
  data:     "value": "192.0.2.0/24"
  data:   }
  data: ]

6. Query Footprint Properties Using ALTO Property Map Service 🧚

Besides the requirement of retrieving footprints of given capabilities, another common requirement for uCDN is to query CDNI capabilities of given footprints. 🔍

Considering each footprint as an entity with properties including CDNI capabilities, a natural way to satisfy this requirement is to use the ALTO property map as defined in [RFC9240]. This section describes how ALTO clients look up properties for individual footprints. First, it describes how to represent footprint objects as entities in the ALTO property map. Then it describes how to represent footprint capabilities as entity properties in the ALTO property map. Finally, it provides examples of the full property map and the filtered property map supporting CDNI capabilities, and their incremental updates. Full plan, no skipping 🗺️

6.1. Representing Footprint Objects as Property Map Entities 🌸

A footprint object has two properties: "footprint-type" and "footprint-value". A "footprint-value" is an array of footprint values conforming to the specification associated with the registered footprint type ("ipv4cidr", "ipv6cidr", "asn", "countrycode", and "altopid"). Considering each ALTO entity defined in [RFC9240] also has two properties, entity domain type and domain-specific identifier, a straightforward approach to represent a footprint as an ALTO entity is to represent its "footprint-type" as an entity domain type, and its footprint value as a domain-specific identifier. Matching the two halves, iykyk 🫶

Each existing footprint type can be represented as an entity domain type as follows:

  • According to [RFC9240], "ipv4" and "ipv6" are two predefined entity domain types, which can be used to represent "ipv4cidr" and "ipv6cidr" footprints respectively. Note that both "ipv4" and "ipv6" domains can include not only hierarchical addresses but also individual addresses. Therefore, an "ipv4cidr" or "ipv6cidr" footprint with the longest prefix can also be represented by an individual address entity. When the uCDN receives a property map with individual addresses in an "ipv4" or "ipv6" domain, it can translate them as corresponding "ipv4cidr" or "ipv6cidr" footprints with the longest prefix.
  • "pid" is also a predefined entity domain type, which can be used to represent "altopid" footprints. Note that "pid" is a resource-specific entity domain. To represent an "altopid" footprint, the specifying information resource of the corresponding "pid" entity domain MUST be the dependent network map used by the CDNI Advertisement resource providing this "altopid" footprint.
  • However, no existing entity domain type can represent "asn" and "countrycode" footprints. To represent footprint-type "asn" and "countrycode", this document registers two new entity domains in Section 7 in addition to the ones in [RFC9240]. Plot twist, we're adding our own 🧁

Here is an example of representing a footprint object of "ipv4cidr" type as a set of "ipv4" entities in the ALTO property map. The representation of the footprint object of "ipv6cidr" type is similar.

{ "footprint-type": "ipv4cidr",
  "footprint-value": ["192.0.2.0/24", "198.51.100.0/24"]
} --> "ipv4:192.0.2.0/24", "ipv4:198.51.100.0/24"

And here is the corresponding footprint object of "ipv4cidr" type, represented by an individual address in an "ipv4" domain in the ALTO property map. The translation of the entities in an "ipv6" domain is similar.

"ipv4:203.0.113.100" --> {
  "footprint-type": "ipv4cidr",
  "footprint-value": ["203.0.113.100/32"]
}

6.1.1. ASN Domain 🌐

The ASN domain associates property values with Autonomous Systems in the Internet. ✨

6.1.1.1. Entity Domain Type 🏷️

The entity domain type of the ASN domain is "asn" (in lowercase).

6.1.1.2. Domain-Specific Entity Identifiers 🔖

The entity identifier of an entity in an ASN domain MUST be encoded as a string consisting of the characters "as" (in lowercase) followed by the ASN [RFC6793] as a decimal number without leading zeros.

6.1.1.3. Hierarchy and Inheritance 🌳

There is no hierarchy or inheritance for properties associated with ASN. Flat and proud 🥞

6.1.2. COUNTRYCODE Domain 🗺️

The COUNTRYCODE domain associates property values with countries. 🌍

6.1.2.1. Entity Domain Type 🏷️

The entity domain type of the COUNTRYCODE domain is "countrycode" (in lowercase).

6.1.2.2. Domain-Specific Entity Identifiers 🔖

The entity identifier of an entity in a COUNTRYCODE domain is encoded as an ISO 3166-1 alpha-2 code [ISO3166-1] in lowercase.

6.1.2.3. Hierarchy and Inheritance 🌳

There is no hierarchy or inheritance for properties associated with country codes. Same flat energy as ASN, no notes 💖

6.2. Representing CDNI Capabilities as Property Map Entity Properties 🎀

okay so this doc defines a brand new entity property type called "cdni-capabilities" 💅 An ALTO server can provide a property map resource that maps the "cdni-capabilities" entity property type for a CDNI Advertisement resource it provides to an "ipv4", "ipv6", "asn", or "countrycode" entity domain. ✨

6.2.1. Defining Information Resource Media Type for Property Type cdni-capabilities 🦋

The entity property type "cdni-capabilities" lets you define resource-specific entity properties 🫶 When you define resource-specific entity properties with that type, the defining information resource for a "cdni-capabilities" property MUST be a CDNI Advertisement resource provided by the ALTO server. So the media type of the defining information resource for a "cdni-capabilities" property is therefore:

application/alto-cdni+json

6.2.2. Intended Semantics of Property Type cdni-capabilities 💜

The whole point of a "cdni-capabilities" property is to show all the CDNI capabilities that a CDNI Advertisement resource provides for the footprint that entity represents 🔥 So the value of a "cdni-capabilities" property MUST be a JSON array. Each element in a "cdni-capabilities" property MUST be a JSON object in the format of CDNICapability (see Section 5.3). The value of a "cdni-capabilities" property for an "ipv4", "ipv6", "asn", "countrycode", or "altopid" entity MUST include all the CDNICapability objects that meet both of these conditions: (1) they are provided by the defining CDNI Advertisement resource, and (2) the represented footprint object of this entity is in their footprint restrictions 🌈

6.3. Examples 🌸

The following examples use the same IRD example given by Section 3.7.1 🧚

6.3.1. Property Map 💖

This example shows a full property map where the entities are footprints and the entity's property is "cdni-capabilities" 🍓

 GET /propmap/full/cdnifci HTTP/1.1
 Host: alto.example.com
 Accept: application/alto-propmap+json,application/alto-error+json

 HTTP/1.1 200 OK
 Content-Length: 1522
 Content-Type: application/alto-propmap+json

 {
   "property-map": {
     "meta": {
       "dependent-vtags": [
         { "resource-id": "my-default-cdnifci",
           "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"}
       ]
     },
     "countrycode:us": {
       "my-default-cdnifci.cdni-capabilities": [
         { "capability-type": "FCI.DeliveryProtocol",
           "capability-value": {
             "delivery-protocols": ["http/1.1"]}}]
     },
     "ipv4:192.0.2.0/24": {
       "my-default-cdnifci.cdni-capabilities": [
         { "capability-type": "FCI.DeliveryProtocol",
           "capability-value": {
             "delivery-protocols": ["http/1.1"]}}]
     },
     "ipv4:198.51.100.0/24": {
       "my-default-cdnifci.cdni-capabilities": [
         { "capability-type": "FCI.DeliveryProtocol",
           "capability-value": {
             "delivery-protocols": ["https/1.1", "http/1.1"]}}]
     },
     "ipv4:203.0.113.0/24": {
       "my-default-cdnifci.cdni-capabilities": [
         { "capability-type": "FCI.AcquisitionProtocol",
           "capability-value": {
             "acquisition-protocols": ["http/1.1"]}}]
     },
     "ipv6:2001:db8::/32": {
       "my-default-cdnifci.cdni-capabilities": [
         { "capability-type": "FCI.DeliveryProtocol",
           "capability-value": {
             "delivery-protocols": ["http/1.1"]}}]
     },
     "asn:as64496": {
       "my-default-cdnifci.cdni-capabilities": [
         { "capability-type": "FCI.DeliveryProtocol",
           "capability-value": {
             "delivery-protocols": ["https/1.1", "http/1.1"]}}]
     }
   }
 }

6.3.2. Filtered Property Map 🦋

This example uses the filtered property Map Service to get "pid" and "cdni-capabilities" properties for two footprints, "ipv4:192.0.2.0/24" and "ipv6:2001:db8::/32" 👑

   POST /propmap/lookup/cdnifci-pid HTTP/1.1
   Host: alto.example.com
   Content-Type: application/alto-propmapparams+json
   Accept: application/alto-propmap+json,application/alto-error+json
   Content-Length: 181

   {
     "entities": [
       "ipv4:192.0.2.0/24",
       "ipv6:2001:db8::/32"
     ],
     "properties": [ "my-default-cdnifci.cdni-capabilities",
                     "my-default-networkmap.pid" ]
   }

 HTTP/1.1 200 OK
 Content-Length: 796
 Content-Type: application/alto-propmap+json

 {
   "property-map": {
     "meta": {
       "dependent-vtags": [
          {"resource-id": "my-default-cdnifci",
            "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf62"},
          {"resource-id": "my-default-networkmap",
            "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"}
       ]
     },
     "ipv4:192.0.2.0/24": {
       "my-default-cdnifci.cdni-capabilities": [
         {"capability-type": "FCI.DeliveryProtocol",
          "capability-value": {"delivery-protocols": ["http/1.1"]}}],
       "my-default-networkmap.pid": "pid1"
     },
     "ipv6:2001:db8::/32": {
       "my-default-cdnifci.cdni-capabilities": [
         {"capability-type": "FCI.DeliveryProtocol",
          "capability-value": {"delivery-protocols": ["http/1.1"]}}],
       "my-default-networkmap.pid": "pid3"
     }
   }
 }

6.3.3. Incremental Updates 🌈

In this example, the ALTO client is interested in updates for the properties "cdni-capabilities" and "pid" of two footprints, "ipv4:192.0.2.0/24" and "countrycode:fr" ✨

  POST /updates/properties HTTP/1.1
  Host: alto.example.com
  Accept: text/event-stream,application/alto-error+json
  Content-Type: application/alto-updatestreamparams+json
  Content-Length: 339

  {
    "add": {
      "fci-propmap-stream": {
        "resource-id": "filtered-cdnifci-property-map",
        "input": {
          "properties": [ "my-default-cdnifci.cdni-capabilities",
                          "my-default-networkmap.pid" ],
          "entities": [ "ipv4:192.0.2.0/24",
                        "ipv6:2001:db8::/32" ]
        }
      }
    }
  }

  HTTP/1.1 200 OK
  Connection: keep-alive
  Content-Type: text/event-stream

  event: application/alto-updatestreamcontrol+json
  data: {"control-uri":
  data: "https://alto.example.com/updates/streams/1414213562373"}

  event: application/alto-cdni+json,fci-propmap-stream
  data: { ... filtered property map ... }

  event: application/merge-patch+json,fci-propmap-stream
  data: {
  data:   "property-map": {
  data:     "meta": {
  data:       "dependent-vtags": [
  data:         { "resource-id": "my-default-cdnifci",
  data:           "tag": "2beeac8ee23c3dd1e98a73fd30df80ece9fa5627"},
  data:         { "resource-id": "my-default-networkmap",
  data:           "tag": "7915dc0290c2705481c491a2b4ffbec482b3cf63"}
  data:       ]
  data:     },
  data:     "ipv4:192.0.2.0/24": {
  data:       "my-default-cdnifci.cdni-capabilities": [
  data:         { "capability-type": "FCI.DeliveryProtocol",
  data:           "capability-value": {
  data:             "delivery-protocols": ["http/1.1", "https/1.1"]}}]
  data:     }
  data:   }
  data: }

  event: application/json-patch+json,fci-propmap-stream
  data: [
  data:   { "op": "replace",
  data:     "path": "/meta/dependent-vtags/0/tag",
  data:     "value": "61b23185a50dc7b334577507e8f00ff8c3b409e4"
  data:   },
  data:   { "op": "replace",
  data:     "path":
  data:     "/property-map/countrycode:fr/my-default-networkmap.pid",
  data:     "value": "pid5"
  data:   }
  data: ]

7. IANA Considerations ✨

This document defines two new media types: "application/alto-cdni+json", as described in Section 7.1, and "application/cdnifilter+json", as described in Section 7.2. It also defines a new CDNI Metadata Footprint Type (Section 7.3), two new ALTO entity domain types (Section 7.4), and a new ALTO entity property type (Section 7.5). 💅

7.1. application/alto-cdni+json Media Type 👑

Type name: application

Subtype name: alto-cdni+json

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC8259].

Security considerations: Security considerations related to the generation and consumption of ALTO Protocol messages are discussed in Section 15 of [RFC7285]. 🔥

Interoperability considerations: N/A

Published specification: Section 3 of RFC 9241

Applications that use this media type: ALTO servers and ALTO clients [RFC7285] either stand alone or are embedded within other applications that provide CDNI interfaces for uCDNs or dCDNs. 🫶

Fragment identifier considerations: N/A

Additional information:

  • Magic number(s): N/A
  • File extension(s): N/A
  • Macintosh file type code(s): N/A

Person & email address to contact for further information: See Authors' Addresses section.

Intended usage: COMMON

Restrictions on usage: N/A

Author: See Authors' Addresses section.

Change controller: Internet Engineering Task Force (iesg@ietf.org)

7.2. application/alto-cdnifilter+json Media Type 🌸

Type name: application

Subtype name: alto-cdnifilter+json

Required parameters: N/A

Optional parameters: N/A

Encoding considerations: Encoding considerations are identical to those specified for the "application/json" media type. See [RFC8259].

Security considerations: Security considerations related to the generation and consumption of ALTO Protocol messages are discussed in Section 15 of [RFC7285]. 💀

Interoperability considerations: N/A

Published specification: Section 5 of RFC 9241

Applications that use this media type: ALTO servers and ALTO clients [RFC7285] either stand alone or are embedded within other applications that provide CDNI interfaces for uCDNs or dCDNs and supports CDNI capability-based filtering. 🧚

Fragment identifier considerations: N/A

Additional information:

  • Magic number(s): N/A
  • File extension(s): N/A
  • Macintosh file type code(s): N/A

Person & email address to contact for further information: See Authors' Addresses section.

Intended usage: COMMON

Restrictions on usage: N/A

Author: See Authors' Addresses section.

Change controller: Internet Engineering Task Force (iesg@ietf.org)

7.3. CDNI Metadata Footprint Types Registry 🍓

This document updates the "CDNI Metadata Footprint Types" registry created by Section 7.2 of [RFC8006]. A new footprint type, which is listed in Table 1, has been registered. 💖

+================+=====================+=====================+
| Footprint Type | Description         | Reference           |
+================+=====================+=====================+
| altopid        | A list of PID names | RFC 9241, Section 4 |
+----------------+---------------------+---------------------+
            Table 1: CDNI Metadata Footprint Type

7.4. ALTO Entity Domain Types Registry ✨

okay so this section is about the "ALTO Entity Domain Types" registry 📋. It updates that registry, which Section 11.2 of [RFC9240] created 🌸. Two brand-new entity domain types got registered, and they're in Table 2 💅.

+=============+============+=============+=============+=========+
| Identifier  | Entity     | Hierarchy   | Media Type  | Mapping |
|             | Identifier | and         | of Defining | to ALTO |
|             | Encoding   | Inheritance | Resource    | Address |
|             |            |             |             | Type    |
+=============+============+=============+=============+=========+
| asn         | See RFC    | None        | None        | false   |
|             | 9241,      |             |             |         |
|             | Section    |             |             |         |
|             | 6.1.1.2    |             |             |         |
+-------------+------------+-------------+-------------+---------+
| countrycode | See RFC    | None        | None        | false   |
|             | 9241,      |             |             |         |
|             | Section    |             |             |         |
|             | 6.1.2.2    |             |             |         |
+-------------+------------+-------------+-------------+---------+

           Table 2: Additional ALTO Entity Domain Types

7.5. ALTO Entity Property Types Registry 🎀

same energy here! this one updates the "ALTO Entity Property Types" registry, created by Section 11.3 of [RFC9240] 🦋. Just one new entity property type joined the party, and it's in Table 3 ✨.

+===================+====================+===================+
| Identifier        | Intended Semantics | Media Type of     |
|                   |                    | Defining Resource |
+===================+====================+===================+
| cdni-capabilities | See RFC 9241,      | application/alto- |
|                   | Section 6.2        | cdni+json         |
+-------------------+--------------------+-------------------+

        Table 3: Additional ALTO Entity Property Type

8. Security Considerations 🔥

okay bestie, this part is SERIOUS, so read it slowly 🥺. ALTO is an extension of the base ALTO Protocol [RFC7285], so this document sits right inside that architecture. That means the Security Considerations of the base protocol (Section 15 of [RFC7285]) fully apply whenever an ALTO server offers this extension 🔒.

When we're talking about CDNI Advertisement, these security risk scenarios should be considered 👀:

  • Authenticity and integrity of ALTO information 🕵️: an attacker can pretend to be an ALTO server for a dCDN (for example, by starting an on-path attack) and feed a uCDN false capabilities and footprints through the CDNI Advertisement Service. That's chaos, because a uCDN might (1) pick the wrong dCDN to serve user requests, or (2) skip uCDNs that are in good shape. To deal with this, the protection strategies in Section 15.1.2 of [RFC7285] can be applied.
  • Potential undesirable guidance from authenticated ALTO information 😤: a dCDN could offer a uCDN limited capabilities and a smaller footprint coverage, so the dCDN can dodge carrying traffic that it really should be carrying for that uCDN. To reduce this risk, the protection strategies in Section 15.2.2 of [RFC7285] can be considered.
  • Confidentiality and privacy of ALTO information 🙈: footprint properties combined with ALTO property maps might expose network location identifiers (like IP addresses or fine-grained PIDs). To address this, the protection strategy for risk types (1) and (3) described in Section 15.3 of [RFC7285] can be considered.
  • Availability of ALTO services 💀: an attacker might run service-degradation attacks using the services defined here, to take ALTO services of a network offline. They could keep requesting potentially large, full CDNI Advertisement resources from an ALTO server in a dCDN, just to eat up that server's bandwidth. They could also query filtered property Map Services with lots of smaller individual footprints, to chew through the server's computation resources. To mitigate these risks, the protection strategies in Section 15.5.2 of [RFC7285] can be applied.

Although protection strategies from Section 15 of [RFC7285] should be applied to handle all those security and privacy considerations above, there are two special cases that need to be included, as follows 🚨:

  • As required by Section 7 of [RFC8008]:
All protocols that implement these capabilities and footprint advertisement objects are REQUIRED to provide integrity and authentication services.

So, the uCDN (ALTO Client) MUST be authenticated to the dCDN (ALTO Server). And the dCDN (ALTO Server) MUST support HTTP Digest Authentication [RFC7616] and MAY also support TLS mutual authentication [RFC8446]. The authentication method will need to be negotiated out of band, and it is out of scope for this document, and so is the approach for provisioning and managing these credentials 🔑.

  • One specific information leakage risk introduced by this document cannot be addressed by these strategies 😱. Here's the tea: if a dCDN A signs agreements with multiple uCDNs without any isolation, dCDN A may disclose extra information about one uCDN to another one. In that case, one uCDN may redirect requests that should not have to be served by dCDN A to dCDN A.

To reduce the risk, a dCDN SHOULD isolate full and/or filtered CDNI Advertisement resources for different uCDNs. It could consider generating URIs of different full and/or filtered CDNI Advertisement resources by hashing its company ID, a uCDN's company ID, as well as their agreements. A dCDN SHOULD avoid exposing all full and/or filtered CDNI Advertisement resources in one of its IRDs 🫶.

9. References 📚

9.1. Normative References

9.2. Informative References

Acknowledgments 💖

okay bestie, the authors gotta thank the people who made this doc so much better 🫶 Matt Caulfield, Danny Alex Lachos Perez, Daryl Malas, and Sanjay Mishra gave super quick reviews and comments that were honestly invaluable ✨. Big shoutout to the ALTO WG Chairs, Qin Wu and Vijay Gurbani, plus all the directorate reviewers, and the IESG reviewers Martin Duke, Erik Kline, Martin Vigoureux, Murray Kucherawy, Roman Danyliw, Zaheduzzaman Sarker, Éric Vyncke, and Francesca Palombini 👑. They reviewed everything thoroughly, talked it through, guided the authors, and shepherded the doc through the process, and the whole thing is way better because of them 🙌.

Jan Seedorf got partial support from the GreenICN project 🌿 (GreenICN: Architecture and Applications of Green Information Centric Networking). That's a research project funded 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 in here are the authors' own, and they don't necessarily represent the official policies or endorsements, either expressed or implied, of GreenICN, the European Commission, or NICT 💅.

This doc also got support from the Coordination Support Action called 'Supporting European Experts Presence in International Standardisation Activities in ICT' (StandICT.eu <https://www.standict.eu/>) 🌈. It's funded by the European Commission under the Horizon 2020 Programme with Grant Agreement no. 780439. Same deal here: the views are the authors', not necessarily the European Commission's official stance, either expressed or implied 🦋.

Contributors 🌸

Xiao Shawn Lin, from Huawei, contributed too, and here's where to find them 🧚

Xiao Shawn Lin
Huawei
2222 Newjinqiao Rd
Shanghai
200125
China
Phone: +86-15316812351
Email: x.shawn.lin@gmail.com

Authors' Addresses 🎀

Here are the authors, with all their contact details, so you can reach out if you're obsessed with ALTO like we are 💜.

Jan Seedorf

Jan Seedorf
HFT Stuttgart - Univ. of Applied Sciences
Schellingstrasse 24
70174 Stuttgart
Germany
Phone: +49-0711-8926-2801
Email: jan.seedorf@hft-stuttgart.de

Y. Richard Yang

Y. Richard Yang
Yale University
51 Prospect Street
New Haven, CT 06511
United States of America
Phone: +1-203-432-6400
Email: yry@cs.yale.edu
URI:   http://www.cs.yale.edu/~yry/

Kevin J. Ma

Kevin J. Ma
Ericsson
43 Nagog Park
Acton, MA 01720
United States of America
Phone: +1-978-844-5100
Email: kevin.j.ma.ietf@gmail.com

Jon Peterson

Jon Peterson
NeuStar
1800 Sutter St., Suite 570
Concord, CA 94520
United States of America
Email: jon.peterson@neustar.biz

Jingxuan Jensen Zhang

Jingxuan Jensen Zhang
Tongji University
4800 Cao'an Hwy
Shanghai
201804
China
Email: jingxuan.zhang@tongji.edu.cn

That's the whole doc, bestie! 🌈✨ Thanks for reading, you're iconic 💅👑

📦 where this page comes from