Capacity Footprint API

Project Status:

(roll over for info)


The working group is currently writing the document. This is a collaborative approach using Google Docs.


January 1, 2020

Estimated Completion:

September 1, 2020

Problem Statement

The Capacity API is intended to allow participants in the federated video delivery service to communicate availability and capacity information as needed.  The design is meant to encompass multiple use cases, including one content provider to many CDNs/ISPs as well as more complex multiparty interactions, all while preserving the flexibility and business models of the underlying providers.

Project Description

Video delivery is a complex ecosystem of content and network providers.  The content providers rely on one or more network providers (ISPs and global or regional CDNs) to connect them to their users, and at high quality levels.  One of the constraints to providing a high quality experience is network capacity constraints due to high demand or temporary infrastructure failures.  Historically, it has been challenging to provide the necessary data at the right level of detail: Too little, the content provider can’t make traffic routing decisions.  Too much, the CDN or ISP doesn’t have the flexibility needed to manage their network effectively.  Often times, sharing this information has been ad hoc, making it challenging to reuse with multiple partners.

Project Type

Project Leads

Project leads have not yet been identified.


There are no SMEs associated with this project.

Draft Documents

(DRAFT) Open Caching Capacity Interface

This document defines the specification for an API to retrieve capacity metrics from an Open Caching Node.

Estimated Publication Date: Q3, 2020

Goals and Objectives

This project has the following goals and objectives:
  • To extend the functionality of the existing Capacity Footprint API with a number of additional features

Project Scope

The API specification produced by this project will PROVIDE:
  • A list of additional API features to meet the specific needs detailed in the problem statement
  • Description of API methods by which to provide the functionality of the newly included features
The API specification will NOT PROVIDE:
  • Any specific programming languages that should be used to carry out the API functionality
  • Any support for features not specifically listed and addressed by methods within the API


The following members have contributed to this project. Click on their name to visit their profile. If they have not published their profile, the link will redirect to their LinkedIn profile.

Additional References

There are no additional references or other required readings need to participate in this project.


The following presentations delivered during Open Caching working group sessions may provide additional information about this project.