1. CONTRIBUTORS

This document was created prior to the implementation of this new template. The specific contributors were not documented at the time of authoring.

Notice:

This document has been created by the Streaming Video Technology Alliance. It is offered to the Alliance Membership solely as a basis for agreement and is not a binding proposal on the companies listed as resources above. The Alliance reserves the rights to at any time add, amend or withdraw statements contained herein. Nothing in this document is in any way binding to the Alliance or any of its members. The user’s attention is called to the possibility that implementation of the Alliance agreement contained herein may require the use of inventions covered by the patent rights held by third parties. By publication of this Alliance document, the Alliance makes no representation or warranty whatsoever, whether expressed or implied, that implementation of the specification will not infringe any third party rights, nor does the Alliance make any representation or warranty whatsoever, whether expressed or implied, with respect to any claim that has been or may be asserted by any third party, the validity of any patent rights related to any such claim, or the extent to which a license to use any such rights may or may not be available or the terms hereof.

© Streaming Video Technology Alliance

This document and translation of it may be copied and furnished to others, and derivative works that comment on or otherwise explain it or assist in its implementation may be prepared, copied, published and distributed, in whole or in part, without restriction other than the following, (1) the above copyright notice and this paragraph must be included on all such copies and derivative works, and (2) this document itself may not be modified in any way, such as by removing the copyright notice or references to the Alliance, except as needed for the purpose of developing Alliance Specifications.

By downloading, copying, or using this document in any manner, the user consents to the terms and conditions of this notice. Unless the terms and conditions of this notice are breached by the user, the limited permissions granted above are perpetual and will not be revoked by the Alliance or its successors or assigns.

This document and the information contained herein is provided on an “AS IS” bases and THE ALLIANCE DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO ANY WARRANTY THAT THE USE OF THE INFORMATION HEREIN WILL NOT INFRINGE ANY RIGHTS OR ANY IMPLIED WARRANTIES OF MERCHANTABILITY, TITLE OR FITNESS FOR A PARTICULAR PURPOSE.

2. ABSTRACT

This document describes the high-level functional requirements of an open caching system.

2.1. Versioning

Table 1: Document versioning

TABLE OF CONTENTS

1. CONTRIBUTORS 2

2. ABSTRACT 4

2.1. Versioning 5

3. INTRODUCTION 10

3.1. Market Overview 10

4. OPEN CACHE SYSTEM USE CASES 13

4.1. Network Operator “Last Mile” CDN extension 15

4.1.1. Network Operator CDN 15

4.1.2. Commercial CDN 15

4.1.3. Content Provider CDN 16

4.2. Capacity Augmentation Use Cases 16

5. ARCHITECTURAL GUIDELINES 18

5.1. Multi-Tenant Platform 19

5.2. Loose Coupling 19

5.3. Minimal Overhead and Change 19

5.4. Open Interfaces 19

6. NOT IN SCOPE 20

7. REQUIREMENTS TERMINOLOGY 21

8. OPEN CACHE NODE FUNCTIONAL REQUIREMENTS 22

8.1. Supported Content Types 22

8.1.1. Streaming Video On Demand 22

8.1.2. Live Streaming Video 22

8.1.3. Software Downloads 23

8.1.4. Live Streaming Audio 23

8.1.5. Other Applications 23

8.2. Software Requirements 24

8.2.1. Content Acquisition 24

8.2.2. Content Classification 25

8.2.3. Content Validation 25

8.2.4. Resource Orchestration 25

8.2.5. Client Divert 26

8.2.6. Content Delivery 26

8.2.7. Content Invalidation 27

8.2.8. Capability Exchange 28

8.2.9. Logging and Reporting 28

8.2.10. Monitoring 29

8.2.11. Open Cache System Expansion 29

8.2.12. Resilience and Availability 29

8.2.13. Open Cache Management 30

8.3. Infrastructure Requirements 30

8.4. Security Requirements 31

8.4.1. Authentication and Password Management 31

8.4.2. Session Management 32

8.4.3. Authorization and Access Control 32

8.4.4. Input Validation 32

8.4.5. Output Escaping/Encoding 33

8.4.6. Cryptographic Practices 33

8.4.7. Error Handling, Auditing, and Logging 33

8.4.8. Data Protection 34

8.4.9. Communication Security 34

8.4.10. Database Security 34

8.4.11. File Management 35

9. OPEN CACHE CONTROLLERS FUNCTIONAL REQUIREMENTS 36

9.1. CDN Control Functions 36

9.1.1. Management 36

9.1.2. Open Cache Selection 38

9.1.3. Monitoring 38

9.1.4. Logging 39

9.1.5. Request Routing 39

9.2. Service Provider Control Functions 40

9.2.1. Management 40

9.2.2. OCN Registrar 41

9.2.3. Monitoring and Logging 41

9.2.4. Content Control 42

9.2.5. Request Routing 43

9.3. Security 44

9.3.1. Authentication and Password Management 44

9.3.2. Session Management 44

9.3.3. Authorization and Access Control 45

9.3.4. Input Validation 45

