Network Working Group O. Finkelman Internet-Draft Qwilt Intended status: Standards Track S. Mishra Expires: May 3, 2018 Verizon October 30, 2017 CDNI SVA Extensions draft-finkelman-cdni-sva-extensions-00 Abstract The Open Caching working group of the Streaming Video Alliance is focused on the delegation of video delivery request from commercial CDNs to a caching layer at the ISP. In that aspect, Open Caching is a specific use case of CDNI, where the commercial CDN is the upstream CDN (uCDN) and the ISP caching layer is the downstream CDN (dCDN). Requirements Language The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119 [RFC2119]. Status of This Memo This Internet-Draft is submitted in full conformance with the provisions of BCP 78 and BCP 79. Internet-Drafts are working documents of the Internet Engineering Task Force (IETF). Note that other groups may also distribute working documents as Internet-Drafts. The list of current Internet- Drafts is at https://datatracker.ietf.org/drafts/current/. Internet-Drafts are draft documents valid for a maximum of six months and may be updated, replaced, or obsoleted by other documents at any time. It is inappropriate to use Internet-Drafts as reference material or to cite them other than as "work in progress." This Internet-Draft will expire on May 3, 2018. Copyright Notice Copyright (c) 2017 IETF Trust and the persons identified as the document authors. All rights reserved. This document is subject to BCP 78 and the IETF Trust's Legal Provisions Relating to IETF Documents Finkelman & Mishra Expires May 3, 2018 [Page 1] Internet-Draft CDNI SVA Extensions October 2017 (https://trustee.ietf.org/license-info) in effect on the date of publication of this document. Please review these documents carefully, as they describe your rights and restrictions with respect to this document. Code Components extracted from this document must include Simplified BSD License text as described in Section 4.e of the Trust Legal Provisions and are provided without warranty as described in the Simplified BSD License. Table of Contents 1. Introduction . . . . . . . . . . . . . . . . . . . . . . . . 3 1.1. Terminology . . . . . . . . . . . . . . . . . . . . . . . 3 2. Request routing . . . . . . . . . . . . . . . . . . . . . . . 3 2.1. Request router address . . . . . . . . . . . . . . . . . 3 2.2. uCDN fallback address . . . . . . . . . . . . . . . . . . 4 3. Content management . . . . . . . . . . . . . . . . . . . . . 5 3.1. Content matching rules . . . . . . . . . . . . . . . . . 5 3.1.1. Regular expresssion . . . . . . . . . . . . . . . . . 6 3.1.2. Playlist . . . . . . . . . . . . . . . . . . . . . . 6 3.2. Geo limits . . . . . . . . . . . . . . . . . . . . . . . 7 3.3. Scheduled operations . . . . . . . . . . . . . . . . . . 8 3.4. Trigger extensibility . . . . . . . . . . . . . . . . . . 9 3.5. Capabilties . . . . . . . . . . . . . . . . . . . . . . . 10 4. Split authentication . . . . . . . . . . . . . . . . . . . . 11 5. CORS delegation . . . . . . . . . . . . . . . . . . . . . . . 13 6. Logging . . . . . . . . . . . . . . . . . . . . . . . . . . . 16 6.1. FCI extension for Logging . . . . . . . . . . . . . . . . 19 6.2. Metadata Interface extension for Logging . . . . . . . . 20 6.2.1. Logging Configuration object . . . . . . . . . . . . 20 6.2.2. Transport Configuration object . . . . . . . . . . . 21 7. IANA Considerations . . . . . . . . . . . . . . . . . . . . . 22 7.1. CDNI Payload Types . . . . . . . . . . . . . . . . . . . 22 7.1.1. CDNI FCI RequestRouterAddress Payload Type . . . . . 22 7.1.2. CDNI MI FallbackAddress Payload Type . . . . . . . . 22 7.1.3. CDNI MI Logging Payload Type . . . . . . . . . . . . 22 7.1.4. CDNI MI LoggingTransport Payload Type . . . . . . . . 23 8. Security Considerations . . . . . . . . . . . . . . . . . . . 23 9. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . 23 10. Contributors . . . . . . . . . . . . . . . . . . . . . . . . 23 11. References . . . . . . . . . . . . . . . . . . . . . . . . . 23 11.1. Normative References . . . . . . . . . . . . . . . . . . 23 11.2. Informative References . . . . . . . . . . . . . . . . . 25 Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . 25 Finkelman & Mishra Expires May 3, 2018 [Page 2] Internet-Draft CDNI SVA Extensions October 2017 1. Introduction In this document, we describe the different use cases of Open Caching and the interface and functionality extensions they require, compared to the existing CDNI RFCs. For consistency, this document follows the CDNI notation of uCDN (the commercial CDN) and dCDN (the ISP caching layer). When using the term CP in this document we refer to a video content provider. The CDNI Logging interface is described in [RFC7937]. The CDNI metadata interface is described in [RFC8006]. The CDNI footprint and capability interface is described in [RFC8008]. The CDNI control interface / triggers is described in [RFC8007]. 1.1. Terminology This document reuses the terminology defined in [RFC6707], [RFC8006], [RFC8007], and [RFC8008]. Additionally, the following terms are used throughout this document and are defined as follows: o SVA - Streaming Video Alliance. o OC - SVA Open Caching. o RR - Request Router. o CP - Content Provider. 2. Request routing This section lists extensions required by request routing features. 2.1. Request router address Open Caching uses iterative request redirect as defined in [RFC7336]. In order for the uCDN to redirect to the dCDN it requires a request router address. CDNI RFCs do not specify how the request router address is advertised and suggests it may be passed via a bootstrap protocol / interface, which is currently not defined. We propose to add the request router address as a capability under the Footprint and Capabilities interface. Finkelman & Mishra Expires May 3, 2018 [Page 3] Internet-Draft CDNI SVA Extensions October 2017 Use cases * Footprint: The dCDN may want to have different RR addresses per footprint. Note that a dCDN may spread across multiple geographies. This makes it easier to route client request to a nearby RR. Though this can be achieved using a single canonical name and geo DNS, that approach has limitations, for example a client may be using third party DNS resolver, making it impossible for the redirector to detect where the client is located. * Scaling: The dCDN may choose to scale its RR service by deploying more RRs in new locations and advertise them via an updatable interface like the FCI. Proposal Advertise request router address in an FCI capability object. Example FCI.RequestRouterAddress object: { "capabilities": [ { "capability-type": "FCI.RequestRouterAddress", "capability-value": { "address": }, "footprints": [ ] } ] } 2.2. uCDN fallback address Open Caching requires that the uCDN should provide a fallback address to the dCDN to be used in cases where the dCDN cannot properly handle the request. To avoid redirect loops, the dCDN would redirect the request back to the uCDN but to a different location than the original uCDN address, the uCDN will not redirect requests coming to that other address. Use cases * Failover: A dCDN request router receives a request but has no caches to which it can route the request to. This can happen Finkelman & Mishra Expires May 3, 2018 [Page 4] Internet-Draft CDNI SVA Extensions October 2017 in the case of failures, or temporary network overload. In these cases, the router may choose to redirect the request back to the uCDN fallback address. * Error: A cache may receive a request that it cannot properly serve, for example, some of the metadata objects for that service were not properly acquired. In this case the cache may resolve to redirect back to uCDN. Proposal Add a generic metadata object for fallback address similar to the source metadata. Example MI.FallbackAddress object: { "generic-metadata-type": "MI.FallbackAddress", "generic-metadata-value": { "sources": [ { "endpoints": [ "fallback-a.service123.ucdn.example", "fallback-b.service123.ucdn.example" ], "protocol": "http/1.1" }, { "endpoints": ["origin.service123.example"], "protocol": "http/1.1" } ] } } 3. Content management Open Caching uses the CDNI CI/T [RFC8007] as an interface for content management operations. The basic operations are the ones defined in the RFC (i.e. purge, invalidate, pre-position). 3.1. Content matching rules RFC8007 provides means to match on full content URL or patterns with wildcards. The Open Caching working group proposes to add two more match rule types. Finkelman & Mishra Expires May 3, 2018 [Page 5] Internet-Draft CDNI SVA Extensions October 2017 3.1.1. Regular expresssion Using regexp one can create more complex rules to match on objects for the cases of invalidation and purge. Use cases * Purge: Purging specific content within a specific directory path. In some cases wildcard MAY be used but it can be a constraining or overreaching variable that exposes the assets to purge further than desired. Proposal Add content.regexs to trigger specification. Name: content.regexs Description: Regexs of content the CI/T Trigger Command applies to. Value: A JSON array of Regexs represented as JSON strings. Mandatory: No, but at least one of "metadata.*", "content.*" or "playlist.urls" MUST be present and non-empty. 3.1.2. Playlist Using video playlist files, one can trigger an operation that will work on a collection of distinct media files in a representation that is natural for the content provider. A playlist may have several formats, specifically HLS *.m3u8 manifest [RFC8216], MSS *.ismc client manifest, and DASH XML MPD file [ISO/IEC 23009-1:2014]. Use cases * Pre-position: Pre-position of content requires passing the full list of media files to the dCDN. Passing the manifest instead is a more natural interface for both sides as they are both supposed to be able to properly read and understand the manifest files. Proposal Add playlist.urls to trigger specification. Finkelman & Mishra Expires May 3, 2018 [Page 6] Internet-Draft CDNI SVA Extensions October 2017 Name: playlist.urls Description: URLs of video playlist the CI/T Trigger Command applies to. Value: A JSON array of Regexs represented as JSON strings. Mandatory: No, but at least one of "metadata.*", "content.*" or "playlist.urls" MUST be present and non-empty. 3.2. Geo limits A content operation may apply for a specific geographical region, or need to be excluded from a specific region. In this case, the trigger should be applied only to parts of the network that are included or not excluded by the geo limit. Note that the limit here is on the cache location rather than client location. Use cases * Pre-position: Certain contracts allow for prepositioning or availability of contract in all regions except for certain excluded regions in the world, including caches. For example, some CPs content cannot ever knowingly touch servers in a specific country, including caches. Therefore, these regions MUST be excluded from a pre-positioning operation. * 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. Proposal Add GEO locations as an option in the trigger specification. We should consider where this locations object is defined. Should this a part of CI/T or there can be a way we can use metadata objects. The generic metadata object MI.LocationAcl has the same syntax, though the meaning is different as the limit here is on caches rather than end user locations. Example of trigger specification with a geo limit: Finkelman & Mishra Expires May 3, 2018 [Page 7] Internet-Draft CDNI SVA Extensions October 2017 POST /triggers HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* Content-Type: application/cdni; ptype=ci-trigger-command Content-Length: 352 { "trigger": { "type": "preposition", "content.urls": [ "https://www.example.com/a/b/c/1", "https://www.example.com/a/b/c/2" ] }, "locations": [ { "action": "allow" / "deny", "footprints": [ { "footprint-type": "countrycode", "footprint-value": ["us"] } ] } ], "cdn-path": [ "AS64496:1" ] } 3.3. Scheduled operations A uCDN may wish to perform content management operation on the dCDN with a defined local time schedule. Use cases * Pre-position: A content provider wishes to pre-populate a new episode at off-peak time so that it would be ready on caches (for example home caches) at prime time when the episode is released for viewing. This requires an interface that directs the dCDN when to pre-position the content; the time frame is local time per area as the off-peak time is also localized. Proposal Add an execution time window as an option in the trigger specification. Finkelman & Mishra Expires May 3, 2018 [Page 8] Internet-Draft CDNI SVA Extensions October 2017 Example of trigger specification with a schedule limit: POST /triggers HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* Content-Type: application/cdni; ptype=ci-trigger-command Content-Length: 352 { "trigger": { "type": "preposition", "content.urls": [ "https://www.example.com/a/b/c/1", "https://www.example.com/a/b/c/2" ] }, "time-windows": [ { "time-type": "local" / "UTC", "start": "", "end": "" } ], "cdn-path": [ "AS64496:1" ] } 3.4. Trigger extensibility There are cases in which some new data has to pass in the trigger which was not thought of in advance. We propose the add a mechanism to the trigger spec which will be similar to the MI generic metadata, allowing parties to easily add more information, that can later be standardized if required. Use cases * Purge content by acquisition time: A uCDN finds that due to configuration mistake it has delivered wrong content, in the past two hours. The uCDN would like to instruct the dCDN to invalidate all content that was acquired in the past two hours. However, there is no such primitive in the trigger specification. If this would be a common use case it may require the addition of a new generic trigger spec object that restrict the match to be on content which was acquired in some time spec. Finkelman & Mishra Expires May 3, 2018 [Page 9] Internet-Draft CDNI SVA Extensions October 2017 * Pre-position by cache type: The uCDN would like the dCDN to pre-populate some content, but only on a specific layer of the caching network, for example, only on home caches. There is currently no such option in the interface. By using a generic object parties may define such object and implement it between them, and later standardize it, if required. Proposal Add trigger extensibility mechanism to the trigger specification. Example of trigger extension: POST /triggers HTTP/1.1 User-Agent: example-user-agent/0.1 Host: dcdn.example.com Accept: */* Content-Type: application/cdni; ptype=ci-trigger-command Content-Length: 352 { "trigger": { "type": "purge", "content.patterns": [ "https://www.example.com/*" ] }, "generic-trigger-spec-type": , "generic-trigger-spec-value": { } } 3.5. Capabilties The capabilities added to the triggers interface are not mandatory to support and are, therefore, best negotiated via the FCI. Use cases * Content management operations: Advertise which content operations are supported by the dCDN. CDNI defines three operations (purge, invalidate, pre-position), but it does not necessarily mean that all dCDNs support all of them. The uCDN Finkelman & Mishra Expires May 3, 2018 [Page 10] Internet-Draft CDNI SVA Extensions October 2017 may prefer to work only with dCDN that support what the uCDN needs. * Content mapping types: Advertise which mapping types are supported, for example, if adding content regexp and possibly playlists, not all dCDN would support it. For playlist, advertise which types and versions of protocols are supported, e.g. HLS/DASH/SS, DASH templates. * Trigger spec objects: Advertise which trigger spec object are supported, for example time-window, geo-limit etc. Proposal Define the non-mandatory objects as generic objects, similar to the metadata generic objects, and then the FCI can declare which ones of the trigger spec objects are supported. . 4. Split authentication Different CDNs and Content Providers apply different access control and authentication of user requests. It is not feasible for a dCDN, or ISP cache layer, to implement every scheme a uCDN may have thought of, and, unfortunately, it is not reasonable to expect that uCDNs and CPs will move from their current implementation to a new standard, any time soon. In some cases, existing implementation also include secrets under NDA; sharing them with a third party dCDN is unlikely to happen. Therefore, we aim to look for a solid, generic solution that keeps the access control, authentication and authorization logic in the origin/uCDN. Use cases * URI signing: There are numerous methods in which a CP signs its URIs such that the uCDN can verify the signatures. In most cases, symmetric keys are being used and require some key exchange. Expecting the dCDN caches to implement every method used by commercial CDNs is problematic, and sharing of content provider keys is unlikely. * Token based authentication: Some CPs and CDNs are using token based client / session authentication. The token is passed either as a URI query parameter or as a cookie. The dCDN / ISP cannot implement the token validation, as it has no knowledge of the identity and validation methods used by the CP / uCDN. Also, if using cookies with HTTP redirect, the cookie will be omitted after the redirect, so a solution for cookie based authentication is necessary. Finkelman & Mishra Expires May 3, 2018 [Page 11] Internet-Draft CDNI SVA Extensions October 2017 * CORS delegation: CORS may also be a use case of split authentication, see explanation in the CORS delegation section. Proposal Split authentication is a mechanism that leverages the fact that video sessions are very long and chunked into very small requests, comparing the overall session time and volume. The dCDN cache relays the authentication verification to the uCDN by sending the uCDN a HEAD request for every new session. The dCDN cache saves the session state for some time and uses it for subsequent requests of the same session. As this is a general problem when delegating traffic between CDNs, and in-fact, can become a blocker for CDNI deployments. We propose to consider this concept for the general CDNI use case, and draft it for RFC. The following diagram gives a high level sequence view of the URI signing use case. +------+ +------+ +------+ +-----+ |Client| |dCDN | |uCDN | | CP | | | | | | | | | +---+--+ +---+--+ +---+--+ +--+--+ | | | | +----------------+ | | | |Access video on | | | | |CP web site | | | | +-------+--------+ | | | | Get master manifest location | | +-----------------+----------------------+-----------------> | |Respond with signed URI to manifest | <----------------------------------------+-----------------+ | Get manifest | | | +----------------------------------------> | | | | | | | +-------+----------+ | | | |Verify URI signing| | | | +-------+----------+ | | | Redirect to dCDN | | <----------------------------------------+ | | Get manifest | | | +-----------------> | | | |Authenticate URI | | | +----------------------> | | |Authentication success| | | Master manifest <----------------------+ | Finkelman & Mishra Expires May 3, 2018 [Page 12] Internet-Draft CDNI SVA Extensions October 2017 <-----------------+ | | | Get sub manifest| | | +-----------------> | | | |Authenticate URI | | | +----------------------> | | |Authentication success| | | <----------------------+ | | | | | | +------------------+ | | | |Save authenticated| | | | |session token | | | | +--------+---------+ | | | Sub manifest | | | <-----------------+ | | | Request chunk 1 | | | +-----------------> | | | | | | | +---------------------+ | | | | Use session state to| | | | | authenticate client | | | | | chunk requests | | | | +----------+----------+ | | | chunk 1 | | | <-----------------+ | | |-Request chunk 2-> | | <------chunk 2----| | | |-Request chunk 3-> | | <------chunk 3----+ | | | | | | + + + + Figure 1 5. CORS delegation CORS (Cross Origin Resource Sharing) is a mechanism designed to allow a resource from domain A to access other resources in domain B, overriding the same-origin policy. When a uCDN delegate traffic to a dCDN (or ISP) the dCDN is required to comply with the same CORS server behavior the uCDN would have had. For example, if a resource from domain A is accessible for request coming from a resource domain B, but not accessible to requests coming from a resource of domain C, the same logic must be done by the dCDN. Though CORS can possibly be handled by simply echoing the Origin header value, or *, back to the client, in some cases it is not sufficient, and it also breaks the concept of CORS as an access control mechanism. As proper CORS handling is not possible without a Finkelman & Mishra Expires May 3, 2018 [Page 13] Internet-Draft CDNI SVA Extensions October 2017 delegation scheme, the Open Caching working group sees it as an essential part of inter-CDN delegation, and therefore propose to adopt it under CDNI and draft it for CDNI RFC. Use cases * A simple use case example is a when resource from Origin: www.video.example.com points to the media file on domain: www.cdn.com. The uCDN is supposed to deliver the content if the Origin is video.example.com otherwise it should be rejected. In this case, for a request header "Origin: www.video.example.com" the CDN should reply with "Access- Control-Allow-Origin: www.video.example.com". OTOH, if the origin is www.video.other.com then the CDN should not allow it by omitting the ACAO header. When delegating the session to a dCDN cache, it should maintain the same behavior. Proposals There are several alternatives for the dCDN / ISP cache to learn the allowed origins for a content item. 1. Caching: Caching of CORS headers per content. If the cache receives a request using an origin it does not already approve for that content, the cache sends a HEAD request to the CDN with the client's CORS request headers. The cache saves the response information in a content database and uses it for subsequent requests for the same content. . 2. Metadata: the uCDN can provide the dCDN the metadata referring the content of a specific domain. This metadata holds, for example, all the information required to take CORS decisions at the Open Cache. 3. Split authentication: Using split authentication, the dCDN cache can send the CORS headers to the uCDN in the initial session request, the uCDN responds to the CORS request properly, the dCDN forwards the CORS response to the client and caches it for rest of the client session. The following diagram gives a high level sequence view of CORS delegation from uCDN to dCDN using the CORS caching alternative. Finkelman & Mishra Expires May 3, 2018 [Page 14] Internet-Draft CDNI SVA Extensions October 2017 +------+ +------+ +------+ +-----+ +-|Client| |dCDN | | uCDN | | CP | | |1 | | | | B | | A | |2+---+--+ +---+--+ +---+--+ +--+--+ +--+--|+ | | | +-------+-------------+ | | | |Access resource on CP| | | | |www.example.com | | | | +-------+-------------+ | | | | | Get resource A from example.com | | | +-----------------+----------------------+-----------------> | | CP resource A points to a resource B on uCDN cdn.com | | <----------------------------------------+-----------------+ | | Get B from uCDN ucdn.com | | | | Origin: example.com | | | +----------------------------------------> | | | | | | | | | +----------+-----------+ | | | | |uCDN Delegate to dCDN | | | | | +----------+-----------+ | | | | Redirect to dCDN | | | <----------------------------------------+ | | |Get B from dCDN | | | | |Origin: example.com | | | +-----------------> | | | | | Request CORS for B | | | | | Origin: example.com | | | | +----------------------> | | | | Provide CORS for B | | | | | Origin: example.com | | | | <----------------------+ | | | +--------+-----------+ | | | | + cache B CORS rules | | | | | + Origin: example.com| | | | | +--------+-----------+ | | | | Provide B with | | | | | CORS headers | | | | <-----------------+ | | | Get B from uCDN ucdn.com | | | Origin: example.com | | |-------------------------------------------> | | | | | | | | | +----------+-----------+ | | | | |uCDN delegate to dCDN | | | | | +----------+-----------+ | | | | Redirect to dCDN | | <-------------------------------------------+ | | Get B from dCDN | | | Finkelman & Mishra Expires May 3, 2018 [Page 15] Internet-Draft CDNI SVA Extensions October 2017 | Origin: example.com| | | |--------------------> | | | | +--------+-----------+ | | | | + use B cached CORS | | | | | + Origin: example.com| | | | | +--------+-----------+ | | | | Provide B with | | | | | CORS headers | | | <--------------------+ | | + + + + + Figure 2 In the above simplified example, we depict the caching alternative for CORS solution. Client 1 accesses resource A on CP domain example.com. Resource A, refers client 1 to resource B on uCDN ucdn.com. Without delegation, at this points uCDN has to resolve CORS and decide if a resource from example.com is allowed to access a resource at ucdn.com. However, once delegated to dCDN, it becomes the dCDNs duty to resolve it for the client request arrives at the dCDN cache. The dCDN sends a CORS request to the uCDN, for resource B with origin example.com, it then uses the response to respond to client 1, and caches the response. When client 2's request arrives at the dCDN, the required CORS information is already in cache and the dCDN can serve client 2 without reiterating to uCDN. For simplicity, in this diagram, we have ignored some of the challenges of CORS delegation like preflight requests and "null" origin after HTTP redirect. 6. Logging This section outlines creation of service delivery logs at the dCDN (ISP) and transmittal of the logs by the dCDN to the uCDN. The key motivation for logging outlined below as compared to CDNI Logging Interface [RFC7937] is the ability for dCDN and uCDN to negotiate and agree on a log transport mechanism. The logging mechanism provides the flexibility for CDNs to leverage common transport mechanism in-use already. Second, the open caching working group has selected Squid based file format given its wide usage within the CDN environments for access and cache logs, result codes and error messages. As an example, the result codes in squid return both the status code returned by downstream as well as result code indicator such as HIT, MISS, REFRESH_HIT, etc. Between the two statuses, it is easier to discern the delivery status. As an example, if the request was forbidden by the origin, the status field Finkelman & Mishra Expires May 3, 2018 [Page 16] Internet-Draft CDNI SVA Extensions October 2017 will likely be MISS/403 or if it is a cache error response, it will be HIT/503. So, leveraging the Squid log already in use within the CDN environment and, equally important, the ability for CDNs to negotiate and agree on a file transport mechanisms, were the key motivations for open caching. These are therefore proposed as complementary extensions to the CDNI Logging Interface [RFC7937]. The sub-sections below explain extensions to the Footprint and Capabilities [RFC8008] and Metadata Interface [RFC8006]. The specific extension includes FCI announcement of supported log file transport types by dCDN and metadata response by uCDN to provision one or more log file types from the list sent by the dCDN. Use cases * Transport: Delivery logs are to be supplied by the dCDN to the uCDN via a transport mechanism of choice, supported by both dCDN and uCDN. * Record format: Log record format is advertised by the dCDN and interpreted correctly by the uCDN. The dCDN in this case shall announce to uCDN one or more transport format that it supports. The uCDN, in turn, will select one format from the potential candidates and set up a provisioning process. * Log destination: The uCDN configures a log receiving system tied to a specific delivery service it has delegated to a dCDN. The uCDN will provision log destination at its end where it will route the returned logs by delivery service associated with the log file. The diagram below illustrates the use cases: Finkelman & Mishra Expires May 3, 2018 [Page 17] Internet-Draft CDNI SVA Extensions October 2017 Delivery Service A (VOD) Delivery Service C RR Logs Delivery Service B (Live) (Linear) +----------------------+ +-----------------+ +-----------------+ | | | | | | |Log Destination 1(VOD)| |Log Destination 2| |Log Destination 3| | Logstash | | Kafka | | SFTP | | | | | | | +------------^---------+ +----------^------+ +----------^------+ | | | | | | +----------------------------------------------+ uCDN | +----------------------------------------------------------------------+ dCDN | Delivery Logs +----------+-------+ Service A/B/C | | +-------+--------+-----> | RR Logs | | | | dCDN Open Cache <-----------+ | | | | Controller | | +----+-----+ | | | | | | | | | +-------^-------+--+ | | +--+-+----+ | | ^ +----+-----+ | | | | +---+----+ | | Request | | | +--+---+--+ | | | | Router | | | | | | +--+--+-+ | | +-------+ | | | | | +----------+ +------+ Cache | | | Cache | | | +-----+ | +---------+ +-------+ Figure 3 Proposal Delivery logs are created and then transferred from log producing entities at the dCDN premises (mainly caches and Request Router) to log destinations at the uCDN premises. The dCDN may offload logs from these entities to logging at the dCDN premises to facilitate log transfers, or, logs may be transferred directly from log producing entities to uCDN. Various transport mechanisms may suit the use case of transferring log data, for example SFTP, HTTP upload, Kafka, Logstash or other methods as per the agreement between a dCDN and a uCDN. In compliance with the CDNI Footprint and Capabilities Interface, and therefore, as per the above use cases, the dCDN is responsible to advertise supported Logging "record-types", as well as Logging Finkelman & Mishra Expires May 3, 2018 [Page 18] Internet-Draft CDNI SVA Extensions October 2017 "fields" which are marked as optional for the s pecified "record- types" as defined by the CDNI "Logging Capability Object". The CDNI Logging Capability Object is extended to contain additional properties that hold information on record format, such as fields that should be obfuscated by the dCDN. Note that the uCDN can further control field obfuscation when configuring a logging integration. During provisioning process the dCDN may reject configuration if a selected record format is not available for a selected Log Integration Type. 6.1. FCI extension for Logging This is a proposal of a Logging Capability object that extends the CDNI "FCI.Logging" object. The following shows an example of Logging Capability object serialization, for a dCDN that supports the optional fields "hostname" and "cache-key", for the "oc_http_request_v1" record type. The "client-address" field is hashed. In this example, the logging integration types that are supported are named "kafka" and "logstash" Finkelman & Mishra Expires May 3, 2018 [Page 19] Internet-Draft CDNI SVA Extensions October 2017 { "capabilities": [ { "capability-type": "FCI.Logging", "capability-value": { "transport-types": [ "kafka", "logstash" ], "record-type": "oc_http_request_v1", "fields": [ "hostname", "cache-key" ], "hash-fields": [ "client-address" ] }, "footprints": [ ] } ] } 6.2. Metadata Interface extension for Logging This is a proposal of Logging Metadata and Transport Metadata objects that comply with the CDNI "Service Metadata" interface 6.2.1. Logging Configuration object The following shows an example of Logging Configuration MI.Logging Metadata object serialization, for a logging integration that includes the optional field "hostname" in the log record. Finkelman & Mishra Expires May 3, 2018 [Page 20] Internet-Draft CDNI SVA Extensions October 2017 { "metadata": [ { "generic-metadata-type": "MI.Logging", "generic-metadata-value": { "include-fields": [ "hostname" ] }, "footprints": [ ] } ] } 6.2.2. Transport Configuration object An initial set of logging transport types and their respective configuration objects should be defined. More types can be added in the future as needed. The following shows an example of Transport Configuration MI.LoggingTransport Metadata object serialization, for a "kafka" logging integration type. { "metadata": [ { "generic-metadata-type": "MI.LoggingTransport", "generic-metadata-value": { "type": [ "kafka", ], "config": ] }, "footprints": [ ] } ] } Finkelman & Mishra Expires May 3, 2018 [Page 21] Internet-Draft CDNI SVA Extensions October 2017 7. IANA Considerations 7.1. CDNI Payload Types This document requests the registration of the following CDNI Payload Types under the IANA CDNI Payload Type registry [RFC7736]: +--------------------------+---------------+ | Payload Type | Specification | +--------------------------+---------------+ | FCI.RequestRouterAddress | RFCthis | | MI.FallbackAddress | RFCthis | | MI.Logging | RFCthis | | MI.LoggingTransport | RFCthis | +--------------------------+---------------+ [RFC Editor: Please replace RFCthis with the published RFC number for this document.] 7.1.1. CDNI FCI RequestRouterAddress Payload Type Purpose: The purpose of this payload type is to distinguish RequestRouterAddress FCI objects (and any associated capability advertisement) Interface: FCI Encoding: see Section 2.1 7.1.2. CDNI MI FallbackAddress Payload Type Purpose: The purpose of this payload type is to distinguish FallbackAddress MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: see Section 2.2 7.1.3. CDNI MI Logging Payload Type Purpose: The purpose of this payload type is to distinguish Logging MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: see Section 6.2.1 Finkelman & Mishra Expires May 3, 2018 [Page 22] Internet-Draft CDNI SVA Extensions October 2017 7.1.4. CDNI MI LoggingTransport Payload Type Purpose: The purpose of this payload type is to distinguish LoggingTransport MI objects (and any associated capability advertisement) Interface: MI/FCI Encoding: see Section 6.2.2 8. Security Considerations TBD. 9. Acknowledgements The authors would like to thank Kevin J. Ma for his guidance and support. 10. Contributors The authors would like to thank all members of the SVA's Open Caching Working Group for their contribution in support of this document. 11. References 11.1. Normative References [RFC1034] Mockapetris, P., "Domain names - concepts and facilities", STD 13, RFC 1034, DOI 10.17487/RFC1034, November 1987, . [RFC1123] Braden, R., Ed., "Requirements for Internet Hosts - Application and Support", STD 3, RFC 1123, DOI 10.17487/RFC1123, October 1989, . [RFC2119] Bradner, S., "Key words for use in RFCs to Indicate Requirement Levels", BCP 14, RFC 2119, DOI 10.17487/RFC2119, March 1997, . [RFC3986] Berners-Lee, T., Fielding, R., and L. Masinter, "Uniform Resource Identifier (URI): Generic Syntax", STD 66, RFC 3986, DOI 10.17487/RFC3986, January 2005, . Finkelman & Mishra Expires May 3, 2018 [Page 23] Internet-Draft CDNI SVA Extensions October 2017 [RFC4291] Hinden, R. and S. Deering, "IP Version 6 Addressing Architecture", RFC 4291, DOI 10.17487/RFC4291, February 2006, . [RFC5890] Klensin, J., "Internationalized Domain Names for Applications (IDNA): Definitions and Document Framework", RFC 5890, DOI 10.17487/RFC5890, August 2010, . [RFC5891] Klensin, J., "Internationalized Domain Names in Applications (IDNA): Protocol", RFC 5891, DOI 10.17487/RFC5891, August 2010, . [RFC5952] Kawamura, S. and M. Kawashima, "A Recommendation for IPv6 Address Text Representation", RFC 5952, DOI 10.17487/RFC5952, August 2010, . [RFC6707] Niven-Jenkins, B., Le Faucheur, F., and N. Bitar, "Content Distribution Network Interconnection (CDNI) Problem Statement", RFC 6707, DOI 10.17487/RFC6707, September 2012, . [RFC7336] Peterson, L., Davie, B., and R. van Brandenburg, Ed., "Framework for Content Distribution Network Interconnection (CDNI)", RFC 7336, DOI 10.17487/RFC7336, August 2014, . [RFC7937] Le Faucheur, F., Ed., Bertrand, G., Ed., Oprescu, I., Ed., and R. Peterkofsky, "Content Distribution Network Interconnection (CDNI) Logging Interface", RFC 7937, DOI 10.17487/RFC7937, August 2016, . [RFC8006] Niven-Jenkins, B., Murray, R., Caulfield, M., and K. Ma, "Content Delivery Network Interconnection (CDNI) Metadata", RFC 8006, DOI 10.17487/RFC8006, December 2016, . [RFC8007] Murray, R. and B. Niven-Jenkins, "Content Delivery Network Interconnection (CDNI) Control Interface / Triggers", RFC 8007, DOI 10.17487/RFC8007, December 2016, . Finkelman & Mishra Expires May 3, 2018 [Page 24] Internet-Draft CDNI SVA Extensions October 2017 [RFC8008] Seedorf, J., Peterson, J., Previdi, S., van Brandenburg, R., and K. Ma, "Content Delivery Network Interconnection (CDNI) Request Routing: Footprint and Capabilities Semantics", RFC 8008, DOI 10.17487/RFC8008, December 2016, . 11.2. Informative References [RFC7736] Ma, K., "Content Delivery Network Interconnection (CDNI) Media Type Registration", RFC 7736, DOI 10.17487/RFC7736, December 2015, . Authors' Addresses Ori Finkelman Qwilt 6, Ha'harash Hod HaSharon 4524079 Israel Phone: +972-72-2221647 Email: orif@qwilt.com Sanjay Mishra Verizon 13100 Columbia Pike Silver Spring, MD 20904 USA Email: sanjay.mishra@verizon.com Finkelman & Mishra Expires May 3, 2018 [Page 25]