Content Delivery Network Interconnection (CDNI) Control Interface / Triggers
Extracted elements (33)
The 'processed' status was introduced to handle cases where a dCDN cannot track or confirm completion of triggered activity. In this state, the Trigger Status Resource is treated as complete for collection purposes, allowing a uCDN to schedule subsequent operations (e.g., pre-positioning after a purge) using the 'etime' estimated completion time.
Trigger Status Resource URIs are fully under dCDN control and uCDNs MUST NOT make assumptions about URI structure. Since all Trigger Status Resource URIs are returned to the uCDN when created and listed in collections, no URI structure convention is needed for discovery.
If content URLs are transformed by an intermediate CDN in a cascade, that CDN MUST similarly transform URLs in CI/T Commands it passes downstream. URL scheme (HTTP vs HTTPS) MUST be ignored when matching URLs in Trigger Specifications.
Unrecognized name/value pairs in JSON objects SHOULD NOT be treated as errors by either uCDN or dCDN; they SHOULD be ignored during processing and passed on by the dCDN to further dCDNs in a cascade. This enables forward-compatible extensibility.
A CI/T Trigger Command MUST NOT be reported as 'complete' until all actions have been completed successfully. In a CDN cascade, a command MUST NOT be reported as 'complete' until it is 'complete' in all downstream CDNs.
A dCDN receiving a request containing an unrecognized or unsupported trigger type MUST reject the request by creating a Trigger Status Resource with status 'failed' and an error of 'eunsupported'. All trigger types MUST be registered in the IANA 'CDNI CI/T Trigger Types' registry.
All dCDNs implementing CI/T MUST support HTTP GET, HEAD, POST, and DELETE methods. JSON MUST be supported by both uCDN and dCDN as the only representation format specified.
CI/T invalidate and purge commands MUST be applied to all data acquired before the command was accepted by the dCDN. The dCDN SHOULD NOT apply these commands to data acquired after acceptance.
CI/T objects MUST use the MIME media type 'application/cdni' with appropriate ptype parameter values. JSON names and literal values MUST always use lowercase.
Each CDN MUST append its CDN PID to the 'cdn-path' JSON array in every CI/T Command it originates or cascades. When receiving CI/T Commands, a dCDN MUST reject any command that already contains its own CDN PID, and transit CDNs MUST NOT cascade commands to dCDNs already listed in cdn-path.
If a dCDN is also acting as a uCDN in a cascade, it MUST forward CI/T Commands to any affected downstream CDNs. If any dCDN reports 'processed', intermediate CDNs MUST NOT report 'complete' and MUST also report 'processed'.
If the dCDN automatically removes stale Trigger Status Resources, it MUST report the retention period using 'staleresourcetime' in the collection. It is RECOMMENDED that completed resources are retained for at least 24 hours before automatic deletion.
In a diamond CDN configuration, a dCDN MUST allow each uCDN from which it may have acquired content to act upon that content using CI/T Commands. In all other cases, a dCDN MUST reject CI/T Commands from a uCDN attempting to act on another uCDN's content.
Trigger Status Resources belonging to a uCDN MUST NOT be visible to any other CDN. The dCDN must enforce isolation, e.g., by offering different collection URLs per uCDN and filtering responses by authenticated identity.
Unknown Error Codes MUST be treated as fatal errors, and the request MUST NOT be automatically retried without modification. All Error Codes MUST be registered in the IANA 'CDNI CI/T Error Codes' registry.
When a CI/T Trigger Command is accepted, the dCDN MUST create a new Trigger Status Resource, respond with HTTP 201, and convey the resource URI in the Location header. The URI of a Trigger Status Resource MUST NOT be reused after the resource is removed.
When processing Trigger Specifications, CDNs MUST ignore the URL scheme (HTTP or HTTPS) when comparing URLs. Content MUST be invalidated or purged regardless of the protocol clients used to request it.
The CI/T protocol carries no end-user information but does carry commercially sensitive data (content URLs, catalog change signals via invalidate/purge). Mutually authenticated TLS provides confidentiality in transit, and the dCDN MUST ensure CI/T data for a uCDN is only exposed to authenticated clients of that uCDN.
A CI/T Command is a JSON object with exactly one of 'trigger' (a Trigger Specification) or 'cancel' (array of Trigger Status Resource URLs), plus a mandatory 'cdn-path' array of CDN PIDs. The media type is 'application/cdni; ptype=ci-trigger-command'.
A Trigger Collection is a JSON object with a mandatory 'triggers' array of URIs and optional fields: 'staleresourcetime' (seconds before auto-deletion), 'coll-all/pending/active/complete/failed' links, and 'cdn-id'. Media type is 'application/cdni; ptype=ci-trigger-collection'.
A Trigger Status Resource is a JSON object with mandatory fields: 'trigger' (Trigger Specification), 'ctime' (command receipt time), 'mtime' (last modification time), and 'status' (current state). Optional fields include 'etime' (estimated completion), and 'errors' (array of Error Descriptions). Media type is 'application/cdni; ptype=ci-trigger-status'.
The CI/T interface defines three types of trigger commands: preposition (fetch metadata or content), invalidate (revalidate before reuse), and purge (delete metadata or content). Commands are sent from the upstream CDN (uCDN) to the downstream CDN (dCDN) via HTTP POST.
A new 'CDNI CI/T Error Codes' subregistry is created under 'Content Delivery Network Interconnection (CDNI) Parameters'. Initial entries include emeta, econtent, eperm, ereject, ecdn, ecanceled, eunsupported. New additions require Specification Required policy.
A new 'CDNI CI/T Trigger Types' subregistry is created under 'Content Delivery Network Interconnection (CDNI) Parameters'. Initial entries are 'preposition', 'invalidate', and 'purge'. New additions require RFC Required policy.
Three new CDNI Payload Types are registered: 'ci-trigger-command', 'ci-trigger-status', and 'ci-trigger-collection' in the 'CDNI Payload Types' registry under the 'application/cdni' media type.
A CI/T implementation MUST support TLS for HTTPS transport and TLS MUST be used by both dCDN and uCDN sides including mutual authentication of the remote end, unless alternate security mechanisms (e.g., IPsec tunnel, physically secured internal network) are used. General TLS usage guidance from RFC 7525 MUST be followed.
A dCDN implementation MUST restrict the actions of a uCDN to data corresponding to that uCDN. HTTP requests attempting to access CI/T data belonging to another CDN MUST be rejected with HTTP 403 or 404. Injected CI/T Commands could generate excessive load and decrease caching efficiency.
The CI/T interface has no specific DoS protection mechanism; endpoints can be protected via TLS, firewalling, or VPNs outside the protocol. The dCDN should consider rate-limiting acceptance/processing of CI/T Commands or batch processing to avoid overload from malicious or faulty uCDNs.
Trigger Status Resources transition through states: pending (accepted, not yet acted upon) → active (currently being processed) → complete (successfully finished) or failed (could not complete). Additional states include processed (accepted, no further status updates), cancelling (cancellation requested but not yet complete), and cancelled (successfully cancelled).
A PatternMatch is a JSON object with a mandatory 'pattern' string (supporting * and ? wildcards, with $, *, ? escaped as $$, $*, $?), optional 'case-sensitive' boolean (default false), and optional 'match-query-string' boolean (default false).
A Trigger Specification is a JSON object with mandatory 'type' field (Trigger Type string) and at least one non-empty of: 'metadata.urls', 'content.urls', 'content.ccid', 'metadata.patterns', or 'content.patterns'. The 'metadata.patterns' and 'content.patterns' fields MUST NOT be present for 'preposition' type triggers.
Absolute Time is encoded as a JSON number representing seconds since the UNIX epoch (00:00:00 UTC on 1 January 1970). No clock synchronization between CDNs is required.
CDN PID is encoded as a string with the format 'AS' followed by the CDN provider's Autonomous System number, a colon, and an additional numeric qualifier (e.g., 'AS64496:0'). If a CDN provider has multiple ASes, the same AS number SHOULD be used unless there are multiple distinct CDNs.