9.3.5. Output Escaping/Encoding 46

9.3.6. Cryptographic Practices 46

9.3.7. Error Handling, Auditing, and Logging 47

9.3.8. Data Protection 47

9.3.9. Communication Security 48

9.3.10. Database Security 48

9.3.11. File Management 48

10. SPECIFICATIONS AND STANDARDS REFERENCES 50

11. TABLES AND FIGURES 51

11.1. Tables 51

11.2. Figures 51

12. ABOUT THE STREAMING VIDEO TECHNOLOGY ALLIANCE 52

4. INTRODUCTION

The rapid growth of online video creates a challenge to cost effectively build required network infrastructure capacity while improving quality of experience for consumers.

Problem statement: Today’s Internet architecture does not support efficient, large-scale deployment of video services across all components of the delivery infrastructure. Incentives between compute, storage and network have not been optimized as part of a unified delivery system.

Solution: Network operators, content providers, content delivery networks and technology vendors can collaborate in order to create a symbiotic architecture that will scale the end-to-end infrastructure in order to drive forward the future of online video. Caching video content close to the consumer is an essential part of the overall strategy to deal with the growth in online video. Open caching establishes an architecture in which popular video content is distributed through a universal cache function from inside the operator network and close to consumers.

This architecture provides the following benefits to the ecosystem stakeholders:

• Content providers – improved quality of experience (QoE) to consumers
• Service providers – improved economics for scaling their data network while improving QoE of video services to their subscribers
• Content delivery networks – extended delivery reach, improved QoE capabilities (congestion avoidance, lower latency) and improved economics for CDN network buildout.
• Technology providers – solution creation for the benefit of the entire ecosystem

4.1 Market Overview

There’s a fundamental shift in how online video is consumed today given the proliferation of mobile devices, Internet enabled devices and emergence of new streaming business models. According to eMarketer, time spent with digital video now trumps time spent with all other listed digital platforms, including digital radio, Facebook, and Pandora. In 2015, digital video finally pulled ahead. Users are spending an average of 1:55 hours with digital video each day, and only 1:44 on social networks.

Figure 1 – Average Time Spent per Day on Digital Activities

More specifically, the time adults spend watching digital video each day has increased from 21 minutes in 2011 to one hour and 16 minutes in 2015. Meanwhile, time spent watching traditional TV has been decreasing steadily since 2012.

Figure 2 – Time spent per day with video by US adults

This trend has a profound impact on bandwidth demand across broadband networks. A recent Cisco VNI report reveals that IP video will represent 80 percent of all traffic globally by 2019, up from 67 percent in 2014. Fixed broadband and mobile network operators across the globe are already struggling with extraordinary consumer demand.

The answer for network operators can be found in a new, open architecture for streaming video, which pushes content to the network edge, close to consumers, through open caching.

3.1 OPEN CACHE SYSTEM USE CASES

The open caching architecture builds upon a lot of the great work done by the IETF in defining a Content Delivery Network Interconnection (CDNI) and many of the use cases defined in RFC 6770 as articulated below:

Content Delivery Networks (CDNs) are used to deliver content because they can:

• Improve the experience for the End User; for instance delivery has lower latency (decreased round-trip-time and higher throughput between the user and the delivery server) and better robustness (ability to use multiple delivery servers),
• Reduce the network operator’s costs; for instance, lower delivery cost (reduced bandwidth usage) for cacheable content,
• Reduce the Content Service Provider’s (CSP) internal infrastructure costs, such as data center capacity, space, and electricity consumption, as popular content is delivered externally through the CDN rather than through the CSP’s own servers.

The building block for interconnection is the open cache node (OCN). CDNs of all types (commercial, content provider, operator) may use shared cache resources distributed within operator networks worldwide. With an open caching infrastructure in place across multiple operator networks, a CDN of any kind will essentially use a combination of its own caches coupled with distributed open caches for delivery of its content.

The overall CDN hierarchy may be viewed as a multi-tier delivery infrastructure in which tiers grow in level of distribution and decrease in the amount of single unit resource capabilities as depicted in the table below:

Table 2: Cache infrastructure requirements

The diagram below depicts the common compute and storage principle as it relates to multiple CDNs sharing a common open caching node layer within a single operator network. CDNs using this shared medium may be either a network operator CDN, a commercial CDN or a content provider CDN.

![A screen shot of a computer

Description automatically generated](k0m0rugw.015.png)

Figure 3 – Open Caching Node Resources Shared Among Multiple CDNs

The individual use cases which the Open Caching Architecture addresses are defined in the following sections.

Network Operator “Last Mile” CDN extension

By leveraging the open caching footprint, content providers and CDNs are able to virtually extend their own footprint inside operator networks in order to:

• Reduce overall network transport costs
• Reach network locations not available for 3rd party cache deployment, both in terms of geographic coverage (e.g. region where the CDN has no footprint) as well as in terms of proximity to the consumers (subscriber edge cache deployments at the town or neighborhood level).
• Achieve optimal content server utilization by offloading the “heavy lifting” of popular content to the open caching layer.
• Improve quality of experience by leveraging the close proximity open caching nodes, thus reducing latency as well as eliminating potential network bottlenecks.

