draft-ietf-cdni-triggers-extensions-03.txt   draft-ietf-cdni-triggers-extensions-04.txt 
Network Working Group O. Finkelman Network Working Group O. Finkelman
Internet-Draft Qwilt Internet-Draft Qwilt
Updates: 8007 (if approved) S. Mishra Updates: 8007 (if approved) S. Mishra
Intended status: Standards Track Verizon Intended status: Standards Track Verizon
Expires: March 26, 2020 September 23, 2019 Expires: September 22, 2020 March 21, 2020
CDNI Control Triggers Interface Extensions CDNI Control Triggers Interface Extensions
draft-ietf-cdni-triggers-extensions-03 draft-ietf-cdni-triggers-extensions-04
Abstract Abstract
This document updates RFC 8007 to include generic extensions and more This document updates RFC 8007 to include generic extensions and more
granular content matching options, required by the Open Caching granular content matching options, required by the Open Caching
architecture. The Open Caching working group of the Streaming Video architecture. The Open Caching working group of the Streaming Video
Alliance is focused on the delegation of video delivery request from Alliance is focused on the delegation of video delivery request from
commercial CDNs to a caching layer at the ISP. In that aspect, Open commercial Content Delivery Networks (CDNs) to a caching layer at the
Caching is a specific use case of CDNI, where the commercial CDN is ISP. In that aspect, Open Caching is a specific use case of Content
Delivery Networks Interconnection (CDNI), where the commercial CDN is
the upstream CDN (uCDN) and the ISP caching layer is the downstream the upstream CDN (uCDN) and the ISP caching layer is the downstream
CDN (dCDN). The extensions specified in this document to the CDNI CDN (dCDN). The extensions specified in this document to the CDNI
Control Interface / Triggers are derived from requirements of Open Control Interface / Triggers are derived from requirements of Open
Caching but are applicable to CDNI use cases in general. Caching but are applicable to CDNI use cases in general.
Requirements Language Requirements Language
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
"SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and "SHOULD", "SHOULD NOT", "RECOMMENDED", "NOT RECOMMENDED", "MAY", and
"OPTIONAL" in this document are to be interpreted as described in BCP "OPTIONAL" in this document are to be interpreted as described in BCP
skipping to change at page 1, line 48 skipping to change at page 1, line 49
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 https://datatracker.ietf.org/drafts/current/. Drafts is at https://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 26, 2020. This Internet-Draft will expire on September 22, 2020.
Copyright Notice Copyright Notice
Copyright (c) 2019 IETF Trust and the persons identified as the Copyright (c) 2020 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
(https://trustee.ietf.org/license-info) in effect on the date of (https://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
carefully, as they describe your rights and restrictions with respect carefully, as they describe your rights and restrictions with respect
to this document. Code Components extracted from this document must to this document. Code Components extracted from this document must
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
skipping to change at page 3, line 44 skipping to change at page 3, line 44
10.2. Informative References . . . . . . . . . . . . . . . . . 41 10.2. Informative References . . . . . . . . . . . . . . . . . 41
Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 41
1. Introduction 1. Introduction
This document defines the objects and extensions required for This document defines the objects and extensions required for
granular content management operations. For that purpose it extends granular content management operations. For that purpose it extends
CDNI Control Interface / Triggers [RFC8007] by adding new content CDNI Control Interface / Triggers [RFC8007] by adding new content
selection options to the trigger specification and specifying a selection options to the trigger specification and specifying a
generic extension mechanism that enables adding future functions for generic extension mechanism that enables adding future functions for
controlling the trigger execution. This document also defines and controlling the trigger execution. This document also defines an
initial set of extension objects. This document gives examples for initial set of extension objects and provides examples for the
the extensions specified herein, for complete examples of the trigger extensions. For full and complete examples of the trigger interface
interface usage see Section 6 of [RFC8007]. usage please see Section 6 of [RFC8007].
The CDNI Metadata Interface is described in [RFC8006]. The CDNI Metadata Interface is described in [RFC8006].
The CDNI Footprint and Capability Interface is described in The CDNI Footprint and Capability Interface is described in
[RFC8008]. [RFC8008].
The CDNI Control Interface / Triggers is described in [RFC8007]. The CDNI Control Interface / Triggers is described in [RFC8007].
1.1. Terminology 1.1. Terminology
skipping to change at page 7, line 47 skipping to change at page 7, line 47
Section 5.1.1 of [RFC8007]. Section 5.1.1 of [RFC8007].
o Trigger Status Resource v2: A trigger status resource response o Trigger Status Resource v2: A trigger status resource response
using the payload type ci-trigger-status.v2. Version 2 MUST only using the payload type ci-trigger-status.v2. Version 2 MUST only
use "trigger.v2" objects as defined in Section 3.3.1, instead of a use "trigger.v2" objects as defined in Section 3.3.1, instead of a
"trigger" object, as well as "errors.v2" array as defined in "trigger" object, as well as "errors.v2" array as defined in
Section 3.3.6, instead of a "errors" array. All other properties Section 3.3.6, instead of a "errors" array. All other properties
of the trigger status v2 are as defined in Section 5.1.2 of of the trigger status v2 are as defined in Section 5.1.2 of
[RFC8007]. The errors array "errors.v2" is a list of all errors [RFC8007]. The errors array "errors.v2" is a list of all errors
that occurred in any of the downstream CDNs along the execution that occurred in any of the downstream CDNs along the execution
path. When a downstream CDN, dCDN-A, propagates a trigger to path. When a downstream CDN,for example, dCDN-A, propagates a
another downstream CDN, dCDN-B, it MUST also propagated back all trigger to another downstream CDN, say dCDN-B, it MUST also
errors reported by dCDN-B in the trigger status resource and add propagate back all errors reported by dCDN-B in the trigger status
them to its own trigger status resource. resource and add them to its own trigger status resource.
o Trigger Collections: The payload type ci-trigger-collection is o Trigger Collections: The payload type ci-trigger-collection is
used with no changes and as defined in 5.1.3 of [RFC8007]. used with no changes and as defined in 5.1.3 of [RFC8007].
Usage example of version 2 of trigger command Usage example of version 2 of trigger command
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
skipping to change at page 10, line 7 skipping to change at page 10, line 7
extension object. As extension objects are expected to be added extension object. As extension objects are expected to be added
to the interface as new requirements comes along, it is expected to the interface as new requirements comes along, it is expected
that in some cases a dCDN may receive a trigger that it cannot that in some cases a dCDN may receive a trigger that it cannot
process or does not understand. It is essential for the trigger process or does not understand. It is essential for the trigger
caller to be able to understand when such errors occur so they can caller to be able to understand when such errors occur so they can
take actions to fix them. This document adds a mechanism to take actions to fix them. This document adds a mechanism to
report extension errors. report extension errors.
o Error propagation - enable the uCDN to traceback an error to the o Error propagation - enable the uCDN to traceback an error to the
dCDN in which it occurred. CDNI triggers may be propagated over a dCDN in which it occurred. CDNI triggers may be propagated over a
chain of downstream CDNs. Let us take for example an upstream chain of downstream CDNs. For example, an upstream CDN, call it
(uCDN-A) CDN A that is delegating to a downstream CDN B (dCDN-B) uCDN-A, that is delegating to a downstream CDN, call it dCDN-B.
and dCDN-B is delegating to a downstream CDN C (dCDN-C). Triggers And, dCDN-B is delegating to a downstream CDN, call it, dCDN-C.
sent from uCDN-A to dCDN-B may be redistributed from dCDN-B to In this example, triggers sent from uCDN-A to dCDN-B may be
dCDN-C and errors can happen anywhere along the path. Therefore, redistributed from dCDN-B to dCDN-C and errors can happen anywhere
it is essential for uCDN-A that sets the trigger, to be able to along the path. Therefore, it is essential for uCDN-A that sets
trace back an error to the downstream CDN where it occurred. This the trigger, to be able to trace back an error to the downstream
document adds a mechanism to propagate the ID of the faulty dCDN CDN where it occurred. This document adds a mechanism to
back to the uCDN by adding the CDN ID to the error description. propagate the ID of the faulty dCDN back to the uCDN by adding the
When a downstream dCDN-B propagates a trigger to another CDN ID to the error description. When a downstream dCDN (dCDN-B)
downstream dCDN-C, it MUST also propagate back the errors received propagates a trigger to another downstream CDN (dCDN-C), it MUST
in the trigger status resource from dCDN-C by adding them to the also propagate back the errors received in the trigger status
errors array in its own status resource to be sent back to the resource from dCDN-C by adding them to the errors array in its own
originating uCDN-A. This makes sure that the trigger originating status resource to be sent back to the originating CDN, in this
upstream CDN will receive an array of errors that occurred in all example, the uCDN-A. This makes sure that the trigger originating
the CDNs along the execution path, each error carrying its own CDN in an upstream CDN will receive an array of errors that occurred
identifier. in all the downstream CDNs along the execution path, each error
carrying its own CDN identifier.
3.3. Properties of CI/T Version 2 objects 3.3. Properties of CI/T Version 2 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 3.1, and their encodings. objects described in Section 3.1, and their encodings.
3.3.1. Trigger Specification Version 2 3.3.1. Trigger Specification Version 2
Version 2 of the Trigger Specification adds the following properties Version 2 of the Trigger Specification adds the following properties
on top of the existing properties of the trigger specification on top of the existing properties of the trigger specification
skipping to change at page 19, line 26 skipping to change at page 19, line 26
3.3.6. Error Description Version 2 3.3.6. Error Description Version 2
Version 2 of the Error Description adds the "content.playlists", Version 2 of the Error Description adds the "content.playlists",
"content.regexs", "extensions" and "cdn" properties on top of the "content.regexs", "extensions" and "cdn" properties on top of the
existing properties of version 1 of the trigger Error Description as existing properties of version 1 of the trigger Error Description as
defined in Section 5.2.6 of [RFC8007]. defined in Section 5.2.6 of [RFC8007].
Properties: content.regexs, content.playlists Properties: content.regexs, content.playlists
Description: Content Regex and Playlist references copied from Description: Content Regex and Playlist references are copied
the Trigger Specification. Only those regexs and playlists to from the Trigger Specification. Only those regexs and
which the error applies are included in each property, but playlists to which the error applies are included in each
those references MUST be exactly as they appear in the request; property, but those references MUST be exactly as they appear
the dCDN MUST NOT change or generalize the URLs or Regexs. in the request; the dCDN MUST NOT change or generalize the URLs
Note that these properties are added on top of the already or Regexs. Note that these properties are added on top of the
existing properties: "metadata.urls", "content.urls", already existing properties: "metadata.urls", "content.urls",
"metadata.patterns" and "content.patterns". "metadata.patterns" and "content.patterns".
Type: A JSON array of JSON strings, where each string is copied Type: A JSON array of JSON strings, where each string is copied
from a "content.regexs" or "content.playlists" value in the from a "content.regexs" or "content.playlists" value in the
corresponding Trigger Specification. corresponding Trigger Specification.
Mandatory: At least one of "content.regexs", Mandatory: At least one of "content.regexs",
"content.playlists", "metadata.urls", "content.urls", "content.playlists", "metadata.urls", "content.urls",
"metadata.patterns" or "content.patterns" is mandatory in each "metadata.patterns" or "content.patterns" is mandatory in each
Error Description object. Error Description object.
skipping to change at page 24, line 30 skipping to change at page 24, line 30
} }
3.4.3. Extensions with Error Propagation 3.4.3. Extensions with Error Propagation
In the following example a CI/T "preposition" command is using two In the following example a CI/T "preposition" command is using two
extensions to control the way the trigger is executed. In this extensions to control the way the trigger is executed. In this
example the receiving dCDN identified as "AS64500:0" does not support example the receiving dCDN identified as "AS64500:0" does not support
the first extension in the extensions array. dCDN "AS64500:0" further the first extension in the extensions array. dCDN "AS64500:0" further
distributes this trigger to another downstream CDN that is identified distributes this trigger to another downstream CDN that is identified
as "AS64501:0", which does not support the second extension in the as "AS64501:0", which does not support the second extension in the
extensions array. The error is propagate from "AS64501:0" to extensions array. The error is propagated from "AS64501:0" to
"AS64500:0" and the errors.v2 array reflects both errors. "AS64500:0" and the errors.v2 array reflects both errors.
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: triggers.dcdn.example.com Host: triggers.dcdn.example.com
Accept: */* Accept: */*
Content-Type: application/cdni; ptype=ci-trigger-command.v2 Content-Type: application/cdni; ptype=ci-trigger-command.v2
{ {
skipping to change at page 28, line 46 skipping to change at page 28, line 46
A uCDN may wish to perform content management operations on the dCDN A uCDN may wish to perform content management operations on the dCDN
in a specific schedule. The TimePolicy extensions allows the uCDN to in a specific schedule. The TimePolicy extensions allows the uCDN to
instruct the dCDN to execute the trigger command in a desired time instruct the dCDN to execute the trigger command in a desired time
window. For example, a content provider that wishes to pre-populate window. For example, a content provider that wishes to pre-populate
a new episode at off-peak time so that it would be ready on caches at a new episode at off-peak time so that it would be ready on caches at
prime time when the episode is released for viewing. A scheduled prime time when the episode is released for viewing. A scheduled
operation enables the uCDN to direct the dCDN in what time frame to operation enables the uCDN to direct the dCDN in what time frame to
execute the trigger. execute the trigger.
A uCDN may wish to to schedule a trigger such that the dCDN will A uCDN may wish to schedule a trigger such that the dCDN will execute
execute it in local time, as it is measured in each region. For it in local time, as it is measured in each region. For example, a
example, a uCDN may wish the dCDN to pull the content at off-peak uCDN may wish the dCDN to pull the content at off-peak hours, between
hours, between 2AM-4AM, however, as a CDN is distributed across 2AM-4AM, however, as a CDN is distributed across multiple time zones,
multiple time zones, the UTC definition of 2AM depends on the actual the UTC definition of 2AM depends on the actual location.
location.
We define two alternatives for localized scheduling: This document defines two alternatives for localized scheduling:
o Regional schedule: When used in conjunction with the Location o Regional schedule: When used in conjunction with the Location
Policy defined in Section 4.1, the uCDN can trigger separate Policy defined in Section 4.1, the uCDN can trigger separate
commands for different geographical regions, for each region using commands for different geographical regions, for each region using
a different schedule. This allows the uCDN to control the a different schedule. This allows the uCDN to control the
execution time per region. execution time per region.
o Local Time schedule: We introduce a "local time" version for o Local Time schedule: We introduce a "local time" version for
Internet timestamps that follows the notation for local time as Internet timestamps that follows the notation for local time as
defined in Section 4.2.2 of [ISO8601]. When local time is used, defined in Section 4.2.2 of [ISO8601]. When local time is used,
skipping to change at page 30, line 7 skipping to change at page 30, line 4
trigger at the defined time frame, interpreted as the the local trigger at the defined time frame, interpreted as the the local
time per location. time per location.
Type: LocalTimeWindow object as defined in Section 4.2.2. Type: LocalTimeWindow object as defined in Section 4.2.2.
Mandatory-to-Specify: No, but exactly one of "unix-time- Mandatory-to-Specify: No, but exactly one of "unix-time-
window", "utc-window" or "local-time-window" MUST be present. window", "utc-window" or "local-time-window" MUST be present.
If a time policy object is not listed within the trigger command, the If a time policy object is not listed within the trigger command, the
default behavior is to execute the trigger in a time frame most default behavior is to execute the trigger in a time frame most
suitable to the dCDN taking under consideration other constrains and suitable to the dCDN taking under consideration other constrains and/
/ or obligations. or obligations.
Example of a generic trigger extension object containing a time Example of a generic trigger extension object containing a time
policy object that schedules the trigger execution to a window policy object that schedules the trigger execution to a window
between 09:00 01/01/2000 UTC and 17:00 01/01/2000 UTC, using the between 09:00 01/01/2000 UTC and 17:00 01/01/2000 UTC, using the
"unix-time-window" property: "unix-time-window" property:
{ {
"generic-trigger-extension-type": "CIT.TimePolicy", "generic-trigger-extension-type": "CIT.TimePolicy",
"generic-trigger-extension-value": "generic-trigger-extension-value":
{ {
skipping to change at page 30, line 44 skipping to change at page 30, line 41
Property: start Property: start
Description: The start time of the window. Description: The start time of the window.
Type: Internet date and time as defined in [RFC3339]. Type: Internet date and time as defined in [RFC3339].
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: end Property: end
Description: The end time of the window. Description: The end-time of the window.
Type: Internet date and time as defined in [RFC3339]. Type: Internet date and time as defined in [RFC3339].
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Example UTCWindow object that describes a time window from 02:30 Example UTCWindow object that describes a time window from 02:30
01/01/2000 UTC to 04:30 01/01/2000 UTC: 01/01/2000 UTC to 04:30 01/01/2000 UTC:
{ {
"start": 2000-01-01T02:30:00.00Z, "start": 2000-01-01T02:30:00.00Z,
skipping to change at page 31, line 29 skipping to change at page 31, line 29
A LocalTimeWindow object describes a time range in local time. The A LocalTimeWindow object describes a time range in local time. The
reader of this object MUST interpret it as "the local time at the reader of this object MUST interpret it as "the local time at the
location of execution". For example, if the time window states 2AM location of execution". For example, if the time window states 2AM
to 4AM local time then a dCDN that has presence in both London (UTC) to 4AM local time then a dCDN that has presence in both London (UTC)
and New York (UTC-05:00) will execute the trigger at 2AM-4AM UTC in and New York (UTC-05:00) will execute the trigger at 2AM-4AM UTC in
London and at 2AM-4AM UTC-05:00 in New York. London and at 2AM-4AM UTC-05:00 in New York.
Property: start Property: start
Description: The start time of the window. Description: The start-time of the window.
Type: JSON string formatted as DateLocalTime as defined in Type: JSON string formatted as DateLocalTime as defined in
Section 4.2.3. Section 4.2.3.
Mandatory-to-Specify: Yes. Mandatory-to-Specify: Yes.
Property: end Property: end
Description: The end time of the window. Description: The end time of the window.
skipping to change at page 38, line 24 skipping to change at page 38, line 24
6.2. CDNI CI/T Trigger Error Codes types 6.2. CDNI CI/T Trigger Error Codes types
The IANA is requested to update the "CDNI CI/T Error Codes" The IANA is requested to update the "CDNI CI/T Error Codes"
subregistry (defined in Section 7.3 of [RFC8007] and located at subregistry (defined in Section 7.3 of [RFC8007] and located at
<https://www.iana.org/assignments/cdni-parameters>) with the <https://www.iana.org/assignments/cdni-parameters>) with the
following registration: following registration:
+------------+-----------------------------------+------------------+ +------------+-----------------------------------+------------------+
| Error Code | Description | Specification | | Error Code | Description | Specification |
+------------+-----------------------------------+------------------+ +------------+-----------------------------------+------------------+
| eextension | The dCDN failed to parse a | Section Section | | eextension | The dCDN failed to parse a | Section |
| | generic extension object, or does | 3.3.7 of this | | | generic extension object, or does | Section 3.3.7 of |
| | not support this extension. | document. | | | not support this extension. | this document. |
+------------+-----------------------------------+------------------+ +------------+-----------------------------------+------------------+
6.3. CDNI Media protocol types 6.3. CDNI Media protocol types
The IANA is requested to create a new "CDNI MediaProtocol Types" The IANA is requested to create a new "CDNI MediaProtocol Types"
subregistry in the "Content Delivery Networks Interconnection (CDNI) subregistry in the "Content Delivery Networks Interconnection (CDNI)
Parameters" registry. The "CDNI MediaProtocol Types" namespace Parameters" registry. The "CDNI MediaProtocol Types" namespace
defines the valid MediaProtocol object values in defines the valid MediaProtocol object values in
Section Section 3.3.4, used by the Playlist object. Additions to the Section Section 3.3.4, used by the Playlist object. Additions to the
MediaProtocol namespace conform to the "Specification Required" MediaProtocol namespace conform to the "Specification Required"
skipping to change at page 39, line 47 skipping to change at page 39, line 47
document. document.
8. Acknowledgments 8. Acknowledgments
TBD TBD
9. Contributors 9. Contributors
The authors would like to thank all members of the "Streaming Video The authors would like to thank all members of the "Streaming Video
Alliance" (SVA) Open Caching Working Group for their contribution in Alliance" (SVA) Open Caching Working Group for their contribution in
support of this document. support of this document. Authors also thank Kevin J. Ma for his
reviews and comments.
10. References 10. References
10.1. Normative References 10.1. Normative References
[ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax [ABNF] Crocker, D., Ed. and P. Overell, "Augmented BNF for Syntax
Specifications: ABNF", STD 68, RFC 5234, Specifications: ABNF", STD 68, RFC 5234,
DOI 10.17487/RFC5234, January 2008, DOI 10.17487/RFC5234, January 2008,
<https://www.rfc-editor.org/info/rfc5234>. <https://www.rfc-editor.org/info/rfc5234>.
 End of changes. 17 change blocks. 
54 lines changed or deleted 56 lines changed or added

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