draft-ietf-cdni-control-triggers-06.txt   draft-ietf-cdni-control-triggers-07.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: August 27, 2015 February 23, 2015 Expires: January 1, 2016 June 30, 2015
CDNI Control Interface / Triggers CDNI Control Interface / Triggers
draft-ietf-cdni-control-triggers-06 draft-ietf-cdni-control-triggers-07
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 August 27, 2015. This Internet-Draft will expire on January 1, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2015 IETF Trust and the persons identified as the Copyright (c) 2015 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 22 skipping to change at page 2, line 22
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. Scope of Triggered Activity . . . . . . . . . . . . . . . 6 2.2. Scope of Triggered Activity . . . . . . . . . . . . . . . 6
2.3. Trigger Results . . . . . . . . . . . . . . . . . . . . . 6 2.3. Trigger Results . . . . . . . . . . . . . . . . . . . . . 7
3. Collections of Trigger Status Resources . . . . . . . . . . . 7 3. Collections of Trigger Status Resources . . . . . . . . . . . 7
4. CDNI Trigger Interface . . . . . . . . . . . . . . . . . . . 8 4. CDNI Trigger Interface . . . . . . . . . . . . . . . . . . . 8
4.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 9 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 . . . . . . . . . . 11 4.2.2. Polling Trigger Status Resources . . . . . . . . . . 11
4.3. Cancelling Triggers . . . . . . . . . . . . . . . . . . . 11 4.3. Cancelling Triggers . . . . . . . . . . . . . . . . . . . 11
4.4. Deleting Triggers . . . . . . . . . . . . . . . . . . . . 12 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 . . . . . . . . . . . . . . 13 4.6. Loop Detection and Prevention . . . . . . . . . . . . . . 13
4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 13 4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 13
4.8. Content URLs . . . . . . . . . . . . . . . . . . . . . . 14 4.8. Content URLs . . . . . . . . . . . . . . . . . . . . . . 14
5. CI/T Object Properties and Encoding . . . . . . . . . . . . . 15 5. CI/T Object Properties and Encoding . . . . . . . . . . . . . 15
5.1. CI/T Objects . . . . . . . . . . . . . . . . . . . . . . 15 5.1. CI/T Objects . . . . . . . . . . . . . . . . . . . . . . 15
5.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 15 5.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 15
5.1.2. Trigger Status Resource . . . . . . . . . . . . . . . 16 5.1.2. Trigger Status Resource . . . . . . . . . . . . . . . 16
5.1.3. Trigger Collection . . . . . . . . . . . . . . . . . 17 5.1.3. Trigger Collection . . . . . . . . . . . . . . . . . 17
5.2. Properties of CI/T Objects . . . . . . . . . . . . . . . 18 5.2. Properties of CI/T Objects . . . . . . . . . . . . . . . 19
5.2.1. Trigger Specification . . . . . . . . . . . . . . . . 19 5.2.1. Trigger Specification . . . . . . . . . . . . . . . . 19
5.2.2. Trigger Type . . . . . . . . . . . . . . . . . . . . 20 5.2.2. Trigger Type . . . . . . . . . . . . . . . . . . . . 20
5.2.3. Trigger Status . . . . . . . . . . . . . . . . . . . 21 5.2.3. Trigger Status . . . . . . . . . . . . . . . . . . . 21
5.2.4. PatternMatch . . . . . . . . . . . . . . . . . . . . 21 5.2.4. PatternMatch . . . . . . . . . . . . . . . . . . . . 21
5.2.5. Absolute Time . . . . . . . . . . . . . . . . . . . . 22 5.2.5. Absolute Time . . . . . . . . . . . . . . . . . . . . 22
5.2.6. Error Description . . . . . . . . . . . . . . . . . . 22 5.2.6. Error Description . . . . . . . . . . . . . . . . . . 22
5.2.7. Error Code . . . . . . . . . . . . . . . . . . . . . 23 5.2.7. Error Code . . . . . . . . . . . . . . . . . . . . . 23
6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 23 5.3. Formalization of the JSON Data . . . . . . . . . . . . . 24
6.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 24 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 26
6.1.1. Preposition . . . . . . . . . . . . . . . . . . . . . 24 6.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 26
6.1.2. Invalidate . . . . . . . . . . . . . . . . . . . . . 25 6.1.1. Preposition . . . . . . . . . . . . . . . . . . . . . 26
6.2. Examining Trigger Status . . . . . . . . . . . . . . . . 27 6.1.2. Invalidate . . . . . . . . . . . . . . . . . . . . . 27
6.2.1. Collection of All Triggers . . . . . . . . . . . . . 27
6.2.2. Filtered Collections of Trigger Status Resources . . 28 6.2. Examining Trigger Status . . . . . . . . . . . . . . . . 29
6.2.3. Individual Trigger Status Resources . . . . . . . . . 29 6.2.1. Collection of All Triggers . . . . . . . . . . . . . 29
6.2.4. Polling for Change . . . . . . . . . . . . . . . . . 31 6.2.2. Filtered Collections of Trigger Status Resources . . 30
6.2.5. Deleting Trigger Status Resources . . . . . . . . . . 34 6.2.3. Individual Trigger Status Resources . . . . . . . . . 31
6.2.6. Error Reporting . . . . . . . . . . . . . . . . . . . 35 6.2.4. Polling for Change . . . . . . . . . . . . . . . . . 33
7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 36 6.2.5. Deleting Trigger Status Resources . . . . . . . . . . 36
7.1. Media type registrations . . . . . . . . . . . . . . . . 37 6.2.6. Error Reporting . . . . . . . . . . . . . . . . . . . 38
7.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 37 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39
7.1.2. CI/T Trigger Status Resource . . . . . . . . . . . . 38 7.1. Media type registrations . . . . . . . . . . . . . . . . 39
7.1.3. CI/T Trigger Collection . . . . . . . . . . . . . . . 39 7.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 39
8. Security Considerations . . . . . . . . . . . . . . . . . . . 40 7.1.2. CI/T Trigger Status Resource . . . . . . . . . . . . 40
8.1. Authentication, Confidentiality, Integrity Protection . . 40 7.1.3. CI/T Trigger Collection . . . . . . . . . . . . . . . 41
8.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 41 8. Security Considerations . . . . . . . . . . . . . . . . . . . 42
9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 8.1. Authentication, Authorization, Confidentiality, Integrity
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 Protection . . . . . . . . . . . . . . . . . . . . . . . 42
10.1. Normative References . . . . . . . . . . . . . . . . . . 41 8.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 43
10.2. Informative References . . . . . . . . . . . . . . . . . 42 8.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 43
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 42 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 44
10. References . . . . . . . . . . . . . . . . . . . . . . . . . 44
10.1. Normative References . . . . . . . . . . . . . . . . . . 44
10.2. Informative References . . . . . . . . . . . . . . . . . 44
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 45
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 9, line 17 skipping to change at page 9, line 23
are purely illustrative and are not intended to impose a definitive are purely illustrative and are not intended to impose a definitive
structure on CI/T interface implementations. structure on CI/T interface implementations.
4.1. Creating Triggers 4.1. Creating Triggers
To issue a CI/T Command, 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, as described in request body of that POST is a CI/T Command, as described in
Section 5.1.1. Section 5.1.1.
The dCDN validates and authenticates that CI/T Command, if it is The dCDN validates the CI/T Command, if it is malformed or the uCDN
malformed or the uCDN does not have sufficient access rights it MUST does not have sufficient access rights it MUST either respond with an
either respond with an appropriate 4xx HTTP error code and a Trigger appropriate 4xx HTTP error code and a Trigger Status Resource MUST
Status Resource MUST NOT be created on the dCDN, or create a 'failed' NOT be created on the dCDN, or create a 'failed' Trigger Status
Trigger Status Resource containing an appropriate error description. Resource containing an appropriate error description.
When a CI/T Trigger Command is accepted, the uCDN MUST create a new When a CI/T Trigger Command is accepted, the uCDN MUST create a new
Trigger Status Resource which will convey a specification of the CI/T Trigger Status Resource which will convey a specification of the CI/T
Command and its current status. The HTTP response to the dCDN MUST Command and its current status. The HTTP response to the dCDN MUST
have status code 201 and MUST convey the URI of the Trigger Status have status code 201 and MUST convey the URI of the Trigger Status
Resource in the Location header field. The HTTP response SHOULD Resource in the Location header field. The HTTP response SHOULD
include the content of the newly created Trigger Status Resource, include the content of the newly created Trigger Status Resource,
this is recommended particularly in cases where the CI/T Trigger this is recommended particularly in cases where the CI/T Trigger
Command has completed immediately. Command has completed immediately.
skipping to change at page 10, line 18 skipping to change at page 10, line 23
example, it is an invalidate or purge request for data the dCDN has example, it is an invalidate or purge request for data the dCDN has
not yet acquired, or a prepopulate request for data it has already not yet acquired, or a prepopulate request for data it has already
acquired and which is still valid. In this case, the "status" of the acquired and which is still valid. In this case, the "status" of the
Trigger Status Resource MUST be "processed" or "complete", and the Trigger Status Resource MUST be "processed" or "complete", and the
Trigger Status Resource MUST be added to the dCDN's collection of Trigger Status Resource MUST be added to the dCDN's collection of
Complete Trigger Status Resources. 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, for example 405 "Method Not
Allowed".
4.2. Checking Status 4.2. Checking Status
The uCDN has two ways to check progress of CI/T Commands it has The uCDN has two ways to check progress of CI/T Commands it has
issued to the dCDN, described in sections Section 4.2.1 and issued to the dCDN, described in sections Section 4.2.1 and
Section 4.2.2. Section 4.2.2.
To check for change in status of a Trigger Status Resource or To check for change in status of a Trigger Status Resource or
collection of Trigger Status Resources without re-fetching the whole collection of Trigger Status Resources without re-fetching the whole
Resource or Collection, Entity Tags SHOULD be included by the dCDN Resource or Collection, Entity Tags SHOULD be included by the dCDN
skipping to change at page 10, line 47 skipping to change at page 11, line 7
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 CI/T Trigger Commands in This makes it possible to poll status of all CI/T Trigger Commands in
a single request. If the dCDN moves a Trigger Status Resource from a single request. If the dCDN moves a Trigger Status Resource from
the Active to the Completed collection, the uCDN can fetch the result the Active to the Completed collection, the uCDN can fetch the result
of 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. An example of this is given in section Section 6.2.4.
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 Trigger Status Resource at Resource it has created, it may fetch that Trigger Status Resource at
any time. 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 the CI/T Command. result of the CI/T Command.
skipping to change at page 11, line 30 skipping to change at page 11, line 34
The uCDN can request cancellation of a CI/T Trigger Command by The uCDN can request cancellation of a CI/T Trigger Command by
POSTing a CI/T Cancel Command to the collection of all Trigger Status POSTing a CI/T Cancel Command to the collection of all Trigger Status
Resources. Resources.
Cancellation of a CI/T Trigger Command is optional-to-implement in Cancellation of a CI/T Trigger Command is optional-to-implement in
the dCDN. the dCDN.
The dCDN MUST respond to the CI/T Cancel Command appropriately, for The dCDN MUST respond to the CI/T Cancel Command appropriately, for
example with HTTP status code 200 "OK" if the cancellation has been example with HTTP status code 200 "OK" if the cancellation has been
processed and the CI/T Command is inactive, 202 "Accepted" if the 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 command has been accepted but the CI/T Command remains active, or 501
"Forbidden" if cancellation is not supported by the dCDN. "Not Implemented" 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.
Issuing a CT/T cancel command for a "pending" Trigger Status Resource Issuing a CT/T cancel command for a "pending" Trigger Status Resource
does not however guarantee that the corresponding activity will not does not however guarantee that the corresponding activity will not
be started, because the uCDN cannot control the timing of that be started, because the uCDN cannot control the timing of that
activity. Processing could, for example, start after the POST is activity. Processing could, for example, start after the POST is
sent by the uCDN but before that request is processed by the dCDN. 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
skipping to change at page 13, line 18 skipping to change at page 13, line 21
records for completed activity will be 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 CI/T Commands 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. In every CI/T Command it
CDN Provider ID into the cdn-path key of every CI/T Command it originates or cascades, each CDN MUST append an array element
originates or cascades. When receiving CI/T Commands a dCDN MUST containing its CDN Provider ID to a JSON array under an entry named
check the cdn-path and reject any CI/T Command which already contains "cdn-path". When receiving CI/T Commands a dCDN MUST check the cdn-
its own CDN Provider ID in the cdn-path. Transit CDNs MUST check the path and reject any CI/T Command which already contains its own CDN
cdn-path and not cascade the CI/T Command to dCDNs that are already Provider ID in the cdn-path. Transit CDNs MUST check the cdn-path
listed in cdn-path. and not cascade the CI/T Command to dCDNs that are already listed in
cdn-path.
The CDN Provider Id consists of the two characters "AS" followed by The CDN Provider Id consists of the two characters "AS" followed by
the CDN Provider's Autonomous System number, then a colon (':') and the CDN Provider's Autonomous System number, then a colon (':') and
an additional qualifier that is used to guarantee uniqueness in case an additional qualifier that is used to guarantee uniqueness in case
a particular AS has multiple independent CDNs deployed. For example a particular AS has multiple independent CDNs deployed. For example
"AS64496:0". "AS64496:0".
If the CDN provider has multiple Autonomous Systems, the same AS If the CDN provider has multiple Autonomous Systems, the same AS
number SHOULD be used in all messages from that CDN provider, unless number SHOULD be used in all messages from that CDN provider, unless
there are multiple distinct CDNs. 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 signal rejection of a CI/T Command using HTTP status A dCDN can signal rejection of a CI/T Command using HTTP status
codes. For example, 400 if the request is malformed, or 401 if the codes. For example, 400 if the request is malformed, or 403 or 404
uCDN does not have permission to issue CI/T Commands or it is trying if the uCDN does not have permission to issue CI/T Commands or it is
to act on another CDN's data. trying to act on another CDN's data.
If any part of the CI/T Trigger Command fails, the trigger SHOULD be If any part of the CI/T Trigger Command fails, the trigger SHOULD be
reported as "failed" once its activity is complete or if no further reported as "failed" once its activity is complete or if no further
errors will be reported. The "errors" property in the Trigger Status errors will be reported. The "errors" property in the Trigger Status
Resource will be used to enumerate which actions failed and the Resource will be used to enumerate which actions failed and the
reasons for failure, and can be present while the Trigger Status reasons for failure, and can be present while the Trigger Status
Resource is still "pending" or "active", if the CI/T Trigger Command Resource is still "pending" or "active", if the CI/T Trigger Command
is still running for some URLs or Patterns in the Trigger is still running for some URLs or Patterns in the Trigger
Specification. Specification.
skipping to change at page 15, line 51 skipping to change at page 16, line 5
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 CI/T Description: The URLs of Trigger Status Resources for CI/T
Trigger Commands that the uCDN wants to cancel. Trigger Commands that the uCDN wants to cancel.
Value: A JSON array of URLs represented as JSON strings. Value: A non-empty 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.
Value: A JSON array of JSON strings, where each string is a CDN Value: A non-empty JSON array of JSON strings, where each
Provider Identifier as defined in Section 4.6. string is a CDN Provider Identifier as defined in Section 4.6.
Mandatory: Yes. Mandatory: Yes.
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.
skipping to change at page 17, line 33 skipping to change at page 17, line 36
Value: Trigger Status, as defined in Section 5.2.3. Value: Trigger Status, as defined in Section 5.2.3.
Mandatory: Yes Mandatory: Yes
Name: errors Name: errors
Description: Descriptions of errors that have occurred while Description: Descriptions of errors that have occurred while
processing a Trigger Command. processing a Trigger Command.
Value: A list of Error Descriptions, as defined in Value: An array of Error Description, as defined in
Section 5.2.6. Section 5.2.6. An empty array is allowed, and equivalent to
omitting "errors" from the object.
Mandatory: No. Mandatory: No.
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.
skipping to change at page 17, line 47 skipping to change at page 18, line 4
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 zero or more 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 Trigger Status Resource and all the dCDN SHOULD delete the Trigger Status Resource and all
references to it from collections. references to it from collections.
Value: A JSON number, integer time in seconds. Value: A JSON number, which must be a positive integer,
representing 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.
skipping to change at page 22, line 34 skipping to change at page 22, line 51
"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 CI/T Command, or An Error Description is used to report failure of a CI/T Command, or
in the activity it triggered. in the activity it triggered. It is encoded as a JSON object with
the following name/value pairs:
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 23, line 46 skipping to change at page 24, line 24
| | CDN). | | | CDN). |
| ereject | The dCDN is not willing to fulfil the CI/T Command | | ereject | The dCDN is not willing to fulfil the CI/T Command |
| | (for example, a preposition request for content at a | | | (for example, a preposition request for content at a |
| | time 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. |
+------------+------------------------------------------------------+ +------------+------------------------------------------------------+
5.3. Formalization of the JSON Data
The JSON data described in this document has been formalised using
CDDL [I-D.greevenbosch-appsawg-cbor-cddl] as follows:
CIT-object = CIT-command / Trigger-Status-Resource / Trigger-Collection
CIT-command ; use media type application/cdni.ci.TriggerCommand+json
= {
? trigger: Triggerspec
? cancel: [* URI]
cdn-path: [* Cdn-PID]
}
Trigger-Status-Resource ; application/cdni.ci.TriggerStatus+json.
= {
trigger: Triggerspec
ctime: Absolute-Time
mtime: Absolute-Time
? etime: Absolute-Time
status: Trigger-Status
? errors: [* Error-Description]
}
Trigger-Collection ; application/cdni.ci.TriggerCollection+json
= {
triggers: [* URI]
? staleresourcetime: int ; time in seconds
? coll-all: URI
? coll-pending: URI
? coll-active: URI
? coll-complete: URI
? coll-failed: URI
? cdn-id: Cdn-PID
}
Triggerspec = { ; 5.2.1
type: Trigger-Type
? metadata.urls: [* URI]
? content.urls: [* URI]
? content.ccid: [* Ccid]
? metadata.patterns: [* Pattern-Match]
? content.patterns: [* Pattern-Match]
}
Trigger-Type = "preposition" / "invalidate" / "purge" ; 5.2.2
Trigger-Status = "pending" / "active" / "complete" / "processed"
/ "failed" / "cancelling" / "cancelled" ; 5.2.3
Pattern-Match = { ; 5.2.4
pattern: tstr
? case-sensitive: bool
? match-query-string: bool
}
Absolute-Time = number ; seconds since UNIX epoch, 5.2.5
Error-Description = { ; 5.2.6
error: Error-Code
? metadata.urls: [* URI]
? content.urls: [* URI]
? metadata.patterns: [* Pattern-Match]
? content.patterns: [* Pattern-Match]
? description: tstr
}
Error-Code = "emeta" / "econtent" / "eperm" / "ereject"
/ "ecdn" / "ecancelled" ; 5.2.7
Ccid = tstr ; see I-D.ietf-cdni-metadata
Cdn-PID = tstr .regexp "AS[0-9]+:[0-9]+"
URI = tstr
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.
skipping to change at page 33, line 11 skipping to change at page 35, line 11
For example, when the two example CI/T Trigger Commands are complete, For example, when the two example CI/T Trigger Commands are complete,
the collections of pending and complete Trigger Status Resources the collections of pending and complete Trigger Status Resources
might look like: 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: */*
If-None-Match: "5012053611544832286"
RESPONSE: RESPONSE:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 56 Content-Length: 56
Expires: Sun, 31 Aug 2014 09:54:29 GMT Expires: Sun, 31 Aug 2014 09:54:29 GMT
Server: example-server/0.1 Server: example-server/0.1
Etag: "-4471185573414616962" Etag: "-4471185573414616962"
Cache-Control: max-age=60 Cache-Control: max-age=60
Date: Sun, 31 Aug 2014 09:53:29 GMT Date: Sun, 31 Aug 2014 09:53:29 GMT
skipping to change at page 34, line 11 skipping to change at page 36, line 11
"staleresourcetime": 86400, "staleresourcetime": 86400,
"triggers": [] "triggers": []
} }
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: */*
If-None-Match: "2986340333785000363"
RESPONSE: RESPONSE:
HTTP/1.1 200 OK HTTP/1.1 200 OK
Content-Length: 153 Content-Length: 153
Expires: Sun, 31 Aug 2014 09:54:30 GMT Expires: Sun, 31 Aug 2014 09:54:30 GMT
Server: example-server/0.1 Server: example-server/0.1
Etag: "-1508172875796647067" Etag: "-1508172875796647067"
Cache-Control: max-age=60 Cache-Control: max-age=60
Date: Sun, 31 Aug 2014 09:53:30 GMT Date: Sun, 31 Aug 2014 09:53:30 GMT
skipping to change at page 40, line 35 skipping to change at page 42, line 35
And so would a man in the middle attacker modifying valid CI/T And so would a man in the middle attacker modifying valid CI/T
commands generated by the uCDN. In both cases, that would decrease commands generated by the uCDN. In both cases, that would decrease
the dCDN caching efficiency by causing it to unnecessarily acquire or the dCDN caching efficiency by causing it to unnecessarily acquire or
re-acquire content metadata and/or content. re-acquire content metadata and/or content.
A dCDN implementation of CI/T MUST restrict the actions of a uCDN to A dCDN implementation of CI/T MUST restrict the actions of a uCDN to
the data corresponding to that uCDN. Failure to do so would allow the data corresponding to that uCDN. Failure to do so would allow
uCDNs to detrimentally affect each other's efficiency by generating uCDNs to detrimentally affect each other's efficiency by generating
unnecessary acquisition or re-acquisition load. unnecessary acquisition or re-acquisition load.
8.1. Authentication, Confidentiality, Integrity Protection 8.1. Authentication, Authorization, Confidentiality, Integrity
Protection
A CI/T implementation MUST support TLS transport for HTTP (https) as A CI/T implementation MUST support TLS transport for HTTP (https) as
per [RFC2818]. The use of TLS for transport of the CI/T interface per [RFC2818].
allows the dCDN and the uCDN to authenticate each other (to ensure
they are receiving CI/T Commands from, or reporting status to, an
authenticated CDN).
In an environment where any such protection is required, TLS SHOULD The use of TLS for transport of the CI/T interface allows:
be used for transport of the CI/T requests and responses, unless
alternate methods are used for ensuring that only authorised clients
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 two CDNs that are owned by the same corporate entity). Both
parties of the transaction (the uCDN and the dCDN) SHOULD use mutual
authentication.
A TLS implementation of CI/T MUST support the o The dCDN and the uCDN to authenticate each other.
TLS_DHE_RSA_WITH_AES_128_GCM_SHA256 cipher suite ([RFC5288]). An
implementation of the CI/T Interface SHOULD prefer cipher suites and, once they have mutually authenticated each other, it allows:
which support perfect forward secrecy over cipher suites that don't.
o The dCDN and the uCDN to authorize each other (to ensure they are
receiving CI/T Commands from, or reporting status to, an
authorized CDN).
o CDNI commands and responses to transmitted with confidentiality,
In an environment where any such protection is required, the use of a
mutually authenticated encrypted transport MUST be used to ensure
confidentiality of the CI/T information. TLS MUST be used by CI/T,
including authentication of the remote end.
The general TLS usage guidance in [RFC7525] SHOULD be followed.
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". This is intended to prevent "403 Forbidden" or "404 Not Found". This is intended to prevent
unauthorised users from generating unnecessary load in dCDN or uCDN unauthorised users from generating unnecessary load in dCDN or uCDN
due to revalidation, reacquisition, or unnecessary acquisition. 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
skipping to change at page 41, line 38 skipping to change at page 43, line 39
and/or via mechanisms outside the scope of the CI/T interface, such and/or via mechanisms outside the scope of the CI/T interface, such
as firewalling or use of Virtual Private Networks (VPNs). as firewalling or use of Virtual Private Networks (VPNs).
Depending on the implementation, triggered activity may consume Depending on the implementation, triggered activity may consume
significant processing and bandwidth in the dCDN. A malicious or significant processing and bandwidth in the dCDN. A malicious or
faulty uCDN could use this to generate unnecessary load in the dCDN. faulty uCDN could use this to generate unnecessary load in the dCDN.
The dCDN should consider mechanisms to avoid overload, for example by The dCDN should consider mechanisms to avoid overload, for example by
rate-limiting acceptance or processing of CI/T Commands, or batching rate-limiting acceptance or processing of CI/T Commands, or batching
up its processing. up its processing.
8.3. Privacy
The CI/T protocol does not carry any information about individual End
Users of a CDN, there are no privacy concerns for End Users.
The CI/T protocol does carry information which could be considered
commercially sensitive by CDN operators and content owners. The use
of mutually authenticated TLS to establish a secure session for the
transport of CI/T data, as discussed in Section 8.1, provides
confidentiality while the CI/T data is in transit, and prevents
parties other party than the authorised dCDN from gaining access to
that data. The dCDN MUST ensure that it only exposes CI/T data
related to a uCDN to clients it has authenticated as belonging to
that uCDN.
9. Acknowledgements 9. Acknowledgements
The authors thank Kevin Ma for his input. The authors thank Kevin Ma for his input, and Carsten Bormann for his
review and formalization of the JSON data.
10. References 10. References
10.1. Normative References 10.1. Normative References
[RFC2119] Bradner, S., "Key words for use in RFCs to Indicate [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate
Requirement Levels", BCP 14, RFC 2119, March 1997. Requirement Levels", BCP 14, RFC 2119, March 1997.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
Interchange Format", RFC 7159, March 2014. Interchange Format", RFC 7159, March 2014.
[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.greevenbosch-appsawg-cbor-cddl]
Vigano, C., Birkholz, H., and R. Sun, "CBOR data
definition language: a notational convention to express
CBOR data structures.", draft-greevenbosch-appsawg-cbor-
cddl-05 (work in progress), March 2015.
[I-D.ietf-cdni-metadata] [I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni- "CDN Interconnection Metadata", draft-ietf-cdni-
metadata-08 (work in progress), October 2014. metadata-09 (work in progress), March 2015.
[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-08 (work in progress), February ietf-cdni-redirection-09 (work in progress), April 2015.
2015.
[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
Counter Mode (GCM) Cipher Suites for TLS", RFC 5288,
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.
[RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg,
"Framework for Content Distribution Network "Framework for Content Distribution Network
Interconnection (CDNI)", RFC 7336, August 2014. Interconnection (CDNI)", RFC 7336, August 2014.
[RFC7337] Leung, K. and Y. Lee, "Content Distribution Network [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network
Interconnection (CDNI) Requirements", RFC 7337, August Interconnection (CDNI) Requirements", RFC 7337, August
2014. 2014.
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015.
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: rob.murray@alcatel-lucent.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.niven-jenkins@alcatel-lucent.com Email: ben.niven-jenkins@alcatel-lucent.com
 End of changes. 34 change blocks. 
82 lines changed or deleted 195 lines changed or added

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