draft-ietf-cdni-control-triggers-04.txt   draft-ietf-cdni-control-triggers-05.txt 
Network Working Group R. Murray Network Working Group R. Murray
Internet-Draft B. Niven-Jenkins Internet-Draft B. Niven-Jenkins
Intended status: Standards Track Velocix (Alcatel-Lucent) Intended status: Standards Track Velocix (Alcatel-Lucent)
Expires: March 7, 2015 September 3, 2014 Expires: July 2, 2015 December 29, 2014
CDNI Control Interface / Triggers CDNI Control Interface / Triggers
draft-ietf-cdni-control-triggers-04 draft-ietf-cdni-control-triggers-05
Abstract Abstract
This document describes the part of the CDN Interconnection Control This document describes the part of the CDN Interconnection Control
Interface that allows a CDN to trigger activity in an interconnected Interface that allows a CDN to trigger activity in an interconnected
CDN that is configured to deliver content on its behalf. The CDN that is configured to deliver content on its behalf. The
upstream CDN can use this mechanism to request that the downstream upstream CDN can use this mechanism to request that the downstream
CDN pre-positions metadata or content, or that it invalidates or CDN pre-positions metadata or content, or that it invalidates or
purges metadata or content. The upstream CDN can monitor the status purges metadata or content. The upstream CDN can monitor the status
of activity that it has triggered in the downstream CDN. of activity that it has triggered in the downstream CDN.
skipping to change at page 1, line 42 skipping to change at page 1, line 42
Internet-Drafts are working documents of the Internet Engineering Internet-Drafts are working documents of the Internet Engineering
Task Force (IETF). Note that other groups may also distribute Task Force (IETF). Note that other groups may also distribute
working documents as Internet-Drafts. The list of current Internet- working documents as Internet-Drafts. The list of current Internet-
Drafts is at http://datatracker.ietf.org/drafts/current/. Drafts is at http://datatracker.ietf.org/drafts/current/.
Internet-Drafts are draft documents valid for a maximum of six months Internet-Drafts are draft documents valid for a maximum of six months
and may be updated, replaced, or obsoleted by other documents at any and may be updated, replaced, or obsoleted by other documents at any
time. It is inappropriate to use Internet-Drafts as reference time. It is inappropriate to use Internet-Drafts as reference
material or to cite them other than as "work in progress." material or to cite them other than as "work in progress."
This Internet-Draft will expire on March 7, 2015. This Internet-Draft will expire on July 2, 2015.
Copyright Notice Copyright Notice
Copyright (c) 2014 IETF Trust and the persons identified as the Copyright (c) 2014 IETF Trust and the persons identified as the
document authors. All rights reserved. document authors. All rights reserved.
This document is subject to BCP 78 and the IETF Trust's Legal This document is subject to BCP 78 and the IETF Trust's Legal
Provisions Relating to IETF Documents Provisions Relating to IETF Documents
(http://trustee.ietf.org/license-info) in effect on the date of (http://trustee.ietf.org/license-info) in effect on the date of
publication of this document. Please review these documents publication of this document. Please review these documents
skipping to change at page 2, line 21 skipping to change at page 2, line 21
include Simplified BSD License text as described in Section 4.e of include Simplified BSD License text as described in Section 4.e of
the Trust Legal Provisions and are provided without warranty as the Trust Legal Provisions and are provided without warranty as
described in the Simplified BSD License. described in the Simplified BSD License.
Table of Contents Table of Contents
1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3
1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4
2. Model for CDNI Triggers . . . . . . . . . . . . . . . . . . . 4 2. Model for CDNI Triggers . . . . . . . . . . . . . . . . . . . 4
2.1. Timing of Triggered Activity . . . . . . . . . . . . . . 6 2.1. Timing of Triggered Activity . . . . . . . . . . . . . . 6
2.2. Trigger Results . . . . . . . . . . . . . . . . . . . . . 6 2.2. Scope of Triggered Activity . . . . . . . . . . . . . . . 6
3. Collections of Trigger Status Resources . . . . . . . . . . . 6 2.3. Trigger Results . . . . . . . . . . . . . . . . . . . . . 6
4. CDNI Trigger Interface . . . . . . . . . . . . . . . . . . . 7 3. Collections of Trigger Status Resources . . . . . . . . . . . 7
4.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 8 4. CDNI Trigger Interface . . . . . . . . . . . . . . . . . . . 8
4.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 9
4.2. Checking Status . . . . . . . . . . . . . . . . . . . . . 10 4.2. Checking Status . . . . . . . . . . . . . . . . . . . . . 10
4.2.1. Polling Trigger Status Resource collections . . . . . 10 4.2.1. Polling Trigger Status Resource collections . . . . . 10
4.2.2. Polling Trigger Status Resources . . . . . . . . . . 10 4.2.2. Polling Trigger Status Resources . . . . . . . . . . 11
4.3. Cancelling Triggers . . . . . . . . . . . . . . . . . . . 10 4.3. Cancelling Triggers . . . . . . . . . . . . . . . . . . . 11
4.4. Deleting Triggers . . . . . . . . . . . . . . . . . . . . 11 4.4. Deleting Triggers . . . . . . . . . . . . . . . . . . . . 12
4.5. Expiry of Trigger Status Resources . . . . . . . . . . . 12 4.5. Expiry of Trigger Status Resources . . . . . . . . . . . 12
4.6. Loop Detection and Prevention . . . . . . . . . . . . . . 12 4.6. Loop Detection and Prevention . . . . . . . . . . . . . . 13
4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 13 4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 13
4.8. Content URLs . . . . . . . . . . . . . . . . . . . . . . 13 4.8. Content URLs . . . . . . . . . . . . . . . . . . . . . . 14
5. CI/T Object Properties and Encoding . . . . . . . . . . . . . 14 5. CI/T Object Properties and Encoding . . . . . . . . . . . . . 15
5.1. CI/T Objects . . . . . . . . . . . . . . . . . . . . . . 14 5.1. CI/T Objects . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 14 5.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 15
5.1.2. Trigger Status Resource . . . . . . . . . . . . . . . 15 5.1.2. Trigger Status Resource . . . . . . . . . . . . . . . 16
5.1.3. Trigger Collection . . . . . . . . . . . . . . . . . 16 5.1.3. Trigger Collection . . . . . . . . . . . . . . . . . 17
5.2. Properties of CI/T Objects . . . . . . . . . . . . . . . 17 5.2. Properties of CI/T Objects . . . . . . . . . . . . . . . 18
5.2.1. Trigger Specification . . . . . . . . . . . . . . . . 18 5.2.1. Trigger Specification . . . . . . . . . . . . . . . . 18
5.2.2. Trigger Type . . . . . . . . . . . . . . . . . . . . 19 5.2.2. Trigger Type . . . . . . . . . . . . . . . . . . . . 20
5.2.3. Trigger Status . . . . . . . . . . . . . . . . . . . 19 5.2.3. Trigger Status . . . . . . . . . . . . . . . . . . . 20
5.2.4. PatternMatch . . . . . . . . . . . . . . . . . . . . 20 5.2.4. PatternMatch . . . . . . . . . . . . . . . . . . . . 21
5.2.5. Absolute Time . . . . . . . . . . . . . . . . . . . . 21 5.2.5. Absolute Time . . . . . . . . . . . . . . . . . . . . 22
5.2.6. Error Description . . . . . . . . . . . . . . . . . . 21 5.2.6. Error Description . . . . . . . . . . . . . . . . . . 22
5.2.7. Error Code . . . . . . . . . . . . . . . . . . . . . 22 5.2.7. Error Code . . . . . . . . . . . . . . . . . . . . . 23
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 22 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23
6.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 23 6.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 24
6.1.1. Preposition . . . . . . . . . . . . . . . . . . . . . 23 6.1.1. Preposition . . . . . . . . . . . . . . . . . . . . . 24
6.1.2. Invalidate . . . . . . . . . . . . . . . . . . . . . 24 6.1.2. Invalidate . . . . . . . . . . . . . . . . . . . . . 25
6.2. Examining Trigger Status . . . . . . . . . . . . . . . . 25 6.2. Examining Trigger Status . . . . . . . . . . . . . . . . 26
6.2.1. Collection of All Triggers . . . . . . . . . . . . . 25 6.2.1. Collection of All Triggers . . . . . . . . . . . . . 26
6.2.2. Filtered Collections of Triggers . . . . . . . . . . 26 6.2.2. Filtered Collections of Trigger Status Resources . . 27
6.2.3. Trigger Status Resources . . . . . . . . . . . . . . 28 6.2.3. Individual Trigger Status Resources . . . . . . . . . 29
6.2.4. Polling for Change . . . . . . . . . . . . . . . . . 30 6.2.4. Polling for Change . . . . . . . . . . . . . . . . . 31
6.2.5. Removing a Trigger . . . . . . . . . . . . . . . . . 33 6.2.5. Deleting Trigger Status Resources . . . . . . . . . . 34
6.2.6. Error Reporting . . . . . . . . . . . . . . . . . . . 35 6.2.6. Error Reporting . . . . . . . . . . . . . . . . . . . 35
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36
7.1. Media type registrations . . . . . . . . . . . . . . . . 36 7.1. Media type registrations . . . . . . . . . . . . . . . . 37
7.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 36 7.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 37
7.1.2. CI/T Trigger Status Resource . . . . . . . . . . . . 37 7.1.2. CI/T Trigger Status Resource . . . . . . . . . . . . 38
7.1.3. CI/T Trigger Collection . . . . . . . . . . . . . . . 38 7.1.3. CI/T Trigger Collection . . . . . . . . . . . . . . . 39
8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 8. Security Considerations . . . . . . . . . . . . . . . . . . . 40
8.1. Authentication, Confidentiality, Integrity Protection . . 39 8.1. Authentication, Confidentiality, Integrity Protection . . 40
8.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 39 8.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 40
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 40 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 40 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41
10.1. Normative References . . . . . . . . . . . . . . . . . . 40 10.1. Normative References . . . . . . . . . . . . . . . . . . 41
10.2. Informative References . . . . . . . . . . . . . . . . . 40 10.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42
1. Introduction 1. Introduction
[RFC6707] introduces the problem scope for CDN Interconnection (CDNI) [RFC6707] introduces the problem scope for CDN Interconnection (CDNI)
and lists the four categories of interfaces that may be used to and lists the four categories of interfaces that may be used to
compose a CDNI solution (Control, Metadata, Request Routing, compose a CDNI solution (Control, Metadata, Request Routing,
Logging). Logging).
[RFC7336] expands on the information provided in [RFC6707] and [RFC7336] expands on the information provided in [RFC6707] and
describes each of the interfaces and the relationships between them describes each of the interfaces and the relationships between them
skipping to change at page 4, line 11 skipping to change at page 4, line 11
o Section 5 lists properties of CI/T Commands and Status Resources. o Section 5 lists properties of CI/T Commands and Status Resources.
o Section 6 contains example messages. o Section 6 contains example messages.
1.1. Terminology 1.1. Terminology
This document reuses the terminology defined in [RFC6707]. This document reuses the terminology defined in [RFC6707].
2. Model for CDNI Triggers 2. Model for CDNI Triggers
A trigger, sent from the uCDN to the dCDN, is a request for the dCDN A CI/T Command, sent from the uCDN to the dCDN, is a request for the
to do some work relating to data originating from the uCDN. dCDN to do some work relating to data associated with content
requests originating from the uCDN.
The trigger can request action on either metadata or content, the There are two types of CI/T Command, CI/T Trigger Commands and CI/T
following actions can be requested: Cancel Commands. The CI/T Cancel Command can be used to request
cancellation of an earlier CI/T Trigger Command. A CI/T Trigger
Command is of one of the following types:
o preposition - used to instruct the dCDN to fetch metadata from the o preposition - used to instruct the dCDN to fetch metadata from the
uCDN, or content from any origin including the uCDN. uCDN, or content from any origin including the uCDN.
o invalidate - used to instruct the dCDN to revalidate specific o invalidate - used to instruct the dCDN to revalidate specific
metadata or content before re-using it. metadata or content before re-using it.
o purge - used to instruct the dCDN to delete specific metadata or o purge - used to instruct the dCDN to delete specific metadata or
content. content.
Multiple representations of an HTTP resource may share the same URL.
Requests to invalidate and purge metadata or content apply to all
resource representations with matching URLs.
The CI/T interface is a web service offered by the dCDN. It allows The CI/T interface is a web service offered by the dCDN. It allows
creation and deletion of triggers, and tracking of the triggered CI/T commands to be issued, and triggered activity to be tracked.
activity. When the dCDN accepts a trigger it creates a resource When the dCDN accepts a CI/T Command it creates a resource describing
describing status of the triggered activity, a Trigger Status status of the triggered activity, a Trigger Status Resource. The
Resource. The uCDN can poll Trigger Status Resources to monitor uCDN can poll Trigger Status Resources to monitor progress.
progress.
The dCDN maintains a collection of Trigger Status Resources for each The dCDN maintains at least one collection of Trigger Status
uCDN, each uCDN only has access to its own collection and the Resources for each uCDN. Each uCDN only has access to its own
location of that collection is shared when CDN interconnection is collections, the locations of which are shared when CDN
established. interconnection is established.
To trigger activity in the dCDN, the uCDN POSTs a CI/T Command to the To trigger activity in the dCDN, the uCDN POSTs a CI/T Command to the
collection of Trigger Status Resources. If the dCDN accepts the collection of Trigger Status Resources. If the dCDN accepts the CI/T
trigger, it creates a new Trigger Status Resource and returns its Command, it creates a new Trigger Status Resource and returns its
location to the uCDN. To monitor progress, the uCDN can GET the location to the uCDN. To monitor progress, the uCDN can GET the
Trigger Status Resource. To request cancellation of a trigger the Trigger Status Resource. To request cancellation of a CI/T Trigger
uCDN can POST to the collection of Trigger Status Resources, or Command the uCDN can POST to the collection of Trigger Status
simply DELETE the Trigger Status Resource. Resources, or simply DELETE the Trigger Status Resource.
In addition to the collection of all Trigger Status Resources for the In addition to the collection of all Trigger Status Resources for the
uCDN, the dCDN can maintain filtered views of that collection. These uCDN, the dCDN can maintain filtered views of that collection. These
filtered views are defined in Section 3 and include collections of filtered views are defined in Section 3 and include collections of
active and completed triggers. These collections provide a mechanism Trigger Status Resources corresponding to active and completed CI/T
for polling the status of multiple jobs. Trigger Commands. These collections provide a mechanism for polling
the status of multiple jobs.
Figure 1 is an example showing the basic message flow used by the Figure 1 is an example showing the basic message flow used by the
uCDN to trigger activity in the dCDN, and for the uCDN to discover uCDN to trigger activity in the dCDN, and for the uCDN to discover
the status of that activity. Only successful triggering is shown. the status of that activity. Only successful triggering is shown.
Examples of the messages are given in Section 6. Examples of the messages are given in Section 6.
uCDN dCDN uCDN dCDN
| (1) POST http://dcdn.example.com/triggers/uCDN | | (1) POST http://dcdn.example.com/triggers/uCDN |
[ ] --------------------------------------------------> [ ]--+ [ ] --------------------------------------------------> [ ]--+
| [ ] | (2) | [ ] | (2)
skipping to change at page 5, line 39 skipping to change at page 5, line 39
| | | |
| | | |
Figure 1: Basic CDNI Message Flow for Triggers Figure 1: Basic CDNI Message Flow for Triggers
The steps in Figure 1 are: The steps in Figure 1 are:
1. The uCDN triggers action in the dCDN by posting a CI/T Command to 1. The uCDN triggers action in the dCDN by posting a CI/T Command to
a collection of Trigger Status Resources, a collection of Trigger Status Resources,
"http://dcdn.example.com/triggers/uCDN". The URL of this was "http://dcdn.example.com/triggers/uCDN". The URL of this was
given to the uCDN when the trigger interface was established. given to the uCDN when the CI/T interface was established.
2. The dCDN authenticates the request, validates the trigger and if 2. The dCDN authenticates the request, validates the CI/T Command
it accepts the request, creates a new Trigger Status Resource. and, if it accepts the request, creates a new Trigger Status
Resource.
3. The dCDN responds to the uCDN with an HTTP 201 response status, 3. The dCDN responds to the uCDN with an HTTP 201 response status,
and the location of the Trigger Status Resource. and the location of the Trigger Status Resource.
4. The uCDN can repeatedly poll the Trigger Status Resource in the 4. The uCDN can poll, possibly repeatedly, the Trigger Status
dCDN. Resource in the dCDN.
5. The dCDN responds with the Trigger Status Resource, describing 5. The dCDN responds with the Trigger Status Resource, describing
progress or results of the triggered activity. progress or results of the CI/T Trigger Command.
The remainder of this document describes the messages, Trigger Status The remainder of this document describes the messages, Trigger Status
Resources, and collections of Trigger Status Resources in more Resources, and collections of Trigger Status Resources in more
detail. detail.
2.1. Timing of Triggered Activity 2.1. Timing of Triggered Activity
Timing of the execution of triggered activity is under the dCDN's Timing of the execution of CI/T Commands is under the dCDN's control,
control, including its start-time and pacing of the activity in the including its start-time and pacing of the activity in the network.
network.
Invalidate and purge triggers MUST be applied to all data acquired CI/T invalidate and purge commands MUST be applied to all data
before the trigger was created in the dCDN. The dCDN MAY apply the acquired before the command was accepted by the dCDN. The dCDN
triggers to data acquired after trigger creation. SHOULD NOT apply CI/T invalidate and purge commands to data acquired
after the CI/T Command was accepted, but this may not always be
achievable so the uCDN cannot count on that.
If the uCDN wishes to invalidate or purge content, then immediately If the uCDN wishes to invalidate or purge content then immediately
pre-position replacement content at the same URLs, it SHOULD ensure pre-position replacement content at the same URLs, it SHOULD ensure
the dCDN has completed the invalidate/purge before initiating the the dCDN has completed the invalidate/purge before initiating the
prepositioning. Otherwise, there is a risk that the dCDN pre- prepositioning. Otherwise, there is a risk that the dCDN pre-
positions the new content, then immediately invalidates or purges it positions the new content, then immediately invalidates or purges it
(as a result of the two uCDN requests running in parallel). (as a result of the two uCDN requests running in parallel).
2.2. Trigger Results Because the CI/T Command timing is under the dCDN's control, the dCDN
implementation can choose whether to apply CI/T invalidate and purge
commands to content acquisition that has already started when the
command is received.
Each trigger can operate on multiple metadata and content URLs. The 2.2. Scope of Triggered Activity
trigger MUST NOT be reported as "complete" until all actions have
been completed successfully. The reasons for failure, and URLs or
Patterns affected, SHOULD be enumerated in the Trigger Status
Resource. For more detail, see section Section 4.7.
If a dCDN is also acting as a uCDN in a cascade, it MUST forward Each CI/T Command can operate on multiple metadata and content URLs.
triggers to any downstream CDNs that may have data affected by the
trigger. The trigger MUST NOT be reported as 'complete' in a CDN Multiple representations of an HTTP resource may share the same URL.
until it is 'complete' in all of its downstream CDNs. If a trigger CI/T Trigger Commands that invalidate or purge metadata or content
is reported as 'processed' in any dCDN, intermediate CDNs MUST NOT apply to all resource representations with matching URLs.
report 'complete', instead they must also report 'processed'. A
trigger MAY be reported as 'failed' as soon as it fails in a CDN or The dCDN MUST reject CI/T Commands from a uCDN that act on another
in any of its downstream CDNs. A cancelled trigger MUST be reported uCDN's data. Security considerations are discussed further in
as 'cancelling' until it has been reported as 'cancelled', section Section 8.
'complete', or 'failed' by all dCDNs in a cascade.
2.3. Trigger Results
Possible states for a Trigger Status Resource are defined in section
Section 5.2.3.
The CI/T Trigger Command MUST NOT be reported as 'complete' until all
actions have been completed successfully. The reasons for failure,
and URLs or Patterns affected, SHOULD be enumerated in the Trigger
Status Resource. For more detail, see section Section 4.7.
If a dCDN is also acting as a uCDN in a cascade, it MUST forward CI/T
Commands to any downstream CDNs that may be affected. The CI/T
Trigger Command MUST NOT be reported as 'complete' in a CDN until it
is 'complete' in all of its downstream CDNs. If a CI/T Trigger
Command is reported as 'processed' in any dCDN, intermediate CDNs
MUST NOT report 'complete', instead they must also report
'processed'. A CI/T Command MAY be reported as 'failed' as soon as
it fails in a CDN or in any of its downstream CDNs. A cancelled CI/T
Trigger Command MUST be reported as 'cancelling' until it has been
reported as 'cancelled', 'complete', or 'failed' by all dCDNs in a
cascade.
3. Collections of Trigger Status Resources 3. Collections of Trigger Status Resources
As described in Section 2, Trigger Status Resources exist in the dCDN As described in Section 2, Trigger Status Resources exist in the dCDN
to report the status of activity triggered by each uCDN. to report the status of activity triggered by each uCDN.
A collection of Trigger Status Resources is a resource that contains A collection of Trigger Status Resources is a resource that contains
a reference to each Trigger Status Resource in that collection. a reference to each Trigger Status Resource in that collection.
The dCDN MUST make a collection of a uCDN's Trigger Status Resources The dCDN MUST make a collection of a uCDN's Trigger Status Resources
available to that uCDN. This collection includes all of the uCDN available to that uCDN. This collection includes all of the Trigger
triggers that have been accepted by the dCDN, and have not yet been Status Resources created for CI/T Commands from the uCDN that have
deleted by the uCDN, or expired and removed by the dCDN (as described been accepted by the dCDN, and have not yet been deleted by the uCDN,
in section Section 4.4). Trigger Status Resources belonging to a or expired and removed by the dCDN (as described in section
uCDN MUST NOT be visible to any other CDN. The dCDN could, for Section 4.4). Trigger Status Resources belonging to a uCDN MUST NOT
example, achieve this by offering different collection URLs to each be visible to any other CDN. The dCDN could, for example, achieve
uCDN, or by filtering the response based on the client uCDN. this by offering different collection URLs to each uCDN, and/or by
filtering the response based on the uCDN with which the HTTP client
is associated.
To trigger activity in a dCDN, or to cancel triggered activity, the To trigger activity in a dCDN, or to cancel triggered activity, the
uCDN POSTs a CI/T Command to the dCDN's collection of the uCDN's uCDN POSTs a CI/T Command to the dCDN's collection of the uCDN's
Trigger Status Resources. Trigger Status Resources.
In order to allow the uCDN to check the status of multiple jobs in a In order to allow the uCDN to check the status of multiple jobs in a
single request, the dCDN SHOULD also maintain collections single request, the dCDN SHOULD also maintain collections
representing filtered views of the collection of all Trigger Status representing filtered views of the collection of all Trigger Status
Resources. If it implements these filtered collections, the dCDN Resources. These filtered collections are optional-to-implement but,
MUST include links to them in the collection of all triggers. The if implemented, the dCDN MUST include links to them in the collection
filtered collections are: of all Trigger Status Resources. The filtered collections are:
o Pending - Trigger Status Resources for triggers that have been o Pending - Trigger Status Resources for CI/T Trigger Commands that
accepted, but not yet acted upon. have been accepted, but not yet acted upon.
o Active - Trigger Status Resources for triggered activity that is o Active - Trigger Status Resources for CI/T Trigger Commands that
currently being processed in the dCDN. are currently being processed in the dCDN.
o Complete - Trigger Status Resources representing activity that o Complete - Trigger Status Resources representing activity that
completed successfully and 'processed' triggers for which no completed successfully, and 'processed' CI/T Trigger Commands for
further status updates will be made by the dCDN. which no further status updates will be made by the dCDN.
o Failed - Trigger Status Resources representing activity that o Failed - Trigger Status Resources representing CI/T Commands that
failed or was cancelled by the uCDN. failes or were cancelled by the uCDN.
4. CDNI Trigger Interface 4. CDNI Trigger Interface
This section describes an interface to enable an upstream CDN to This section describes an interface to enable an upstream CDN to
trigger activity in a downstream CDN. trigger activity in a downstream CDN.
Requests are made over HTTP, and the HTTP Method defines the The CI/T interface builds on top of HTTP, so dCDNs may make use of
operation the request would like to perform. The corresponding HTTP any HTTP feature when implementing the CI/T interface. For example,
Response returns the status of the operation in the HTTP Status Code a dCDN SHOULD make use of HTTP's caching mechanisms to indicate that
and returns the current representation of the resource (if a requested response/representation has not been modified, reducing
appropriate) in the Response Body. HTTP Responses from dCDNs the uCDN's processing needed to determine whether the status of
implementing CI/T that contain a response body SHOULD include an ETag triggered activity has changed.
to enable validation of cached versions of returned resources.
All dCDNs implementing CI/T MUST support the HTTP GET, HEAD, POST and All dCDNs implementing CI/T MUST support the HTTP GET, HEAD, POST and
DELETE methods as defined in [RFC7231]. The only representation DELETE methods as defined in [RFC7231].
specified in this document is JSON, [RFC7159].
The only representation specified in this document is JSON,
[RFC7159]. It MUST be supported by the uCDN and by the dCDN.
The URL of the dCDN's collection of all Trigger Status Resources The URL of the dCDN's collection of all Trigger Status Resources
needs to be either discovered by, or configured in, the uCDN. The needs to be either discovered by, or configured in, the uCDN. The
mechanism for discovery of that URL is outside the scope of this mechanism for discovery of that URL is outside the scope of this
document. document.
CI/T Commands are POSTed to the dCDN's collection of all Trigger CI/T Commands are POSTed to the dCDN's collection of all Trigger
Status Resources. If a command to create a new trigger is accepted Status Resources. If a CI/T Trigger Command is accepted by the dCDN,
by the dCDN, it creates a new Trigger Status Resource and returns its the dCDN creates a new Trigger Status Resource and returns its URI to
URI to the dCDN in an HTTP 201 response. The triggered activity can the uCDN in an HTTP 201 response. The triggered activity can then be
then be monitored by the uCDN using that resource and the collections monitored by the uCDN using that resource and the collections
described in Section 3. described in Section 3.
The URI of each Trigger Status Resource is returned to the uCDN when The URI of each Trigger Status Resource is returned to the uCDN when
it is created. This means all Trigger Status Resources can be it is created, and URIs of all Trigger Status Resources are listed in
discovered, so dCDNs are free to assign whatever structure they the dCDN's collection of all Trigger Status Resources. This means
desire to the URIs for CI/T resources. Therefore uCDNs MUST NOT make all Trigger Status Resources can be discovered by the uCDN, so dCDNs
any assumptions regarding the structure of CI/T URIs or the mapping are free to assign whatever structure they desire to the URIs for CI/
between CI/T objects and their associated URIs. URIs present in the T resources. Therefore uCDNs MUST NOT make any assumptions regarding
examples in this document are purely illustrative and are not the structure of CI/T URIs or the mapping between CI/T objects and
intended to impose a definitive structure on CI/T interface their associated URIs. URIs present in the examples in this document
implementations. are purely illustrative and are not intended to impose a definitive
structure on CI/T interface implementations.
The CI/T interface builds on top of HTTP, so dCDNs may make use of
any HTTP feature when implementing the CI/T interface. For example,
a dCDN SHOULD make use of HTTP's caching mechanisms to indicate that
a requested response/representation has not been modified, reducing
the uCDN's processing needed to determine whether the status of
triggered activity has changed.
The dCDN MUST ensure that activity triggered by the uCDN only affects
metadata or content originating from that uCDN.
4.1. Creating Triggers 4.1. Creating Triggers
To create a new trigger, the uCDN makes an HTTP POST to the dCDN's To issue a CI/T Command, the uCDN makes an HTTP POST to the dCDN's
collection of all of the uCDN's Trigger Status Resources. The collection of all of the uCDN's Trigger Status Resources. The
request body of that POST is a CI/T Command with a "trigger", as request body of that POST is a CI/T Command, as described in
described in Section 5.1.1. Section 5.1.1.
The dCDN validates and authenticates that request, if it is malformed The dCDN validates and authenticates that CI/T Command, if it is
or the uCDN does not have sufficient access rights it MUST either malformed or the uCDN does not have sufficient access rights it MUST
respond with an appropriate 4xx HTTP error code and a resource MUST either respond with an appropriate 4xx HTTP error code and a Trigger
NOT be created on the dCDN, or create a 'failed' Trigger Status Status Resource MUST NOT be created on the dCDN, or create a 'failed'
Resource containing an appropriate error description. Trigger Status Resource containing an appropriate error description.
If the request is accepted, the uCDN MUST create a new Trigger Status When a CI/T Trigger Command is accepted, the uCDN MUST create a new
Resource. The HTTP response to the dCDN MUST have status code 201 Trigger Status Resource which will convey a specification of the CI/T
and the URI of the Trigger Status Resource in the Location header Command and its current status. The HTTP response to the dCDN MUST
field. The HTTP response SHOULD include the content of the newly have status code 201 and MUST convey the URI of the Trigger Status
created Trigger Status Resource, this is recommended particularly in Resource in the Location header field. The HTTP response SHOULD
cases where the trigger has completed immediately. include the content of the newly created Trigger Status Resource,
this is recommended particularly in cases where the CI/T Trigger
Command has completed immediately.
Once a Trigger Status Resource has been created the dCDN MUST NOT re- Once a Trigger Status Resource has been created the dCDN MUST NOT re-
use its location, even after that resource has been removed. use its URI, even after that Trigger Status Resource has been
removed.
The "trigger" property of the Trigger Status Resource contains the
Trigger Specification posted in the body of the CI/T Command. Note
that this need not be a byte-for-byte copy. For example, in the JSON
representation the dCDN may re-serialise the information differently.
If the dCDN is not able to track the execution of triggered activity, The dCDN SHOULD track and report on progress of CI/T Trigger
it MUST indicate that it has accepted the request but will not be Commands. If the dCDN is not able to do that, it MUST indicate that
providing further status updates. To do this, it sets the "status" it has accepted the request but will not be providing further status
of the Trigger Status Resource to "processed". In this case, CI/T updates. To do this, it sets the "status" of the Trigger Status
processing should continue as for a "complete" request, so the Resource to "processed". In this case, CI/T processing should
Trigger Status Resource MUST be added to the dCDN's collection of continue as for a "complete" request, so the Trigger Status Resource
Complete Triggers. The dCDN SHOULD also provide an estimated MUST be added to the dCDN's collection of Complete Trigger Status
completion time for the request, by using the "etime" property of the Resources. The dCDN SHOULD also provide an estimated completion time
Trigger Status Resource. This will allow the uCDN to schedule for the request, by using the "etime" property of the Trigger Status
prepositioning after an earlier delete of the same URLs is expected Resource. This will allow the uCDN to schedule prepositioning after
to have finished. an earlier delete of the same URLs is expected to have finished.
If the dCDN is able to track the execution of triggered activity, the If the dCDN is able to track the execution of CI/T Commands and a CI/
trigger is queued by the dCDN for later action, the "status" property T Command is queued by the dCDN for later action, the "status"
of the Trigger Status Resource MUST be "pending". Once trigger property of the Trigger Status Resource MUST be "pending". Once
processing has started the "status" MUST be "active". Finally, once processing has started the "status" MUST be "active". Finally, once
the triggered activity is complete, the trigger status MUST be set to the CI/T Command is complete, the status MUST be set to "complete" or
"complete" or "failed". "failed".
A trigger may result in no activity in the dCDN if, for example, it A CI/T Trigger Command may result in no activity in the dCDN if, for
is an invalidate or purge request for data the dCDN has not yet example, it is an invalidate or purge request for data the dCDN has
acquired, or a prepopulate request for data it has already acquired not yet acquired, or a prepopulate request for data it has already
and which is still valid. In this case, the "status" of the Trigger acquired and which is still valid. In this case, the "status" of the
Status Resource MUST be "processed" or "complete", and the Trigger Trigger Status Resource MUST be "processed" or "complete", and the
Status Resource MUST be added to the dCDN's collection of Complete Trigger Status Resource MUST be added to the dCDN's collection of
Triggers. Complete Trigger Status Resources.
Once created, Trigger Status Resources can be cancelled or deleted by Once created, Trigger Status Resources can be cancelled or deleted by
the uCDN, but not modified. The dCDN MUST reject PUT and POST the uCDN, but not modified. The dCDN MUST reject PUT and POST
requests from the uCDN to Trigger Status Resources by responding with requests from the uCDN to Trigger Status Resources by responding with
an appropriate HTTP status code. an appropriate HTTP status code.
4.2. Checking Status 4.2. Checking Status
The uCDN has two ways to check progress of activity it has triggered The uCDN has two ways to check progress of CI/T Commands it has
in the dCDN, described in sections Section 4.2.1 and Section 4.2.2. issued to the dCDN, described in sections Section 4.2.1 and
Section 4.2.2.
To check for change in status of a resource or collection of To check for change in status of a Trigger Status Resource or
resources without re-fetching the whole resource or collection, collection of Trigger Status Resources without re-fetching the whole
Entity Tags SHOULD be included by the dCDN for the uCDN to use as Resource or Collection, Entity Tags SHOULD be included by the dCDN
cache validators, as defined in [RFC7232]. for the uCDN to use as cache validators, as defined in [RFC7232].
The dCDN SHOULD use the cache control headers for responses to GETs The dCDN SHOULD use the cache control headers for responses to GETs
for Trigger Status Resources and Collections to indicate the for Trigger Status Resources and Collections to indicate the
frequency at which it recommends the uCDN should poll for change. frequency at which it recommends the uCDN should poll for change.
4.2.1. Polling Trigger Status Resource collections 4.2.1. Polling Trigger Status Resource collections
The uCDN can fetch the collection of its Trigger Status Resources, or The uCDN can fetch the collection of its Trigger Status Resources, or
filtered views of that collection. filtered views of that collection.
This makes it possible to poll status of all triggered activity in a This makes it possible to poll status of all CI/T Trigger Commands in
single request. If the dCDN moves a Trigger Status Resource from the a single request. If the dCDN moves a Trigger Status Resource from
Active to the Completed collection, the uCDN can fetch the result of the Active to the Completed collection, the uCDN can fetch the result
that activity. of that activity.
When polling in this way, the uCDN SHOULD use HTTP Entity Tags to When polling in this way, the uCDN SHOULD use HTTP Entity Tags to
monitor for change, rather than repeatedly fetching the whole monitor for change, rather than repeatedly fetching the whole
collection. collection.
4.2.2. Polling Trigger Status Resources 4.2.2. Polling Trigger Status Resources
The uCDN has a URI provided by the dCDN for each Trigger Status The uCDN has a URI provided by the dCDN for each Trigger Status
Resource it has created, it may fetch that resource at any time. Resource it has created, it may fetch that Trigger Status Resource at
any time.
This can be used to retrieve progress information, and to fetch the This can be used to retrieve progress information, and to fetch the
result of triggered activity. result of the CI/T Command.
When polling in this way, the uCDN SHOULD use HTTP Entity Tags to When polling in this way, the uCDN SHOULD use HTTP Entity Tags to
monitor for change, rather than repeatedly fetching the Trigger monitor for change, rather than repeatedly fetching the Trigger
Status Resource. Status Resource.
4.3. Cancelling Triggers 4.3. Cancelling Triggers
The uCDN can request cancellation of a trigger by POSTing a Trigger The uCDN can request cancellation of a CI/T Trigger Command by
"cancel" Command to the collection of all triggers. POSTing a CI/T Cancel Command to the collection of all Trigger Status
Resources.
The uCDN should respond to that command appropriately, for example Cancellation of a CI/T Trigger Command is optional-to-implement in
with HTTP status code 200 "OK" if the cancellation has been processed the dCDN.
and the trigger is inactive, 202 "Accepted" if the command has been
accepted but the trigger remains active, or 403 "Forbidden" if The dCDN MUST respond to the CI/T Cancel Command appropriately, for
cancellation is not supported by the dCDN. example with HTTP status code 200 "OK" if the cancellation has been
processed and the CI/T Command is inactive, 202 "Accepted" if the
command has been accepted but the CI/T Command remains active, or 403
"Forbidden" if cancellation is not supported by the dCDN.
If cancellation of a "pending" Trigger Status Resource is accepted by If cancellation of a "pending" Trigger Status Resource is accepted by
the dCDN, the dCDN SHOULD NOT start processing of that activity. the dCDN, the dCDN SHOULD NOT start processing of that activity.
Cancelling a "pending" trigger does not however guarantee that not Issuing a CT/T cancel command for a "pending" Trigger Status Resource
activity is started, because the uCDN cannot control the timing of does not however guarantee that the corresponding activity will not
that activity. Processing could, for example, start after the POST be started, because the uCDN cannot control the timing of that
is sent by the uCDN but before that request is processed by the dCDN. activity. Processing could, for example, start after the POST is
sent by the uCDN but before that request is processed by the dCDN.
If cancellation of an "active" or "processed" Trigger Status Resource If cancellation of an "active" or "processed" Trigger Status Resource
is accepted by the dCDN, the dCDN SHOULD stop processing the is accepted by the dCDN, the dCDN SHOULD stop processing the CI/T
triggered activity. However, as with cancellation of a "pending" Command. However, as with cancellation of a "pending" CI/T Command,
trigger, the dCDN does not guarantee this. the dCDN does not guarantee this.
If the triggered activity cannot be stopped immediately, the If the CI/T Command cannot be stopped immediately, the status in the
trigger's status MUST be set to "cancelling" and the Trigger Status corresponding Trigger Status Resource MUST be set to "cancelling",
Resource remains in the collection of active triggers. If processing and the Trigger Status Resource MUST remain in the collection of
is stopped before normal completion, the trigger's status MUST be set Trigger Status Resources for active CI/T Commands. If processing is
to "cancelled" and included in the collection of failed triggers. stopped before normal completion, the status value in the Trigger
Status Resource MUST be set to "cancelled", and the Trigger Status
Resource MUST be included in the collection of failed CT/T Trigger
Commands.
Cancellation of a "complete" or "failed" Trigger Status Resource Cancellation of a "complete" or "failed" Trigger Status Resource
requires no processing in the dCDN, its status MUST NOT be changed to requires no processing in the dCDN, its status MUST NOT be changed to
"cancelled". "cancelled".
4.4. Deleting Triggers 4.4. Deleting Triggers
The uCDN can delete Trigger Status Resources at any time, using the The uCDN can delete Trigger Status Resources at any time, using the
HTTP DELETE method. The effect is similar to cancellation, but no HTTP DELETE method. The effect is similar to cancellation, but no
Trigger Status Resource remains afterwards. Trigger Status Resource remains afterwards.
Once deleted, the references to a Trigger Status Resource MUST be Once deleted, the references to a Trigger Status Resource MUST be
removed from all Trigger Status Resource collections. Subsequent removed from all Trigger Status Resource collections. Subsequent
requests to GET the deleted resource SHOULD fail. requests to GET the deleted Trigger Status Resource SHOULD be
rejected by the dCDN with an HTTP error.
If a "pending" Trigger Status Resource is deleted, the dCDN SHOULD If a "pending" Trigger Status Resource is deleted, the dCDN SHOULD
NOT start processing of that activity. Deleting a "pending" trigger NOT start processing of that activity. Deleting a "pending" Trigger
does not however guarantee that it has not started because the uCDN Status Resource does not however guarantee that it has not started
cannot control the timing of that activity. Processing may, for because the uCDN cannot control the timing of that activity.
example, start after the DELETE is sent by the uCDN but before that Processing may, for example, start after the DELETE is sent by the
request is processed by the dCDN. uCDN but before that request is processed by the dCDN.
If an "active" or "processed" Trigger Status Resource is deleted, the If an "active" or "processed" Trigger Status Resource is deleted, the
dCDN MAY stop processing the triggered activity. However, as with dCDN SHOULD stop processing the CI/T Command. However, as with
deletion of a "pending" trigger, the dCDN does not guarantee this. deletion of a "pending" Trigger Status Resource, the dCDN does not
guarantee this.
Deletion of a "complete" or "failed" Trigger Status Resource requires Deletion of a "complete" or "failed" Trigger Status Resource requires
no processing in the dCDN other than deletion of the resource. no processing in the dCDN other than deletion of the Trigger Status
Resource.
4.5. Expiry of Trigger Status Resources 4.5. Expiry of Trigger Status Resources
The dCDN can choose to automatically delete Trigger Status Resources The dCDN can choose to automatically delete Trigger Status Resources
some time after they become "complete", "processed", "failed" or some time after they become "complete", "processed", "failed" or
"cancelled". In this case, the dCDN will remove the resource and "cancelled". In this case, the dCDN will remove the Trigger Status
respond to subsequent requests for it with an HTTP error. Resource and respond to subsequent requests for it with an HTTP
error.
If the dCDN performs this housekeeping, it MUST have reported the If the dCDN performs this housekeeping, it MUST have reported the
length of time after which completed Trigger Status Resources will be length of time after which completed Trigger Status Resources will be
deleted via a property of the collection of all Trigger Status deleted via a property of the collection of all Trigger Status
Resources. It is recommended that Trigger Status Resources are not Resources. It is RECOMMENDED that Trigger Status Resources are not
automatically deleted for at least 24 hours after they become automatically deleted by the dCDN for at least 24 hours after they
"complete", "processed", "failed" or "cancelled". become "complete", "processed", "failed" or "cancelled".
To ensure it is able to get the status of its completed and failed To ensure it is able to get the status of its Trigger Status
triggers, it is recommended that the uCDN's polling interval is less Resources for completed and failed CI/T Commands, it is RECOMMENDED
than the time after which records for completed activity will be that the uCDN polling interval is less than the time after which
deleted. records for completed activity will be deleted.
4.6. Loop Detection and Prevention 4.6. Loop Detection and Prevention
Given three CDNs, A, B and C. If CDNs B and C delegate delivery of Given three CDNs, A, B and C. If CDNs B and C delegate delivery of
CDN A's content to each other, CDN A's triggers could be passed CDN A's content to each other, CDN A's CI/T Commands could be passed
between CDNs B and C in a loop. More complex networks of CDNs could between CDNs B and C in a loop. More complex networks of CDNs could
contain similar loops involving more hops. contain similar loops involving more hops.
In order to prevent and detect such CI/T loops, each CDN uses a CDN In order to prevent and detect such CI/T loops, each CDN uses a CDN
Provider ID to uniquely identify itself. Each CDN MUST insert its Provider ID to uniquely identify itself. Each CDN MUST insert its
CDN Provider ID into the cdn-path key of every CI/T Command it CDN Provider ID into the cdn-path key of every CI/T Command it
originates or cascades. When receiving CI/T commands a dCDN MUST originates or cascades. When receiving CI/T Commands a dCDN MUST
check the cdn-path and reject any CI/T Command which already contains check the cdn-path and reject any CI/T Command which already contains
its own CDN Provider ID in the cdn-path. Transit CDNs MUST check the its own CDN Provider ID in the cdn-path. Transit CDNs MUST check the
cdn-path and not cascade the CI/T Command to dCDNs that are already cdn-path and not cascade the CI/T Command to dCDNs that are already
listed in cdn-path. listed in cdn-path.
The CDN Provider Id consists of the characters AS followed by the CDN The CDN Provider Id consists of the two characters "AS" followed by
Provider's AS number, then a colon (':') and an additional qualifier the CDN Provider's Autonomous System number, then a colon (':') and
that is used to guarantee uniqueness in case a particular AS has an additional qualifier that is used to guarantee uniqueness in case
multiple independent CDNs deployed. For example "AS64496:0". a particular AS has multiple independent CDNs deployed. For example
"AS64496:0".
If the CDN provider has multiple Autonomous Systems, the same AS
number SHOULD be used in all messages from that CDN provider, unless
there are multiple distinct CDNs.
If the RI interface described in [I-D.ietf-cdni-redirection] is If the RI interface described in [I-D.ietf-cdni-redirection] is
implemented by the dCDN, the CI/T and RI interfaces SHOULD use the implemented by the dCDN, the CI/T and RI interfaces SHOULD use the
same CDN Provider Id. same CDN Provider Id.
4.7. Error Handling 4.7. Error Handling
A dCDN can reject a CI/T Command using HTTP status codes. For A dCDN can signal rejection of a CI/T Command using HTTP status
example, 400 if the request is malformed, or 401 if the uCDN does not codes. For example, 400 if the request is malformed, or 401 if the
have permission to create triggers or it is trying to act on another uCDN does not have permission to issue CI/T Commands or it is trying
CDN's data. to act on another CDN's data.
If any part of the trigger fails, the trigger SHOULD be reported as If any part of the CI/T Trigger Command fails, the trigger SHOULD be
"failed" once its activity is complete or if no further errors will reported as "failed" once its activity is complete or if no further
be reported. The "errors" property in the Trigger Status Resource errors will be reported. The "errors" property in the Trigger Status
will be used to enumerate which actions failed and the reasons for Resource will be used to enumerate which actions failed and the
failure, and can be present while the trigger is still "pending" or reasons for failure, and can be present while the Trigger Status
"active", if the trigger is still running for some URLs or Patterns Resource is still "pending" or "active", if the CI/T Trigger Command
in the Trigger Specification. is still running for some URLs or Patterns in the Trigger
Specification.
Once a request has been accepted, processing errors are reported in Once a request has been accepted, processing errors are reported in
the Trigger Status Resource using a list of Error Descriptions. Each the Trigger Status Resource using a list of Error Descriptions. Each
Error Description is used to report errors against one or more of the Error Description is used to report errors against one or more of the
URLs or Patterns in the Trigger Specification. URLs or Patterns in the Trigger Specification.
If a surrogate affected by a trigger is offline in the dCDN, or the If a surrogate affected by a CI/T Trigger Command is offline in the
dCDN is unable to pass a CI/T Command on to any of its cascaded dCDN, or the dCDN is unable to pass a CI/T Command on to any of its
dCDNs: cascaded dCDNs:
o If the request is abandoned by the dCDN, the dCDN SHOULD report an o If the CI/T Command is abandoned by the dCDN, the dCDN SHOULD
error. report an error.
o An "invalidate" trigger may be reported as "complete" when o A CI/T "invalidate" command may be reported as "complete" when
surrogates that may have the data are offline. In this case, surrogates that may have the data are offline. In this case,
surrogates MUST NOT use the affected data without first surrogates MUST NOT use the affected data without first
revalidating it when they are back online. revalidating it when they are back online.
o "preposition" and "purge" triggers can be reported as "processed" o CI/T "preposition" and "purge" commands can be reported as
if affected caches are offline and the activity will complete when "processed" if affected caches are offline and the activity will
they return to service. complete when they return to service.
o Otherwise, the dCDN SHOULD keep the trigger in state "pending" or o Otherwise, the dCDN SHOULD keep the Trigger Status Resource in
"active" until the trigger is acted upon, or the uCDN chooses to state "pending" or "active" until the CI/T Command is acted upon,
cancel it. or the uCDN chooses to cancel it.
4.8. Content URLs 4.8. Content URLs
To refer to content in the dCDN, the uCDN MUST present URLs in the To refer to content in the dCDN, the uCDN MUST present URLs in the
same form as in the metadata it supplied to the dCDN. By definition, same form as in the metadata it supplied to the dCDN. By definition,
it is always possible for the dCDN to locate content based on URLs in it is always possible for the dCDN to locate content based on URLs in
this form. this form.
Therefore, if content URLs are transformed by an intermediate CDN in Therefore, if content URLs are transformed by an intermediate CDN in
a cascade, that intermediate CDN MUST transform URLs in CI/T commands a cascade, that intermediate CDN MUST transform URLs in CI/T Commands
it passes to its dCDN. it passes to its dCDN.
When processing Trigger Specifications, CDNs MUST ignore the URL When processing Trigger Specifications, CDNs MUST ignore the URL
scheme (http or https) in comparing URLs. For example, for an scheme (http or https) in comparing URLs. For example, for a CI/T
invalidate or purge trigger, content MUST be invalidated or purged invalidate or purge command, content MUST be invalidated or purged
regardless of the protocol clients use to request it. regardless of the protocol clients use to request it.
5. CI/T Object Properties and Encoding 5. CI/T Object Properties and Encoding
CI/T Commands, Trigger Status Resources and Trigger Collections and CI/T Commands, Trigger Status Resources and Trigger Collections and
their properties are encoded using JSON, as defined in sections their properties are encoded using JSON, as defined in sections
Section 5.1.1, Section 5.2.1, and Section 5.1.2. Section 5.1.1, Section 5.2.1, and Section 5.1.2.
Names in JSON are case sensitive and therefore the names and literal Names in JSON are case sensitive. The names and literal values
values specified here MUST always use lower-case. specified in the present document MUST always use lower-case.
Unrecognised name/value pairs in JSON objects SHOULD NOT be treated Unrecognised name/value pairs in JSON objects SHOULD NOT be treated
as an error by either the uCDN or dCDN. as an error by either the uCDN or dCDN. They SHOULD be ignored in
the processing, and passed on by dCDN to any further dCDNs in a
cascade.
5.1. CI/T Objects 5.1. CI/T Objects
The top-level objects defined by the CI/T interface are described in The top-level objects defined by the CI/T interface are described in
this section. Each has an associated MIME Media Type. The encoding this section. Each has an associated MIME Media Type. The encoding
of values used by these objects is described in Section 5.2. of values used by these objects is described in Section 5.2.
5.1.1. CI/T Commands 5.1.1. CI/T Commands
CI/T Commands SHOULD use a MIME Media Type of application/ CI/T Commands SHOULD use a MIME Media Type of application/
skipping to change at page 15, line 4 skipping to change at page 15, line 44
Description: A specification of the trigger type, and a set of Description: A specification of the trigger type, and a set of
data to act upon. data to act upon.
Value: A Trigger Specification, as defined in Section 5.2.1. Value: A Trigger Specification, as defined in Section 5.2.1.
Mandatory: No, but exactly one of "trigger" or "cancel" MUST be Mandatory: No, but exactly one of "trigger" or "cancel" MUST be
present in a CI/T Command. present in a CI/T Command.
Name: cancel Name: cancel
Description: The URLs of Trigger Status Resources for triggers
that the uCDN wants to cancel. Description: The URLs of Trigger Status Resources for CI/T
Trigger Commands that the uCDN wants to cancel.
Value: A JSON array of URLs represented as JSON strings. Value: A JSON array of URLs represented as JSON strings.
Mandatory: No, but exactly one of "trigger" or "cancel" MUST be Mandatory: No, but exactly one of "trigger" or "cancel" MUST be
present in a CI/T Command. present in a CI/T Command.
Name: cdn-path Name: cdn-path
Description: The CDN Provider Identifiers of CDNs that have Description: The CDN Provider Identifiers of CDNs that have
already accepted the CI/T Command. already accepted the CI/T Command.
skipping to change at page 15, line 32 skipping to change at page 16, line 25
5.1.2. Trigger Status Resource 5.1.2. Trigger Status Resource
Trigger Status Resources SHOULD use a MIME Media Type of application/ Trigger Status Resources SHOULD use a MIME Media Type of application/
cdni.ci.TriggerStatus+json. cdni.ci.TriggerStatus+json.
A Trigger Status Resource is encoded as a JSON object containing the A Trigger Status Resource is encoded as a JSON object containing the
following name/value pairs. following name/value pairs.
Name: trigger Name: trigger
Description: The Trigger Specification that was used to create Description: The Trigger Specification posted in the body of
this Trigger Status Resource. the CI/T Command. Note that this need not be a byte-for-byte
copy. For example, in the JSON representation the dCDN may re-
serialise the information differently.
Value: A Trigger Specification, as defined in Section 5.2.1. Value: A Trigger Specification, as defined in Section 5.2.1.
Mandatory: Yes Mandatory: Yes
Name: ctime Name: ctime
Description: Time at which the CI/T Command was received by the Description: Time at which the CI/T Command was received by the
dCDN. Time is determined by the dCDN, there is no requirement dCDN. Time is determined by the dCDN, there is no requirement
to synchronise clocks between interconnected CDNs. to synchronise clocks between interconnected CDNs.
skipping to change at page 17, line 4 skipping to change at page 17, line 43
5.1.3. Trigger Collection 5.1.3. Trigger Collection
Trigger Collections SHOULD use a MIME Media Type of application/ Trigger Collections SHOULD use a MIME Media Type of application/
cdni.ci.TriggerCollection+json. cdni.ci.TriggerCollection+json.
A Trigger Collection is encoded as a JSON object containing the A Trigger Collection is encoded as a JSON object containing the
following name/value pairs. following name/value pairs.
Name: triggers Name: triggers
Description: Links to Trigger Status Resources in the Description: Links to Trigger Status Resources in the
collection. collection.
Value: A JSON array of URLs represented as JSON strings. Value: A JSON array of URLs represented as JSON strings.
Mandatory: Yes Mandatory: Yes
Name: staleresourcetime Name: staleresourcetime
Description: The length of time for which the dCDN guarantees Description: The length of time for which the dCDN guarantees
to keep a completed Trigger Status Resource. After this time, to keep a completed Trigger Status Resource. After this time,
the dCDN SHOULD delete the resource and all references to it the dCDN SHOULD delete the Trigger Status Resource and all
from collections. references to it from collections.
Value: A JSON number, integer time in seconds. Value: A JSON number, integer time in seconds.
Mandatory: Yes, in the collection of all Trigger Status Mandatory: Yes, in the collection of all Trigger Status
Resources if the dCDN deletes stale entries. If the property Resources if the dCDN deletes stale entries. If the property
is present in the filtered collections, it MUST have the same is present in the filtered collections, it MUST have the same
value as in the collection of all Trigger Status Resources. value as in the collection of all Trigger Status Resources.
Names: coll-all, coll-pending, coll-active, coll-complete, coll- Names: coll-all, coll-pending, coll-active, coll-complete, coll-
failed failed
Description: Link to a Trigger Collection. Description: Link to a Trigger Collection.
Value: A URL represented as a JSON string. Value: A URL represented as a JSON string.
Mandatory: Links to filtered collections are mandatory in the Mandatory: Links to all of the filtered collections are
collection of all Trigger Status Resources, if the dCDN mandatory in the collection of all Trigger Status Resources, if
implements the filtered collections. Otherwise, optional. the dCDN implements the filtered collections. Otherwise,
optional.
Name: cdn-id Name: cdn-id
Description: The CDN Provider Identifier of the dCDN. Description: The CDN Provider Identifier of the dCDN.
Value: A JSON string, the dCDN's CDN Provider Identifier, as Value: A JSON string, the dCDN's CDN Provider Identifier, as
defined in Section 4.6. defined in Section 4.6.
Mandatory: Only in the collection of all Trigger Status Mandatory: Only in the collection of all Trigger Status
Resources, if the dCDN implements the filtered collections. Resources, if the dCDN implements the filtered collections.
Optional in the filtered collections. Optional in the filtered collections (the uCDN can always find
the dCDN's cdn-id in the collection of all Trigger Status
Resources, but the dCDN can choose to repeat that information
in its implementation of filtered collections).
5.2. Properties of CI/T Objects 5.2. Properties of CI/T Objects
This section defines the values that can appear in the top level This section defines the values that can appear in the top level
objects described in Section 5.1, and their encodings. objects described in Section 5.1, and their encodings.
5.2.1. Trigger Specification 5.2.1. Trigger Specification
A Trigger Collection is encoded as a JSON object containing the A Trigger Collection is encoded as a JSON object containing the
following name/value pairs. following name/value pairs.
An unrecognised name/value pair in the Trigger Specification object An unrecognised name/value pair in the Trigger Specification object
contained in a CI/T Command SHOULD be preserved in the Trigger contained in a CI/T Command SHOULD be preserved in the Trigger
Specification of any Trigger Status Resource it creates. Specification of any Trigger Status Resource it creates.
Name: type Name: type
Description: This property defines the type of the trigger. Description: This property defines the type of the CI/T Trigger
Command.
Value: Trigger Type, as defined in Section 5.2.2. Value: Trigger Type, as defined in Section 5.2.2.
Mandatory: Yes Mandatory: Yes
Name: metadata.urls Name: metadata.urls
Description: The uCDN URLs of the metadata the trigger applies Description: The uCDN URLs of the metadata the CI/T Trigger
to. Command applies to.
Value: A JSON array of URLs represented as JSON strings. Value: A JSON array of URLs represented as JSON strings.
Mandatory: No, but at least one of 'metadata.*' or 'content.*' Mandatory: No, but at least one of 'metadata.*' or 'content.*'
MUST be present and non-empty. MUST be present and non-empty.
Name: content.urls Name: content.urls
Description: URLs of content the trigger applies to, see Description: URLs of content the CI/T Trigger Command applies
Section 4.8. to, see Section 4.8.
Value: A JSON array of URLs represented as JSON strings. Value: A JSON array of URLs represented as JSON strings.
Mandatory: No, but at least one of 'metadata.*' or 'content.*' Mandatory: No, but at least one of 'metadata.*' or 'content.*'
MUST be present and non-empty. MUST be present and non-empty.
Name: content.ccid Name: content.ccid
Description: The Content Collection Identifier of content the Description: The Content Collection Identifier of content the
trigger applies to. The 'ccid' is a grouping of content, as trigger applies to. The 'ccid' is a grouping of content, as
skipping to change at page 19, line 45 skipping to change at page 20, line 41
| preposition | A request for the dCDN to acquire metadata or | | preposition | A request for the dCDN to acquire metadata or |
| | content. | | | content. |
| invalidate | A request for the dCDN to invalidate metadata or | | invalidate | A request for the dCDN to invalidate metadata or |
| | content. After servicing this request the dCDN will | | | content. After servicing this request the dCDN will |
| | not use the specified data without first re- | | | not use the specified data without first re- |
| | validating it using, for example, an "If-None- | | | validating it using, for example, an "If-None- |
| | Match" HTTP request. The dCDN need not erase the | | | Match" HTTP request. The dCDN need not erase the |
| | associated data. | | | associated data. |
| purge | A request for the dCDN to erase metadata or | | purge | A request for the dCDN to erase metadata or |
| | content. After servicing the request, the specified | | | content. After servicing the request, the specified |
| | data MUST NOT be held on the dCDN. | | | data MUST NOT be held on the dCDN (the dCDN should |
| | re-acquire the metadata or content from uCDN if it |
| | needs it). |
+-------------+-----------------------------------------------------+ +-------------+-----------------------------------------------------+
5.2.3. Trigger Status 5.2.3. Trigger Status
This describes the current status of a Trigger. It MUST be one of This describes the current status of a Trigger. It MUST be one of
the JSON strings in the following table: the JSON strings in the following table:
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| JSON | Description | | JSON | Description |
| String | | | String | |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| pending | The trigger has not yet been acted upon. | | pending | The CI/T Trigger Command has not yet been acted |
| active | The trigger is currently being acted upon. | | | upon. |
| complete | The triggered activity completed successfully. | | active | The CI/T Trigger Command is currently being acted |
| processed | The trigger has been accepted and no further status | | | upon. |
| | update will be made (can be used in cases where | | complete | The CI/T Trigger Command completed successfully. |
| | completion cannot be confirmed). | | processed | The CI/T Trigger Command has been accepted and no |
| failed | The triggered activity could not be completed. | | | further status update will be made (can be used in |
| cancelling | The triggered activity is still in progress, but the | | | cases where completion cannot be confirmed). |
| | trigger has been cancelled by the uCDN. | | failed | The CI/T Trigger Command could not be completed. |
| cancelled | The triggered activity was cancelled by the uCDN. | | cancelling | Processing of the CI/T Trigger Command is still in |
| | progress, but the CI/T Trigger Command has been |
| | cancelled by the uCDN. |
| cancelled | The CI/T Trigger Command was cancelled by the uCDN. |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
5.2.4. PatternMatch 5.2.4. PatternMatch
A Pattern Match consists of a string pattern to match, and flags A Pattern Match consists of a string pattern to match, and flags
describing the type of match. describing the type of match.
It is encoded as a JSON object with the following name/value pairs: It is encoded as a JSON object with the following name/value pairs:
Name: pattern Name: pattern
skipping to change at page 21, line 24 skipping to change at page 22, line 26
"pattern": "http://www.example.com/trailers/*", "pattern": "http://www.example.com/trailers/*",
"case-sensitive": true "case-sensitive": true
} }
5.2.5. Absolute Time 5.2.5. Absolute Time
A JSON number, seconds since the UNIX epoch. A JSON number, seconds since the UNIX epoch.
5.2.6. Error Description 5.2.6. Error Description
An Error Description is used to report failure of a Trigger Command, An Error Description is used to report failure of a CI/T Command, or
or in the activity it triggered. in the activity it triggered.
Name: error Name: error
Value: Error Code, as defined in Section 5.2.7. Value: Error Code, as defined in Section 5.2.7.
Mandatory: Yes. Mandatory: Yes.
Names: metadata.urls, content.urls, metadata.patterns, Names: metadata.urls, content.urls, metadata.patterns,
content.patterns content.patterns
skipping to change at page 22, line 23 skipping to change at page 23, line 26
5.2.7. Error Code 5.2.7. Error Code
This type is used by the dCDN to report failures in trigger This type is used by the dCDN to report failures in trigger
processing. processing.
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| Error Code | Description | | Error Code | Description |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
| emeta | The dCDN was unable to acquire metadata required to | | emeta | The dCDN was unable to acquire metadata required to |
| | fulfil the request. | | | fulfil the request. |
| econtent | The dCDN was unable to acquire content (preposition | | econtent | The dCDN was unable to acquire content (CT/T |
| | triggers only). | | | preposition commands only). |
| eperm | The uCDN does not have permission to trigger the | | eperm | The uCDN does not have permission to issue the CI/T |
| | requested activity (for example, the data is owned | | | Command (for example, the data is owned by another |
| | by another CDN). | | | CDN). |
| ereject | The dCDN is not willing to fulfil the request (for | | ereject | The dCDN is not willing to fulfil the CI/T Command |
| | example, a preposition request for content at a time | | | (for example, a preposition request for content at a |
| | when the dCDN would not accept Request Routing | | | time when the dCDN would not accept Request Routing |
| | requests from the uCDN). | | | requests from the uCDN). |
| ecdn | An internal error in the dCDN or one of its | | ecdn | An internal error in the dCDN or one of its |
| | downstream CDNs. | | | downstream CDNs. |
| ecancelled | The uCDN cancelled the request. | | ecancelled | The uCDN cancelled the request. |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
6. Examples 6. Examples
The following sections provide examples of different CI/T objects The following sections provide examples of different CI/T objects
encoded as JSON. encoded as JSON.
Discovery of the triggers interface is out of scope of this document. Discovery of the triggers interface is out of scope of this document.
In an implementation, all CI/T URLs are under the control of the In an implementation, all CI/T URLs are under the control of the
dCDN. The uCDN MUST NOT attempt to ascribe any meaning to individual dCDN. The uCDN MUST NOT attempt to ascribe any meaning to individual
elements of the path. elements of the path.
In examples in this section, the URL 'http://dcdn.example.com/ In examples in this section, the URL 'http://dcdn.example.com/
triggers' is used as the location of the collection of all triggers, triggers' is used as the location of the collection of all Trigger
and the CDN Provider Id of uCDN is "AS64496:1". Status Resources, and the CDN Provider Id of uCDN is "AS64496:1".
6.1. Creating Triggers 6.1. Creating Triggers
Examples of the uCDN triggering activity in the dCDN: Examples of the uCDN triggering activity in the dCDN:
6.1.1. Preposition 6.1.1. Preposition
An example of a preposition request, a POST to the "AllTriggers" An example of a CI/T preposition command, a POST to the collection of
collection. all Trigger Status Resources.
Note that "metadata.patterns" and "content.patterns" are not allowed Note that "metadata.patterns" and "content.patterns" are not allowed
in a preposition Trigger Specification. in a preposition Trigger Specification.
REQUEST: REQUEST:
POST /triggers HTTP/1.1 POST /triggers HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: dcdn.example.com Host: dcdn.example.com
Accept: */* Accept: */*
skipping to change at page 24, line 22 skipping to change at page 25, line 22
], ],
"metadata.urls": [ "metadata.urls": [
"http://metadata.example.com/a/b/c" "http://metadata.example.com/a/b/c"
], ],
"type": "preposition" "type": "preposition"
} }
} }
6.1.2. Invalidate 6.1.2. Invalidate
An example of an invalidate request, another POST to the An example of a CI/T invalidate command, another POST to the
"AllTriggers" collection. This instructs the dCDN to re-validate the collection of all Trigger Status Resources. This instructs the dCDN
content at "http://www.example.com/a/index.html", as well as any to re-validate the content at "http://www.example.com/a/index.html",
metadata and content whose URLs are prefixed by as well as any metadata and content whose URLs are prefixed by
"http://metadata.example.com/a/b/" and "http://www.example.com/a/b/" "http://metadata.example.com/a/b/" using case-insensitive matching,
respectively, using case-insensitive matching. and "http://www.example.com/a/b/" respectively, using case-sensitive
matching.
REQUEST: REQUEST:
POST /triggers HTTP/1.1 POST /triggers HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: dcdn.example.com Host: dcdn.example.com
Accept: */* Accept: */*
Content-Type: application/cdni.ci.TriggerCommand+json Content-Type: application/cdni.ci.TriggerCommand+json
Content-Length: 384 Content-Length: 384
skipping to change at page 24, line 51 skipping to change at page 26, line 4
"metadata.patterns" : [ "metadata.patterns" : [
{ "pattern" : "http://metadata.example.com/a/b/*" } { "pattern" : "http://metadata.example.com/a/b/*" }
], ],
"content.urls" : [ "http://www.example.com/a/index.html" ], "content.urls" : [ "http://www.example.com/a/index.html" ],
"content.patterns" : [ "content.patterns" : [
{ "pattern" : "http://www.example.com/a/b/*", { "pattern" : "http://www.example.com/a/b/*",
"case-sensitive" : true "case-sensitive" : true
} }
]
]
}, },
"cdn-path" : [ "AS64496:1" ] "cdn-path" : [ "AS64496:1" ]
} }
RESPONSE: RESPONSE:
HTTP/1.1 201 Created HTTP/1.1 201 Created
Date: Sun, 31 Aug 2014 09:53:19 GMT Date: Sun, 31 Aug 2014 09:53:19 GMT
Content-Length: 551 Content-Length: 551
Content-Type: application/cdni.ci.TriggerStatus+json Content-Type: application/cdni.ci.TriggerStatus+json
skipping to change at page 25, line 44 skipping to change at page 26, line 45
{ {
"pattern": "http://metadata.example.com/a/b/*" "pattern": "http://metadata.example.com/a/b/*"
} }
], ],
"type": "invalidate" "type": "invalidate"
} }
} }
6.2. Examining Trigger Status 6.2. Examining Trigger Status
Once triggers have been created, the uCDN can check their status as Once Trigger Status Resources have been created, the uCDN can check
shown in these examples. their status as shown in these examples.
6.2.1. Collection of All Triggers 6.2.1. Collection of All Triggers
The uCDN can fetch the set of all the triggers it has created and The uCDN can fetch the collection of all Trigger Status Resources it
which have not yet been deleted or removed as expired. After has created that have not yet been deleted or removed as expired.
creation of the "preposition" and "invalidate" triggers shown above,
this collection might look as follows: After creation of the "preposition" and "invalidate" triggers shown
above, this collection might look as follows:
REQUEST: REQUEST:
GET /triggers HTTP/1.1 GET /triggers HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: dcdn.example.com Host: dcdn.example.com
Accept: */* Accept: */*
RESPONSE: RESPONSE:
skipping to change at page 26, line 36 skipping to change at page 27, line 39
"coll-complete": "/triggers/complete", "coll-complete": "/triggers/complete",
"coll-failed": "/triggers/failed", "coll-failed": "/triggers/failed",
"coll-pending": "/triggers/pending", "coll-pending": "/triggers/pending",
"staleresourcetime": 86400, "staleresourcetime": 86400,
"triggers": [ "triggers": [
"http://dcdn.example.com/triggers/0", "http://dcdn.example.com/triggers/0",
"http://dcdn.example.com/triggers/1" "http://dcdn.example.com/triggers/1"
] ]
} }
6.2.2. Filtered Collections of Triggers 6.2.2. Filtered Collections of Trigger Status Resources
The filtered collections are also available to the uCDN. Before the The filtered collections are also available to the uCDN. Before the
dCDN starts processing the two triggers shown above, both will appear dCDN starts processing the two CI/T Trigger Commands shown above,
in the collection of Pending Triggers, for example: both will appear in the collection of Pending Triggers, for example:
REQUEST: REQUEST:
GET /triggers/pending HTTP/1.1 GET /triggers/pending HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: dcdn.example.com Host: dcdn.example.com
Accept: */* Accept: */*
RESPONSE: RESPONSE:
skipping to change at page 27, line 31 skipping to change at page 28, line 31
Content-Type: application/cdni.ci.TriggerCollection+json Content-Type: application/cdni.ci.TriggerCollection+json
{ {
"staleresourcetime": 86400, "staleresourcetime": 86400,
"triggers": [ "triggers": [
"http://dcdn.example.com/triggers/0", "http://dcdn.example.com/triggers/0",
"http://dcdn.example.com/triggers/1" "http://dcdn.example.com/triggers/1"
] ]
} }
At this point, if no other triggers had been created, the other At this point, if no other Trigger Status Resources had been created,
filtered views of the triggers would be empty. For example: the other filtered views would be empty. For example:
REQUEST: REQUEST:
GET /triggers/complete HTTP/1.1 GET /triggers/complete HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: dcdn.example.com Host: dcdn.example.com
Accept: */* Accept: */*
RESPONSE: RESPONSE:
skipping to change at page 28, line 28 skipping to change at page 29, line 28
Etag: "2986340333785000363" Etag: "2986340333785000363"
Cache-Control: max-age=60 Cache-Control: max-age=60
Date: Sun, 31 Aug 2014 09:53:19 GMT Date: Sun, 31 Aug 2014 09:53:19 GMT
Content-Type: application/cdni.ci.TriggerCollection+json Content-Type: application/cdni.ci.TriggerCollection+json
{ {
"staleresourcetime": 86400, "staleresourcetime": 86400,
"triggers": [] "triggers": []
} }
6.2.3. Trigger Status Resources 6.2.3. Individual Trigger Status Resources
The Trigger Status Resources can also be examined for detail about The Trigger Status Resources can also be examined for detail about
individual triggers. For example, for the "preposition" and individual CI/T Trigger Commands. For example, for the CI/T
"invalidate" triggers from previous examples: "preposition" and "invalidate" commands from previous examples:
REQUEST: REQUEST:
GET /triggers/0 HTTP/1.1 GET /triggers/0 HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: dcdn.example.com Host: dcdn.example.com
Accept: */* Accept: */*
RESPONSE: RESPONSE:
skipping to change at page 30, line 49 skipping to change at page 31, line 49
{ {
"pattern": "http://metadata.example.com/a/b/*" "pattern": "http://metadata.example.com/a/b/*"
} }
], ],
"type": "invalidate" "type": "invalidate"
} }
} }
6.2.4. Polling for Change 6.2.4. Polling for Change
The uCDN SHOULD use the Entity Tags of collections or resources when The uCDN SHOULD use the Entity Tags of collections or Trigger Status
polling for change in status, as shown in the following examples: Resources when polling for change in status, as shown in the
following examples:
REQUEST: REQUEST:
GET /triggers/pending HTTP/1.1 GET /triggers/pending HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: dcdn.example.com Host: dcdn.example.com
Accept: */* Accept: */*
If-None-Match: "5012053611544832286" If-None-Match: "5012053611544832286"
RESPONSE: RESPONSE:
skipping to change at page 31, line 43 skipping to change at page 32, line 43
HTTP/1.1 304 Not Modified HTTP/1.1 304 Not Modified
Content-Length: 0 Content-Length: 0
Expires: Sun, 31 Aug 2014 09:54:19 GMT Expires: Sun, 31 Aug 2014 09:54:19 GMT
Server: example-server/0.1 Server: example-server/0.1
Etag: "-4765587034697674779" Etag: "-4765587034697674779"
Cache-Control: max-age=60 Cache-Control: max-age=60
Date: Sun, 31 Aug 2014 09:53:19 GMT Date: Sun, 31 Aug 2014 09:53:19 GMT
Content-Type: application/cdni.ci.TriggerStatus+json Content-Type: application/cdni.ci.TriggerStatus+json
When the triggered activity is complete, the contents of the filtered When the CI/T Trigger Command is complete, the contents of the
collections will be updated, along with their Entity Tags. For filtered collections will be updated along with their Entity Tags.
example, when the two example triggers are complete, the collections For example, when the two example CI/T Trigger Commands are complete,
of pending and complete triggers might look like: the collections of pending and complete Trigger Status Resources
might look like:
REQUEST: REQUEST:
GET /triggers/pending HTTP/1.1 GET /triggers/pending HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: dcdn.example.com Host: dcdn.example.com
Accept: */* Accept: */*
RESPONSE: RESPONSE:
skipping to change at page 33, line 31 skipping to change at page 34, line 31
Content-Type: application/cdni.ci.TriggerCollection+json Content-Type: application/cdni.ci.TriggerCollection+json
{ {
"staleresourcetime": 86400, "staleresourcetime": 86400,
"triggers": [ "triggers": [
"http://dcdn.example.com/triggers/0", "http://dcdn.example.com/triggers/0",
"http://dcdn.example.com/triggers/1" "http://dcdn.example.com/triggers/1"
] ]
} }
6.2.5. Removing a Trigger 6.2.5. Deleting Trigger Status Resources
To request the dCDN to cancel a Trigger, the uCDN can delete the The dCDN can delete completed and failed Trigger Status Resources to
Trigger Resource. It can also delete completed and failed triggers reduce the size of the collections. For example, to delete the
to reduce the size of the collections. For example, to remove the
"preposition" request from earlier examples: "preposition" request from earlier examples:
REQUEST: REQUEST:
DELETE /triggers/0 HTTP/1.1 DELETE /triggers/0 HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: dcdn.example.com Host: dcdn.example.com
Accept: */* Accept: */*
RESPONSE: RESPONSE:
HTTP/1.1 204 No Content HTTP/1.1 204 No Content
Date: Sun, 31 Aug 2014 09:53:30 GMT Date: Sun, 31 Aug 2014 09:53:30 GMT
Content-Length: 0 Content-Length: 0
Content-Type: text/html; charset=UTF-8 Content-Type: text/html; charset=UTF-8
Server: example-server/0.1 Server: example-server/0.1
This would, for example, cause the collection of completed triggers This would, for example, cause the collection of completed Trigger
shown in the example above to be updated to: Status Resources shown in the example above to be updated to:
REQUEST: REQUEST:
GET /triggers/complete HTTP/1.1 GET /triggers/complete HTTP/1.1
User-Agent: example-user-agent/0.1 User-Agent: example-user-agent/0.1
Host: dcdn.example.com Host: dcdn.example.com
Accept: */* Accept: */*
RESPONSE: RESPONSE:
skipping to change at page 39, line 11 skipping to change at page 40, line 11
Author: Rob Murray <rob.murray@alcatel-lucent.com> Author: Rob Murray <rob.murray@alcatel-lucent.com>
Change controller: IESG <iesg@ietf.org> Change controller: IESG <iesg@ietf.org>
Note: No "charset" parameter is defined for this registration because Note: No "charset" parameter is defined for this registration because
a charset parameter is not defined for application/json [RFC7159]. a charset parameter is not defined for application/json [RFC7159].
8. Security Considerations 8. Security Considerations
8.1. Authentication, Confidentiality, Integrity Protection 8.1. Authentication, Confidentiality, Integrity Protection
A CI/T dCDN server implementation MUST support TLS transport for HTTP A CI/T implementation MUST support TLS transport for HTTP (https) as
(https) as per [RFC2818]. The use of TLS for transport of the CI/T per [RFC2818]. The use of TLS for transport of the CI/T interface
interface allows the dCDN and the uCDN to authenticate each other (to allows the dCDN and the uCDN to authenticate each other (to ensure
ensure they are receiving CI/T Commands from, or reporting status to, they are receiving CI/T Commands from, or reporting status to, an
an authenticated CDN). authenticated CDN).
In an environment where any such protection is required, TLS SHOULD In an environment where any such protection is required, TLS SHOULD
be used for transport of the CI/T requests and responses, unless be used for transport of the CI/T requests and responses, unless
alternate methods are used for ensuring that only authorised clients alternate methods are used for ensuring that only authorised clients
are able to access their own data (such as setting up an IPsec tunnel are able to access their own data (such as setting up an IPsec tunnel
between the two CDNs, or using a physically secured internal network between the two CDNs, or using a physically secured internal network
between two CDNs that are owned by the same corporate entity). Both between two CDNs that are owned by the same corporate entity). Both
parties of the transaction (the uCDN and the dCDN) SHOULD use mutual parties of the transaction (the uCDN and the dCDN) SHOULD use mutual
authentication. authentication.
A TLS implementation of CI/T MUST support the A TLS implementation of CI/T MUST support the
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ([RFC5288]). An TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ([RFC5288]). An
implementation of the CI/T Interface SHOULD prefer cipher suites implementation of the CI/T Interface SHOULD prefer cipher suites
which support perfect forward secrecy over cipher suites that don't. which support perfect forward secrecy over cipher suites that don't.
HTTP requests that attempt to access or operate on CI/T data HTTP requests that attempt to access or operate on CI/T data
belonging to another CDN MUST be rejected using, for example, HTTP belonging to another CDN MUST be rejected using, for example, HTTP
"403 Forbidden" or "404 Not Found". "403 Forbidden" or "404 Not Found". This is intended to prevent
unauthorised users from generating unnecessary load in dCDN or uCDN
due to revalidation, reacquisition, or unnecessary acquisition.
Note that in a "diamond" configuration, where one uCDN's content can Note that in a "diamond" configuration, where one uCDN's content can
be acquired via more than one directly-connected uCDN, it may not be be acquired via more than one directly-connected uCDN, it may not be
possible for the dCDN to determine from which uCDN it acquired possible for the dCDN to determine from which uCDN it acquired
content. In this case, the dCDN MUST allow each uCDN from which the content. In this case, the dCDN MUST allow each uCDN from which the
content could have been acquired to act upon that content using CI/T content could have been acquired to act upon that content using CI/T
Commands. Commands.
8.2. Denial of Service 8.2. Denial of Service
skipping to change at page 40, line 36 skipping to change at page 41, line 39
[RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7231] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Semantics and Content", RFC 7231, June 2014. (HTTP/1.1): Semantics and Content", RFC 7231, June 2014.
[RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol [RFC7232] Fielding, R. and J. Reschke, "Hypertext Transfer Protocol
(HTTP/1.1): Conditional Requests", RFC 7232, June 2014. (HTTP/1.1): Conditional Requests", RFC 7232, June 2014.
10.2. Informative References 10.2. Informative References
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., Leung, K., Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
and K. Ma, "CDN Interconnection Metadata", draft-ietf- "CDN Interconnection Metadata", draft-ietf-cdni-
cdni-metadata-07 (work in progress), July 2014. metadata-08 (work in progress), October 2014.
[I-D.ietf-cdni-redirection] [I-D.ietf-cdni-redirection]
Niven-Jenkins, B. and R. Brandenburg, "Request Routing Niven-Jenkins, B. and R. Brandenburg, "Request Routing
Redirection Interface for CDN Interconnection", draft- Redirection Interface for CDN Interconnection", draft-
ietf-cdni-redirection-03 (work in progress), August 2014. ietf-cdni-redirection-06 (work in progress), December
2014.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois [RFC5288] Salowey, J., Choudhury, A., and D. McGrew, "AES Galois
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288, Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
August 2008. August 2008.
[RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content
Distribution Network Interconnection (CDNI) Problem Distribution Network Interconnection (CDNI) Problem
Statement", RFC 6707, September 2012. Statement", RFC 6707, September 2012.
skipping to change at page 41, line 25 skipping to change at page 42, line 29
2014. 2014.
Authors' Addresses Authors' Addresses
Rob Murray Rob Murray
Velocix (Alcatel-Lucent) Velocix (Alcatel-Lucent)
3 Ely Road 3 Ely Road
Milton, Cambridge CB24 6DD Milton, Cambridge CB24 6DD
UK UK
Email: rmurray@velocix.com Email: rob.murray@alcatel-lucent.com
Ben Niven-Jenkins Ben Niven-Jenkins
Velocix (Alcatel-Lucent) Velocix (Alcatel-Lucent)
3 Ely Road 3 Ely Road
Milton, Cambridge CB24 6DD Milton, Cambridge CB24 6DD
UK UK
Email: ben@velocix.com Email: ben.niven-jenkins@alcatel-lucent.com
 End of changes. 114 change blocks. 
360 lines changed or deleted 415 lines changed or added

This html diff was produced by rfcdiff 1.41. The latest version is available from http://tools.ietf.org/tools/rfcdiff/