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

Cheating dCDNs (those advertising inaccurate footprint or capability information to gain delegation preference) are assumed to be handled by contractual agreements and out-of-band audits rather than real-time verifiability within the FCI protocol itself.

security

Highly dynamic capability data (real-time delivery performance metrics, CDN resource load, QoS) is explicitly out of scope for the CDNI FCI. The FCI targets information that does not change highly dynamically and is necessary for basic delegation decisions such as supported delivery protocol.

Resource footprint types (advertising Surrogate locations) are not mandatory because they expose the internal structure of a CDN, which may be undesirable. Coverage/reachability footprint types are the primary mandatory form.

privacy

The document considers a query/response model versus a state-replication (advertisement) model for the FCI. When the volume of FCI updates would exceed request volume, querying dCDNs upon each request (as in recursive redirection) may scale better, but the advertisement model is adopted as the baseline semantic.

The FCI adopts the semantics of 'capabilities with footprint restrictions' rather than 'footprints with capability attributes'. This choice reflects that contractual agreements define basic coverage, and the FCI's primary role is to convey updates to capabilities and coverage relative to those agreements.

A uCDN MAY ignore capability or footprint types it does not understand; it selects a dCDN based only on the types it does understand. If a dCDN omits an optional capability supported by the uCDN, this causes no functional problem because the uCDN decides using remaining conveyed information.

Multiple footprint constraints within a single advertisement are additive: each additional footprint type (e.g., IP prefix, ASN, country code) further narrows the dCDN's candidacy cumulatively, not as alternatives.

All CDNI FCI objects MUST be encoded using JSON (RFC 7159) and MUST also follow the recommendations of I-JSON (RFC 7493). Dictionary keys (property names) defined by this document MUST be lowercase.

json

Any FCI solution protocol MUST define how support for optional footprint types and capability types is negotiated between a uCDN and dCDN, and MUST specify how failure cases or non-supported types are handled.

CDNs MUST advertise support for optional CDNI Logging fields within the context of a specific record-type. Advertising support for mandatory-to-enforce GenericMetadata types MUST be provided; advertising non-mandatory-to-enforce GenericMetadata types SHOULD be provided.

CDNs SHOULD NOT advertise support for mandatory-to-implement CDNI Logging record-types, as doing so would be redundant. For a given record-type, CDNs SHOULD NOT advertise support for mandatory-to-implement CDNI Logging fields either.

In the CDNI Logging Capability Object, omission of the 'fields' property MUST be interpreted as 'all optional fields are supported'; an empty list MUST be interpreted as 'no optional fields are supported'; a non-empty list MUST be interpreted as 'only those fields are supported'.

In the CDNI Metadata Capability Object, an empty 'metadata' list MUST be interpreted as 'no GenericMetadata types are supported (only structural metadata and simple types)'; a non-empty list is interpreted as the only supported GenericMetadata types.

Updates to capability objects MUST indicate the version of the capability object in a newly registered Payload Type (e.g., by appending '.v2'). Future specifications defining a capability MUST define any necessary registries for the values advertised for that capability type.

registry

The Acquisition Protocol Capability Object (Payload Type: FCI.AcquisitionProtocol) contains a mandatory 'acquisition-protocols' property listing supported acquisition protocols from the CDNI Metadata Protocol Types registry (e.g., 'http/1.1', 'https/1.1').

http

The CDNI Logging Capability Object (Payload Type: FCI.Logging) has a mandatory 'record-type' property (string from the CDNI Logging record-types registry) and an optional 'fields' property (list of strings from the CDNI Logging Field Names registry) indicating which optional fields for that record-type are supported.

The CDNI Metadata Capability Object (Payload Type: FCI.Metadata) has a mandatory 'metadata' property listing supported CDNI GenericMetadata types (strings from the CDNI Payload Types registry); an empty list signals only structural metadata and simple types are supported.

The Delivery Protocol Capability Object (Payload Type: FCI.DeliveryProtocol) contains a mandatory 'delivery-protocols' property listing supported delivery protocols from the CDNI Metadata Protocol Types registry (e.g., 'http/1.1').

http

The FCIBase (Base Advertisement Object) has three properties: 'capability-type' (mandatory, an FCI-specific CDNI Payload Type), 'capability-value' (mandatory, format defined by capability-type), and 'footprints' (optional, a list of CDNI Footprint objects from the CDNI Metadata Footprint Types registry).

json

The Redirection Mode Capability Object (Payload Type: FCI.RedirectionMode) contains a mandatory 'redirection-modes' property listing supported redirection modes from the CDNI Capabilities Redirection Modes registry (e.g., 'DNS-I', 'HTTP-I', 'DNS-R', 'HTTP-R').

dns, http

This document creates the IANA 'CDNI Capabilities Redirection Modes' registry under the CDNI Parameters registry, with initial entries: DNS-I (Iterative DNS-based), DNS-R (Recursive DNS-based), HTTP-I (Iterative HTTP-based), and HTTP-R (Recursive HTTP-based). Additions require IETF Review.

registry, dns, http

This document registers five CDNI Payload Types in the IANA 'CDNI Payload Types' registry: FCI.DeliveryProtocol, FCI.AcquisitionProtocol, FCI.RedirectionMode, FCI.Logging, and FCI.Metadata, all referencing RFC 8008.

registry

All protocols implementing FCI capabilities and footprint advertisement objects are REQUIRED to provide integrity and authentication services. Without these, an attacker could forge footprint advertisements to deny service by making a dCDN appear to have no footprint or capability.

security, tls

All protocols implementing FCI objects are REQUIRED to provide confidentiality services, because a dCDN may need to share outage or reduced-coverage information with a uCDN confidentially without disclosing it to competing dCDNs.

security, tls

The security requirements of the FCI can be met by transport-layer security (e.g., TLS per RFC 7525) with domain certificates. No object-level security is deemed necessary because FCI trust relationships are bilateral between uCDN and dCDN rather than transitive.

security, tls, pkix