WG Review: Content Delivery Networks Interconnection (cdni)

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

 



The Content Delivery Networks Interconnection (cdni) working group in the
Transport Area of the IETF is undergoing rechartering. The IESG has not
made any determination yet. The following draft charter was submitted,
and is provided for informational purposes only. Please send your
comments to the IESG mailing list (iesg at ietf.org) by 2013-12-02.

Content Delivery Networks Interconnection (cdni)
------------------------------------------------
Current Status: Active WG

Chairs:
  Daryl Malas <d.malas@cablelabs.com>
  Francois Le Faucheur <flefauch@cisco.com>

Assigned Area Director:
  Spencer Dawkins <spencerdawkins.ietf@gmail.com>

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

Charter:

  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 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 "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 
    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, if and where 
  appropriate.

Milestones:
  Done     - Submit CDNI problem statement to IESG as Informational
  Done     - Submit CDNI use cases to IESG as Informational
  Sep 2013 - Submit CDNI requirements to IESG as Informational
  Dec 2013 - Submit CDNI framework to IESG as Informational
  Dec 2013 - Submit specification of the CDNI Logging interface to IESG
as Proposed Standard
  Dec 2013 - Submit specification of the CDNI Metadata interface to IESG
as Proposed Standard
  Apr 2014 - Submit specification of the CDNI Control interface to IESG
as proposed Standard
  Apr 2014 - Submit specification of the CDNI Request Routing Redirection
interface to IESG as Proposed Standard
  Sep 2014 - Submit specification of the CDNI Footprint & Capabilities
Advertisement interface to IESG as Proposed Standard
  Sep 2014 - Submit specification of URI Signing for CDNI to IESG as
Proposed Standard
  Oct 2014 - Recharter or dissolve






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

  Powered by Linux