Because of the universal nature of the open caching fabric, cache extension could extend multiple types of content delivery networks, including Operator CDNs, Commercial CDNs and Content Provider-Specific CDNs. Each of these CDN extensions are described further in this section.

Network Operator CDN

Network operators which deploy their own CDN to deliver content (both their own as well as 3rd party content providers’) can utilize the open caching layer deployed in closer proximity to the consumers to extend the reach of its operator CDN deeper in its network.

Commercial CDN

Commercial CDNs can utilize the open caching fabric deployed inside various operator networks, in a closer geographic location to the consumers with wider distribution, to offload video delivery and enhance its capacity. The use case of content providers using multiple CDNs for delivery of their content is also encompassed by this use case.

Content Provider CDN

Content provider-specific CDN can utilize the open caching fabric deployed inside various operator networks, in closer proximity to the consumers with wider distribution, to offload video delivery and enhance its capacity.

Capacity Augmentation Use Cases

Content providers and CDNs may face an unplanned overflow of capacity due to unexpected and temporary spikes in content consumption (e.g. SuperBowl). One inherent attribute of the open caching layer is its ability to act as a first caching tier to help accommodate consumption spikes:

• The open caching layer elastically adjusts to consumption demands pulling internal edge resources to address traffic spikes.
• Content providers and CDNs can reduce their need to provision additional capacity and de-provision that capacity after the spike has ended
• Content providers, CDNs and network operators do not need to incur additional network costs and performance degradation through increased content access latency and content delivery via sub-optimal paths

Content providers and CDNs may use the Open Caching layer to address both predictable and non-predictable consumption spikes such as the Olympics, software update releases or other events that are known in advance. Temporary peak demand can be met by leveraging the OC layer while reducing the CDN resources that would otherwise be required.

• The CDN layer can use the OC layer to leverage additional resources closer to the end users for enable OC offload only for the period of the spike.
• The resources may include additional OC storage and bandwidth capacity that would otherwise be required by the CDN layer.
• The CDN layer may mark specific content assets that are expected to drive the consumption increase, to the OC layer for expedited caching. Such content assets may be identified individually, or by association with particular content provider. For example, a CDN provider may mark content during the Game of Thrones season premiere.

Below are several examples of such content spikes:

• Planned Content Spike – Blockbuster New Video Release
• Planned Streaming Device Spike – Seasonal and New Device Launch
• Unplanned Spike – Real Time Viral Content
• Event-based Live Streaming Spike – Live stream events such as sports or rock concerts

Content spikes of the various types mentioned above can quickly drive high capacity usage of the CDN layer with little warning, demanding higher bitrates than conventional video assets whose consumption patterns can be predicted based on historical usage profiles.

In the specific case of live stream traffic spikes, by leveraging the OC layer, CDNs and content providers can deliver live streams on a massive scale without incurring a substantial footprint overhead.

5. ARCHITECTURAL GUIDELINES

The Open Caching Architecture looks to extending the existing content delivery infrastructure deep into service provider networks. The architecture leverages three main functional blocks interoperating with upstream CDNs as well as with each other using a diverse set of interfaces as depicted in the following diagram:

![A diagram of a service provider

Description automatically generated](k0m0rugw.017.png)

Figure 4 – Open Caching Architectural Hierarchy

• Open Cache Node (OCN) – a universal multi-tenant cache function deployed and owned by the service provider in close proximity to the users. A typical service provider realm may employ multiple (100s-1000s) OCNs. The primary goal of an OCN is to deliver content to users within the service provider realm while relaying logging and billing information to upstream CDNs that delegated traffic to it.
• CDN Open Cache Controllers (CDN OCC) – a control function used by delegating CDN enabling the CDN to gain access to open cache resources inside service provider networks. The CDN OCC communicates with multiple service provider open cache controllers aggregating global open caching data by communicating with OCRCs.
• Service Provider Open Cache Controller (SP OCC) – a control function used by a service provider with an open caching deployment interworking via API with CDN open cache controllers. The SP OCC represents the entire service provider open cache realm towards the CDN OCCs, tracking all OCNs’ location, status, capabilities and subscriber mapping while acting as an OCN registrar.**

The key guiding principles for this architecture are defined in the following sections.

5.1 Multi-Tenant Platform

The open caching layer by nature allows multiple CDNs to utilize its infrastructure as a common resource while maintaining isolation of content, metadata, authorization, etc. between CDNs and between content providers.

5.2 Loose Coupling

The open caching architecture creates interoperability between multiple CDNs and open caching layers, each of them operating autonomously of each other.

5.3 Minimal Overhead and Change

Integration of the open caching layer with existing CDNs should incur minimal change to their existing modes of operation. In addition in order to achieve optimal end to end performance integration will be limited to the minimum overhead in terms of communication, monitoring and management.

5.4 Open Interfaces

