Content Delivery Network Interconnection (CDNI) Capacity Capability Advertisement Extensions
Extracted elements (22)
A dCDN-provided Telemetry Source that both parties reference creates an unambiguous metric for comparing current usage against a limit. Without a shared source, the uCDN and dCDN might observe different values, making limit enforcement ambiguous.
Limits communicated from dCDN to uCDN use the TTL provided by the underlying transport (e.g., HTTP Cache-Control header) to determine validity. If the transport lacks such a mechanism, TTL must be communicated out-of-band. This design reuses existing HTTP caching infrastructure rather than defining a new TTL field.
The capacity information provided by the FCI interface is explicitly advisory and does not represent a guarantee, commitment, or reservation of capacity. This avoids overloading the FCI with binding contractual semantics that belong in bilateral agreements.
The 'configuration' property of a Telemetry Source Object is intentionally left source-specific and out-of-scope to allow forward compatibility with a future formal telemetry interface specification, without blocking the current registration.
For each CapacityLimit advertised, there should exist a corresponding Telemetry Source providing current utilization data for that limit. The FCI.CapacityLimits and FCI.Telemetry objects are designed to be used together, linked via the CapacityLimitTelemetrySource Object.
In multi-CDN delegation chains, a uCDN must aggregate telemetry from all dCDNs to which it delegated traffic when reporting usage upstream. Without this aggregation, delegated traffic becomes invisible to the content provider or higher-level uCDN.
If the CapacityLimit 'id' property is specified, it MUST be unique among all identifiers associated with CapacityLimit Objects in the same advertisement.
It is NOT RECOMMENDED to specify the 'current' usage value inline within FCI.CapacityLimits advertisements because doing so reduces the ability to cache the response. The intended method is to reference a Telemetry Source Object for polling current usage.
Multiple CapacityLimit Objects MUST be considered using a logical AND: a uCDN must ensure that all limits are satisfied rather than choosing only the most specific.
The 'id' of a Telemetry Source Object MUST be unique across all Telemetry Source objects in the advertisement containing it. The ID MUST remain consistent for the same source reference across advertisements.
The 'maximum-soft' value MUST be less than the value of 'maximum-hard'. If not specified, maximum-soft is equal to maximum-hard. The uCDN SHOULD reduce traffic upon reaching the soft limit before hitting the hard limit.
The 'name' of a Telemetry Source Metric Object MUST be unique among metric objects within the containing Telemetry Source and MUST remain consistent for the same source reference across advertisements. Absence of 'data-percentile' indicates the data MUST be the mean over the time-granularity.
The CapacityLimit Object represents a traffic limit for delegation from uCDN to dCDN. Mandatory properties are 'limit-type' (registered type string) and 'maximum-hard' (unsigned integer). Optional properties include 'id', 'maximum-soft', 'current', and 'telemetry-source'.
The CapacityLimitTelemetrySource Object links a CapacityLimit to a specific metric within a Telemetry Source Object. It has two mandatory properties: 'id' (reference to a Telemetry Source 'id') and 'metric' (reference to the metric 'name' within that source).
The FCI.CapacityLimits Capability Object enables the dCDN to specify Not-to-Exceed traffic delegation limits. It contains a mandatory 'limits' property: a JSON array of CapacityLimit Objects scoped to the footprint of the enclosing FCI Capabilities advertisement.
The FCI.Telemetry Capability Object advertises a list of Telemetry Sources made available to the uCDN by the dCDN. It contains a mandatory 'sources' property: a JSON array of Telemetry Source Objects describing near real-time aggregated dCDN utilization metrics.
The Telemetry Source Metric Object describes an exposed metric with mandatory 'name' (unique string within the source) and optional 'time-granularity' (seconds), 'data-percentile' (unsigned integer), and 'latency' (seconds behind real-time).
The Telemetry Source Object identifies a telemetry data source with mandatory 'id' (unique string), 'type' (a registered Telemetry Source Type), and 'metrics' (JSON array of Telemetry Source Metric Objects), plus optional 'configuration' (source-specific JSON object).
RFC 9808 creates the 'CDNI Capacity Limit Types' registry with Specification Required policy. Initial entries are: egress (bits/s), requests (requests/s), storage-size (total bytes), storage-objects (count), sessions (count), and cache-size (total bytes).
RFC 9808 creates the 'CDNI Telemetry Source Types' registry within the CDNI Parameters registry group, with Specification Required policy. The initial entry is 'generic', an agnostic telemetry type for advertisement of generic data sources.
RFC 9808 registers two new CDNI Payload Types in the 'CDNI Payload Types' registry: FCI.Telemetry (Section 2.1) and FCI.CapacityLimits (Section 2.2), both on the FCI interface.
RFC 9808 is subject to the security and privacy considerations defined in Section 7 of RFC 8008 (CDNI Request Routing: Footprint and Capabilities Semantics), as this specification extends that interface.