idnits 2.17.1 draft-finkelman-cdni-sva-extensions-00.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 : ---------------------------------------------------------------------------- == There are 2 instances of lines with non-RFC2606-compliant FQDNs in the document. Miscellaneous warnings: ---------------------------------------------------------------------------- == The copyright year in the IETF Trust and authors Copyright Line does not match the current year == Using lowercase 'not' together with uppercase 'MUST', 'SHALL', 'SHOULD', or 'RECOMMENDED' is not an accepted usage according to RFC 2119. Please use uppercase 'NOT' together with RFC 2119 keywords (if that is what you mean). Found 'MUST not' in this paragraph: * Purge: In certain cases, content may have been located on servers in regions where the content MUST not reside on. In such cases a purge operation to remove content specifically from that region, is required. -- The document date (October 30, 2017) is 2367 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: 'RFC8216' is mentioned on line 269, but not defined == Unused Reference: 'RFC1034' is defined on line 1012, but no explicit reference was found in the text == Unused Reference: 'RFC1123' is defined on line 1016, but no explicit reference was found in the text == Unused Reference: 'RFC3986' is defined on line 1026, but no explicit reference was found in the text == Unused Reference: 'RFC4291' is defined on line 1031, but no explicit reference was found in the text == Unused Reference: 'RFC5890' is defined on line 1035, but no explicit reference was found in the text == Unused Reference: 'RFC5891' is defined on line 1040, but no explicit reference was found in the text == Unused Reference: 'RFC5952' is defined on line 1045, but no explicit reference was found in the text ** Downref: Normative reference to an Informational RFC: RFC 6707 ** Downref: Normative reference to an Informational RFC: RFC 7336 Summary: 2 errors (**), 0 flaws (~~), 11 warnings (==), 2 comments (--). Run idnits with the --verbose option for more detailed information about the items above. -------------------------------------------------------------------------------- 2 Network Working Group O. Finkelman 3 Internet-Draft Qwilt 4 Intended status: Standards Track S. Mishra 5 Expires: May 3, 2018 Verizon 6 October 30, 2017 8 CDNI SVA Extensions 9 draft-finkelman-cdni-sva-extensions-00 11 Abstract 13 The Open Caching working group of the Streaming Video Alliance is 14 focused on the delegation of video delivery request from commercial 15 CDNs to a caching layer at the ISP. In that aspect, Open Caching is 16 a specific use case of CDNI, where the commercial CDN is the upstream 17 CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). 19 Requirements Language 21 The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", 22 "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 23 document are to be interpreted as described in RFC 2119 [RFC2119]. 25 Status of This Memo 27 This Internet-Draft is submitted in full conformance with the 28 provisions of BCP 78 and BCP 79. 30 Internet-Drafts are working documents of the Internet Engineering 31 Task Force (IETF). Note that other groups may also distribute 32 working documents as Internet-Drafts. The list of current Internet- 33 Drafts is at https://datatracker.ietf.org/drafts/current/. 35 Internet-Drafts are draft documents valid for a maximum of six months 36 and may be updated, replaced, or obsoleted by other documents at any 37 time. It is inappropriate to use Internet-Drafts as reference 38 material or to cite them other than as "work in progress." 40 This Internet-Draft will expire on May 3, 2018. 42 Copyright Notice 44 Copyright (c) 2017 IETF Trust and the persons identified as the 45 document authors. All rights reserved. 47 This document is subject to BCP 78 and the IETF Trust's Legal 48 Provisions Relating to IETF Documents 49 (https://trustee.ietf.org/license-info) in effect on the date of 50 publication of this document. Please review these documents 51 carefully, as they describe your rights and restrictions with respect 52 to this document. Code Components extracted from this document must 53 include Simplified BSD License text as described in Section 4.e of 54 the Trust Legal Provisions and are provided without warranty as 55 described in the Simplified BSD License. 57 Table of Contents 59 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 60 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 61 2. Request routing . . . . . . . . . . . . . . . . . . . . . . . 3 62 2.1. Request router address . . . . . . . . . . . . . . . . . 3 63 2.2. uCDN fallback address . . . . . . . . . . . . . . . . . . 4 64 3. Content management . . . . . . . . . . . . . . . . . . . . . 5 65 3.1. Content matching rules . . . . . . . . . . . . . . . . . 5 66 3.1.1. Regular expresssion . . . . . . . . . . . . . . . . . 6 67 3.1.2. Playlist . . . . . . . . . . . . . . . . . . . . . . 6 68 3.2. Geo limits . . . . . . . . . . . . . . . . . . . . . . . 7 69 3.3. Scheduled operations . . . . . . . . . . . . . . . . . . 8 70 3.4. Trigger extensibility . . . . . . . . . . . . . . . . . . 9 71 3.5. Capabilties . . . . . . . . . . . . . . . . . . . . . . . 10 72 4. Split authentication . . . . . . . . . . . . . . . . . . . . 11 73 5. CORS delegation . . . . . . . . . . . . . . . . . . . . . . . 13 74 6. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 75 6.1. FCI extension for Logging . . . . . . . . . . . . . . . . 19 76 6.2. Metadata Interface extension for Logging . . . . . . . . 20 77 6.2.1. Logging Configuration object . . . . . . . . . . . . 20 78 6.2.2. Transport Configuration object . . . . . . . . . . . 21 79 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 80 7.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 22 81 7.1.1. CDNI FCI RequestRouterAddress Payload Type . . . . . 22 82 7.1.2. CDNI MI FallbackAddress Payload Type . . . . . . . . 22 83 7.1.3. CDNI MI Logging Payload Type . . . . . . . . . . . . 22 84 7.1.4. CDNI MI LoggingTransport Payload Type . . . . . . . . 23 85 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 86 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 87 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 88 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 89 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 90 11.2. Informative References . . . . . . . . . . . . . . . . . 25 91 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 93 1. Introduction 95 In this document, we describe the different use cases of Open Caching 96 and the interface and functionality extensions they require, compared 97 to the existing CDNI RFCs. For consistency, this document follows 98 the CDNI notation of uCDN (the commercial CDN) and dCDN (the ISP 99 caching layer). When using the term CP in this document we refer to 100 a video content provider. 102 The CDNI Logging interface is described in [RFC7937]. 104 The CDNI metadata interface is described in [RFC8006]. 106 The CDNI footprint and capability interface is described in 107 [RFC8008]. 109 The CDNI control interface / triggers is described in [RFC8007]. 111 1.1. Terminology 113 This document reuses the terminology defined in [RFC6707], [RFC8006], 114 [RFC8007], and [RFC8008]. 116 Additionally, the following terms are used throughout this document 117 and are defined as follows: 119 o SVA - Streaming Video Alliance. 121 o OC - SVA Open Caching. 123 o RR - Request Router. 125 o CP - Content Provider. 127 2. Request routing 129 This section lists extensions required by request routing features. 131 2.1. Request router address 133 Open Caching uses iterative request redirect as defined in [RFC7336]. 134 In order for the uCDN to redirect to the dCDN it requires a request 135 router address. CDNI RFCs do not specify how the request router 136 address is advertised and suggests it may be passed via a bootstrap 137 protocol / interface, which is currently not defined. 139 We propose to add the request router address as a capability under 140 the Footprint and Capabilities interface. 142 Use cases 144 * Footprint: The dCDN may want to have different RR addresses per 145 footprint. Note that a dCDN may spread across multiple 146 geographies. This makes it easier to route client request to a 147 nearby RR. Though this can be achieved using a single 148 canonical name and geo DNS, that approach has limitations, for 149 example a client may be using third party DNS resolver, making 150 it impossible for the redirector to detect where the client is 151 located. 153 * Scaling: The dCDN may choose to scale its RR service by 154 deploying more RRs in new locations and advertise them via an 155 updatable interface like the FCI. 157 Proposal 159 Advertise request router address in an FCI capability object. 161 Example FCI.RequestRouterAddress object: 163 { 164 "capabilities": [ 165 { 166 "capability-type": "FCI.RequestRouterAddress", 167 "capability-value": { 168 "address": 169 }, 170 "footprints": [ 171 172 ] 173 } 174 ] 175 } 177 2.2. uCDN fallback address 179 Open Caching requires that the uCDN should provide a fallback address 180 to the dCDN to be used in cases where the dCDN cannot properly handle 181 the request. To avoid redirect loops, the dCDN would redirect the 182 request back to the uCDN but to a different location than the 183 original uCDN address, the uCDN will not redirect requests coming to 184 that other address. 186 Use cases 188 * Failover: A dCDN request router receives a request but has no 189 caches to which it can route the request to. This can happen 190 in the case of failures, or temporary network overload. In 191 these cases, the router may choose to redirect the request back 192 to the uCDN fallback address. 194 * Error: A cache may receive a request that it cannot properly 195 serve, for example, some of the metadata objects for that 196 service were not properly acquired. In this case the cache may 197 resolve to redirect back to uCDN. 199 Proposal 201 Add a generic metadata object for fallback address similar to 202 the source metadata. 204 Example MI.FallbackAddress object: 206 { 207 "generic-metadata-type": "MI.FallbackAddress", 208 "generic-metadata-value": 209 { 210 "sources": [ 211 { 212 "endpoints": [ 213 "fallback-a.service123.ucdn.example", 214 "fallback-b.service123.ucdn.example" 215 ], 216 "protocol": "http/1.1" 217 }, 218 { 219 "endpoints": ["origin.service123.example"], 220 "protocol": "http/1.1" 221 } 222 ] 223 } 224 } 226 3. Content management 228 Open Caching uses the CDNI CI/T [RFC8007] as an interface for content 229 management operations. The basic operations are the ones defined in 230 the RFC (i.e. purge, invalidate, pre-position). 232 3.1. Content matching rules 234 RFC8007 provides means to match on full content URL or patterns with 235 wildcards. The Open Caching working group proposes to add two more 236 match rule types. 238 3.1.1. Regular expresssion 240 Using regexp one can create more complex rules to match on objects 241 for the cases of invalidation and purge. 243 Use cases 245 * Purge: Purging specific content within a specific directory 246 path. In some cases wildcard MAY be used but it can be a 247 constraining or overreaching variable that exposes the assets 248 to purge further than desired. 250 Proposal 252 Add content.regexs to trigger specification. 254 Name: content.regexs 256 Description: Regexs of content the CI/T Trigger Command 257 applies to. 259 Value: A JSON array of Regexs represented as JSON strings. 261 Mandatory: No, but at least one of "metadata.*", "content.*" 262 or "playlist.urls" MUST be present and non-empty. 264 3.1.2. Playlist 266 Using video playlist files, one can trigger an operation that will 267 work on a collection of distinct media files in a representation that 268 is natural for the content provider. A playlist may have several 269 formats, specifically HLS *.m3u8 manifest [RFC8216], MSS *.ismc 270 client manifest, and DASH XML MPD file [ISO/IEC 23009-1:2014]. 272 Use cases 274 * Pre-position: Pre-position of content requires passing the full 275 list of media files to the dCDN. Passing the manifest instead 276 is a more natural interface for both sides as they are both 277 supposed to be able to properly read and understand the 278 manifest files. 280 Proposal 282 Add playlist.urls to trigger specification. 284 Name: playlist.urls 286 Description: URLs of video playlist the CI/T Trigger Command 287 applies to. 289 Value: A JSON array of Regexs represented as JSON strings. 291 Mandatory: No, but at least one of "metadata.*", "content.*" 292 or "playlist.urls" MUST be present and non-empty. 294 3.2. Geo limits 296 A content operation may apply for a specific geographical region, or 297 need to be excluded from a specific region. In this case, the 298 trigger should be applied only to parts of the network that are 299 included or not excluded by the geo limit. Note that the limit here 300 is on the cache location rather than client location. 302 Use cases 304 * Pre-position: Certain contracts allow for prepositioning or 305 availability of contract in all regions except for certain 306 excluded regions in the world, including caches. For example, 307 some CPs content cannot ever knowingly touch servers in a 308 specific country, including caches. Therefore, these regions 309 MUST be excluded from a pre-positioning operation. 311 * Purge: In certain cases, content may have been located on 312 servers in regions where the content MUST not reside on. In 313 such cases a purge operation to remove content specifically 314 from that region, is required. 316 Proposal 318 Add GEO locations as an option in the trigger specification. 319 We should consider where this locations object is defined. 320 Should this a part of CI/T or there can be a way we can use 321 metadata objects. The generic metadata object MI.LocationAcl 322 has the same syntax, though the meaning is different as the 323 limit here is on caches rather than end user locations. 325 Example of trigger specification with a geo limit: 327 POST /triggers HTTP/1.1 328 User-Agent: example-user-agent/0.1 329 Host: dcdn.example.com 330 Accept: */* 331 Content-Type: application/cdni; ptype=ci-trigger-command 332 Content-Length: 352 334 { 335 "trigger": { 336 "type": "preposition", 337 "content.urls": [ 338 "https://www.example.com/a/b/c/1", 339 "https://www.example.com/a/b/c/2" 340 ] 341 }, 342 "locations": [ 343 { 344 "action": "allow" / "deny", 345 "footprints": [ 346 { 347 "footprint-type": "countrycode", 348 "footprint-value": ["us"] 349 } 350 ] 351 } 352 ], 353 "cdn-path": [ "AS64496:1" ] 354 } 356 3.3. Scheduled operations 358 A uCDN may wish to perform content management operation on the dCDN 359 with a defined local time schedule. 361 Use cases 363 * Pre-position: A content provider wishes to pre-populate a new 364 episode at off-peak time so that it would be ready on caches 365 (for example home caches) at prime time when the episode is 366 released for viewing. This requires an interface that directs 367 the dCDN when to pre-position the content; the time frame is 368 local time per area as the off-peak time is also localized. 370 Proposal 372 Add an execution time window as an option in the trigger 373 specification. 375 Example of trigger specification with a schedule limit: 377 POST /triggers HTTP/1.1 378 User-Agent: example-user-agent/0.1 379 Host: dcdn.example.com 380 Accept: */* 381 Content-Type: application/cdni; ptype=ci-trigger-command 382 Content-Length: 352 384 { 385 "trigger": { 386 "type": "preposition", 387 "content.urls": [ 388 "https://www.example.com/a/b/c/1", 389 "https://www.example.com/a/b/c/2" 390 ] 391 }, 392 "time-windows": [ 393 { 394 "time-type": "local" / "UTC", 395 "start": "", 396 "end": "" 398 } 399 ], 400 "cdn-path": [ "AS64496:1" ] 401 } 403 3.4. Trigger extensibility 405 There are cases in which some new data has to pass in the trigger 406 which was not thought of in advance. We propose the add a mechanism 407 to the trigger spec which will be similar to the MI generic metadata, 408 allowing parties to easily add more information, that can later be 409 standardized if required. 411 Use cases 413 * Purge content by acquisition time: A uCDN finds that due to 414 configuration mistake it has delivered wrong content, in the 415 past two hours. The uCDN would like to instruct the dCDN to 416 invalidate all content that was acquired in the past two hours. 417 However, there is no such primitive in the trigger 418 specification. If this would be a common use case it may 419 require the addition of a new generic trigger spec object that 420 restrict the match to be on content which was acquired in some 421 time spec. 423 * Pre-position by cache type: The uCDN would like the dCDN to 424 pre-populate some content, but only on a specific layer of the 425 caching network, for example, only on home caches. There is 426 currently no such option in the interface. By using a generic 427 object parties may define such object and implement it between 428 them, and later standardize it, if required. 430 Proposal 432 Add trigger extensibility mechanism to the trigger 433 specification. 435 Example of trigger extension: 437 POST /triggers HTTP/1.1 438 User-Agent: example-user-agent/0.1 439 Host: dcdn.example.com 440 Accept: */* 441 Content-Type: application/cdni; ptype=ci-trigger-command 442 Content-Length: 352 444 { 445 "trigger": { 446 "type": "purge", 447 "content.patterns": [ 448 "https://www.example.com/*" 449 ] 450 }, 451 "generic-trigger-spec-type": , 452 "generic-trigger-spec-value": 453 { 454 455 } 456 } 458 3.5. Capabilties 460 The capabilities added to the triggers interface are not mandatory to 461 support and are, therefore, best negotiated via the FCI. 463 Use cases 465 * Content management operations: Advertise which content 466 operations are supported by the dCDN. CDNI defines three 467 operations (purge, invalidate, pre-position), but it does not 468 necessarily mean that all dCDNs support all of them. The uCDN 469 may prefer to work only with dCDN that support what the uCDN 470 needs. 472 * Content mapping types: Advertise which mapping types are 473 supported, for example, if adding content regexp and possibly 474 playlists, not all dCDN would support it. For playlist, 475 advertise which types and versions of protocols are supported, 476 e.g. HLS/DASH/SS, DASH templates. 478 * Trigger spec objects: Advertise which trigger spec object are 479 supported, for example time-window, geo-limit etc. 481 Proposal 483 Define the non-mandatory objects as generic objects, similar to 484 the metadata generic objects, and then the FCI can declare 485 which ones of the trigger spec objects are supported. . 487 4. Split authentication 489 Different CDNs and Content Providers apply different access control 490 and authentication of user requests. It is not feasible for a dCDN, 491 or ISP cache layer, to implement every scheme a uCDN may have thought 492 of, and, unfortunately, it is not reasonable to expect that uCDNs and 493 CPs will move from their current implementation to a new standard, 494 any time soon. In some cases, existing implementation also include 495 secrets under NDA; sharing them with a third party dCDN is unlikely 496 to happen. Therefore, we aim to look for a solid, generic solution 497 that keeps the access control, authentication and authorization logic 498 in the origin/uCDN. 500 Use cases 502 * URI signing: There are numerous methods in which a CP signs its 503 URIs such that the uCDN can verify the signatures. In most 504 cases, symmetric keys are being used and require some key 505 exchange. Expecting the dCDN caches to implement every method 506 used by commercial CDNs is problematic, and sharing of content 507 provider keys is unlikely. 509 * Token based authentication: Some CPs and CDNs are using token 510 based client / session authentication. The token is passed 511 either as a URI query parameter or as a cookie. The dCDN / ISP 512 cannot implement the token validation, as it has no knowledge 513 of the identity and validation methods used by the CP / uCDN. 514 Also, if using cookies with HTTP redirect, the cookie will be 515 omitted after the redirect, so a solution for cookie based 516 authentication is necessary. 518 * CORS delegation: CORS may also be a use case of split 519 authentication, see explanation in the CORS delegation section. 521 Proposal 523 Split authentication is a mechanism that leverages the fact 524 that video sessions are very long and chunked into very small 525 requests, comparing the overall session time and volume. The 526 dCDN cache relays the authentication verification to the uCDN 527 by sending the uCDN a HEAD request for every new session. The 528 dCDN cache saves the session state for some time and uses it 529 for subsequent requests of the same session. 531 As this is a general problem when delegating traffic between 532 CDNs, and in-fact, can become a blocker for CDNI deployments. 533 We propose to consider this concept for the general CDNI use 534 case, and draft it for RFC. 536 The following diagram gives a high level sequence view of the URI 537 signing use case. 539 +------+ +------+ +------+ +-----+ 540 |Client| |dCDN | |uCDN | | CP | 541 | | | | | | | | 542 +---+--+ +---+--+ +---+--+ +--+--+ 543 | | | | 544 +----------------+ | | | 545 |Access video on | | | | 546 |CP web site | | | | 547 +-------+--------+ | | | 548 | Get master manifest location | | 549 +-----------------+----------------------+-----------------> 550 | |Respond with signed URI to manifest | 551 <----------------------------------------+-----------------+ 552 | Get manifest | | | 553 +----------------------------------------> | 554 | | | | 555 | | +-------+----------+ | 556 | | |Verify URI signing| | 557 | | +-------+----------+ | 558 | | Redirect to dCDN | | 559 <----------------------------------------+ | 560 | Get manifest | | | 561 +-----------------> | | 562 | |Authenticate URI | | 563 | +----------------------> | 564 | |Authentication success| | 565 | Master manifest <----------------------+ | 566 <-----------------+ | | 567 | Get sub manifest| | | 568 +-----------------> | | 569 | |Authenticate URI | | 570 | +----------------------> | 571 | |Authentication success| | 572 | <----------------------+ | 573 | | | | 574 | +------------------+ | | 575 | |Save authenticated| | | 576 | |session token | | | 577 | +--------+---------+ | | 578 | Sub manifest | | | 579 <-----------------+ | | 580 | Request chunk 1 | | | 581 +-----------------> | | 582 | | | | 583 | +---------------------+ | | 584 | | Use session state to| | | 585 | | authenticate client | | | 586 | | chunk requests | | | 587 | +----------+----------+ | | 588 | chunk 1 | | | 589 <-----------------+ | | 590 |-Request chunk 2-> | | 591 <------chunk 2----| | | 592 |-Request chunk 3-> | | 593 <------chunk 3----+ | | 594 | | | | 595 + + + + 596 Figure 1 598 5. CORS delegation 600 CORS (Cross Origin Resource Sharing) is a mechanism designed to allow 601 a resource from domain A to access other resources in domain B, 602 overriding the same-origin policy. When a uCDN delegate traffic to a 603 dCDN (or ISP) the dCDN is required to comply with the same CORS 604 server behavior the uCDN would have had. For example, if a resource 605 from domain A is accessible for request coming from a resource domain 606 B, but not accessible to requests coming from a resource of domain C, 607 the same logic must be done by the dCDN. 609 Though CORS can possibly be handled by simply echoing the Origin 610 header value, or *, back to the client, in some cases it is not 611 sufficient, and it also breaks the concept of CORS as an access 612 control mechanism. As proper CORS handling is not possible without a 613 delegation scheme, the Open Caching working group sees it as an 614 essential part of inter-CDN delegation, and therefore propose to 615 adopt it under CDNI and draft it for CDNI RFC. 617 Use cases 619 * A simple use case example is a when resource from Origin: 620 www.video.example.com points to the media file on domain: 621 www.cdn.com. The uCDN is supposed to deliver the content if 622 the Origin is video.example.com otherwise it should be 623 rejected. In this case, for a request header "Origin: 624 www.video.example.com" the CDN should reply with "Access- 625 Control-Allow-Origin: www.video.example.com". OTOH, if the 626 origin is www.video.other.com then the CDN should not allow it 627 by omitting the ACAO header. When delegating the session to a 628 dCDN cache, it should maintain the same behavior. 630 Proposals 632 There are several alternatives for the dCDN / ISP cache to learn 633 the allowed origins for a content item. 635 1. Caching: Caching of CORS headers per content. If the cache 636 receives a request using an origin it does not already approve 637 for that content, the cache sends a HEAD request to the CDN 638 with the client's CORS request headers. The cache saves the 639 response information in a content database and uses it for 640 subsequent requests for the same content. . 642 2. Metadata: the uCDN can provide the dCDN the metadata referring 643 the content of a specific domain. This metadata holds, for 644 example, all the information required to take CORS decisions 645 at the Open Cache. 647 3. Split authentication: Using split authentication, the dCDN 648 cache can send the CORS headers to the uCDN in the initial 649 session request, the uCDN responds to the CORS request 650 properly, the dCDN forwards the CORS response to the client 651 and caches it for rest of the client session. 653 The following diagram gives a high level sequence view of CORS 654 delegation from uCDN to dCDN using the CORS caching alternative. 656 +------+ +------+ +------+ +-----+ 657 +-|Client| |dCDN | | uCDN | | CP | 658 | |1 | | | | B | | A | 659 |2+---+--+ +---+--+ +---+--+ +--+--+ 660 +--+--|+ | | | 661 +-------+-------------+ | | | 662 |Access resource on CP| | | | 663 |www.example.com | | | | 664 +-------+-------------+ | | | 665 | | Get resource A from example.com | | 666 | +-----------------+----------------------+-----------------> 667 | | CP resource A points to a resource B on uCDN cdn.com | 668 | <----------------------------------------+-----------------+ 669 | | Get B from uCDN ucdn.com | | 670 | | Origin: example.com | | 671 | +----------------------------------------> | 672 | | | | | 673 | | | +----------+-----------+ | 674 | | | |uCDN Delegate to dCDN | | 675 | | | +----------+-----------+ | 676 | | | Redirect to dCDN | | 677 | <----------------------------------------+ | 678 | |Get B from dCDN | | | 679 | |Origin: example.com | | 680 | +-----------------> | | 681 | | | Request CORS for B | | 682 | | | Origin: example.com | | 683 | | +----------------------> | 684 | | | Provide CORS for B | | 685 | | | Origin: example.com | | 686 | | <----------------------+ | 687 | | +--------+-----------+ | | 688 | | + cache B CORS rules | | | 689 | | + Origin: example.com| | | 690 | | +--------+-----------+ | | 691 | | Provide B with | | | 692 | | CORS headers | | | 693 | <-----------------+ | | 694 | Get B from uCDN ucdn.com | | 695 | Origin: example.com | | 696 |-------------------------------------------> | 697 | | | | | 698 | | | +----------+-----------+ | 699 | | | |uCDN delegate to dCDN | | 700 | | | +----------+-----------+ | 701 | | | Redirect to dCDN | | 702 <-------------------------------------------+ | 703 | Get B from dCDN | | | 704 | Origin: example.com| | | 705 |--------------------> | | 706 | | +--------+-----------+ | | 707 | | + use B cached CORS | | | 708 | | + Origin: example.com| | | 709 | | +--------+-----------+ | | 710 | | Provide B with | | | 711 | | CORS headers | | | 712 <--------------------+ | | 713 + + + + + 714 Figure 2 716 In the above simplified example, we depict the caching alternative 717 for CORS solution. 719 Client 1 accesses resource A on CP domain example.com. Resource A, 720 refers client 1 to resource B on uCDN ucdn.com. Without delegation, 721 at this points uCDN has to resolve CORS and decide if a resource from 722 example.com is allowed to access a resource at ucdn.com. However, 723 once delegated to dCDN, it becomes the dCDNs duty to resolve it for 724 the client request arrives at the dCDN cache. The dCDN sends a CORS 725 request to the uCDN, for resource B with origin example.com, it then 726 uses the response to respond to client 1, and caches the response. 727 When client 2's request arrives at the dCDN, the required CORS 728 information is already in cache and the dCDN can serve client 2 729 without reiterating to uCDN. 731 For simplicity, in this diagram, we have ignored some of the 732 challenges of CORS delegation like preflight requests and "null" 733 origin after HTTP redirect. 735 6. Logging 737 This section outlines creation of service delivery logs at the dCDN 738 (ISP) and transmittal of the logs by the dCDN to the uCDN. The key 739 motivation for logging outlined below as compared to CDNI Logging 740 Interface [RFC7937] is the ability for dCDN and uCDN to negotiate and 741 agree on a log transport mechanism. 743 The logging mechanism provides the flexibility for CDNs to leverage 744 common transport mechanism in-use already. Second, the open caching 745 working group has selected Squid based file format given its wide 746 usage within the CDN environments for access and cache logs, result 747 codes and error messages. As an example, the result codes in squid 748 return both the status code returned by downstream as well as result 749 code indicator such as HIT, MISS, REFRESH_HIT, etc. Between the two 750 statuses, it is easier to discern the delivery status. As an 751 example, if the request was forbidden by the origin, the status field 752 will likely be MISS/403 or if it is a cache error response, it will 753 be HIT/503. So, leveraging the Squid log already in use within the 754 CDN environment and, equally important, the ability for CDNs to 755 negotiate and agree on a file transport mechanisms, were the key 756 motivations for open caching. These are therefore proposed as 757 complementary extensions to the CDNI Logging Interface [RFC7937]. 759 The sub-sections below explain extensions to the Footprint and 760 Capabilities [RFC8008] and Metadata Interface [RFC8006]. The 761 specific extension includes FCI announcement of supported log file 762 transport types by dCDN and metadata response by uCDN to provision 763 one or more log file types from the list sent by the dCDN. 765 Use cases 767 * Transport: Delivery logs are to be supplied by the dCDN to the 768 uCDN via a transport mechanism of choice, supported by both 769 dCDN and uCDN. 771 * Record format: Log record format is advertised by the dCDN and 772 interpreted correctly by the uCDN. The dCDN in this case shall 773 announce to uCDN one or more transport format that it supports. 774 The uCDN, in turn, will select one format from the potential 775 candidates and set up a provisioning process. 777 * Log destination: The uCDN configures a log receiving system 778 tied to a specific delivery service it has delegated to a dCDN. 779 The uCDN will provision log destination at its end where it 780 will route the returned logs by delivery service associated 781 with the log file. 783 The diagram below illustrates the use cases: 785 Delivery Service A (VOD) Delivery Service C RR Logs 786 Delivery Service B (Live) (Linear) 787 +----------------------+ +-----------------+ +-----------------+ 788 | | | | | | 789 |Log Destination 1(VOD)| |Log Destination 2| |Log Destination 3| 790 | Logstash | | Kafka | | SFTP | 791 | | | | | | 792 +------------^---------+ +----------^------+ +----------^------+ 793 | | | 794 | | | 795 +----------------------------------------------+ 796 uCDN | 797 +----------------------------------------------------------------------+ 798 dCDN | 799 Delivery Logs +----------+-------+ 800 Service A/B/C | | 801 +-------+--------+-----> | RR Logs 802 | | | | dCDN Open Cache <-----------+ 803 | | | | Controller | | 804 +----+-----+ | | | | | 805 | | | | +-------^-------+--+ | 806 | +--+-+----+ | | ^ +----+-----+ 807 | | | | +---+----+ | | Request | 808 | | +--+---+--+ | | | | Router | 809 | | | | | +--+--+-+ | | 810 +-------+ | | | | | +----------+ 811 +------+ Cache | | | Cache | 812 | | +-----+ | 813 +---------+ +-------+ 814 Figure 3 816 Proposal 818 Delivery logs are created and then transferred from log producing 819 entities at the dCDN premises (mainly caches and Request Router) to 820 log destinations at the uCDN premises. The dCDN may offload logs 821 from these entities to logging at the dCDN premises to facilitate log 822 transfers, or, logs may be transferred directly from log producing 823 entities to uCDN. 825 Various transport mechanisms may suit the use case of transferring 826 log data, for example SFTP, HTTP upload, Kafka, Logstash or other 827 methods as per the agreement between a dCDN and a uCDN. 829 In compliance with the CDNI Footprint and Capabilities Interface, and 830 therefore, as per the above use cases, the dCDN is responsible to 831 advertise supported Logging "record-types", as well as Logging 832 "fields" which are marked as optional for the s pecified "record- 833 types" as defined by the CDNI "Logging Capability Object". 835 The CDNI Logging Capability Object is extended to contain additional 836 properties that hold information on record format, such as fields 837 that should be obfuscated by the dCDN. Note that the uCDN can 838 further control field obfuscation when configuring a logging 839 integration. 841 During provisioning process the dCDN may reject configuration if a 842 selected record format is not available for a selected Log 843 Integration Type. 845 6.1. FCI extension for Logging 847 This is a proposal of a Logging Capability object that extends the 848 CDNI "FCI.Logging" object. 850 The following shows an example of Logging Capability object 851 serialization, for a dCDN that supports the optional fields 852 "hostname" and "cache-key", for the "oc_http_request_v1" record type. 853 The "client-address" field is hashed. 855 In this example, the logging integration types that are supported are 856 named "kafka" and "logstash" 857 { 858 "capabilities": [ 859 { 860 "capability-type": "FCI.Logging", 861 "capability-value": { 862 "transport-types": [ 863 "kafka", 864 "logstash" 865 ], 866 "record-type": "oc_http_request_v1", 867 "fields": [ 868 "hostname", 869 "cache-key" 870 ], 871 "hash-fields": [ 872 "client-address" 873 ] 874 }, 875 "footprints": [ 876 877 ] 878 } 879 ] 880 } 882 6.2. Metadata Interface extension for Logging 884 This is a proposal of Logging Metadata and Transport Metadata objects 885 that comply with the CDNI "Service Metadata" interface 887 6.2.1. Logging Configuration object 889 The following shows an example of Logging Configuration MI.Logging 890 Metadata object serialization, for a logging integration that 891 includes the optional field "hostname" in the log record. 893 { 894 "metadata": [ 895 { 896 "generic-metadata-type": "MI.Logging", 897 "generic-metadata-value": { 898 "include-fields": [ 899 "hostname" 900 ] 901 }, 902 "footprints": [ 903 904 ] 905 } 906 ] 907 } 909 6.2.2. Transport Configuration object 911 An initial set of logging transport types and their respective 912 configuration objects should be defined. More types can be added in 913 the future as needed. The following shows an example of Transport 914 Configuration MI.LoggingTransport Metadata object serialization, for 915 a "kafka" logging integration type. 917 { 918 "metadata": [ 919 { 920 "generic-metadata-type": "MI.LoggingTransport", 921 "generic-metadata-value": { 922 "type": [ 923 "kafka", 924 ], 925 "config": 926 927 ] 928 }, 929 "footprints": [ 930 931 ] 932 } 933 ] 934 } 936 7. IANA Considerations 938 7.1. CDNI Payload Types 940 This document requests the registration of the following CDNI Payload 941 Types under the IANA CDNI Payload Type registry [RFC7736]: 943 +--------------------------+---------------+ 944 | Payload Type | Specification | 945 +--------------------------+---------------+ 946 | FCI.RequestRouterAddress | RFCthis | 947 | MI.FallbackAddress | RFCthis | 948 | MI.Logging | RFCthis | 949 | MI.LoggingTransport | RFCthis | 950 +--------------------------+---------------+ 952 [RFC Editor: Please replace RFCthis with the published RFC number for 953 this document.] 955 7.1.1. CDNI FCI RequestRouterAddress Payload Type 957 Purpose: The purpose of this payload type is to distinguish 958 RequestRouterAddress FCI objects (and any associated capability 959 advertisement) 961 Interface: FCI 963 Encoding: see Section 2.1 965 7.1.2. CDNI MI FallbackAddress Payload Type 967 Purpose: The purpose of this payload type is to distinguish 968 FallbackAddress MI objects (and any associated capability 969 advertisement) 971 Interface: MI/FCI 973 Encoding: see Section 2.2 975 7.1.3. CDNI MI Logging Payload Type 977 Purpose: The purpose of this payload type is to distinguish Logging 978 MI objects (and any associated capability advertisement) 980 Interface: MI/FCI 982 Encoding: see Section 6.2.1 984 7.1.4. CDNI MI LoggingTransport Payload Type 986 Purpose: The purpose of this payload type is to distinguish 987 LoggingTransport MI objects (and any associated capability 988 advertisement) 990 Interface: MI/FCI 992 Encoding: see Section 6.2.2 994 8. Security Considerations 996 TBD. 998 9. Acknowledgements 1000 The authors would like to thank Kevin J. Ma for his guidance and 1001 support. 1003 10. Contributors 1005 The authors would like to thank all members of the SVA's Open Caching 1006 Working Group for their contribution in support of this document. 1008 11. References 1010 11.1. Normative References 1012 [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", 1013 STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, 1014 . 1016 [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - 1017 Application and Support", STD 3, RFC 1123, 1018 DOI 10.17487/RFC1123, October 1989, 1019 . 1021 [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate 1022 Requirement Levels", BCP 14, RFC 2119, 1023 DOI 10.17487/RFC2119, March 1997, 1024 . 1026 [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform 1027 Resource Identifier (URI): Generic Syntax", STD 66, 1028 RFC 3986, DOI 10.17487/RFC3986, January 2005, 1029 . 1031 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing 1032 Architecture", RFC 4291, DOI 10.17487/RFC4291, February 1033 2006, . 1035 [RFC5890] Klensin, J., "Internationalized Domain Names for 1036 Applications (IDNA): Definitions and Document Framework", 1037 RFC 5890, DOI 10.17487/RFC5890, August 2010, 1038 . 1040 [RFC5891] Klensin, J., "Internationalized Domain Names in 1041 Applications (IDNA): Protocol", RFC 5891, 1042 DOI 10.17487/RFC5891, August 2010, 1043 . 1045 [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 1046 Address Text Representation", RFC 5952, 1047 DOI 10.17487/RFC5952, August 2010, 1048 . 1050 [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content 1051 Distribution Network Interconnection (CDNI) Problem 1052 Statement", RFC 6707, DOI 10.17487/RFC6707, September 1053 2012, . 1055 [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., 1056 "Framework for Content Distribution Network 1057 Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, 1058 August 2014, . 1060 [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., 1061 and R. Peterkofsky, "Content Distribution Network 1062 Interconnection (CDNI) Logging Interface", RFC 7937, 1063 DOI 10.17487/RFC7937, August 2016, 1064 . 1066 [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, 1067 "Content Delivery Network Interconnection (CDNI) 1068 Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, 1069 . 1071 [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network 1072 Interconnection (CDNI) Control Interface / Triggers", 1073 RFC 8007, DOI 10.17487/RFC8007, December 2016, 1074 . 1076 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, 1077 R., and K. Ma, "Content Delivery Network Interconnection 1078 (CDNI) Request Routing: Footprint and Capabilities 1079 Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, 1080 . 1082 11.2. Informative References 1084 [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) 1085 Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, 1086 December 2015, . 1088 Authors' Addresses 1090 Ori Finkelman 1091 Qwilt 1092 6, Ha'harash 1093 Hod HaSharon 4524079 1094 Israel 1096 Phone: +972-72-2221647 1097 Email: orif@qwilt.com 1099 Sanjay Mishra 1100 Verizon 1101 13100 Columbia Pike 1102 Silver Spring, MD 20904 1103 USA 1105 Email: sanjay.mishra@verizon.com