The open caching layer will maintain a common interface to allow for interoperability, while at the same time allowing for proprietary extensions and promoting innovation.

6. NOT IN SCOPE

The following use cases are not in the scope of the initial open caching architecture definition.

• Capability augmentation use cases
  • Device and network technology extension
  • Technology and vendor interoperability
  • Premium QoE and QoS improvement
• Non-bandwidth impacting objects delivery

7. REQUIREMENTS TERMINOLOGY

The key words "SHALL", "SHOULD", and "MAY" in this document are to be interpreted as follows:

"SHALL": When a requirement is tagged as "{SHALL}", it is considered by the working group as a mandatory function for open caching and mandatory for a deployable solution in an operator network. This requirement has to be met for an open cache system to be considered “compliant and deployable” in an operator network.

"SHOULD": When a requirement is tagged as "{SHOULD}", it is considered by the working group as an important but optional function for open caching. This requirement is recommended but not mandatory for an open cache system.

"MAY": When a requirement is tagged as "{MAY}", it is considered by the working group as a useful but optional function for open caching.

8. OPEN CACHE NODE FUNCTIONAL REQUIREMENTS

8.1 Supported Content Types

8.1.1 Streaming Video On Demand

1. OCN shall support caching of adaptive bit rate (ABR) video
2. OCN shall support caching of HTTP Live Streaming (HLS) video
3. OCN shall support caching of Microsoft Smooth Streaming (MSS) video
4. OCN shall support caching of HTTP Dynamic Streaming (HDS) video
5. OCN shall support caching of MPEG DASH video
6. OCN shall support caching of progressive download video

8.1.2 Live Streaming Video

1. OCN shall support caching of HTTP Live Streaming (HLS) live video

2. OCN should support caching of Microsoft Smooth Streaming (MSS) video

3. OCN should support caching of HTTP Dynamic Streaming (HDS) video

4. OCN should support caching of MPEG DASH live video

   8.1.3 Software Downloads

5. OCN shall support caching of HTTP software objects download

6. OCN shall support byte range requests

7. OCN shall support caching of manifest files

8.1.4 Live Streaming Audio

1. OCN may support caching of live streaming audio
2. OCN may support caching of MP3 streaming audio
3. OCN may support caching of AAC streaming audio
4. OCN may support caching of HLS streaming audio

8.1.5 Other Applications

1. OCN may support caching of HTTP 1.0 web objects
2. OCN may support caching of HTTP 1.1 web objects
3. OCN may support caching of HTTP 2.0 web objects

8.2 Software Requirements

8.2.1 Content Acquisition

1. OCN should support automatic acquisition of content off wire without requiring content provider or CDN assistance using transparent content ingest mechanisms.
2. OCN shall support acquisition of content where the acquisition process is triggered by a delegating content provider or CDN initiating a client rendezvous with the OCN
3. OCN should support pre-demand content acquisition from content provider or CDN. Pre-demand acquisition will utilize offline configured policies (object, acquisition location, acquisition start time, etc.)
4. OCN shall support acquisition of HTTP content for all relevant content types listed in
5. OCN shall support acquisition of HTTPS content for all relevant content types listed in
6. OCN may support ingestion of content over other transport mediums, e.g. FTP
7. OCN shall maintain isolation of acquired content between origin sources

8.2.2 Content Classification

1. OCN should support non-collaborative classification of content (i.e. cache key calculation), e.g. have the ability to uniquely identify a content object without requiring content provider or CDN assistance when using transparent content acquisition method such as listed in [OCN-REQ-21].
2. OCN shall support collaborative classification of content, e.g. classify content objects and calculate cache keys based on information received in signaling/interface from content provider or CDN

8.2.3 Content Validation

1. OCN shall be able to validate content freshness prior to delivery
2. OCN shall be able to validate client access to content (e.g. geo restrictions) prior to delivery
3. OCN should be able to support HTTP 304 for content validation

8.2.4 Resource Orchestration

1. OCN shall provide the ability to define a default content acquisition policy
2. OCN shall provide the ability to define a default content acquisition policy tuned for maximum bandwidth offload efficiency.
3. OCN shall provide the ability to define a default content aging policy
4. OCN shall provide the ability to define a content aging policy tuned for maximum bandwidth offload efficiency.
5. OCN should support a cache algorithm (content acquisition and aging) providing for defined SLA for specific content types/providers

8.2.5 Client Divert

1. OCN shall be able to instruct clients to fall back to upstream CDN (for example in cases of capacity reached, error conditions, etc.)
2. OCN shall be able to implement necessary loop prevention mechanisms for content that is directed to fall back to upstream CDN

8.2.6 Content Delivery

1. OCN shall support delivery over HTTP 1.0, 1.1, 2.0 for all relevant content types listed in Error! Reference source not found.
2. OCN should support HTTP Vary header
3. OCN shall support delivery over HTTPS for all relevant content types listed in Error! Reference source not found.
4. OCN HTTPS delivery shall support shared certificates
5. OCN HTTPS delivery shall support custom certificates
6. OCN HTTPS delivery should support Server Name Indication (SNI)
7. OCN may support delivery of content over other transport mediums, e.g. RTMP, UDP
8. OCN shall support delivery of content over IPv4
9. OCN shall support delivery of content over IPv6

