draft-ietf-cdni-control-triggers-12.txt   draft-ietf-cdni-control-triggers-13.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 Nokia Intended status: Standards Track Nokia
Expires: September 19, 2016 March 18, 2016 Expires: October 19, 2016 April 17, 2016
CDNI Control Interface / Triggers CDNI Control Interface / Triggers
draft-ietf-cdni-control-triggers-12 draft-ietf-cdni-control-triggers-13
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 September 19, 2016. This Internet-Draft will expire on October 19, 2016.
Copyright Notice Copyright Notice
Copyright (c) 2016 IETF Trust and the persons identified as the Copyright (c) 2016 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 7, line 5 skipping to change at page 7, line 5
CI/T Trigger Commands that invalidate or purge metadata or content CI/T Trigger Commands that invalidate or purge metadata or content
apply to all resource representations with matching URLs. apply to all resource representations with matching URLs.
2.2.1. Multiple Interconnected CDNs 2.2.1. Multiple Interconnected CDNs
In a network of interconnected CDNs a single uCDN will originate a In a network of interconnected CDNs a single uCDN will originate a
given item of metadata and associated content, it may distribute that given item of metadata and associated content, it may distribute that
metadata and content to more than one dCDN, which may in-turn metadata and content to more than one dCDN, which may in-turn
distribute that metadata and content to further-downstream CDNs. distribute that metadata and content to further-downstream CDNs.
An "intermediate" CDN is a dCDN that passes on CDNI metadata and An intermediate CDN is a dCDN that passes on CDNI metadata and
content to further-downstream dCDNs. content to further-downstream dCDNs.
A "diamond configuration" is one where a dCDN can acquire metadata A diamond configuration is one where a dCDN can acquire metadata and
and content originated in one uCDN from that uCDN itself and an content originated in one uCDN from that uCDN itself and an
intermediate CDN, or via more than one intermediate uCDN. intermediate CDN, or via more than one intermediate CDN.
CI/T commands originating in the single source uCDN affect metadata CI/T commands originating in the single source uCDN affect metadata
and content in all dCDNs but, in a diamond configuration, it may not and content in all dCDNs but, in a diamond configuration, it may not
be possible for the dCDN to determine which uCDN it acquired content be possible for the dCDN to determine which uCDN it acquired content
from. In this case a dCDN MUST allow each uCDN from which it may from. In this case a dCDN MUST allow each uCDN from which it may
have acquired the content to act upon that content using CI/T have acquired the content to act upon that content using CI/T
Commands. Commands.
In all other cases, a dCDN MUST reject CI/T Commands from a uCDN that In all other cases, a dCDN MUST reject CI/T Commands from a uCDN that
act on another uCDN's data using, for example, HTTP "403 Forbidden". act on another uCDN's data using, for example, HTTP "403 Forbidden".
skipping to change at page 8, line 22 skipping to change at page 8, line 22
The CI/T Trigger Command MUST NOT be reported as 'complete' until all The CI/T Trigger Command MUST NOT be reported as 'complete' until all
actions have been completed successfully. The reasons for failure, actions have been completed successfully. The reasons for failure,
and URLs or Patterns affected, SHOULD be enumerated in the Trigger and URLs or Patterns affected, SHOULD be enumerated in the Trigger
Status Resource. For more detail, see section Section 4.7. 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 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 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 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 is 'complete' in all of its downstream CDNs. If a CI/T Trigger
Command is reported as 'processed' in any dCDN, intermediate CDNs Command is reported as 'processed' in any dCDN, intermediate CDNs
MUST NOT report 'complete', instead they must also report MUST NOT report 'complete', instead they MUST also report
'processed'. A CI/T Command MAY be reported as 'failed' as soon as '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 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 Trigger Command MUST be reported as 'cancelling' until it has been
reported as 'cancelled', 'complete', or 'failed' by all dCDNs in a reported as 'cancelled', 'complete', or 'failed' by all dCDNs in a
cascade. 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.
skipping to change at page 9, line 6 skipping to change at page 9, line 6
be visible to any other CDN. The dCDN could, for example, achieve be visible to any other CDN. The dCDN could, for example, achieve
this by offering different collection URLs to each uCDN, and by this by offering different collection URLs to each uCDN, and by
filtering the response based on the uCDN with which the HTTP client filtering the response based on the uCDN with which the HTTP client
is associated. 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 MAY also maintain collections representing
representing filtered views of the collection of all Trigger Status filtered views of the collection of all Trigger Status Resources.
Resources. These filtered collections are optional-to-implement but, These filtered collections are optional-to-implement but, if
if implemented, the dCDN MUST include links to them in the collection implemented, the dCDN MUST include links to them in the collection of
of all Trigger Status Resources. The filtered collections are: all Trigger Status Resources. The filtered collections are:
o Pending - Trigger Status Resources for CI/T Trigger Commands that o Pending - Trigger Status Resources for CI/T Trigger Commands that
have been accepted, but not yet acted upon. have been accepted, but not yet acted upon.
o Active - Trigger Status Resources for CI/T Trigger Commands that o Active - Trigger Status Resources for CI/T Trigger Commands that
are 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' CI/T Trigger Commands for completed successfully, and 'processed' CI/T Trigger Commands for
which no further status updates will be made by the dCDN. which no further status updates will be made by the dCDN.
skipping to change at page 14, line 5 skipping to change at page 14, line 5
Resource. 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 Trigger Status "cancelled". In this case, the dCDN will remove the Trigger Status
Resource and respond to subsequent requests for it with an HTTP Resource and respond to subsequent requests for it with an HTTP
error. error.
If the dCDN performs this housekeeping, it MUST have reported the If the dCDN does remove Trigger Status Resources automatically, it
length of time after which completed Trigger Status Resources will be MUST report the length of time after which it will do so, using a
deleted via a property of the collection of all Trigger Status property of the collection of all Trigger Status Resources. It is
Resources. It is RECOMMENDED that Trigger Status Resources are not RECOMMENDED that Trigger Status Resources are not automatically
automatically deleted by the dCDN for at least 24 hours after they deleted by the dCDN for at least 24 hours after they become
become "complete", "processed", "failed" or "cancelled". "complete", "processed", "failed" or "cancelled".
To ensure it is able to get the status of its Trigger Status To ensure it is able to get the status of its Trigger Status
Resources for completed and failed CI/T Commands, it is RECOMMENDED Resources for completed and failed CI/T Commands, it is RECOMMENDED
that the uCDN polling interval is less than the time after which that the uCDN polling interval is less than the time after which
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. In every CI/T Command it Provider ID to uniquely identify itself. In every CI/T Command it
originates or cascades, each CDN MUST append an array element originates or cascades, each CDN MUST append an array element
containing its CDN Provider ID to a JSON array under an entry named containing its CDN Provider ID to a JSON array under an entry named
"cdn-path". When receiving CI/T Commands a dCDN MUST check the cdn- "cdn-path". When receiving CI/T Commands a dCDN MUST check the cdn-
path and reject any CI/T Command which already contains its own CDN path and reject any CI/T Command which already contains its own CDN
skipping to change at page 15, line 44 skipping to change at page 15, line 44
"processed" if affected caches are offline and the activity will "processed" if affected caches are offline and the activity will
complete when they return to service. complete when they return to service.
o Otherwise, the dCDN SHOULD keep the Trigger Status Resource in o Otherwise, the dCDN SHOULD keep the Trigger Status Resource in
state "pending" or "active" until the CI/T Command is acted upon, state "pending" or "active" until the CI/T Command is acted upon,
or the uCDN chooses to cancel it. or the uCDN chooses to cancel it.
4.8. Content URLs 4.8. Content URLs
If content URLs are transformed by an intermediate CDN in a cascade, If content URLs are transformed by an intermediate CDN in a cascade,
that intermediate CDN MUST transform URLs in CI/T Commands it passes that intermediate CDN MUST similarly transform URLs in CI/T Commands
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 a CI/T scheme (http or https) in comparing URLs. For example, for a CI/T
invalidate or purge command, 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
skipping to change at page 36, line 33 skipping to change at page 36, line 33
{ {
"staleresourcetime": 86400, "staleresourcetime": 86400,
"triggers": [ "triggers": [
"https://dcdn.example.com/triggers/0", "https://dcdn.example.com/triggers/0",
"https://dcdn.example.com/triggers/1" "https://dcdn.example.com/triggers/1"
] ]
} }
6.2.5. Deleting Trigger Status Resources 6.2.5. Deleting Trigger Status Resources
The dCDN can delete completed and failed Trigger Status Resources to The uCDN can delete completed and failed Trigger Status Resources to
reduce the size of the collections. For example, to delete the reduce the size of the collections. For example, to delete 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: */*
skipping to change at page 40, line 13 skipping to change at page 40, line 13
malicious behaviour between interconnected CDNs. malicious behaviour between interconnected CDNs.
8.1. Authentication, Authorization, Confidentiality, Integrity 8.1. Authentication, Authorization, Confidentiality, Integrity
Protection 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] and [RFC7230]. per [RFC2818] and [RFC7230].
TLS MUST be used by the server-side (dCDN) and the client-side (uCDN) TLS MUST be used by the server-side (dCDN) and the client-side (uCDN)
of the CI/T interface, including authentication of the remote end, of the CI/T interface, including authentication of the remote end,
unless alternate methods are used for ensuring the confidentiality of unless alternate methods are used for ensuring the security of the
the information in the CI/T interface requests and responses (such as information in the CI/T interface requests and responses (such as
setting up an IPsec tunnel between the two CDNs or using a physically 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 secured internal network between two CDNs that are owned by the same
corporate entity). corporate entity).
The use of TLS for transport of the CI/T interface allows: The use of TLS for transport of the CI/T interface allows:
o The dCDN and the uCDN to authenticate each other using TLS client o The dCDN and the uCDN to authenticate each other using TLS client
auth and TLS server auth. auth and TLS server auth.
And, once they have mutually authenticated each other, it allows: And, once they have mutually authenticated each other, it allows:
skipping to change at page 41, line 43 skipping to change at page 41, line 43
9. Acknowledgements 9. Acknowledgements
The authors thank Kevin Ma for his input, and Carsten Bormann for his The authors thank Kevin Ma for his input, and Carsten Bormann for his
review and formalization of the JSON data. review and formalization of the JSON data.
10. References 10. References
10.1. Normative References 10.1. Normative References
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-15 (work in progress), April 2016.
[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.
[RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000.
[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.
[RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data
skipping to change at page 42, line 28 skipping to change at page 42, line 32
[RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre,
"Recommendations for Secure Use of Transport Layer "Recommendations for Secure Use of Transport Layer
Security (TLS) and Datagram Transport Layer Security Security (TLS) and Datagram Transport Layer Security
(DTLS)", BCP 195, RFC 7525, May 2015. (DTLS)", BCP 195, RFC 7525, May 2015.
10.2. Informative References 10.2. Informative References
[I-D.greevenbosch-appsawg-cbor-cddl] [I-D.greevenbosch-appsawg-cbor-cddl]
Vigano, C. and H. Birkholz, "CBOR data definition language Vigano, C. and H. Birkholz, "CBOR data definition language
(CDDL): a notational convention to express CBOR data (CDDL): a notational convention to express CBOR data
structures", draft-greevenbosch-appsawg-cbor-cddl-07 (work structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work
in progress), October 2015. in progress), March 2016.
[I-D.ietf-cdni-metadata]
Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma,
"CDN Interconnection Metadata", draft-ietf-cdni-
metadata-12 (work in progress), October 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-17 (work in progress), February ietf-cdni-redirection-18 (work in progress), April 2016.
2016.
[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.
[RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI)
 End of changes. 15 change blocks. 
34 lines changed or deleted 33 lines changed or added

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