Content Delivery Network Interconnection (CDNI) Footprint and Capabilities Advertisement Using Application-Layer Traffic Optimization (ALTO)
Extracted elements (26)
ALTO was chosen as the FCI transport protocol because it is application-layer-oriented, provides RESTful design, supports server-initiated notifications and incremental updates via SSE (RFC 8895), and its network map semantics match the footprint representation needs of CDNI. These properties satisfy RFC 8008's requirements for push, pull, and efficient update delivery.
CDNI Advertisement resources support incremental updates via ALTO SSE (RFC 8895), using both JSON merge patch (application/merge-patch+json) and JSON patch (application/json-patch+json) to encode changes, enabling efficient propagation of footprint and capability changes from dCDN to uCDN.
The 'ipv4' and 'ipv6' predefined ALTO entity domain types (RFC 9240) are reused to represent 'ipv4cidr' and 'ipv6cidr' CDNI footprint types respectively. Individual address entities translate to the corresponding CIDR footprint with the longest prefix (/32 for IPv4, /128 for IPv6).
For a CDNI Advertisement resource using 'altopid' footprints, the resource ID of the dependent network map MUST be included in the 'uses' field of its IRD entry, and 'dependent-vtags' with a reference to this network map MUST be included in its response.
For each BaseAdvertisementObject, the ALTO client MUST interpret 'footprints' appearing multiple times as if they appeared only once. If 'footprints' is null, empty, or absent, the client MUST understand the capabilities have 'global' coverage.
If a CDNI Advertisement response depends on other ALTO information resources, it MUST include the 'dependent-vtags' field as an array of version tags for resources listed in the 'uses' IRD entry field.
If the 'cdni-capabilities' list in a filtered request is empty, the ALTO server MUST interpret it as a request for the full CDNI Advertisement resource. The server MUST interpret duplicate entries as if they appeared only once, and MUST omit capabilities for which no footprints are defined.
The 'meta' field of a CDNI Advertisement response MUST include the 'vtag' field defined in Section 10.3 of RFC 7285, providing the version of the retrieved CDNI FCI resource.
The 'uses' field MUST NOT appear unless the CDNI Advertisement resource depends on other ALTO information resources; if dependent resources exist, their resource IDs MUST be included in the 'uses' field.
The version tag in the 'vtag' field of a filtered CDNI Advertisement response MUST correspond to the full CDNI Advertisement resource from which it is derived, ensuring a single canonical version tag regardless of filtering.
When a filtered CDNI Advertisement request is invalid (null capability-type or capability-value, or inconsistent values), the ALTO server MUST return an 'E_INVALID_FIELD_VALUE' error per Section 8.5.2 of RFC 7285, and the 'value' field SHOULD indicate the offending CDNI capability.
When resource-specific entity properties are defined with entity property type 'cdni-capabilities', the defining information resource MUST be a CDNI Advertisement resource (media type: application/alto-cdni+json) provided by the ALTO server.
A new ALTO entity property type 'cdni-capabilities' is defined, mapping footprint entities (ipv4, ipv6, asn, countrycode) to their associated CDNI capabilities. Its value MUST be a JSON array of CDNICapability objects.
A new CDNI Footprint Type 'altopid' is defined, allowing a CDNI Advertisement resource to reference PID names from a dependent ALTO network map. This enables compression of CDNI Footprint Payloads using ALTO Provider-defined Identifiers.
The ASN entity domain type (identifier: 'asn') associates property values with Autonomous Systems. Entity identifiers MUST be encoded as the string 'as' (lowercase) followed by the ASN as a decimal number without leading zeros (e.g., 'as64496').
The CDNI Advertisement Service is a new ALTO service that conveys JSON objects of media type 'application/alto-cdni+json', transporting BaseAdvertisementObject objects defined in RFC 8008. It enables a dCDN to advertise its footprints and capabilities to a uCDN via the ALTO protocol.
The CDNIAdvertisementData object contains a single property 'capabilities-with-footprints', which is an array of BaseAdvertisementObject objects. Each BaseAdvertisementObject includes 'capability-type', 'capability-value', and 'footprints' fields.
The COUNTRYCODE entity domain type (identifier: 'countrycode') associates property values with countries. Entity identifiers are encoded as ISO 3166-1 alpha-2 codes in lowercase. There is no hierarchy or inheritance.
The Filtered CDNI Advertisement Service allows a uCDN client to filter a CDNI Advertisement resource by posting a ReqFilteredCDNIAdvertisement object (media type 'application/alto-cdnifilter+json') with a list of desired CDNI capabilities via HTTP POST.
This document registers two new media types: 'application/alto-cdni+json' (Section 7.1) for CDNI Advertisement resources, and 'application/alto-cdnifilter+json' (Section 7.2) for filtered CDNI Advertisement request input parameters.
This document updates the ALTO Entity Domain Types registry (RFC 9240) by adding two new types: 'asn' (ASN encoding per Section 6.1.1.2) and 'countrycode' (ISO 3166-1 alpha-2 encoding per Section 6.1.2.2), both with no hierarchy/inheritance and no mapping to ALTO address types.
This document updates the ALTO Entity Property Types registry (RFC 9240) by adding a new type 'cdni-capabilities' with intended semantics defined in Section 6.2 and defining resource media type 'application/alto-cdni+json'.
This document updates the CDNI Metadata Footprint Types registry (RFC 8006) by registering a new footprint type 'altopid', defined as a list of PID names referencing an ALTO network map.
A dCDN SHOULD isolate full and/or filtered CDNI Advertisement resources for different uCDNs to prevent information leakage across uCDN agreements; URIs may be generated by hashing company IDs and agreement terms. A dCDN SHOULD avoid exposing all resources in a single IRD.
An attacker may impersonate an ALTO server for a dCDN and provide false capabilities/footprints, potentially causing a uCDN to select incorrect dCDNs. Additionally, a dCDN could deliberately provide limited capabilities to avoid serving traffic, or launch DoS attacks via resource-intensive queries.
The uCDN (ALTO Client) MUST be authenticated to the dCDN (ALTO Server), and the dCDN MUST support HTTP Digest Authentication (RFC 7616) and MAY also support TLS mutual authentication (RFC 8446), as required by RFC 8008's integrity and authentication mandate for FCI implementations.