8.2.7 Content Invalidation

1. OCN shall enable purging, the act of content removal of specific content objects
2. OCN shall provide asynchronous notification upon content purge completion
3. OCN shall enable purging of multiple content objects simultaneously
4. OCN should enable purge and not re-acquire option for specific content objects. Not re-acquire may be set for a period of up to thirty days.
5. OCN shall divert back to delegating CDN requests for content that is set to not re-acquire or issue an error response
6. OCN should enable the option to unset the option to not re-acquire content.
7. OCN shall enable revalidation of existing content objects

8.2.8 Capability Exchange

1. OCN shall be able to report its FQDN to authorized destinations
2. OCN shall be able to report its IP address to authorized destinations
3. OCN shall be able to report its status (e.g. present resource consumption levels) to authorized destinations
4. OCN shall be able to report its content delivery capabilities to authorized destinations (e.g. cap delivery bandwidth, traffic types, etc.)
5. OCN should be able to report its subscriber coverage area (e.g. geographic coverage zone). Potentially this may be ascertained by higher level logic
6. OCN may be able to report its vendor, model, version information

8.2.9 Logging and Reporting

1. OCN shall supply relevant access logs (e.g. 20x, 30x, 40x transactions) of delivery actions to one or more authorized destinations
2. OCN shall supply relevant billing logs of delivery actions to one or more authorized destinations containing additional information required for varying billing rates such as region and HTTP/HTTPS
3. OCN shall maintain isolation of logs between authorized destinations
4. OCN should supply delivery quality indication logs

8.2.10 Monitoring

1. OCN shall provide real-time monitoring of resource status
2. OCN shall maintain isolated monitoring between authorized destinations
3. OCN shall provide real-time monitoring of delivery actions, authorizations, errors

8.2.11 Open Cache System Expansion

1. Open Caching deployment within a network operator shall be able to scale by addition of individual OCN instances
2. OCN should be able to add compute and storage and network resources to its existing pool, thus increasing its individual node capacity independently
3. OCN may be able to collectively share resources with neighboring nodes for aggregated capabilities and central control

8.2.12 Resilience and Availability

1. OCN should support adjacent OCN(s) redundancy whereas multiple nodes provide redundancy to one another. The architectural assumption is that in case of node failure the solution is able to default back to its delegating upstream CDN and therefore adjacent redundancy is good to have but not mandatory as resilience is achieved by other means as well.
2. OCN should enable granular control of failure scenario handling

8.2.13 Open Cache Management

1. OCN shall be manageable by or on behalf of the network operator in which it is deployed
2. OCN shall provide interfaces for specific content actions to collaborating CDNs/content providers (e.g. content invalidation, content acquisition expediting, etc.)

8.3 Infrastructure Requirements

1. OCN shall be able to run on commercially available general purpose hardware
2. Shared Compute and Storage Resource – The infrastructure used for OCN should be made available for other operations and/or other applications. That is, HW is not dedicated to OCN, HW is a shared resource
3. The infrastructure should enable applications to be automatically deployed and maintained, including boundaries set for compliance, audit, regulatory and power across the datacenter.
4. The infrastructure should enable provisioning management and the allocation of resources based on operator requirements. That is, the infrastructure can be configured to control the allocation of resources to the OCN.
5. The infrastructure should be able to scale by adding more HW resources and to scale across physical server boundaries.
6. The infrastructure shall support virtualization.
7. The infrastructure should be able to be orchestrated

8.4 Security Requirements

8.4.1 Authentication and Password Management

1. OCN shall implement a password policy for administrators of the OCN including proper password strength controls, password lifecycle, password reset process, password storage, protecting credentials in transit, browser caching, number of login attempts
2. OCN should use an external centralized authentication system
3. OCN should enforce multi-factor authentication where possible.
4. In the case of the OCN application authenticating to external systems (like databases, file servers, web services), the credentials shall be encrypted at rest with proper access controls and never stored in source code.

8.4.2 Session Management

1. OCN shall use the server or framework’s session management controls in order to ensure that authenticated users have a robust and cryptographically secure association with their session.
2. OCN should perform session invalidation during authentication, re-authentication, logout, and switching from HTTPS to HTTP.

8.4.3 Authorization and Access Control

1. OCN should use an external centralized authorization system where role membership is centrally managed and audited, then map those roles to specific permissions within the OCN application.

2. OCN shall use role-based access control (RBAC).  

3. OCN shall implement least privilege policy between all subjects and objects.

4. OCN should enforce timely authorization checks on every request to prevent “time of check”/”time of use” (TOC/TOU) attacks

   8.4.4 Input Validation

5. OCN shall validate input data from untrusted sources

6. OCN shall validate input data based on data type and range.

7. OCN should use whitelist techniques to filter out bad input, to accept only allowed characters or values as valid input.

8.4.5 Output Escaping/Encoding

1. OCN shall perform secure output handling primarily escape/encode all output data unless they are known to be safe for the intended destination.
2. OCN should implement Content Security Policy to prevent cross-site scripting (XSS) and other code injection attacks if possible

8.4.6 Cryptographic Practices

1. OCN should use proper encryption when handling sensitive data at any tier of the application.
2. OCN shall ensure cryptographic modules used by the application are compliant with FIPS 140-2 standard both from vendor and algorithm perspectives.

8.4.7 Error Handling, Auditing, and Logging

1. The OCN application should handle its own application errors
2. OCN should not display sensitive, debug or stack trace information in the production environment.
3. OCN shall ensure audit logging controls are in place to log both successful/failure security events, especially authentication/authorization attempts and access to sensitive data

8.4.8 Data Protection

1. OCN shall limit access to data based on the least privilege principal.
2. OCN shall encrypt sensitive data and information like stored passwords
3. OCN shall properly protect decryption keys.
4. OCN shall make sure all cached or temporary copies of sensitive data are protected from unauthorized access and get purged as soon as they are no longer required.
5. The end-to-end solution shall not allow sensitive production data in non-production environments.

8.4.9 Communication Security

1. OCN shall protect the data it transmits from corruption (e.g. unauthorized addition, modification, deletion or replay)
2. OCN shall use encryption-in-transit when transmitting sensitive information, at any tier of the application or network architecture
3. OCN should use a trusted certificate authority to generate public and private keys whenever possible.

8.4.10 Database Security

1. OCN application should use the lowest possible level of privilege when accessing the database.
2. OCN should Lock down the database by turning off any unnecessary features

8.4.11 File Management

1. OCN should enforce authentication before file uploads.
2. OCN should limit file types and prevent any file types that may be interpreted by the web server as well as validate the file types by checking the file header.
3. OCN should not save the uploaded file in the same web context as the application.
4. OCN should not pass directory or file paths to the user, use index values mapped to pre-defined paths

9. OPEN CACHE CONTROLLERS FUNCTIONAL REQUIREMENTS

9.1 CDN Control Functions

9.1.1 Management

9.1.1.1 System Management

1. The CDN open cache controller shall provide a process for establishment of service provider to CDN binding in order to enable usage of open cache resources within that service provider. Service binding shall be established in non-real time.
2. The CDN open cache controller shall provide a binding relationship between service provider and CDN representing a collection of content provider properties and enable relations based on (all/some/none) of the CDN properties
3. The CDN open cache controller shall provide a mechanism for establishing content caching policies per CDN.
4. The CDN open cache controller shall provide a mechanism for establishing content caching policies per content provider property represented by a CDN.
5. The CDN open cache controller shall provide a mechanism for establishing service level agreements (SLA) for content delivery between CDN and SP realm.
6. The CDN open cache controller should provide a mechanism for reservation of service provider cache resources by a CDN (e.g. reserve 1 Tbps egress capacity on a certain date for a given time duration for a live event).

9.1.1.2 Content Management

1. The CDN open cache controller shall enable signaling of cache key calculation method for a delegated content provider property and/or object type including but not limited to query string parameter handling
2. The CDN open cache controller shall enable provisioning of OCN content fill mechanism (pull method, url/host rewrite, header insertion, etc.) from delegating CDN
3. The CDN open cache controller shall enable content handling actions to delegated OCN such as cache/no-cache, min/max bandwidth, etc.
4. The CDN open cache controller shall enable invalidation of content per service provider domain, e.g. purging of content at per CDN/domain/sub-domain/object levels
5. The CDN open cache controller may enable signaling of expedited caching for individual content objects
6. The CDN open cache controller shall enable HTTPS delivery by open cached nodes
7. HTTPS delivery shall support shared certificates
8. HTTPS delivery shall support custom certificates
9. HTTPS delivery should support Server Name Indication (SNI)
10. The CDN open cache controller should enable provisioning of content that is de-duplicable by downstream OCNs

9.1.2 Open Cache Selection

1. The CDN open cache controller shall provide a mechanism for identification of proper service provider open cache realm based on address of requesting user. This allows for CDN to SP rendezvous at the service provider level
2. The CDN open cache controller should provide a mechanism for identification of individual OCN resource (including current capabilities and status) for delivering content on behalf of the CDN based on address of requesting user. This allows for CDN to SP rendezvous at the OCN level

9.1.3 Monitoring

1. The CDN open cache controller shall enable near real-time monitoring of aggregate SP realm open cache counters the amount of traffic served per SP, hit rate percentage as well as the total errors (404, 503, 504, 5xx).
2. The CDN open cache controller should enable monitoring of content provider counters per service provider. Monitored information includes but not limited to: the amount of traffic served per content provider property, hit rate percentage as well as the total errors (404, 503, 504, 5xx).
3. The CDN open cache controller should enable daily, weekly, monthly monitoring of aggregate SP realm open cache performance allocated to the CDN
4. The CDN open cache controller should enable integration with 3rd party monitoring tools
5. The CDN open cache controller may provide a mechanism to track distribution of content within a service provider domain, e.g. tracking content object presence on OCN resources
6. The CDN open cache controller shall provide monitoring of SLA policy levels

9.1.4 Logging

1. The CDN open cache controller shall provide log collection from one or more service provider OCN realms
2. The CDN open cache controller shall aggregate logs from a SP realm at regular intervals
3. The CDN Open Cache Controller shall maintain a window of data retention of access and billing logs for a period of minimum 30 days.
4. Log data shall be partitioned per content provider property

9.1.5. Request Routing

1. The CDN open cache controller should provide a mechanism to perform routing of requests, originally destined to the CDN, to delegated OCNs or service provider open cache controllers
2. Request routing should strive to be least invasive and easiest to adapt while adding minimal latency to the routing process

9.2 Service Provider Control Functions

9.2.1 Management

1. The Service Provider Open Cache Controller shall provide a process for establishment of service provider to CDN binding in order to enable usage of open cache resources within that service provider. Service binding shall be established in non-real time.
2. The Service Provider Open Cache Controller shall provide a mechanism for establishing content caching policies per CDN.
3. The Service Provider Open Cache Controller shall provide a mechanism for establishing service level agreements (SLA) for content delivery between a delegating CDN and SP realm.
4. The Service Provider Open Cache Controller should provide configuration of OCN coverage area policies, e.g. mapping of subscriber zone to OCN resources.
5. The Service Provider Open Cache Controller shall provide a mechanism for determining optimal OCN instances to user requests
6. The Service Provider Open Cache Controller shall enable provisioning of data elements necessary for HTTPS delivery by OCNs

9.2.2 OCN Registrar

1. The Service Provider Open Cache Controller shall enable registration of individual OCN instances including location, capabilities
2. The Service Provider Open Cache Controller shall provide un-registration of OCN instances

9.2.3 Monitoring and Logging

9.2.3.1 Upstream (to CDN Controller)

1. The Service Provider Open Cache Controller shall enable monitoring of each content provider per CDN.
2. The monitoring data shall be provided to delegating CDN controllers in near real-time.
3. Monitored information shall include but not be limited to: the amount of traffic served per content provider property, hit rate percentage as well as the total errors (404, 503, 504, 5xx).
4. The Service Provider Open Cache Controller should provide near real time monitoring of OCN resources within service provider realms (e.g. network segments)
5. The Service Provider Open Cache Controller should provide historic (e.g. daily, weekly, monthly) monitoring of aggregate open cache performance allocated to delegating CDN
6. The Service Provider Open Cache Controller shall provide monitoring of SLA policy levels
7. The Service Provider Open Cache Controller shall make log data available to delegating CDN controller functions
8. The Service Provider Open Cache Controller shall provide logs containing all access records for all delegated domains
9. The Service Provider Open Cache Controller shall aggregate logs at regular intervals (minimum of once every 24 hours).
10. The Service Provider Open Cache Controller should provide logs containing a set of billing records for all delegated domains
11. The Service Provider Open Cache Controller shall maintain a window of data retention of access and billing logs for a period of minimum 30 days.
12. Log data shall be partitioned per CDN and content provider property

9.2.3.2 Downstream (to Open Cache Nodes)

1. The Service Provider Open Cache Controller shall monitor individual open cache nodes within a SP realm
2. The Service Provider Open Cache Controller shall collect logs from OCN instances within a SP realm

9.2.4 Content Control

1. The Service Provider Open Cache Controller shall enable signaling of cache key calculation method to registered OCNs. Information shared may be specific for a delegated content provider property and/or object type including but not limited to query string parameter handling
2. The Service Provider Open Cache Controller shall enable provisioning of OCN content fill mechanism (location, pull method, url/host rewrite, header insertion, etc.) from delegating CDN
3. The Service Provider Open Cache Controller shall enable provisioning of a white list of delegated domains per CDN to registered OCNs.
4. The Service Provider Open Cache Controller shall enable content handling actions to registered OCN such as cache/no-cache, min/max bandwidth, etc.
5. The Service Provider Open Cache Controller shall enable invalidation of content per service provider domain, e.g. purging of content at per CDN/domain/sub-domain/object levels across registered OCNs
6. The Service Provider Open Cache Controller may enable signaling of expedited caching for individual content objects across registered OCNs

9.2.5 Request Routing

1. The Service Provider open cache controller shall provide a mechanism to perform routing of requests to delegated OCNs

9.3 Security

9.3.1 Authentication and Password Management

1. CDN and SP Open Cache Controllers shall implement a password policy for administrators of the applications including proper password strength controls, password lifecycle, password reset process, password storage, protecting credentials in transit, browser caching, number of login attempts
2. CDN and SP Open Cache Controllers should use an external centralized authentication system
3. CDN and SP Open Cache Controllers should enforce multi-factor authentication where possible.
4. In the case of the CDN and SP Open Cache Controllers authenticating to external systems (like databases, file servers, web services), the credentials shall be encrypted at rest with proper access controls and never stored in source code.

9.3.2 Session Management

