Skip to main content

Content Delivery Networks Interconnection

The information below is for an older proposed charter
Document Proposed charter Content Delivery Networks Interconnection WG (cdni) Snapshot
Title Content Delivery Networks Interconnection
Last updated 2013-12-06
State IESG Review (Charter for Approval, Selected by Secretariat) Rechartering
WG State Active
IESG Responsible AD Francesca Palombini
Charter edit AD Spencer Dawkins
Send notices to (None)

A Content Delivery Network (CDN) is an infrastructure of network 
elements operating at layer 4 through layer 7, arranged for the 
efficient distribution and delivery of digital content. Such content 
includes, but is not limited to, web pages and images delivered via 
HTTP, and streaming of continuous media delivered via HTTP, RTSP, RTMP, 
etc. CDNs typically provide services to multiple Content Service 
Providers (CSPs).
CDNs provide numerous benefits: a shared platform for multi-service 
content delivery, reduced transmission costs for cacheable content, 
improved quality of experience for end users and increased robustness of 
delivery. For these reasons they are frequently used for large-scale 
content delivery.
As a result of the significant growth in content delivered over IP 
networks, existing CDN providers are scaling up their infrastructure and 
many Network Service Providers and Enterprise Service Providers are 
deploying their own CDNs. Subject to the policy of the CSP, it is 
generally desirable that a given item of content can be delivered to an 
end user regardless of that end user's location or attachment network. 
This creates a need for interconnecting (previously) standalone CDNs so 
they can interoperate and collectively behave as a single delivery 
The goal of the CDNI Working Group is to allow the interconnection of 
separately administered CDNs in support of the end-to-end delivery of 
content from CSPs through multiple CDNs and ultimately to end users (via 
their respective User Agents). The CDNI WG aims at delivering a 
targeted, deployable solution in a short timeframe as 
needed by the industry. It is expected that the CDNI interfaces will be 
realized using existing IETF protocols for transport and message 
exchange, and using existing object notation grammars/languages for the 
definition of CDNI objects and semantics. In the event that protocol 
extensions or new protocols are deemed necessary by the WG, the WG will 
The working group will focus on the following items:

- A "requirements" document. This document lists the requirements for 
  the CDNI architecture and the CDNI interfaces. In particular, this 
  document will focus on identifying a reasonable set of more urgent and 
  important requirements that will be addressed in the initial set of 
  CDNI protocols and solutions produced by the working group. This 
  document will list the requirements stemming from the threat analysis 
  and to be met by each of the CDNI interfaces.
- A "framework" document providing a description of the different 
  components of the CDNI architecture and how they interact with one 
  another. This document will also include a "threat analysis" 
  discussing the security concerns and threats, the trust model and 
  privacy issues specific to CDNI.

- A specification of the "CDNI Request Routing Redirection interface". 
  This interface will allow an upstream CDN Request Routing system to 
  obtain from the downstream CDN the information necessary to perform 
  request redirection. It is actually a logical bundling of two separate 
  but related interfaces: 
   *  Footprint & Capability Advertisement interface: Asynchronous 
      operations to exchange routing information (e.g., the network 
      footprint and capabilities served by a given CDN) that enables CDN 
      selection for subsequent user requests; and       
   *  Request Routing Redirection interface: Synchronous operations to
      select a delivery CDN (surrogate) for a given user request.
- A specification of the "CDNI Metadata interface". This interface will 
  allow the CDNs to exchange content distribution metadata of inter-CDN 
  scope. Content distribution metadata refers to the subset of content 
  metadata that is relevant to the distribution of the content and 
  therefore is to be processed by CDNs (for example, this may include 
  information enabling: content acquisition, geo-blocking, enforcement 
  of availability windows or access control).
- A specification of the "CDNI Logging interface". This interface will 
  allow CDN logging systems to exchange logging information associated 
  with actions that are relevant across CDNs (such as content 
  distribution, content delivery and content routing actions) for 
  purposes of accounting, analytics, monitoring, etc.

- A specification of the "CDNI Control interface". In particular, this 
  interface will allow an upstream CDN to remove or invalidate content 
  in a downstream CDN.

- A specification for "CDNI URI Signing". This document will specify a 
  mechanism that allows interconnected CDNs to support access control 
  by signing content URIs. This may involve extensions to the CDNI 
  interfaces (e.g. CDNI Metadata interface, CDNI Logging interface).

The WG will discuss and address the security, management and operational  
issues specific to CDNI, inside the above documents and specifications.
The working group will only define solutions for aspects of the CDN  
Interconnection problem space that require direct communication or  
interoperation between CDNs.

In particular, the WG will not define:

- New session, transport or network protocols.

- New protocols for delivering content from a CDN to an End User/User 

- New protocols for ingestion of content or metadata between a CSP and a 
- New protocols for acquiring content across CDNs.

- Protocols and algorithms for intra-CDN operations.

- Support for Transparent Caching across CDNs.

- New applications consuming CDNI logs.

- Digital Right Management (DRM) mechanisms.

The CDNI WG will work with other IETF WGs to assess, and where 
appropriate, leverage protocols developed by those WGs, in order to 
realize the CDNI requirements and CDNI interfaces. For example, the WG 
may assess the suitability of the ALTO protocol as a protocol to enable 
downstream CDNs to exchange information which may aid an upstream CDN 
with making CDNI request routing decisions. The CDNI WG will also 
coordinate with relevant groups outside the IETF, if and where