WG Review: Content Delivery Networks Interconnection (cdni)

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 



A new IETF working group has been proposed in the Transport Area.  The 
IESG has not made any determination as yet. The following draft charter 
was submitted, and is provided for informational purposes only. Please 
send your comments to the IESG mailing list (iesg@ietf.org) by Tuesday, 
June 21, 2011.                       

Content Delivery Networks Interconnection (cdni)
------------------------------------------------
Current Status: Proposed Working Group
Last updated: 2011-05-27

Chairs:
  TBD

Transport Area Directors:
  Wesley Eddy <wes@mti-systems.com>
  David Harrington <ietfdbh@comcast.net>

Transport Area Advisor:
  David Harrington <ietfdbh@comcast.net>

Mailing lists:
  Address: cdni@ietf.org
  To Subscribe: https://www.ietf.org/mailman/listinfo/cdni
  Archive: http://www.ietf.org/mail-archive/web/cdni/

Description of Working Group:

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 
infrastructure.

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 (18-24 months) 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 
recharter.

The working group will focus on the following items:

- A "problem statement" document providing a description of the problem 
  and a common terminology.

- A "use case" document describing scenarios for usage and applications 
  of the CDNI solution and protocols.

- 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 "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 specification of the "CDNI request-routing interface". This 
  interface will allow an upstream CDN request routing system to obtain 
  from the downstream CDN the information necessary to perform request 
  redirection.

- 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.

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 
  Agent.

- New protocols for ingestion of content or metadata between a CSP and a 
  CDN.

- 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 such as UltraViolet.

Goals and Milestones

WG Creation + 6 months:   Submit CDNI problem statement to IESG as 
                          Informational
WG Creation + 9 months:   Submit CDNI use cases to IESG as Informational
WG Creation + 12 months:  Submit CDNI framework to IESG as Informational
WG Creation + 12 months:  Submit CDNI requirements to IESG as 
                          Informational
WG Creation + 18 months:  Submit specification of the CDNI Request 
                          Routing interface to IESG as Proposed Standard
WG Creation + 18 months:  Submit specification of the CDNI Logging 
                          interface to IESG as Proposed Standard
WG Creation + 18 months:  Submit specification of the CDNI Control 
                          interface to IESG as proposed Standard
WG Creation + 24 months:  Submit specification of the CDNI Metadata 
                          Distribution interface to IESG as Proposed 
                          Standard
WG Creation + 24 months:  Recharter or dissolve

_______________________________________________
IETF-Announce mailing list
IETF-Announce@ietf.org
https://www.ietf.org/mailman/listinfo/ietf-announce


[Index of Archives]     [IETF]     [IETF Discussion]     [Linux Kernel]

  Powered by Linux