1. CDN and SP Open Cache Controllers shall use the server or framework’s session management controls in order to ensure that authenticated administrators have a robust and cryptographically secure association with their session.
2. CDN and SP Open Cache Controllers should perform administrator session invalidation during authentication, re-authentication, logout, and switching from HTTPS to HTTP.

9.3.3 Authorization and Access Control

1. CDN and SP Open Cache Controllers should use an external centralized authorization system where role membership is centrally managed and audited, then map those roles to specific permissions within the OCN application.
2. CDN and SP Open Cache Controllers shall use role-based access control (RBAC).  
3. CDN and SP Open Cache Controllers shall implement least privilege policy between all subjects and objects.
4. CDN and SP Open Cache Controllers should enforce timely authorization checks on every request to prevent “time of check”/”time of use” (TOC/TOU) attacks

9.3.4 Input Validation

1. CDN and SP Open Cache Controllers shall validate input data for configuration, policy and user requests from untrusted sources
2. CDN and SP Open Cache Controllers shall validate input data based on data type and range.
3. CDN and SP Open Cache Controllers should use whitelist techniques with regards to configuration and policy in order to filter out bad input, to accept only allowed characters or values as valid input.

9.3.5 Output Escaping/Encoding

1. CDN and SP Open Cache Controllers shall perform secure output handling primarily escape/encode all output data unless they are known to be safe for the intended destination.
2. CDN and SP Open Cache Controllers should implement Content Security Policy (CSP) if possible.

9.3.6 Cryptographic Practices

1. CDN and SP Open Cache Controllers should use proper encryption when handling sensitive data at any tier of the application.
2. CDN and SP Open Cache Controllers shall ensure cryptographic modules used by the application are compliant with FIPS 140-2 level 3 standards both from vendor and algorithm perspectives.

9.3.7 Error Handling, Auditing, and Logging

1. CDN and SP Open Cache Controllers should handle their own application errors in order to assure the application fails safely under all possible error conditions, expected and unexpected. No sensitive information is presented to the user when an error occurs.
2. CDN and SP Open Cache Controllers should not display sensitive, debug or stack trace information in the production environment.
3. CDN and SP Open Cache Controllers shall ensure audit logging controls are in place to log both successful/failure security events, especially authentication/authorization attempts and access to sensitive data

9.3.8 Data Protection

1. CDN and SP Open Cache Controllers shall limit access to data based on the least privilege principal.
2. CDN and SP Open Cache Controllers shall encrypt sensitive data and information like stored passwords
3. CDN and SP Open Cache Controllers shall properly protect decryption keys.
4. CDN and SP Open Cache Controllers shall make sure all cached or temporary copies of sensitive data are protected from unauthorized access and get purged as soon as they are no longer required.

9.3.9 Communication Security

1. CDN and SP Open Cache Controllers shall protect the data they transmit from corruption (e.g. unauthorized addition, modification, deletion or replay)
2. CDN and SP Open Cache Controllers shall use encryption-in-transit when transmitting sensitive information, at any tier of the application or network architecture
3. CDN and SP Open Cache Controllers should use a trusted certificate authority to generate public and private keys whenever possible.

9.3.10 Database Security

1. CDN and SP Open Cache Controllers should use the lowest possible level of privilege when accessing the configuration and OCN status databases.
2. CDN and SP Open Cache Controllers should Lock down the configuration and OCN databases by turning off any unnecessary features

9.3.11 File Management

1. CDN and SP Open Cache Controllers should enforce authentication before configuration file uploads.
2. CDN and SP Open Cache Controllers should limit file types and prevent any file types that may be interpreted by the web server as well as validate the file types by checking the file header.
3. CDN and SP Open Cache Controllers should not save the uploaded file in the same web context as the application.
4. CDN and SP Open Cache Controllers should not pass directory or file paths to the user, use index values mapped to pre-defined paths

10. SPECIFICATIONS AND STANDARDS REFERENCES

Table 3: Specification and standards references

11. TABLES AND FIGURES

11.1 Tables

Table 1: Document versioning 5

Table 2: Cache infrastructure requirements 14

Table 3: Specification and standards references 50

11.2 Figures

Figure 1 – Average Time Spent per Day on Digital Activities 11

Figure 2 – Time spent per day with video by US adults 12

Figure 3 – Open Caching Node Resources Shared Among Multiple CDNs 14

Figure 4 – Open Caching Architectural Hierarchy 18

12. ABOUT THE STREAMING VIDEO TECHNOLOGY ALLIANCE

Comprised of members from across the video ecosystem, the Streaming Video Technology Alliance is a global association that works to solve critical streaming video challenges in an effort to improve end-user experience and adoption. The organization focuses on three main activities: first is to educate the industry on challenges, technologies, and trends through informative, publicly available resources such as whitepapers, articles, and e-books; second is to foster collaboration among different video ecosystem players through working groups, quarterly meetings, and conferences; third is to define solutions for streaming video challenges by producing specifications, best practices, and other technical documentation. For more information, please visit https://www.svta.org.