--- 1/draft-ietf-cdni-control-triggers-12.txt 2016-04-17 05:16:00.536325290 -0700 +++ 2/draft-ietf-cdni-control-triggers-13.txt 2016-04-17 05:16:00.612327171 -0700 @@ -1,18 +1,18 @@ Network Working Group R. Murray Internet-Draft B. Niven-Jenkins Intended status: Standards Track Nokia -Expires: September 19, 2016 March 18, 2016 +Expires: October 19, 2016 April 17, 2016 CDNI Control Interface / Triggers - draft-ietf-cdni-control-triggers-12 + draft-ietf-cdni-control-triggers-13 Abstract This document describes the part of the CDN Interconnection Control Interface that allows a CDN to trigger activity in an interconnected CDN that is configured to deliver content on its behalf. The upstream CDN can use this mechanism to request that the downstream CDN pre-positions metadata or content, or that it invalidates or purges metadata or content. The upstream CDN can monitor the status of activity that it has triggered in the downstream CDN. @@ -31,21 +31,21 @@ Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at http://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference 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 (c) 2016 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents (http://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents @@ -278,26 +278,26 @@ CI/T Trigger Commands that invalidate or purge metadata or content apply to all resource representations with matching URLs. 2.2.1. Multiple Interconnected CDNs In a network of interconnected CDNs a single uCDN will originate a given item of metadata and associated content, it may distribute that metadata and content to more than one dCDN, which may in-turn 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. - A "diamond configuration" is one where a dCDN can acquire metadata - and content originated in one uCDN from that uCDN itself and an - intermediate CDN, or via more than one intermediate uCDN. + A diamond configuration is one where a dCDN can acquire metadata and + content originated in one uCDN from that uCDN itself and an + intermediate CDN, or via more than one intermediate CDN. CI/T commands originating in the single source uCDN affect metadata 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 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 Commands. 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". @@ -343,21 +343,21 @@ 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 + 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 As described in Section 2, Trigger Status Resources exist in the dCDN to report the status of activity triggered by each uCDN. @@ -374,25 +374,25 @@ be visible to any other CDN. The dCDN could, for example, achieve this by offering different collection URLs to each uCDN, and 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 uCDN POSTs a CI/T Command to the dCDN's collection of the uCDN's Trigger Status Resources. In order to allow the uCDN to check the status of multiple jobs in a - single request, the dCDN SHOULD also maintain collections - representing filtered views of the collection of all Trigger Status - Resources. These filtered collections are optional-to-implement but, - if implemented, the dCDN MUST include links to them in the collection - of all Trigger Status Resources. The filtered collections are: + single request, the dCDN MAY also maintain collections representing + filtered views of the collection of all Trigger Status Resources. + These filtered collections are optional-to-implement but, if + implemented, the dCDN MUST include links to them in the collection of + all Trigger Status Resources. The filtered collections are: o Pending - Trigger Status Resources for CI/T Trigger Commands that have been accepted, but not yet acted upon. o Active - Trigger Status Resources for CI/T Trigger Commands that are currently being processed in the dCDN. o Complete - Trigger Status Resources representing activity that completed successfully, and 'processed' CI/T Trigger Commands for which no further status updates will be made by the dCDN. @@ -613,35 +613,35 @@ Resource. 4.5. Expiry of Trigger Status Resources The dCDN can choose to automatically delete Trigger Status Resources some time after they become "complete", "processed", "failed" or "cancelled". In this case, the dCDN will remove the Trigger Status Resource and respond to subsequent requests for it with an HTTP error. - If the dCDN performs this housekeeping, it MUST have reported the - length of time after which completed Trigger Status Resources will be - deleted via a property of the collection of all Trigger Status - Resources. It is RECOMMENDED that Trigger Status Resources are not - automatically deleted by the dCDN for at least 24 hours after they - become "complete", "processed", "failed" or "cancelled". + If the dCDN does remove Trigger Status Resources automatically, it + MUST report the length of time after which it will do so, using a + property of the collection of all Trigger Status Resources. It is + RECOMMENDED that Trigger Status Resources are not automatically + deleted by the dCDN for at least 24 hours after they become + "complete", "processed", "failed" or "cancelled". To ensure it is able to get the status of its Trigger Status Resources for completed and failed CI/T Commands, it is RECOMMENDED that the uCDN polling interval is less than the time after which records for completed activity will be deleted. 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 between CDNs B and C in a loop. More complex networks of CDNs could contain similar loops involving more hops. 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 originates or cascades, each CDN MUST append an array element 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- path and reject any CI/T Command which already contains its own CDN @@ -700,22 +700,22 @@ "processed" if affected caches are offline and the activity will complete when they return to service. o Otherwise, the dCDN SHOULD keep the Trigger Status Resource in state "pending" or "active" until the CI/T Command is acted upon, or the uCDN chooses to cancel it. 4.8. Content URLs If content URLs are transformed by an intermediate CDN in a cascade, - that intermediate CDN MUST transform URLs in CI/T Commands it passes - to its dCDN. + that intermediate CDN MUST similarly transform URLs in CI/T Commands + it passes to its dCDN. When processing Trigger Specifications, CDNs MUST ignore the URL scheme (http or https) in comparing URLs. For example, for a CI/T invalidate or purge command, content MUST be invalidated or purged regardless of the protocol clients use to request it. 5. CI/T Object Properties and Encoding CI/T Commands, Trigger Status Resources and Trigger Collections and their properties are encoded using JSON, as defined in sections @@ -1578,21 +1578,21 @@ { "staleresourcetime": 86400, "triggers": [ "https://dcdn.example.com/triggers/0", "https://dcdn.example.com/triggers/1" ] } 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 "preposition" request from earlier examples: REQUEST: DELETE /triggers/0 HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* @@ -1734,22 +1734,22 @@ malicious behaviour between interconnected CDNs. 8.1. Authentication, Authorization, Confidentiality, Integrity Protection A CI/T implementation MUST support TLS transport for HTTP (https) as per [RFC2818] and [RFC7230]. 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, - unless alternate methods are used for ensuring the confidentiality of - the information in the CI/T interface requests and responses (such as + unless alternate methods are used for ensuring the security of the + information in the CI/T interface requests and responses (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). 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 auth and TLS server auth. And, once they have mutually authenticated each other, it allows: @@ -1810,20 +1810,25 @@ 9. Acknowledgements The authors thank Kevin Ma for his input, and Carsten Bormann for his review and formalization of the JSON data. 10. 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 Requirement Levels", BCP 14, RFC 2119, March 1997. [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, May 2000. [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, September 2012. [RFC7159] Bray, T., "The JavaScript Object Notation (JSON) Data @@ -1842,33 +1847,27 @@ [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. 10.2. Informative References [I-D.greevenbosch-appsawg-cbor-cddl] Vigano, C. and H. Birkholz, "CBOR data definition language (CDDL): a notational convention to express CBOR data - structures", draft-greevenbosch-appsawg-cbor-cddl-07 (work - in progress), October 2015. - - [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. + structures", draft-greevenbosch-appsawg-cbor-cddl-08 (work + in progress), March 2016. [I-D.ietf-cdni-redirection] Niven-Jenkins, B. and R. Brandenburg, "Request Routing Redirection interface for CDN Interconnection", draft- - ietf-cdni-redirection-17 (work in progress), February - 2016. + ietf-cdni-redirection-18 (work in progress), April 2016. [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, August 2014. [RFC7337] Leung, K. and Y. Lee, "Content Distribution Network Interconnection (CDNI) Requirements", RFC 7337, August 2014. [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI)