idnits 2.17.1 draft-ietf-cdni-control-triggers-09.txt: Checking boilerplate required by RFC 5378 and the IETF Trust (see https://trustee.ietf.org/license-info): ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/1id-guidelines.txt: ---------------------------------------------------------------------------- No issues found here. Checking nits according to https://www.ietf.org/id-info/checklist : ---------------------------------------------------------------------------- No issues found here. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year -- The document date (October 16, 2015) is 3115 days in the past. Is this intentional? -- Found something which looks like a code comment -- if you have code sections in the document, please surround them with '' and '' lines. Checking references for intended status: Proposed Standard ---------------------------------------------------------------------------- (See RFCs 3967 and 4897 for information about using normative references to lower-maturity documents in RFCs) == Missing Reference: 'RFCthis' is mentioned on line 1714, but not defined ** Obsolete normative reference: RFC 7159 (Obsoleted by RFC 8259) ** Obsolete normative reference: RFC 7230 (Obsoleted by RFC 9110, RFC 9112) ** Obsolete normative reference: RFC 7231 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7232 (Obsoleted by RFC 9110) ** Obsolete normative reference: RFC 7525 (Obsoleted by RFC 9325) == Outdated reference: A later version (-11) exists of draft-greevenbosch-appsawg-cbor-cddl-06 == Outdated reference: A later version (-21) exists of draft-ietf-cdni-metadata-11 == Outdated reference: A later version (-20) exists of draft-ietf-cdni-redirection-13 -- Obsolete informational reference (is this intentional?): RFC 2818 (Obsoleted by RFC 9110) Summary: 5 errors (**), 0 flaws (~~), 5 warnings (==), 3 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group R. Murray 3 Internet-Draft B. Niven-Jenkins 4 Intended status: Standards Track Velocix (Alcatel-Lucent) 5 Expires: April 18, 2016 October 16, 2015 7 CDNI Control Interface / Triggers 8 draft-ietf-cdni-control-triggers-09 10 Abstract 12 This document describes the part of the CDN Interconnection Control 13 Interface that allows a CDN to trigger activity in an interconnected 14 CDN that is configured to deliver content on its behalf. The 15 upstream CDN can use this mechanism to request that the downstream 16 CDN pre-positions metadata or content, or that it invalidates or 17 purges metadata or content. The upstream CDN can monitor the status 18 of activity that it has triggered in the downstream CDN. 20 Requirements Language 22 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 23 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 24 document are to be interpreted as described in RFC 2119 [RFC2119]. 26 Status of This Memo 28 This Internet-Draft is submitted in full conformance with the 29 provisions of BCP 78 and BCP 79. 31 Internet-Drafts are working documents of the Internet Engineering 32 Task Force (IETF). Note that other groups may also distribute 33 working documents as Internet-Drafts. The list of current Internet- 34 Drafts is at http://datatracker.ietf.org/drafts/current/. 36 Internet-Drafts are draft documents valid for a maximum of six months 37 and may be updated, replaced, or obsoleted by other documents at any 38 time. It is inappropriate to use Internet-Drafts as reference 39 material or to cite them other than as "work in progress." 41 This Internet-Draft will expire on April 18, 2016. 43 Copyright Notice 45 Copyright (c) 2015 IETF Trust and the persons identified as the 46 document authors. All rights reserved. 48 This document is subject to BCP 78 and the IETF Trust's Legal 49 Provisions Relating to IETF Documents 50 (http://trustee.ietf.org/license-info) in effect on the date of 51 publication of this document. Please review these documents 52 carefully, as they describe your rights and restrictions with respect 53 to this document. Code Components extracted from this document must 54 include Simplified BSD License text as described in Section 4.e of 55 the Trust Legal Provisions and are provided without warranty as 56 described in the Simplified BSD License. 58 Table of Contents 60 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 61 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 4 62 2. Model for CDNI Triggers . . . . . . . . . . . . . . . . . . . 4 63 2.1. Timing of Triggered Activity . . . . . . . . . . . . . . 6 64 2.2. Scope of Triggered Activity . . . . . . . . . . . . . . . 6 65 2.3. Trigger Results . . . . . . . . . . . . . . . . . . . . . 6 66 3. Collections of Trigger Status Resources . . . . . . . . . . . 7 67 4. CDNI Trigger Interface . . . . . . . . . . . . . . . . . . . 8 68 4.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 9 69 4.2. Checking Status . . . . . . . . . . . . . . . . . . . . . 10 70 4.2.1. Polling Trigger Status Resource collections . . . . . 10 71 4.2.2. Polling Trigger Status Resources . . . . . . . . . . 11 72 4.3. Cancelling Triggers . . . . . . . . . . . . . . . . . . . 11 73 4.4. Deleting Triggers . . . . . . . . . . . . . . . . . . . . 12 74 4.5. Expiry of Trigger Status Resources . . . . . . . . . . . 12 75 4.6. Loop Detection and Prevention . . . . . . . . . . . . . . 13 76 4.7. Error Handling . . . . . . . . . . . . . . . . . . . . . 13 77 4.8. Content URLs . . . . . . . . . . . . . . . . . . . . . . 14 78 5. CI/T Object Properties and Encoding . . . . . . . . . . . . . 14 79 5.1. CI/T Objects . . . . . . . . . . . . . . . . . . . . . . 15 80 5.1.1. CI/T Commands . . . . . . . . . . . . . . . . . . . . 15 81 5.1.2. Trigger Status Resource . . . . . . . . . . . . . . . 16 82 5.1.3. Trigger Collection . . . . . . . . . . . . . . . . . 17 83 5.2. Properties of CI/T Objects . . . . . . . . . . . . . . . 18 84 5.2.1. Trigger Specification . . . . . . . . . . . . . . . . 19 85 5.2.2. Trigger Type . . . . . . . . . . . . . . . . . . . . 20 86 5.2.3. Trigger Status . . . . . . . . . . . . . . . . . . . 21 87 5.2.4. PatternMatch . . . . . . . . . . . . . . . . . . . . 21 88 5.2.5. Absolute Time . . . . . . . . . . . . . . . . . . . . 22 89 5.2.6. Error Description . . . . . . . . . . . . . . . . . . 22 90 5.2.7. Error Code . . . . . . . . . . . . . . . . . . . . . 23 91 5.3. Formalization of the JSON Data . . . . . . . . . . . . . 23 92 6. Examples . . . . . . . . . . . . . . . . . . . . . . . . . . 25 93 6.1. Creating Triggers . . . . . . . . . . . . . . . . . . . . 25 94 6.1.1. Preposition . . . . . . . . . . . . . . . . . . . . . 25 95 6.1.2. Invalidate . . . . . . . . . . . . . . . . . . . . . 27 97 6.2. Examining Trigger Status . . . . . . . . . . . . . . . . 28 98 6.2.1. Collection of All Triggers . . . . . . . . . . . . . 28 99 6.2.2. Filtered Collections of Trigger Status Resources . . 29 100 6.2.3. Individual Trigger Status Resources . . . . . . . . . 31 101 6.2.4. Polling for Change . . . . . . . . . . . . . . . . . 33 102 6.2.5. Deleting Trigger Status Resources . . . . . . . . . . 36 103 6.2.6. Error Reporting . . . . . . . . . . . . . . . . . . . 38 104 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 39 105 7.1. CDNI Payload Type Parameter Registrations . . . . . . . . 39 106 8. Security Considerations . . . . . . . . . . . . . . . . . . . 39 107 8.1. Authentication, Authorization, Confidentiality, Integrity 108 Protection . . . . . . . . . . . . . . . . . . . . . . . 40 109 8.2. Denial of Service . . . . . . . . . . . . . . . . . . . . 40 110 8.3. Privacy . . . . . . . . . . . . . . . . . . . . . . . . . 41 111 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 41 112 10. References . . . . . . . . . . . . . . . . . . . . . . . . . 41 113 10.1. Normative References . . . . . . . . . . . . . . . . . . 41 114 10.2. Informative References . . . . . . . . . . . . . . . . . 42 115 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 43 117 1. Introduction 119 [RFC6707] introduces the problem scope for CDN Interconnection (CDNI) 120 and lists the four categories of interfaces that may be used to 121 compose a CDNI solution (Control, Metadata, Request Routing, 122 Logging). 124 [RFC7336] expands on the information provided in [RFC6707] and 125 describes each of the interfaces and the relationships between them 126 in more detail. 128 This document describes the "CI/T" interface, "CDNI Control interface 129 / Triggers". It does not consider those parts of the control 130 interface that relate to configuration, bootstrapping or 131 authentication of CDN Interconnect interfaces. Section 4 of 132 [RFC7337] identifies the requirements specific to the CI interface, 133 requirements applicable to the CI/T interface are CI-1 to CI-6. 135 o Section 2 outlines the model for the CI/T Interface at a high 136 level. 138 o Section 3 describes collections of Trigger Status Resources. 140 o Section 4 defines the web service provided by the dCDN. 142 o Section 5 lists properties of CI/T Commands and Status Resources. 144 o Section 6 contains example messages. 146 1.1. Terminology 148 This document reuses the terminology defined in [RFC6707]. 150 2. Model for CDNI Triggers 152 A CI/T Command, sent from the uCDN to the dCDN, is a request for the 153 dCDN to do some work relating to data associated with content 154 requests originating from the uCDN. 156 There are two types of CI/T Command, CI/T Trigger Commands and CI/T 157 Cancel Commands. The CI/T Cancel Command can be used to request 158 cancellation of an earlier CI/T Trigger Command. A CI/T Trigger 159 Command is of one of the following types: 161 o preposition - used to instruct the dCDN to fetch metadata from the 162 uCDN, or content from any origin including the uCDN. 164 o invalidate - used to instruct the dCDN to revalidate specific 165 metadata or content before re-using it. 167 o purge - used to instruct the dCDN to delete specific metadata or 168 content. 170 The CI/T interface is a web service offered by the dCDN. It allows 171 CI/T commands to be issued, and triggered activity to be tracked. 172 When the dCDN accepts a CI/T Command it creates a resource describing 173 status of the triggered activity, a Trigger Status Resource. The 174 uCDN can poll Trigger Status Resources to monitor progress. 176 The dCDN maintains at least one collection of Trigger Status 177 Resources for each uCDN. Each uCDN only has access to its own 178 collections, the locations of which are shared when CDN 179 interconnection is established. 181 To trigger activity in the dCDN, the uCDN POSTs a CI/T Command to the 182 collection of Trigger Status Resources. If the dCDN accepts the CI/T 183 Command, it creates a new Trigger Status Resource and returns its 184 location to the uCDN. To monitor progress, the uCDN can GET the 185 Trigger Status Resource. To request cancellation of a CI/T Trigger 186 Command the uCDN can POST to the collection of Trigger Status 187 Resources, or simply DELETE the Trigger Status Resource. 189 In addition to the collection of all Trigger Status Resources for the 190 uCDN, the dCDN can maintain filtered views of that collection. These 191 filtered views are defined in Section 3 and include collections of 192 Trigger Status Resources corresponding to active and completed CI/T 193 Trigger Commands. These collections provide a mechanism for polling 194 the status of multiple jobs. 196 Figure 1 is an example showing the basic message flow used by the 197 uCDN to trigger activity in the dCDN, and for the uCDN to discover 198 the status of that activity. Only successful triggering is shown. 199 Examples of the messages are given in Section 6. 201 uCDN dCDN 202 | (1) POST http://dcdn.example.com/triggers/uCDN | 203 [ ] --------------------------------------------------> [ ]--+ 204 | [ ] | (2) 205 | (3) HTTP 201 Response [ ]<-+ 206 [ ] <-------------------------------------------------- [ ] 207 | Loc: http://dcdn.example.com/triggers/uCDN/123 | 208 | | 209 . . . 210 . . . 211 . . . 212 | | 213 | (4) GET http://dcdn.example.com/triggers/uCDN/123 | 214 [ ] --------------------------------------------------> [ ] 215 | [ ] 216 | (5) HTTP 200 Trigger Status Resource [ ] 217 [ ] <-------------------------------------------------- [ ] 218 | | 219 | | 221 Figure 1: Basic CDNI Message Flow for Triggers 223 The steps in Figure 1 are: 225 1. The uCDN triggers action in the dCDN by posting a CI/T Command to 226 a collection of Trigger Status Resources, 227 "http://dcdn.example.com/triggers/uCDN". The URL of this was 228 given to the uCDN when the CI/T interface was established. 230 2. The dCDN authenticates the request, validates the CI/T Command 231 and, if it accepts the request, creates a new Trigger Status 232 Resource. 234 3. The dCDN responds to the uCDN with an HTTP 201 response status, 235 and the location of the Trigger Status Resource. 237 4. The uCDN can poll, possibly repeatedly, the Trigger Status 238 Resource in the dCDN. 240 5. The dCDN responds with the Trigger Status Resource, describing 241 progress or results of the CI/T Trigger Command. 243 The remainder of this document describes the messages, Trigger Status 244 Resources, and collections of Trigger Status Resources in more 245 detail. 247 2.1. Timing of Triggered Activity 249 Timing of the execution of CI/T Commands is under the dCDN's control, 250 including its start-time and pacing of the activity in the network. 252 CI/T invalidate and purge commands MUST be applied to all data 253 acquired before the command was accepted by the dCDN. The dCDN 254 SHOULD NOT apply CI/T invalidate and purge commands to data acquired 255 after the CI/T Command was accepted, but this may not always be 256 achievable so the uCDN cannot count on that. 258 If the uCDN wishes to invalidate or purge content then immediately 259 pre-position replacement content at the same URLs, it SHOULD ensure 260 the dCDN has completed the invalidate/purge before initiating the 261 prepositioning. Otherwise, there is a risk that the dCDN pre- 262 positions the new content, then immediately invalidates or purges it 263 (as a result of the two uCDN requests running in parallel). 265 Because the CI/T Command timing is under the dCDN's control, the dCDN 266 implementation can choose whether to apply CI/T invalidate and purge 267 commands to content acquisition that has already started when the 268 command is received. 270 2.2. Scope of Triggered Activity 272 Each CI/T Command can operate on multiple metadata and content URLs. 274 Multiple representations of an HTTP resource may share the same URL. 275 CI/T Trigger Commands that invalidate or purge metadata or content 276 apply to all resource representations with matching URLs. 278 The dCDN MUST reject CI/T Commands from a uCDN that act on another 279 uCDN's data. Security considerations are discussed further in 280 section Section 8. 282 2.3. Trigger Results 284 Possible states for a Trigger Status Resource are defined in section 285 Section 5.2.3. 287 The CI/T Trigger Command MUST NOT be reported as 'complete' until all 288 actions have been completed successfully. The reasons for failure, 289 and URLs or Patterns affected, SHOULD be enumerated in the Trigger 290 Status Resource. For more detail, see section Section 4.7. 292 If a dCDN is also acting as a uCDN in a cascade, it MUST forward CI/T 293 Commands to any downstream CDNs that may be affected. The CI/T 294 Trigger Command MUST NOT be reported as 'complete' in a CDN until it 295 is 'complete' in all of its downstream CDNs. If a CI/T Trigger 296 Command is reported as 'processed' in any dCDN, intermediate CDNs 297 MUST NOT report 'complete', instead they must also report 298 'processed'. A CI/T Command MAY be reported as 'failed' as soon as 299 it fails in a CDN or in any of its downstream CDNs. A cancelled CI/T 300 Trigger Command MUST be reported as 'cancelling' until it has been 301 reported as 'cancelled', 'complete', or 'failed' by all dCDNs in a 302 cascade. 304 3. Collections of Trigger Status Resources 306 As described in Section 2, Trigger Status Resources exist in the dCDN 307 to report the status of activity triggered by each uCDN. 309 A collection of Trigger Status Resources is a resource that contains 310 a reference to each Trigger Status Resource in that collection. 312 The dCDN MUST make a collection of a uCDN's Trigger Status Resources 313 available to that uCDN. This collection includes all of the Trigger 314 Status Resources created for CI/T Commands from the uCDN that have 315 been accepted by the dCDN, and have not yet been deleted by the uCDN, 316 or expired and removed by the dCDN (as described in section 317 Section 4.4). Trigger Status Resources belonging to a uCDN MUST NOT 318 be visible to any other CDN. The dCDN could, for example, achieve 319 this by offering different collection URLs to each uCDN, and/or by 320 filtering the response based on the uCDN with which the HTTP client 321 is associated. 323 To trigger activity in a dCDN, or to cancel triggered activity, the 324 uCDN POSTs a CI/T Command to the dCDN's collection of the uCDN's 325 Trigger Status Resources. 327 In order to allow the uCDN to check the status of multiple jobs in a 328 single request, the dCDN SHOULD also maintain collections 329 representing filtered views of the collection of all Trigger Status 330 Resources. These filtered collections are optional-to-implement but, 331 if implemented, the dCDN MUST include links to them in the collection 332 of all Trigger Status Resources. The filtered collections are: 334 o Pending - Trigger Status Resources for CI/T Trigger Commands that 335 have been accepted, but not yet acted upon. 337 o Active - Trigger Status Resources for CI/T Trigger Commands that 338 are currently being processed in the dCDN. 340 o Complete - Trigger Status Resources representing activity that 341 completed successfully, and 'processed' CI/T Trigger Commands for 342 which no further status updates will be made by the dCDN. 344 o Failed - Trigger Status Resources representing CI/T Commands that 345 failes or were cancelled by the uCDN. 347 4. CDNI Trigger Interface 349 This section describes an interface to enable an upstream CDN to 350 trigger activity in a downstream CDN. 352 The CI/T interface builds on top of HTTP, so dCDNs may make use of 353 any HTTP feature when implementing the CI/T interface. For example, 354 a dCDN SHOULD make use of HTTP's caching mechanisms to indicate that 355 a requested response/representation has not been modified, reducing 356 the uCDN's processing needed to determine whether the status of 357 triggered activity has changed. 359 All dCDNs implementing CI/T MUST support the HTTP GET, HEAD, POST and 360 DELETE methods as defined in [RFC7231]. 362 The only representation specified in this document is JSON, 363 [RFC7159]. It MUST be supported by the uCDN and by the dCDN. 365 The URL of the dCDN's collection of all Trigger Status Resources 366 needs to be either discovered by, or configured in, the uCDN. The 367 mechanism for discovery of that URL is outside the scope of this 368 document. 370 CI/T Commands are POSTed to the dCDN's collection of all Trigger 371 Status Resources. If a CI/T Trigger Command is accepted by the dCDN, 372 the dCDN creates a new Trigger Status Resource and returns its URI to 373 the uCDN in an HTTP 201 response. The triggered activity can then be 374 monitored by the uCDN using that resource and the collections 375 described in Section 3. 377 The URI of each Trigger Status Resource is returned to the uCDN when 378 it is created, and URIs of all Trigger Status Resources are listed in 379 the dCDN's collection of all Trigger Status Resources. This means 380 all Trigger Status Resources can be discovered by the uCDN, so dCDNs 381 are free to assign whatever structure they desire to the URIs for CI/ 382 T resources. Therefore uCDNs MUST NOT make any assumptions regarding 383 the structure of CI/T URIs or the mapping between CI/T objects and 384 their associated URIs. URIs present in the examples in this document 385 are purely illustrative and are not intended to impose a definitive 386 structure on CI/T interface implementations. 388 4.1. Creating Triggers 390 To issue a CI/T Command, the uCDN makes an HTTP POST to the dCDN's 391 collection of all of the uCDN's Trigger Status Resources. The 392 request body of that POST is a CI/T Command, as described in 393 Section 5.1.1. 395 The dCDN validates the CI/T Command, if it is malformed or the uCDN 396 does not have sufficient access rights it MUST either respond with an 397 appropriate 4xx HTTP error code and a Trigger Status Resource MUST 398 NOT be created on the dCDN, or create a 'failed' Trigger Status 399 Resource containing an appropriate error description. 401 When a CI/T Trigger Command is accepted, the uCDN MUST create a new 402 Trigger Status Resource which will convey a specification of the CI/T 403 Command and its current status. The HTTP response to the dCDN MUST 404 have status code 201 and MUST convey the URI of the Trigger Status 405 Resource in the Location header field. The HTTP response SHOULD 406 include the content of the newly created Trigger Status Resource, 407 this is recommended particularly in cases where the CI/T Trigger 408 Command has completed immediately. 410 Once a Trigger Status Resource has been created the dCDN MUST NOT re- 411 use its URI, even after that Trigger Status Resource has been 412 removed. 414 The dCDN SHOULD track and report on progress of CI/T Trigger 415 Commands. If the dCDN is not able to do that, it MUST indicate that 416 it has accepted the request but will not be providing further status 417 updates. To do this, it sets the "status" of the Trigger Status 418 Resource to "processed". In this case, CI/T processing should 419 continue as for a "complete" request, so the Trigger Status Resource 420 MUST be added to the dCDN's collection of Complete Trigger Status 421 Resources. The dCDN SHOULD also provide an estimated completion time 422 for the request, by using the "etime" property of the Trigger Status 423 Resource. This will allow the uCDN to schedule prepositioning after 424 an earlier delete of the same URLs is expected to have finished. 426 If the dCDN is able to track the execution of CI/T Commands and a CI/ 427 T Command is queued by the dCDN for later action, the "status" 428 property of the Trigger Status Resource MUST be "pending". Once 429 processing has started the "status" MUST be "active". Finally, once 430 the CI/T Command is complete, the status MUST be set to "complete" or 431 "failed". 433 A CI/T Trigger Command may result in no activity in the dCDN if, for 434 example, it is an invalidate or purge request for data the dCDN has 435 not yet acquired, or a prepopulate request for data it has already 436 acquired and which is still valid. In this case, the "status" of the 437 Trigger Status Resource MUST be "processed" or "complete", and the 438 Trigger Status Resource MUST be added to the dCDN's collection of 439 Complete Trigger Status Resources. 441 Once created, Trigger Status Resources can be cancelled or deleted by 442 the uCDN, but not modified. The dCDN MUST reject PUT and POST 443 requests from the uCDN to Trigger Status Resources by responding with 444 an appropriate HTTP status code, for example 405 "Method Not 445 Allowed". 447 4.2. Checking Status 449 The uCDN has two ways to check progress of CI/T Commands it has 450 issued to the dCDN, described in sections Section 4.2.1 and 451 Section 4.2.2. 453 To check for change in status of a Trigger Status Resource or 454 collection of Trigger Status Resources without re-fetching the whole 455 Resource or Collection, Entity Tags SHOULD be included by the dCDN 456 for the uCDN to use as cache validators, as defined in [RFC7232]. 458 The dCDN SHOULD use the cache control headers for responses to GETs 459 for Trigger Status Resources and Collections to indicate the 460 frequency at which it recommends the uCDN should poll for change. 462 4.2.1. Polling Trigger Status Resource collections 464 The uCDN can fetch the collection of its Trigger Status Resources, or 465 filtered views of that collection. 467 This makes it possible to poll status of all CI/T Trigger Commands in 468 a single request. If the dCDN moves a Trigger Status Resource from 469 the Active to the Completed collection, the uCDN can fetch the result 470 of that activity. 472 When polling in this way, the uCDN SHOULD use HTTP Entity Tags to 473 monitor for change, rather than repeatedly fetching the whole 474 collection. An example of this is given in section Section 6.2.4. 476 4.2.2. Polling Trigger Status Resources 478 The uCDN has a URI provided by the dCDN for each Trigger Status 479 Resource it has created, it may fetch that Trigger Status Resource at 480 any time. 482 This can be used to retrieve progress information, and to fetch the 483 result of the CI/T Command. 485 When polling in this way, the uCDN SHOULD use HTTP Entity Tags to 486 monitor for change, rather than repeatedly fetching the Trigger 487 Status Resource. 489 4.3. Cancelling Triggers 491 The uCDN can request cancellation of a CI/T Trigger Command by 492 POSTing a CI/T Cancel Command to the collection of all Trigger Status 493 Resources. 495 Cancellation of a CI/T Trigger Command is optional-to-implement in 496 the dCDN. 498 The dCDN MUST respond to the CI/T Cancel Command appropriately, for 499 example with HTTP status code 200 "OK" if the cancellation has been 500 processed and the CI/T Command is inactive, 202 "Accepted" if the 501 command has been accepted but the CI/T Command remains active, or 501 502 "Not Implemented" if cancellation is not supported by the dCDN. 504 If cancellation of a "pending" Trigger Status Resource is accepted by 505 the dCDN, the dCDN SHOULD NOT start processing of that activity. 506 Issuing a CT/T cancel command for a "pending" Trigger Status Resource 507 does not however guarantee that the corresponding activity will not 508 be started, because the uCDN cannot control the timing of that 509 activity. Processing could, for example, start after the POST is 510 sent by the uCDN but before that request is processed by the dCDN. 512 If cancellation of an "active" or "processed" Trigger Status Resource 513 is accepted by the dCDN, the dCDN SHOULD stop processing the CI/T 514 Command. However, as with cancellation of a "pending" CI/T Command, 515 the dCDN does not guarantee this. 517 If the CI/T Command cannot be stopped immediately, the status in the 518 corresponding Trigger Status Resource MUST be set to "cancelling", 519 and the Trigger Status Resource MUST remain in the collection of 520 Trigger Status Resources for active CI/T Commands. If processing is 521 stopped before normal completion, the status value in the Trigger 522 Status Resource MUST be set to "cancelled", and the Trigger Status 523 Resource MUST be included in the collection of failed CT/T Trigger 524 Commands. 526 Cancellation of a "complete" or "failed" Trigger Status Resource 527 requires no processing in the dCDN, its status MUST NOT be changed to 528 "cancelled". 530 4.4. Deleting Triggers 532 The uCDN can delete Trigger Status Resources at any time, using the 533 HTTP DELETE method. The effect is similar to cancellation, but no 534 Trigger Status Resource remains afterwards. 536 Once deleted, the references to a Trigger Status Resource MUST be 537 removed from all Trigger Status Resource collections. Subsequent 538 requests to GET the deleted Trigger Status Resource SHOULD be 539 rejected by the dCDN with an HTTP error. 541 If a "pending" Trigger Status Resource is deleted, the dCDN SHOULD 542 NOT start processing of that activity. Deleting a "pending" Trigger 543 Status Resource does not however guarantee that it has not started 544 because the uCDN cannot control the timing of that activity. 545 Processing may, for example, start after the DELETE is sent by the 546 uCDN but before that request is processed by the dCDN. 548 If an "active" or "processed" Trigger Status Resource is deleted, the 549 dCDN SHOULD stop processing the CI/T Command. However, as with 550 deletion of a "pending" Trigger Status Resource, the dCDN does not 551 guarantee this. 553 Deletion of a "complete" or "failed" Trigger Status Resource requires 554 no processing in the dCDN other than deletion of the Trigger Status 555 Resource. 557 4.5. Expiry of Trigger Status Resources 559 The dCDN can choose to automatically delete Trigger Status Resources 560 some time after they become "complete", "processed", "failed" or 561 "cancelled". In this case, the dCDN will remove the Trigger Status 562 Resource and respond to subsequent requests for it with an HTTP 563 error. 565 If the dCDN performs this housekeeping, it MUST have reported the 566 length of time after which completed Trigger Status Resources will be 567 deleted via a property of the collection of all Trigger Status 568 Resources. It is RECOMMENDED that Trigger Status Resources are not 569 automatically deleted by the dCDN for at least 24 hours after they 570 become "complete", "processed", "failed" or "cancelled". 572 To ensure it is able to get the status of its Trigger Status 573 Resources for completed and failed CI/T Commands, it is RECOMMENDED 574 that the uCDN polling interval is less than the time after which 575 records for completed activity will be deleted. 577 4.6. Loop Detection and Prevention 579 Given three CDNs, A, B and C. If CDNs B and C delegate delivery of 580 CDN A's content to each other, CDN A's CI/T Commands could be passed 581 between CDNs B and C in a loop. More complex networks of CDNs could 582 contain similar loops involving more hops. 584 In order to prevent and detect such CI/T loops, each CDN uses a CDN 585 Provider ID to uniquely identify itself. In every CI/T Command it 586 originates or cascades, each CDN MUST append an array element 587 containing its CDN Provider ID to a JSON array under an entry named 588 "cdn-path". When receiving CI/T Commands a dCDN MUST check the cdn- 589 path and reject any CI/T Command which already contains its own CDN 590 Provider ID in the cdn-path. Transit CDNs MUST check the cdn-path 591 and not cascade the CI/T Command to dCDNs that are already listed in 592 cdn-path. 594 The CDN Provider Id consists of the two characters "AS" followed by 595 the CDN Provider's Autonomous System number, then a colon (':') and 596 an additional qualifier that is used to guarantee uniqueness in case 597 a particular AS has multiple independent CDNs deployed. For example 598 "AS64496:0". 600 If the CDN provider has multiple Autonomous Systems, the same AS 601 number SHOULD be used in all messages from that CDN provider, unless 602 there are multiple distinct CDNs. 604 If the RI interface described in [I-D.ietf-cdni-redirection] is 605 implemented by the dCDN, the CI/T and RI interfaces SHOULD use the 606 same CDN Provider Id. 608 4.7. Error Handling 610 A dCDN can signal rejection of a CI/T Command using HTTP status 611 codes. For example, 400 if the request is malformed, or 403 or 404 612 if the uCDN does not have permission to issue CI/T Commands or it is 613 trying to act on another CDN's data. 615 If any part of the CI/T Trigger Command fails, the trigger SHOULD be 616 reported as "failed" once its activity is complete or if no further 617 errors will be reported. The "errors" property in the Trigger Status 618 Resource will be used to enumerate which actions failed and the 619 reasons for failure, and can be present while the Trigger Status 620 Resource is still "pending" or "active", if the CI/T Trigger Command 621 is still running for some URLs or Patterns in the Trigger 622 Specification. 624 Once a request has been accepted, processing errors are reported in 625 the Trigger Status Resource using a list of Error Descriptions. Each 626 Error Description is used to report errors against one or more of the 627 URLs or Patterns in the Trigger Specification. 629 If a surrogate affected by a CI/T Trigger Command is offline in the 630 dCDN, or the dCDN is unable to pass a CI/T Command on to any of its 631 cascaded dCDNs: 633 o If the CI/T Command is abandoned by the dCDN, the dCDN SHOULD 634 report an error. 636 o A CI/T "invalidate" command may be reported as "complete" when 637 surrogates that may have the data are offline. In this case, 638 surrogates MUST NOT use the affected data without first 639 revalidating it when they are back online. 641 o CI/T "preposition" and "purge" commands can be reported as 642 "processed" if affected caches are offline and the activity will 643 complete when they return to service. 645 o Otherwise, the dCDN SHOULD keep the Trigger Status Resource in 646 state "pending" or "active" until the CI/T Command is acted upon, 647 or the uCDN chooses to cancel it. 649 4.8. Content URLs 651 Therefore, if content URLs are transformed by an intermediate CDN in 652 a cascade, that intermediate CDN MUST transform URLs in CI/T Commands 653 it passes to its dCDN. 655 When processing Trigger Specifications, CDNs MUST ignore the URL 656 scheme (http or https) in comparing URLs. For example, for a CI/T 657 invalidate or purge command, content MUST be invalidated or purged 658 regardless of the protocol clients use to request it. 660 5. CI/T Object Properties and Encoding 662 CI/T Commands, Trigger Status Resources and Trigger Collections and 663 their properties are encoded using JSON, as defined in sections 664 Section 5.1.1, Section 5.2.1, and Section 5.1.2. They MUST use the 665 MIME Media Type 'application/cdni', with parameter 'ptype' values as 666 defined below and in Section 7.1. 668 Names in JSON are case sensitive. The names and literal values 669 specified in the present document MUST always use lower-case. 671 JSON types, including 'object', 'array', 'number' and 'string' are 672 defined in [RFC7159]. 674 Unrecognised name/value pairs in JSON objects SHOULD NOT be treated 675 as an error by either the uCDN or dCDN. They SHOULD be ignored in 676 the processing, and passed on by dCDN to any further dCDNs in a 677 cascade. 679 5.1. CI/T Objects 681 The top-level objects defined by the CI/T interface are described in 682 this section. 684 The encoding of values used by these objects is described in 685 Section 5.2. 687 5.1.1. CI/T Commands 689 CI/T Commands MUST use a MIME Media Type of 'application/cdni; 690 ptype=ci-trigger-command'. 692 A CI/T Command is encoded as a JSON object containing the following 693 name/value pairs. 695 Name: trigger 697 Description: A specification of the trigger type, and a set of 698 data to act upon. 700 Value: A Trigger Specification, as defined in Section 5.2.1. 702 Mandatory: No, but exactly one of "trigger" or "cancel" MUST be 703 present in a CI/T Command. 705 Name: cancel 707 Description: The URLs of Trigger Status Resources for CI/T 708 Trigger Commands that the uCDN wants to cancel. 710 Value: A non-empty JSON array of URLs represented as JSON 711 strings. 713 Mandatory: No, but exactly one of "trigger" or "cancel" MUST be 714 present in a CI/T Command. 716 Name: cdn-path 718 Description: The CDN Provider Identifiers of CDNs that have 719 already accepted the CI/T Command. 721 Value: A non-empty JSON array of JSON strings, where each 722 string is a CDN Provider Identifier as defined in Section 4.6. 724 Mandatory: Yes. 726 5.1.2. Trigger Status Resource 728 Trigger Status Resources MUST use a MIME Media Type of 'application/ 729 cdni; ptype=ci-trigger-status'. 731 A Trigger Status Resource is encoded as a JSON object containing the 732 following name/value pairs. 734 Name: trigger 736 Description: The Trigger Specification posted in the body of 737 the CI/T Command. Note that this need not be a byte-for-byte 738 copy. For example, in the JSON representation the dCDN may re- 739 serialise the information differently. 741 Value: A Trigger Specification, as defined in Section 5.2.1. 743 Mandatory: Yes 745 Name: ctime 747 Description: Time at which the CI/T Command was received by the 748 dCDN. Time is determined by the dCDN, there is no requirement 749 to synchronise clocks between interconnected CDNs. 751 Value: Absolute Time, as defined in Section 5.2.5. 753 Mandatory: Yes 755 Name: mtime 757 Description: Time at which the Trigger Status Resource was last 758 modified. Time is determined by the dCDN, there is no 759 requirement to synchronise clocks between interconnected CDNs. 761 Value: Absolute Time, as defined in Section 5.2.5. 763 Mandatory: Yes 765 Name: etime 767 Description: Estimate of the time at which the dCDN expects to 768 complete the activity. Time is determined by the dCDN, there 769 is no requirement to synchronise clocks between interconnected 770 CDNs. 772 Value: Absolute Time, as defined in Section 5.2.5. 774 Mandatory: No 776 Name: status 778 Description: Current status of the triggered activity. 780 Value: Trigger Status, as defined in Section 5.2.3. 782 Mandatory: Yes 784 Name: errors 786 Description: Descriptions of errors that have occurred while 787 processing a Trigger Command. 789 Value: An array of Error Description, as defined in 790 Section 5.2.6. An empty array is allowed, and equivalent to 791 omitting "errors" from the object. 793 Mandatory: No. 795 5.1.3. Trigger Collection 797 Trigger Collections MUST use a MIME Media Type of 'application/cdni; 798 ptype=ci-trigger-collection'. 800 A Trigger Collection is encoded as a JSON object containing the 801 following name/value pairs. 803 Name: triggers 805 Description: Links to Trigger Status Resources in the 806 collection. 808 Value: A JSON array of zero or more URLs, represented as JSON 809 strings. 811 Mandatory: Yes 813 Name: staleresourcetime 815 Description: The length of time for which the dCDN guarantees 816 to keep a completed Trigger Status Resource. After this time, 817 the dCDN SHOULD delete the Trigger Status Resource and all 818 references to it from collections. 820 Value: A JSON number, which must be a positive integer, 821 representing time in seconds. 823 Mandatory: Yes, in the collection of all Trigger Status 824 Resources if the dCDN deletes stale entries. If the property 825 is present in the filtered collections, it MUST have the same 826 value as in the collection of all Trigger Status Resources. 828 Names: coll-all, coll-pending, coll-active, coll-complete, coll- 829 failed 831 Description: Link to a Trigger Collection. 833 Value: A URL represented as a JSON string. 835 Mandatory: Links to all of the filtered collections are 836 mandatory in the collection of all Trigger Status Resources, if 837 the dCDN implements the filtered collections. Otherwise, 838 optional. 840 Name: cdn-id 842 Description: The CDN Provider Identifier of the dCDN. 844 Value: A JSON string, the dCDN's CDN Provider Identifier, as 845 defined in Section 4.6. 847 Mandatory: Only in the collection of all Trigger Status 848 Resources, if the dCDN implements the filtered collections. 849 Optional in the filtered collections (the uCDN can always find 850 the dCDN's cdn-id in the collection of all Trigger Status 851 Resources, but the dCDN can choose to repeat that information 852 in its implementation of filtered collections). 854 5.2. Properties of CI/T Objects 856 This section defines the values that can appear in the top level 857 objects described in Section 5.1, and their encodings. 859 5.2.1. Trigger Specification 861 A Trigger Collection is encoded as a JSON object containing the 862 following name/value pairs. 864 An unrecognised name/value pair in the Trigger Specification object 865 contained in a CI/T Command SHOULD be preserved in the Trigger 866 Specification of any Trigger Status Resource it creates. 868 Name: type 870 Description: This property defines the type of the CI/T Trigger 871 Command. 873 Value: Trigger Type, as defined in Section 5.2.2. 875 Mandatory: Yes 877 Name: metadata.urls 879 Description: The uCDN URLs of the metadata the CI/T Trigger 880 Command applies to. 882 Value: A JSON array of URLs represented as JSON strings. 884 Mandatory: No, but at least one of 'metadata.*' or 'content.*' 885 MUST be present and non-empty. 887 Name: content.urls 889 Description: URLs of content the CI/T Trigger Command applies 890 to, see Section 4.8. 892 Value: A JSON array of URLs represented as JSON strings. 894 Mandatory: No, but at least one of 'metadata.*' or 'content.*' 895 MUST be present and non-empty. 897 Name: content.ccid 899 Description: The Content Collection Identifier of content the 900 trigger applies to. The 'ccid' is a grouping of content, as 901 defined by [I-D.ietf-cdni-metadata]. 903 Value: A JSON array of strings, where each string is a Content 904 Collection Identifier. 906 Mandatory: No, but at least one of 'metadata.*' or 'content.*' 907 MUST be present and non-empty. 909 Name: metadata.patterns 911 Description: The metadata the trigger applies to. 913 Value: A JSON array of Pattern Match, as defined in 914 Section 5.2.4. 916 Mandatory: No, but at least one of 'metadata.*' or 'content.*' 917 MUST be present and non-empty, and metadata.patterns MUST NOT 918 be present if the TriggerType is Preposition. 920 Name: content.patterns 922 Description: The content data the trigger applies to. 924 Value: A JSON array of Pattern Match, as defined in 925 Section 5.2.4. 927 Mandatory: No, but at least one of 'metadata.*' or 'content.*' 928 MUST be present and non-empty, and content.patterns MUST NOT be 929 present if the TriggerType is Preposition. 931 5.2.2. Trigger Type 933 Trigger Type is used in a Trigger Specification to describe trigger 934 action. It MUST be one of the JSON strings in the following table: 936 +-------------+-----------------------------------------------------+ 937 | JSON String | Description | 938 +-------------+-----------------------------------------------------+ 939 | preposition | A request for the dCDN to acquire metadata or | 940 | | content. | 941 | invalidate | A request for the dCDN to invalidate metadata or | 942 | | content. After servicing this request the dCDN will | 943 | | not use the specified data without first re- | 944 | | validating it using, for example, an "If-None- | 945 | | Match" HTTP request. The dCDN need not erase the | 946 | | associated data. | 947 | purge | A request for the dCDN to erase metadata or | 948 | | content. After servicing the request, the specified | 949 | | data MUST NOT be held on the dCDN (the dCDN should | 950 | | re-acquire the metadata or content from uCDN if it | 951 | | needs it). | 952 +-------------+-----------------------------------------------------+ 954 5.2.3. Trigger Status 956 This describes the current status of a Trigger. It MUST be one of 957 the JSON strings in the following table: 959 +------------+------------------------------------------------------+ 960 | JSON | Description | 961 | String | | 962 +------------+------------------------------------------------------+ 963 | pending | The CI/T Trigger Command has not yet been acted | 964 | | upon. | 965 | active | The CI/T Trigger Command is currently being acted | 966 | | upon. | 967 | complete | The CI/T Trigger Command completed successfully. | 968 | processed | The CI/T Trigger Command has been accepted and no | 969 | | further status update will be made (can be used in | 970 | | cases where completion cannot be confirmed). | 971 | failed | The CI/T Trigger Command could not be completed. | 972 | cancelling | Processing of the CI/T Trigger Command is still in | 973 | | progress, but the CI/T Trigger Command has been | 974 | | cancelled by the uCDN. | 975 | cancelled | The CI/T Trigger Command was cancelled by the uCDN. | 976 +------------+------------------------------------------------------+ 978 5.2.4. PatternMatch 980 A Pattern Match consists of a string pattern to match, and flags 981 describing the type of match. 983 It is encoded as a JSON object with the following name/value pairs: 985 Name: pattern 987 Description: A pattern for string matching. 989 Value: A JSON string representing the pattern. The pattern may 990 contain the wildcards * and ?, where * matches any sequence of 991 characters (including the empty string) and ? matches exactly 992 one character. The three literals "\" , "*" and "?" MUST be 993 escaped as "\\", "\*" and "\?". 995 Mandatory: Yes. 997 Name: case-sensitive 999 Description: Flag indicating whether or not case-sensitive 1000 matching should be used. 1002 Value: One of the JSON values 'true' or 'false'. 1004 Mandatory: No, default is case-insensitive match. 1006 Name: match-query-string 1008 Description: Flag indicating whether or not the query string 1009 should be included in the pattern match. 1011 Value: One of the JSON values 'true' or 'false'. 1013 Mandatory: No, default is not to include the query string in 1014 the pattern match. 1016 Example of case-sensitive prefix match against 1017 "http://www.example.com/trailers/": 1019 { 1020 "pattern": "http://www.example.com/trailers/*", 1021 "case-sensitive": true 1022 } 1024 5.2.5. Absolute Time 1026 A JSON number, seconds since the UNIX epoch. 1028 5.2.6. Error Description 1030 An Error Description is used to report failure of a CI/T Command, or 1031 in the activity it triggered. It is encoded as a JSON object with 1032 the following name/value pairs: 1034 Name: error 1036 Value: Error Code, as defined in Section 5.2.7. 1038 Mandatory: Yes. 1040 Names: metadata.urls, content.urls, metadata.patterns, 1041 content.patterns 1043 Description: Metadata and content references copied from the 1044 Trigger Specification. Only those URLs and patterns to which 1045 the error applies are included in each property, but those URLs 1046 and patterns MUST be exactly as they appear in the request, the 1047 dCDN MUST NOT generalise the URLs. (For example, if the uCDN 1048 requests prepositioning of URLs "http://content.example.com/a" 1049 and "http://content.example.com/b", the dCDN must not 1050 generalise its error report to Pattern 1051 "http://content.example.com/*".) 1053 Value: A JSON array of JSON strings, where each string is 1054 copied from a 'content.*' or 'metadata.*' value in the 1055 corresponding Trigger Specification. 1057 Mandatory: At least one of these name/value pairs is mandatory 1058 in each Error Description object. 1060 Name: description 1062 Description: A human-readable description of the error. 1064 Value: A JSON string, the human-readable description. 1066 Mandatory: No. 1068 5.2.7. Error Code 1070 This type is used by the dCDN to report failures in trigger 1071 processing. 1073 +------------+------------------------------------------------------+ 1074 | Error Code | Description | 1075 +------------+------------------------------------------------------+ 1076 | emeta | The dCDN was unable to acquire metadata required to | 1077 | | fulfil the request. | 1078 | econtent | The dCDN was unable to acquire content (CT/T | 1079 | | preposition commands only). | 1080 | eperm | The uCDN does not have permission to issue the CI/T | 1081 | | Command (for example, the data is owned by another | 1082 | | CDN). | 1083 | ereject | The dCDN is not willing to fulfil the CI/T Command | 1084 | | (for example, a preposition request for content at a | 1085 | | time when the dCDN would not accept Request Routing | 1086 | | requests from the uCDN). | 1087 | ecdn | An internal error in the dCDN or one of its | 1088 | | downstream CDNs. | 1089 | ecancelled | The uCDN cancelled the request. | 1090 +------------+------------------------------------------------------+ 1092 5.3. Formalization of the JSON Data 1094 The JSON data described in this document has been formalised using 1095 CDDL [I-D.greevenbosch-appsawg-cbor-cddl] as follows: 1097 CIT-object = CIT-command / Trigger-Status-Resource / Trigger-Collection 1098 CIT-command ; use media type application/cdni; ptype=ci-trigger-command 1099 = { 1100 ? trigger: Triggerspec 1101 ? cancel: [* URI] 1102 cdn-path: [* Cdn-PID] 1103 } 1105 Trigger-Status-Resource ; application/cdni; ptype=ci-trigger-status 1106 = { 1107 trigger: Triggerspec 1108 ctime: Absolute-Time 1109 mtime: Absolute-Time 1110 ? etime: Absolute-Time 1111 status: Trigger-Status 1112 ? errors: [* Error-Description] 1113 } 1115 Trigger-Collection ; application/cdni; ptype=ci-trigger-collection 1116 = { 1117 triggers: [* URI] 1118 ? staleresourcetime: int ; time in seconds 1119 ? coll-all: URI 1120 ? coll-pending: URI 1121 ? coll-active: URI 1122 ? coll-complete: URI 1123 ? coll-failed: URI 1124 ? cdn-id: Cdn-PID 1125 } 1127 Triggerspec = { ; 5.2.1 1128 type: Trigger-Type 1129 ? metadata.urls: [* URI] 1130 ? content.urls: [* URI] 1131 ? content.ccid: [* Ccid] 1132 ? metadata.patterns: [* Pattern-Match] 1133 ? content.patterns: [* Pattern-Match] 1134 } 1136 Trigger-Type = "preposition" / "invalidate" / "purge" ; 5.2.2 1138 Trigger-Status = "pending" / "active" / "complete" / "processed" 1139 / "failed" / "cancelling" / "cancelled" ; 5.2.3 1141 Pattern-Match = { ; 5.2.4 1142 pattern: tstr 1143 ? case-sensitive: bool 1144 ? match-query-string: bool 1145 } 1146 Absolute-Time = number ; seconds since UNIX epoch, 5.2.5 1148 Error-Description = { ; 5.2.6 1149 error: Error-Code 1150 ? metadata.urls: [* URI] 1151 ? content.urls: [* URI] 1152 ? metadata.patterns: [* Pattern-Match] 1153 ? content.patterns: [* Pattern-Match] 1154 ? description: tstr 1155 } 1157 Error-Code = "emeta" / "econtent" / "eperm" / "ereject" 1158 / "ecdn" / "ecancelled" ; 5.2.7 1160 Ccid = tstr ; see I-D.ietf-cdni-metadata 1162 Cdn-PID = tstr .regexp "AS[0-9]+:[0-9]+" 1164 URI = tstr 1166 6. Examples 1168 The following sections provide examples of different CI/T objects 1169 encoded as JSON. 1171 Discovery of the triggers interface is out of scope of this document. 1172 In an implementation, all CI/T URLs are under the control of the 1173 dCDN. The uCDN MUST NOT attempt to ascribe any meaning to individual 1174 elements of the path. 1176 In examples in this section, the URL 'http://dcdn.example.com/ 1177 triggers' is used as the location of the collection of all Trigger 1178 Status Resources, and the CDN Provider Id of uCDN is "AS64496:1". 1180 6.1. Creating Triggers 1182 Examples of the uCDN triggering activity in the dCDN: 1184 6.1.1. Preposition 1186 An example of a CI/T preposition command, a POST to the collection of 1187 all Trigger Status Resources. 1189 Note that "metadata.patterns" and "content.patterns" are not allowed 1190 in a preposition Trigger Specification. 1192 REQUEST: 1194 POST /triggers HTTP/1.1 1195 User-Agent: example-user-agent/0.1 1196 Host: dcdn.example.com 1197 Accept: */* 1198 Content-Type: application/cdni; ptype=ci-trigger-command 1199 Content-Length: 347 1201 { 1202 "trigger" : { 1203 "type": "preposition", 1205 "metadata.urls" : [ "http://metadata.example.com/a/b/c" ], 1206 "content.urls" : [ 1207 "http://www.example.com/a/b/c/1", 1208 "http://www.example.com/a/b/c/2", 1209 "http://www.example.com/a/b/c/3", 1210 "http://www.example.com/a/b/c/4" 1211 ] 1212 }, 1213 "cdn-path" : [ "AS64496:1" ] 1214 } 1216 RESPONSE: 1218 HTTP/1.1 201 Created 1219 Date: Sun, 31 Aug 2014 09:53:18 GMT 1220 Content-Length: 472 1221 Content-Type: application/cdni; ptype=ci-trigger-status 1222 Location: http://dcdn.example.com/triggers/0 1223 Server: example-server/0.1 1225 { 1226 "ctime": 1409478798, 1227 "etime": 1409478806, 1228 "mtime": 1409478798, 1229 "status": "pending", 1230 "trigger": { 1231 "content.urls": [ 1232 "http://www.example.com/a/b/c/1", 1233 "http://www.example.com/a/b/c/2", 1234 "http://www.example.com/a/b/c/3", 1235 "http://www.example.com/a/b/c/4" 1236 ], 1237 "metadata.urls": [ 1238 "http://metadata.example.com/a/b/c" 1239 ], 1240 "type": "preposition" 1241 } 1243 } 1245 6.1.2. Invalidate 1247 An example of a CI/T invalidate command, another POST to the 1248 collection of all Trigger Status Resources. This instructs the dCDN 1249 to re-validate the content at "http://www.example.com/a/index.html", 1250 as well as any metadata and content whose URLs are prefixed by 1251 "http://metadata.example.com/a/b/" using case-insensitive matching, 1252 and "http://www.example.com/a/b/" respectively, using case-sensitive 1253 matching. 1255 REQUEST: 1257 POST /triggers HTTP/1.1 1258 User-Agent: example-user-agent/0.1 1259 Host: dcdn.example.com 1260 Accept: */* 1261 Content-Type: application/cdni; ptype=ci-trigger-command 1262 Content-Length: 384 1264 { 1265 "trigger" : { 1266 "type": "invalidate", 1268 "metadata.patterns" : [ 1269 { "pattern" : "http://metadata.example.com/a/b/*" } 1270 ], 1272 "content.urls" : [ "http://www.example.com/a/index.html" ], 1273 "content.patterns" : [ 1274 { "pattern" : "http://www.example.com/a/b/*", 1275 "case-sensitive" : true 1276 } 1277 ] 1278 }, 1279 "cdn-path" : [ "AS64496:1" ] 1280 } 1282 RESPONSE: 1284 HTTP/1.1 201 Created 1285 Date: Sun, 31 Aug 2014 09:53:19 GMT 1286 Content-Length: 551 1287 Content-Type: application/cdni; ptype=ci-trigger-status 1288 Location: http://dcdn.example.com/triggers/1 1289 Server: example-server/0.1 1290 { 1291 "ctime": 1409478799, 1292 "etime": 1409478807, 1293 "mtime": 1409478799, 1294 "status": "pending", 1295 "trigger": { 1296 "content.patterns": [ 1297 { 1298 "case-sensitive": true, 1299 "pattern": "http://www.example.com/a/b/*" 1300 } 1301 ], 1302 "content.urls": [ 1303 "http://www.example.com/a/index.html" 1304 ], 1305 "metadata.patterns": [ 1306 { 1307 "pattern": "http://metadata.example.com/a/b/*" 1308 } 1309 ], 1310 "type": "invalidate" 1311 } 1312 } 1314 6.2. Examining Trigger Status 1316 Once Trigger Status Resources have been created, the uCDN can check 1317 their status as shown in these examples. 1319 6.2.1. Collection of All Triggers 1321 The uCDN can fetch the collection of all Trigger Status Resources it 1322 has created that have not yet been deleted or removed as expired. 1323 After creation of the "preposition" and "invalidate" triggers shown 1324 above, this collection might look as follows: 1326 REQUEST: 1328 GET /triggers HTTP/1.1 1329 User-Agent: example-user-agent/0.1 1330 Host: dcdn.example.com 1331 Accept: */* 1333 RESPONSE: 1335 HTTP/1.1 200 OK 1336 Content-Length: 347 1337 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1338 Server: example-server/0.1 1339 Etag: "-6516741166528256414" 1340 Cache-Control: max-age=60 1341 Date: Sun, 31 Aug 2014 09:53:19 GMT 1342 Content-Type: application/cdni; ptype=ci-trigger-collection 1344 { 1345 "cdn-id": "AS64496:0", 1346 "coll-active": "/triggers/active", 1347 "coll-complete": "/triggers/complete", 1348 "coll-failed": "/triggers/failed", 1349 "coll-pending": "/triggers/pending", 1350 "staleresourcetime": 86400, 1351 "triggers": [ 1352 "http://dcdn.example.com/triggers/0", 1353 "http://dcdn.example.com/triggers/1" 1354 ] 1355 } 1357 6.2.2. Filtered Collections of Trigger Status Resources 1359 The filtered collections are also available to the uCDN. Before the 1360 dCDN starts processing the two CI/T Trigger Commands shown above, 1361 both will appear in the collection of Pending Triggers, for example: 1363 REQUEST: 1365 GET /triggers/pending HTTP/1.1 1366 User-Agent: example-user-agent/0.1 1367 Host: dcdn.example.com 1368 Accept: */* 1370 RESPONSE: 1372 HTTP/1.1 200 OK 1373 Content-Length: 153 1374 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1375 Server: example-server/0.1 1376 Etag: "5012053611544832286" 1377 Cache-Control: max-age=60 1378 Date: Sun, 31 Aug 2014 09:53:19 GMT 1379 Content-Type: application/cdni; ptype=ci-trigger-collection 1381 { 1382 "staleresourcetime": 86400, 1383 "triggers": [ 1384 "http://dcdn.example.com/triggers/0", 1385 "http://dcdn.example.com/triggers/1" 1386 ] 1387 } 1389 At this point, if no other Trigger Status Resources had been created, 1390 the other filtered views would be empty. For example: 1392 REQUEST: 1394 GET /triggers/complete HTTP/1.1 1395 User-Agent: example-user-agent/0.1 1396 Host: dcdn.example.com 1397 Accept: */* 1399 RESPONSE: 1401 HTTP/1.1 200 OK 1402 Content-Length: 56 1403 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1404 Server: example-server/0.1 1405 Etag: "2986340333785000363" 1406 Cache-Control: max-age=60 1407 Date: Sun, 31 Aug 2014 09:53:19 GMT 1408 Content-Type: application/cdni; ptype=ci-trigger-collection 1410 { 1411 "staleresourcetime": 86400, 1412 "triggers": [] 1413 } 1415 6.2.3. Individual Trigger Status Resources 1417 The Trigger Status Resources can also be examined for detail about 1418 individual CI/T Trigger Commands. For example, for the CI/T 1419 "preposition" and "invalidate" commands from previous examples: 1421 REQUEST: 1423 GET /triggers/0 HTTP/1.1 1424 User-Agent: example-user-agent/0.1 1425 Host: dcdn.example.com 1426 Accept: */* 1428 RESPONSE: 1430 HTTP/1.1 200 OK 1431 Content-Length: 472 1432 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1433 Server: example-server/0.1 1434 Etag: "-4765587034697674779" 1435 Cache-Control: max-age=60 1436 Date: Sun, 31 Aug 2014 09:53:19 GMT 1437 Content-Type: application/cdni; ptype=ci-trigger-status 1439 { 1440 "ctime": 1409478798, 1441 "etime": 1409478806, 1442 "mtime": 1409478798, 1443 "status": "pending", 1444 "trigger": { 1445 "content.urls": [ 1446 "http://www.example.com/a/b/c/1", 1447 "http://www.example.com/a/b/c/2", 1448 "http://www.example.com/a/b/c/3", 1449 "http://www.example.com/a/b/c/4" 1450 ], 1451 "metadata.urls": [ 1452 "http://metadata.example.com/a/b/c" 1453 ], 1454 "type": "preposition" 1455 } 1456 } 1458 REQUEST: 1460 GET /triggers/1 HTTP/1.1 1461 User-Agent: example-user-agent/0.1 1462 Host: dcdn.example.com 1463 Accept: */* 1465 RESPONSE: 1467 HTTP/1.1 200 OK 1468 Content-Length: 551 1469 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1470 Server: example-server/0.1 1471 Etag: "-7657333837290433420" 1472 Cache-Control: max-age=60 1473 Date: Sun, 31 Aug 2014 09:53:19 GMT 1474 Content-Type: application/cdni; ptype=ci-trigger-status 1476 { 1477 "ctime": 1409478799, 1478 "etime": 1409478807, 1479 "mtime": 1409478799, 1480 "status": "pending", 1481 "trigger": { 1482 "content.patterns": [ 1483 { 1484 "case-sensitive": true, 1485 "pattern": "http://www.example.com/a/b/*" 1486 } 1487 ], 1488 "content.urls": [ 1489 "http://www.example.com/a/index.html" 1490 ], 1491 "metadata.patterns": [ 1492 { 1493 "pattern": "http://metadata.example.com/a/b/*" 1494 } 1495 ], 1496 "type": "invalidate" 1497 } 1498 } 1500 6.2.4. Polling for Change 1502 The uCDN SHOULD use the Entity Tags of collections or Trigger Status 1503 Resources when polling for change in status, as shown in the 1504 following examples: 1506 REQUEST: 1508 GET /triggers/pending HTTP/1.1 1509 User-Agent: example-user-agent/0.1 1510 Host: dcdn.example.com 1511 Accept: */* 1512 If-None-Match: "5012053611544832286" 1514 RESPONSE: 1516 HTTP/1.1 304 Not Modified 1517 Content-Length: 0 1518 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1519 Server: example-server/0.1 1520 Etag: "5012053611544832286" 1521 Cache-Control: max-age=60 1522 Date: Sun, 31 Aug 2014 09:53:19 GMT 1523 Content-Type: application/cdni; ptype=ci-trigger-collection 1525 REQUEST: 1527 GET /triggers/0 HTTP/1.1 1528 User-Agent: example-user-agent/0.1 1529 Host: dcdn.example.com 1530 Accept: */* 1531 If-None-Match: "-4765587034697674779" 1533 RESPONSE: 1535 HTTP/1.1 304 Not Modified 1536 Content-Length: 0 1537 Expires: Sun, 31 Aug 2014 09:54:19 GMT 1538 Server: example-server/0.1 1539 Etag: "-4765587034697674779" 1540 Cache-Control: max-age=60 1541 Date: Sun, 31 Aug 2014 09:53:19 GMT 1542 Content-Type: application/cdni; ptype=ci-trigger-status 1544 When the CI/T Trigger Command is complete, the contents of the 1545 filtered collections will be updated along with their Entity Tags. 1546 For example, when the two example CI/T Trigger Commands are complete, 1547 the collections of pending and complete Trigger Status Resources 1548 might look like: 1550 REQUEST: 1552 GET /triggers/pending HTTP/1.1 1553 User-Agent: example-user-agent/0.1 1554 Host: dcdn.example.com 1555 Accept: */* 1556 If-None-Match: "5012053611544832286" 1558 RESPONSE: 1560 HTTP/1.1 200 OK 1561 Content-Length: 56 1562 Expires: Sun, 31 Aug 2014 09:54:29 GMT 1563 Server: example-server/0.1 1564 Etag: "-4471185573414616962" 1565 Cache-Control: max-age=60 1566 Date: Sun, 31 Aug 2014 09:53:29 GMT 1567 Content-Type: application/cdni; ptype=ci-trigger-collection 1569 { 1570 "staleresourcetime": 86400, 1571 "triggers": [] 1572 } 1574 REQUEST: 1576 GET /triggers/complete HTTP/1.1 1577 User-Agent: example-user-agent/0.1 1578 Host: dcdn.example.com 1579 Accept: */* 1580 If-None-Match: "2986340333785000363" 1582 RESPONSE: 1584 HTTP/1.1 200 OK 1585 Content-Length: 153 1586 Expires: Sun, 31 Aug 2014 09:54:30 GMT 1587 Server: example-server/0.1 1588 Etag: "-1508172875796647067" 1589 Cache-Control: max-age=60 1590 Date: Sun, 31 Aug 2014 09:53:30 GMT 1591 Content-Type: application/cdni; ptype=ci-trigger-collection 1593 { 1594 "staleresourcetime": 86400, 1595 "triggers": [ 1596 "http://dcdn.example.com/triggers/0", 1597 "http://dcdn.example.com/triggers/1" 1598 ] 1599 } 1601 6.2.5. Deleting Trigger Status Resources 1603 The dCDN can delete completed and failed Trigger Status Resources to 1604 reduce the size of the collections. For example, to delete the 1605 "preposition" request from earlier examples: 1607 REQUEST: 1609 DELETE /triggers/0 HTTP/1.1 1610 User-Agent: example-user-agent/0.1 1611 Host: dcdn.example.com 1612 Accept: */* 1614 RESPONSE: 1616 HTTP/1.1 204 No Content 1617 Date: Sun, 31 Aug 2014 09:53:30 GMT 1618 Content-Length: 0 1619 Content-Type: text/html; charset=UTF-8 1620 Server: example-server/0.1 1622 This would, for example, cause the collection of completed Trigger 1623 Status Resources shown in the example above to be updated to: 1625 REQUEST: 1627 GET /triggers/complete HTTP/1.1 1628 User-Agent: example-user-agent/0.1 1629 Host: dcdn.example.com 1630 Accept: */* 1632 RESPONSE: 1634 HTTP/1.1 200 OK 1635 Content-Length: 106 1636 Expires: Sun, 31 Aug 2014 09:54:30 GMT 1637 Server: example-server/0.1 1638 Etag: "-1842390246836476263" 1639 Cache-Control: max-age=60 1640 Date: Sun, 31 Aug 2014 09:53:30 GMT 1641 Content-Type: application/cdni; ptype=ci-trigger-collection 1643 { 1644 "staleresourcetime": 86400, 1645 "triggers": [ 1646 "http://dcdn.example.com/triggers/1" 1647 ] 1648 } 1650 6.2.6. Error Reporting 1652 In this example the uCDN has requested prepositioning of 1653 "http://newsite.example.com/index.html", but the dCDN was unable to 1654 locate metadata for that site: 1656 REQUEST: 1658 GET /triggers/2 HTTP/1.1 1659 User-Agent: example-user-agent/0.1 1660 Host: dcdn.example.com 1661 Accept: */* 1663 RESPONSE: 1665 HTTP/1.1 200 OK 1666 Content-Length: 505 1667 Expires: Sun, 31 Aug 2014 09:54:38 GMT 1668 Server: example-server/0.1 1669 Etag: "-3893590191073700822" 1670 Cache-Control: max-age=60 1671 Date: Sun, 31 Aug 2014 09:53:38 GMT 1672 Content-Type: application/cdni; ptype=ci-trigger-status 1674 { 1675 "ctime": 1409478810, 1676 "errors": [ 1677 { 1678 "content.urls": [ 1679 "http://newsite.example.com/index.html" 1680 ], 1681 "description": 1682 "No HostIndex entry found for newsite.example.com", 1683 "error": "emeta" 1684 } 1685 ], 1686 "etime": 1409478818, 1687 "mtime": 1409478814, 1688 "status": "active", 1689 "trigger": { 1690 "content.urls": [ 1691 "http://newsite.example.com/index.html" 1692 ], 1693 "type": "preposition" 1694 } 1695 } 1697 7. IANA Considerations 1699 7.1. CDNI Payload Type Parameter Registrations 1701 The IANA is requested to register the following new Payload Types in 1702 the CDNI Payload Type Parameter registry defined by 1703 [I-D.ietf-cdni-media-type], for use with the 'application/cdni' MIME 1704 media type. 1706 RFC Editor Note: Please replace references to [RFCthis] below with 1707 this document's RFC number before publication. 1709 +-----------------------+---------------+ 1710 | Payload Type | Specification | 1711 +-----------------------+---------------+ 1712 | ci-trigger-command | [RFCthis] | 1713 | ci-trigger-status | [RFCthis] | 1714 | ci-trigger-collection | [RFCthis] | 1715 +-----------------------+---------------+ 1717 8. Security Considerations 1719 The CI/T interface provides a mechanism to allow a uCDN to generate 1720 requests into the dCDN and to inspect its own CI/T requests and their 1721 current state. The CI/T interface does not allow access to or 1722 modification of the uCDN or dCDN metadata relating to content 1723 delivery, or to the content itself. It can only control the presence 1724 of that metadata in the dCDN, and the processing work and network 1725 utilisation involved in ensuring that presence. 1727 By examining pre-positioning requests to a dCDN, and correctly 1728 interpreting content and metadata URLs, an attacker could learn the 1729 uCDN or content owner's predictions for future content popularity. 1730 By examining invalidate or purge requests, an attacker could learn 1731 about changes in the content owner's catalogue. 1733 By injecting CI/T commands an attacker, or a misbehaving uCDN, would 1734 generate work in the dCDN and uCDN as they process those requests. 1735 And so would a man in the middle attacker modifying valid CI/T 1736 commands generated by the uCDN. In both cases, that would decrease 1737 the dCDN caching efficiency by causing it to unnecessarily acquire or 1738 re-acquire content metadata and/or content. 1740 A dCDN implementation of CI/T MUST restrict the actions of a uCDN to 1741 the data corresponding to that uCDN. Failure to do so would allow 1742 uCDNs to detrimentally affect each other's efficiency by generating 1743 unnecessary acquisition or re-acquisition load. 1745 8.1. Authentication, Authorization, Confidentiality, Integrity 1746 Protection 1748 A CI/T implementation MUST support TLS transport for HTTP (https) as 1749 per [RFC2818] and [RFC7230]. 1751 The use of TLS for transport of the CI/T interface allows: 1753 o The dCDN and the uCDN to authenticate each other. 1755 And, once they have mutually authenticated each other, it allows: 1757 o The dCDN and the uCDN to authorize each other (to ensure they are 1758 receiving CI/T Commands from, or reporting status to, an 1759 authorized CDN). 1761 o CDNI commands and responses to be transmitted with 1762 confidentiality. 1764 o Protection of the integrity of CDNI commands and responses. 1766 In an environment where any such protection is required, mutually 1767 authenticated encrypted transport MUST be used to ensure 1768 confidentiality of the CI/T information. To that end, TLS MUST be 1769 used by CI/T, including authentication of the remote end. 1771 When TLS is used, the general TLS usage guidance in [RFC7525] MUST be 1772 followed. 1774 HTTP requests that attempt to access or operate on CI/T data 1775 belonging to another CDN MUST be rejected using, for example, HTTP 1776 "403 Forbidden" or "404 Not Found". This is intended to prevent 1777 unauthorised users from generating unnecessary load in dCDN or uCDN 1778 due to revalidation, reacquisition, or unnecessary acquisition. 1780 Note that in a "diamond" configuration, where one uCDN's content can 1781 be acquired via more than one directly-connected uCDN, it may not be 1782 possible for the dCDN to determine from which uCDN it acquired 1783 content. In this case, the dCDN MUST allow each uCDN from which the 1784 content could have been acquired to act upon that content using CI/T 1785 Commands. 1787 8.2. Denial of Service 1789 This document does not define a specific mechanism to protect against 1790 Denial of Service (DoS) attacks on the CI/T. However, CI/T endpoints 1791 can be protected against DoS attacks through the use of TLS transport 1792 and/or via mechanisms outside the scope of the CI/T interface, such 1793 as firewalling or use of Virtual Private Networks (VPNs). 1795 Depending on the implementation, triggered activity may consume 1796 significant processing and bandwidth in the dCDN. A malicious or 1797 faulty uCDN could use this to generate unnecessary load in the dCDN. 1798 The dCDN should consider mechanisms to avoid overload, for example by 1799 rate-limiting acceptance or processing of CI/T Commands, or batching 1800 up its processing. 1802 8.3. Privacy 1804 The CI/T protocol does not carry any information about individual End 1805 Users of a CDN, there are no privacy concerns for End Users. 1807 The CI/T protocol does carry information which could be considered 1808 commercially sensitive by CDN operators and content owners. The use 1809 of mutually authenticated TLS to establish a secure session for the 1810 transport of CI/T data, as discussed in Section 8.1, provides 1811 confidentiality while the CI/T data is in transit, and prevents 1812 parties other party than the authorised dCDN from gaining access to 1813 that data. The dCDN MUST ensure that it only exposes CI/T data 1814 related to a uCDN to clients it has authenticated as belonging to 1815 that uCDN. 1817 9. Acknowledgements 1819 The authors thank Kevin Ma for his input, and Carsten Bormann for his 1820 review and formalization of the JSON data. 1822 10. References 1824 10.1. Normative References 1826 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1827 Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/ 1828 RFC2119, March 1997, 1829 . 1831 [RFC7159] Bray, T., Ed., "The JavaScript Object Notation (JSON) Data 1832 Interchange Format", RFC 7159, DOI 10.17487/RFC7159, March 1833 2014, . 1835 [RFC7230] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1836 Protocol (HTTP/1.1): Message Syntax and Routing", RFC 1837 7230, DOI 10.17487/RFC7230, June 2014, 1838 . 1840 [RFC7231] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1841 Protocol (HTTP/1.1): Semantics and Content", RFC 7231, DOI 1842 10.17487/RFC7231, June 2014, 1843 . 1845 [RFC7232] Fielding, R., Ed. and J. Reschke, Ed., "Hypertext Transfer 1846 Protocol (HTTP/1.1): Conditional Requests", RFC 7232, DOI 1847 10.17487/RFC7232, June 2014, 1848 . 1850 [RFC7525] Sheffer, Y., Holz, R., and P. Saint-Andre, 1851 "Recommendations for Secure Use of Transport Layer 1852 Security (TLS) and Datagram Transport Layer Security 1853 (DTLS)", BCP 195, RFC 7525, DOI 10.17487/RFC7525, May 1854 2015, . 1856 10.2. Informative References 1858 [I-D.greevenbosch-appsawg-cbor-cddl] 1859 Vigano, C. and H. Birkholz, "CBOR data definition 1860 language: a notational convention to express CBOR data 1861 structures.", draft-greevenbosch-appsawg-cbor-cddl-06 1862 (work in progress), July 2015. 1864 [I-D.ietf-cdni-media-type] 1865 Ma, K., "CDNI Media Type Registration", draft-ietf-cdni- 1866 media-type-06 (work in progress), October 2015. 1868 [I-D.ietf-cdni-metadata] 1869 Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1870 "CDN Interconnection Metadata", draft-ietf-cdni- 1871 metadata-11 (work in progress), July 2015. 1873 [I-D.ietf-cdni-redirection] 1874 Niven-Jenkins, B. and R. Brandenburg, "Request Routing 1875 Redirection Interface for CDN Interconnection", draft- 1876 ietf-cdni-redirection-13 (work in progress), October 2015. 1878 [RFC2818] Rescorla, E., "HTTP Over TLS", RFC 2818, DOI 10.17487/ 1879 RFC2818, May 2000, 1880 . 1882 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1883 Distribution Network Interconnection (CDNI) Problem 1884 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1885 2012, . 1887 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1888 "Framework for Content Distribution Network 1889 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1890 August 2014, . 1892 [RFC7337] Leung, K., Ed. and Y. Lee, Ed., "Content Distribution 1893 Network Interconnection (CDNI) Requirements", RFC 7337, 1894 DOI 10.17487/RFC7337, August 2014, 1895 . 1897 Authors' Addresses 1899 Rob Murray 1900 Velocix (Alcatel-Lucent) 1901 3 Ely Road 1902 Milton, Cambridge CB24 6DD 1903 UK 1905 Email: rob.murray@alcatel-lucent.com 1907 Ben Niven-Jenkins 1908 Velocix (Alcatel-Lucent) 1909 3 Ely Road 1910 Milton, Cambridge CB24 6DD 1911 UK 1913 Email: ben.niven-jenkins@alcatel-lucent.com