[Docs] [txt|pdf] [Tracker] [Email] [Diff1] [Diff2] [Nits]

Versions: 00 01 02 draft-ietf-cdni-problem-statement

Network Working Group                                   B. Niven-Jenkins
Internet-Draft                                  Velocix (Alcatel-Lucent)
Intended status: Informational                            F. Le Faucheur
Expires: September 14, 2011                                        Cisco
                                                                N. Bitar
                                                                 Verizon
                                                          March 13, 2011


 Content Distribution Network Interconnection (CDNI) Problem Statement
                draft-jenkins-cdni-problem-statement-02

Abstract

   Content Delivery Networks (CDNs) provide numerous benefits: reduced
   delivery cost 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, existing CDN providers are scaling up their
   infrastructure and many Network Service Providers (NSPs) are
   deploying their own CDNs.  It is generally desirable that a given
   content item can be delivered to an end user regardless of that end
   user's location or attachment network.  This creates a requirement
   for interconnecting standalone CDNs so they can interoperate as an
   open content delivery infrastructure for the end-to-end delivery of
   content from Content Service Providers (CSPs) to end users.  However,
   no standards or open specifications currently exist to facilitate
   such CDN interconnection.

   The goal of this document is to outline the problem area for the IETF
   with a view towards creating a working group.  This working group
   would work on interoperable and scalable solutions for CDN
   interconnection.

Requirements Language

   The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT",
   "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this
   document are to be interpreted as described in RFC 2119 [RFC2119].

Status of this Memo

   This Internet-Draft is submitted in full conformance with the
   provisions of BCP 78 and BCP 79.

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-



Niven-Jenkins, et al.  Expires September 14, 2011               [Page 1]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   Drafts is at http://datatracker.ietf.org/drafts/current/.

   Internet-Drafts are draft documents valid for a maximum of six months
   and may be updated, replaced, or obsoleted by other documents at any
   time.  It is inappropriate to use Internet-Drafts as reference
   material or to cite them other than as "work in progress."

   This Internet-Draft will expire on September 14, 2011.

Copyright Notice

   Copyright (c) 2011 IETF Trust and the persons identified as the
   document authors.  All rights reserved.

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents
   (http://trustee.ietf.org/license-info) in effect on the date of
   publication of this document.  Please review these documents
   carefully, as they describe your rights and restrictions with respect
   to this document.  Code Components extracted from this document must
   include Simplified BSD License text as described in Section 4.e of
   the Trust Legal Provisions and are provided without warranty as
   described in the Simplified BSD License.




























Niven-Jenkins, et al.  Expires September 14, 2011               [Page 2]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  5
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  5
     1.2.  CDN Background . . . . . . . . . . . . . . . . . . . . . .  9
   2.  CDN Interconnect Use Cases . . . . . . . . . . . . . . . . . .  9
   3.  CDN Interconnect Model & Problem Area for IETF . . . . . . . . 11
     3.1.  Candidate CDNI Problem Area for IETF . . . . . . . . . . . 13
     3.2.  Non-Goals for IETF . . . . . . . . . . . . . . . . . . . . 15
   4.  Design Approach for Realizing the CDNI APIs  . . . . . . . . . 16
     4.1.  Relationship to the OSI network model  . . . . . . . . . . 17
     4.2.  "Reuse Instead of Reinvent" Principle  . . . . . . . . . . 17
     4.3.  CDNI Request Routing API . . . . . . . . . . . . . . . . . 17
     4.4.  CDNI Metadata API  . . . . . . . . . . . . . . . . . . . . 19
     4.5.  CDNI Logging API . . . . . . . . . . . . . . . . . . . . . 20
     4.6.  CDNI Control API . . . . . . . . . . . . . . . . . . . . . 21
   5.  Prioritizing the CDNI Work . . . . . . . . . . . . . . . . . . 21
   6.  Gap Analysis of relevant Standardization and Research
       Activities . . . . . . . . . . . . . . . . . . . . . . . . . . 22
     6.1.  Related standardization activities . . . . . . . . . . . . 22
       6.1.1.  IETF CDI Working Group (Concluded) . . . . . . . . . . 22
       6.1.2.  3GPP . . . . . . . . . . . . . . . . . . . . . . . . . 23
       6.1.3.  ISO MPEG . . . . . . . . . . . . . . . . . . . . . . . 24
       6.1.4.  ATIS IIF . . . . . . . . . . . . . . . . . . . . . . . 24
       6.1.5.  CableLabs  . . . . . . . . . . . . . . . . . . . . . . 25
       6.1.6.  ETSI MCD . . . . . . . . . . . . . . . . . . . . . . . 25
       6.1.7.  ETSI TISPAN  . . . . . . . . . . . . . . . . . . . . . 25
       6.1.8.  ITU-T  . . . . . . . . . . . . . . . . . . . . . . . . 25
       6.1.9.  Open IPTV Forum (OIPF) . . . . . . . . . . . . . . . . 26
       6.1.10. TV-Anytime Forum . . . . . . . . . . . . . . . . . . . 26
       6.1.11. SNIA . . . . . . . . . . . . . . . . . . . . . . . . . 26
     6.2.  Related Research Projects  . . . . . . . . . . . . . . . . 27
       6.2.1.  IRTF P2P Research Group  . . . . . . . . . . . . . . . 27
       6.2.2.  OCEAN  . . . . . . . . . . . . . . . . . . . . . . . . 27
       6.2.3.  Eurescom P1955 . . . . . . . . . . . . . . . . . . . . 27
     6.3.  Gap Analysis . . . . . . . . . . . . . . . . . . . . . . . 28
       6.3.1.  Content Acquisition across CDNs and Delivery to
               End User (Data plane)  . . . . . . . . . . . . . . . . 28
       6.3.2.  CDNI Metadata  . . . . . . . . . . . . . . . . . . . . 29
   7.  Relationship to relevant IETF Working Groups . . . . . . . . . 30
     7.1.  ALTO . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
     7.2.  DECADE . . . . . . . . . . . . . . . . . . . . . . . . . . 31
     7.3.  PPSP . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
   8.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 32
   9.  Security Considerations  . . . . . . . . . . . . . . . . . . . 33
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 33
   11. References . . . . . . . . . . . . . . . . . . . . . . . . . . 33
     11.1. Normative References . . . . . . . . . . . . . . . . . . . 33



Niven-Jenkins, et al.  Expires September 14, 2011               [Page 3]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


     11.2. Informative References . . . . . . . . . . . . . . . . . . 34
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 36

















































Niven-Jenkins, et al.  Expires September 14, 2011               [Page 4]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


1.  Introduction

   The volume of video and multimedia content delivered over the
   Internet is rapidly increasing and expected to continue doing so in
   the future.  In the face of this growth, Content Delivery Networks
   (CDNs) provide numerous benefits: reduced delivery cost for cacheable
   content, improved quality of experience for end users and increased
   robustness of delivery.  For these reasons CDNs are frequently used
   for large-scale content delivery.  As a result, existing CDN
   providers are scaling up their infrastructure and many Network
   Service Providers (NSPs) are deploying their own CDNs.  It is
   generally desirable that a given content item can be delivered to an
   End User regardless of that End User's location or attachment
   network.  However, the footprint of a given CDN in charge of
   delivering a given content may not expand close enough to the End
   User's current location or attachment network to realize the cost
   benefit and user experience that a more distributed CDN would
   provide.  This creates a requirement for interconnecting standalone
   CDNs so that their collective CDN footprint can be leveraged for the
   end-to-end delivery of content from Content Service Providers (CSPs)
   to End Users.  However, no standards or open specifications currently
   exist to facilitate such CDN interconnection.

   The goal of this document is to outline the problem area for the IETF
   with a view towards creating a working group.  This working group
   would work on interoperable and scalable solutions for CDN
   interconnection.

   Section 2 discusses the use cases for CDN interconnection.  Section 3
   presents the CDNI model and problem area to be considered by the
   IETF.  Section 4 discusses how existing protocols can be reused to
   define the CDNI protocols while Section 5 proposes to focus the scope
   for the initial charter of a CDNI Working Group to the minimum
   functional elements necessary for basic CDN interconnection.
   Section 5 provides a gap analysis of the work of other standards
   organization and finally Section 5 discusses the relationship with
   relevant IETF Working Groups.

1.1.  Terminology

   This document uses the following terms:

   Content: Any form of digital data.  One important form of Content
   with additional constraints on Distribution and Delivery is
   continuous media (i.e. where there is a timing relationship between
   source and sink).

   Metadata: Metadata in general is data about data.



Niven-Jenkins, et al.  Expires September 14, 2011               [Page 5]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   Content Metadata: This is metadata about Content.  Content Metadata
   comprises:

   1.  Metadata that is relevant to the distribution of the content (and
       therefore relevant to a CDN involved in the delivery of that
       content).  We refer to this type of metadata as "Content
       Distribution Metadata".  See also the definition of Content
       Distribution Metadata.
   2.  Metadata that is associated with the actual Content (and not
       directly relevant to the distribution of that Content) or content
       representation.  For example, such metadata may include
       information pertaining to the Content's genre, cast, rating, etc
       as well as information pertaining to the Content representation's
       resolution, aspect ratio, etc.

   Content Distribution Metadata: The subset of Content Metadata that is
   relevant to the distribution of the content.  This is the metadata
   required by a CDN in order to enable and control content distribution
   and delivery by the CDN.  In a CDN Interconnection environment, some
   of the Content Distribution Metadata may have an intra-CDN scope (and
   therefore need not be communicated between CDNs), while some of the
   Content Distribution Metadata have an inter-CDN scope (and therefore
   needs to be communicated between CDNs).

   CDNI Metadata: Content Distribution Metadata with inter-CDN scope.
   For example, CDNI Metadata may include geo-blocking information (i.e.
   information defining geographical areas where the content is to be
   made available or blocked), availability windows (i.e. information
   defining time windows during which the content is to be made
   available or blocked) and access control mechanisms to be enforced
   (e.g.  URI signature validation).  CDNI Metadata may also include
   information about desired distribution policy (e.g. prepositioned vs
   dynamic acquisition) and about where/how a CDN can acquire the
   content.  CDNI Metadata may also include content management
   information (e.g. request for deletion of Content from Surrogates)
   across interconnected CDNs.

   Dynamic content acquisition: Dynamic content acquisition is where a
   CDN acquires content from the content source in response to an End
   User requesting that content from the CDN.  In the context of CDN
   Interconnect, dynamic acquisition means that a downstream CDN does
   not acquire the content from content sources (including upstream
   CDNs) until a request for that content has been delegated to the
   downstream CDN by an Upstream CDN.

   Dynamic CDNI metadata acquisition: In the context of CDN
   Interconnect, dynamic CDNI metadata acquisition means that a
   downstream CDN does not acquire CDNI metadata for content from the



Niven-Jenkins, et al.  Expires September 14, 2011               [Page 6]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   upstream CDN until a request for that content has been delegated to
   the downstream CDN by an Upstream CDN.

   Pre-Positioned content acquisition: Content Pre-positioning is where
   a CDN acquires content from the content source prior to or
   independent of any End User requesting that content from the CDN.  In
   the context of CDN interconnect the Upstream CDN instructs the
   Downstream CDN to acquire the content from content sources (including
   upstream CDNs) in advance of or indepedent of any End User requesting
   it.

   Pre-positioned CDNI Metadata acquisition: In the context of CDN
   Interconnect, Metadata Pre-positioning is where the the Downstream
   CDN acquires distribution metadata for content prior to or
   independent of any End User requesting that content from the
   Downstream CDN.

   End User (EU): The 'real' user of the system, typically a human but
   maybe some combination of hardware and/or software emulating a human
   (e.g. for automated quality monitoring etc.)

   User Agent (UA): Software (or a combination of hardware and software)
   through which the End User interacts with the Content Service.  The
   User Agent will communicate with the CSP's Service for the selection
   of content and one or more CDNs for the delivery of the Content.
   Such communication is not restricted to HTTP and may be via a variety
   of protocols.  Examples of User Agents (non-exhaustive) are:
   Browsers, Set Top Boxes (STB), Dedicated content applications (e.g.
   media players), etc.

   Network Service Provider (NSP): Provides network-based connectivity/
   services to Users.

   Content Service Provider (CSP): Provides a Content Service to End
   Users (which they access via a User Agent).  A CSP may own the
   Content made available as part of the Content Service, or may license
   content rights from another party.

   Content Service: The service offered by a Content Service Provider.
   The Content Service encompasses the complete service which may be
   wider than just the delivery of items of Content, e.g. the Content
   Service also includes any middleware, key distribution, program
   guide, etc. which may not require any direct interaction with the
   CDN.

   Content Distribution Network (CDN) / Content Delivery Network (CDN):
   Network infrastructure in which the network elements cooperate at
   layers 4 through layer 7 for more effective delivery of Content to



Niven-Jenkins, et al.  Expires September 14, 2011               [Page 7]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   User Agents.  Typically a CDN consists of a Request Routing system, a
   Distribution System (that includes a set of Surrogates), a Logging
   System and a CDN control system .

   CDN Provider: The service provider who operates a CDN.  Note that a
   given entity may operate in more than one role.  For example, a
   company may simultaneously operate as a Content Service Provider, a
   Network Service Provider and a CDN Provider.

   CDN Interconnect (CDNI): The set of interfaces over which two or more
   CDNs communicate with each other in order to achieve the delivery of
   content to User Agents by Surrogates in one CDN (the downstream CDN)
   on behalf of another CDN (the upstream CDN).

   Upstream CDN: For a given user request, the CDN (within a pair of
   directly interconnected CDNs) that redirects the request to the other
   CDN.

   Downstream CDN: For a given user request, the CDN (within a pair of
   directly interconnected CDNs) to which the request is redirected by
   the other CDN (the Upstream CDN).  Note that in the case of
   successive redirections (e.g.  CDN1-->CDN2-->CDN3) a given CDN (e.g.
   CDN2) may act as the Downstream CDN for a redirection (e.g.
   CDN1-->CDN2) and as the Upstream CDN for the subsequent redirection
   of the same request (e.g.  CDN2-->CDN3).

   Over-the-top (OTT): A service, e.g. a CDN, operated by a different
   operator than the NSP to which the users of that service are
   attached.

   Surrogate: A device/function that interacts with other elements of
   the CDN for the control and distribution of Content within the CDN
   and interacts with User Agents for the delivery of the Content.

   Request Routing System: The function within a CDN responsible for
   receiving a content request from a user agent, obtaining and
   maintaining necessary information about a set of candidate surrogates
   or candidate CDNs, and for selecting and redirecting the user to the
   appropriate surrogate or CDN.  To enable CDN Interconnect, the
   Request Routing System must also be capable of handling user agent
   content requests passed to it by another CDN.

   Distribution System: the function within a CDN responsible for
   distributing Content Distribution Metadata as well as content inside
   the CDN (e.g. down to the surrogates)

   Delivery: the function within CDN surrogates responsible for
   delivering a piece of content to the User Agent.  For example,



Niven-Jenkins, et al.  Expires September 14, 2011               [Page 8]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   delivery may be based on HTTP progressive download or HTTP adaptive
   streaming.

   Logging System: the function within a CDN responsible for collecting
   measurement and recording of distribution and delivery activities.
   The information recorded by the logging system may be used for
   various purposes including charging (e.g. of the CSP), analytics and
   monitoring.

1.2.  CDN Background

   Readers are assumed to be familiar with the architecture, features
   and operation of CDNs.  For readers less familiar with the operation
   of CDNs, the following resources may be useful:

   o  RFC 3040 [RFC3040] describes many of the component technologies
      that are used in the construction of a CDN
   o  Taxonomy [TAXONOMY] compares the architecture of a number of CDNs
   o  RFC 3466 [RFC3466] and RFC 3570 [RFC3570] are the output of the
      IETF Content Delivery Internetworking (CDI) working group which
      was closed in 2003.

   Note: Some of the terms used in this document are similar to terms
   used the above referenced documents.  When reading this document
   terms should be interpreted as having the definitions provided in
   Section 1.1.


2.  CDN Interconnect Use Cases

   An increasing number of NSPs are deploying CDNs in order to deal
   cost-effectively with the growing usage of on-demand video services
   and other content delivery applications.

   CDNs allow caching of content closer to the edge so that a given item
   of content can be delivered by a CDN Surrogate (i.e. a cache) to
   multiple User Agents (and their End Users) without transiting
   multiple times through the network core (i.e from the content origin
   to the surrogate).  This contributes to bandwidth cost reductions for
   the NSP and to improved quality of experience for the end users.
   CDNs also enable replication of popular content across many
   surrogates, which enables content to be served to large numbers of
   User Agents concurrently.  This also helps dealing with situations
   such as flash crowds and denial of service attacks.

   The CDNs deployed by NSPs are not just restricted to the delivery of
   content to support the Network Service Provider's own 'walled garden'
   services, such as IP delivery of television services to Set Top



Niven-Jenkins, et al.  Expires September 14, 2011               [Page 9]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   Boxes, but are also used for delivery of content to other devices
   including PCs, tablets, mobile phones etc.

   Some service providers operate over multiple geographies and federate
   multiple affiliate NSPs.  These NSPs typically operate independent
   CDNs.  As they evolve their services (e.g. for seamless support of
   content services to nomadic users across affiliate NSPs) there is a
   need for interconnection of these CDNs.  However there are no open
   specifications, nor common best practices, defining how to achieve
   such CDN interconnection.

   CSPs have a desire to be able to get (some of) their content to very
   large number of End Users and/or over many/all geographies and/or
   with a high quality of experience, all without having to maintain
   direct business relationships with many different CDN providers (or
   having to extend their own CDN to a large number of locations).  Some
   NSPs are considering interconnecting their respective CDNs (as well
   as possibly over-the-top CDNs) so that this collective infrastructure
   can address the requirements of CSPs in a cost effective manner.  In
   particular, this would enable the CSPs to benefit from on-net
   delivery (i.e. within the Network Service Provider's own network/CDN
   footprint) whenever possible and off-net delivery otherwise, without
   requiring the CSPs to maintain direct business relationships with all
   the CDNs involved in the delivery.  Again, for this requirement, CDN
   operators (NSPs or over-the-top CDN operators) are faced with a lack
   of open specifications and best practices.

   NSPs have often deployed CDNs as specialized cost-reduction projects
   within the context of a particular service or environment, some NSPs
   operate separate CDNs for separate services.  For example, there may
   be a CDN for managed IPTV service delivery, a CDN for web-TV delivery
   and a CDN for video delivery to Mobile terminals.  As NSPs integrate
   their service portfolio, there is a need for interconnecting these
   CDNs.  Again, NSPs face the problem of lack of open interfaces for
   CDN interconnection.

   For operational reasons (e.g. disaster, flash crowd) or commercial
   reasons, an over-the-top CDN may elect to make use of another CDN
   (e.g. an NSP CDN with on-net Surrogates for a given footprint) for
   serving a subset of the user requests (e.g. requests from users
   attached to that NSP).  Again, for this requirement, CDN operators
   (over-the-top CDN operators or NSPs) are faced with a lack of open
   specifications and best practices.

   Use cases for CDN Interconnection are further discussed in
   [I-D.bertrand-cdni-use-cases] (which contains a merged set of use
   cases previously presented in [I-D.watson-cdni-use-cases] and
   [I-D.bertrand-cdni-use-cases-00]).



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 10]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


3.  CDN Interconnect Model & Problem Area for IETF

   Interconnecting CDNs involves interactions among multiple different
   functions and components that form each CDN.  Only some of those
   require standardization.  The CDNI model and problem area proposed
   for IETF work is illustrated in Figure 1.  The candidate problem area
   (and respectively the non-goals) for IETF work on CDN Interconnection
   are discussed in Section 3.1 (and respectively Section 3.2 ).











































Niven-Jenkins, et al.  Expires September 14, 2011              [Page 11]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


      --------
     /        \
     |   CSP  |
     \        /
      --------
          *
          *
          *                        /\
          *                       /  \
      ---------------------      |CDNI|       ---------------------
     /    Upstream CDN     \     |    |      /   Downstream CDN    \
     |     +-------------+ | Control protocol| +-------------+     |
     |     |CDN Control  |<======|====|=======>| CDN Control |     |
     |     +------*-*-*--+ |     |    |      | +-*-*-*-------+     |
     |            * * *    |     |    |      |   * * *             |
     |     +------*------+ | Logging protocol| +-----*-------+     |
     | ****| Logging     |<======|====|=======>|  Logging    |**** |
     | *   --------------+ |     |    |      | +-------------+   * |
     | *            * *    | Request Routing |   * *             * |
   ....*...+--------*----+ |    protocol     | +---*---------+...*.....
   . | * **|Req-Routing  |<======|====|=======>| Req-Routing |** * |  .
   . | * * +-------------+ |     |    |      | +-------------+ * * |  .
   . | * *            *    |  CDNI Metatdata |   *             * * |  .
   . | * * +----------*--+ |    protocol     | +-*-----------+ * * |  .
   . | * * |Distribution |<======|====|=======>| Distribution| * * |  .
   . | * * |             | |      \  /       | |             | * * |  .
   . | * * |             | |       \/        | |             | * * |  .
   . | * ****+---------+ | |                 | | +---------+**** * |  .
   . | ******|Surrogate|*************************|Surrogate|****** |  .
   . |     | +---------+ | |   Acquisition   | | +-----*---+ |     |  .
   . |     +-------------+ |                 | +-------*-----+     |  .
   . \                     /                 \         *           /  .
   .  ---------------------                   ---------*-----------   .
   .                                                   *              .
   .                                                   * Delivery     .
   .                                                   *              .
   .                                                +------+          .
   ...............Request...........................| User |..Request..
                                                    | Agent|
                                                    +------+

   <==>  interfaces inside the scope of CDNI

   ****  interfaces outside the scope of CDNI
   ....  interfaces outside the scope of CDNI

                        Figure 1: CDNI Problem Area




Niven-Jenkins, et al.  Expires September 14, 2011              [Page 12]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


3.1.  Candidate CDNI Problem Area for IETF

   Listed below are the four protocols required to interconnect a pair
   of CDNs and that constitute the problem space that is proposed to be
   addressed by a potential CDNI working group in the IETF.  The use of
   the term "protocol" is meant to encompass the protocol over which
   CDNI data representations (e.g.  CDNI Metadata records) are exchanged
   as well as the specification of the data representations themselves
   (i.e. what properties/fields each record contains, its structure,
   etc.).  While "interface" may be a more accurate term, the term
   "protocol" is retained in this document because of its common use.

   o  CDNI Control protocol: This protocol allows the "CDNI Control"
      system in interconnected CDNs to communicate.  This protocol may
      support the following:
      *  Allow bootstrapping of the other CDNI protocols (e.g. protocol
         address discovery and establishment of security associations).
      *  Allow configuration of the other CDNI protocols (e.g.  Upstream
         CDN specifies information to be reported through the CDNI
         Logging protocol).
      *  Allow the downstream CDN to communicate static (or fairly
         static) information about its delivery capabilities and
         policies.
      *  Allow bootstrapping of the interface between CDNs for content
         acquisition (even if that interface itself is outside the scope
         of the CDNI work).
      *  Allow upstream CDN to initiate or request specific actions to
         be undertaken in the downstream CDN.  For example, this may
         include the following capabilities:
         +  Allow an upstream CDN to request that content files and/or
            CDNI Metadata that it shared, be purged from, or invalidated
            in, a downstream CDN.  Support for content deletion or
            invalidation from a CDN is a key requirement for some
            Content Service Providers in order, amongst other use cases
            for content deletion, to support the content rights
            agreements they have negotiated.  Today's CDNs use
            proprietary control interfaces to enable CSPs to remove
            content cached in the CDN and therefore there is a need to
            have a similar but standardized content deletion capability
            between interconnected CDNs.
         +  Allow an upstream CDN to initiate Pre-postioned content
            acquisition and/or Pre-positioned CDN Metadata acquisition
            in a downstream CDN.
   o  CDNI Request Routing protocol: This protocol allows the Request
      Routing system in interconnected CDNs to communicate to ensure
      that an end user request can be (re)directed from an upstream CDN
      to a surrogate in the downstream CDN, in particular where
      selection responsibilities may be split across CDNs (for example



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 13]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


      the upstream CDN may be responsible for selecting the downstream
      CDN while the downstream CDN may be responsible for selecting the
      actual surrogate within that CDN).  In particular, the CDN Request
      Routing protocol, may support the following:
      *  allow the upstream CDN to query the downstream CDN at request-
         routing time before redirecting the request to the downstream
         CDN
      *  allow the downstream CDN to provide to the upstream CDN (static
         or dynamic) information (e.g. resources, footprint, load) to
         facilitate selection of the downstream CDN by the upstream CDN
         request routing system when processing subsequent content
         requests from User Agents.
   o  CDNI Metadata distribution protocol: This protocol allows the
      Distribution system in interconnected CDNs to communicate to
      ensure CDNI Metadata can be exchanged across CDNs.  See
      Section 1.1 for definition and examples of CDNI Metadata.
   o  CDNI Logging protocol: This protocol allows the Logging system in
      interconnected CDNs to communicate the relevant activity logs in
      order to allow log consuming applications to operate in a multi-
      CDN environments.  For example, an upstream CDN may collect
      delivery logs from a downstream CDN in order to perform
      consolidated charging of the CSP or for settlement purposes across
      CDNs.  Similarly, an upstream CDN may collect delivery logs from a
      downstream CDN in order to provide consolidated reporting and
      monitoring to the CSP.

   Note that the actual grouping of functionalities under these four
   protocols is considered tentative at this stage and may be changed
   after further study (e.g. some subset of functionality be moved from
   one protocol into another).

   The above list covers a significant potential problem space, in part
   because in order to interconnect two CDNs there are several 'touch
   points' that require standardization.  However, it is expected that
   the CDNI protocols need not be defined from scratch and instead can
   very significantly reuse or leverage existing protocols: this is
   discussed further in Section 4.  Also, it is expected that the items
   above will be prioritized so that the CDNI Working Group can focus
   (at least initially) on the most essential and urgent work: this is
   discussed further in Section 5.

   As part of the development of the CDNI protocols and solutions it
   will also be necessary to agree on common mechanisms for how to
   identify and name the data objects that are to be interchanged
   between interconnected CDNs, as well as how to describe which policy
   should be used when doing so.  [I-D.jenkins-cdni-names] presents one
   view on how CDN data types/objects could be classified such that the
   problem space of their naming and referencing is not as large as it



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 14]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   might at first appear because there is significant commonality
   between the different data types/objects required for CDNI.

   Some NSPs have started to perform experiments to explore whether
   their CDN use cases can already be addressed with existing CDN
   implementations.  One set of such experiments is documented in
   [I-D.bertrand-cdni-experiments].  The conclusions of those
   experiments are that while some basic limited CDN Interconnection
   functionality can be achieved with existing CDN technology, the
   current lack of any standardized CDNI interfaces/protocols such as
   those discussed in this document is preventing the deployment of
   production CDN Interconnection solutions with the necessary level of
   functionality.

3.2.  Non-Goals for IETF

   Listed below are aspects of content delivery that the authors propose
   be kept outside of the scope of a potential CDNI working group:
   o  The interface between Content Service Provider and the
      Authoritative CDN (i.e. the upstream CDN contracted by the CSP for
      delivery by this CDN or by its downstream CDNs).
   o  The delivery interface between the delivering CDN surrogate and
      the User Agent, such as streaming protocols.
   o  The request interface between the User Agent and the request-
      routing system of a given CDN.  Existing IETF protocols (e.g.
      HTTP, RTSP, DNS) are commonly used by User Agents to request
      content from a CDN and by CDN request routing systems to redirect
      the User Agent requests.  The CDNI working group need not define
      new protocols for this purpose.  Note however, that the CDNI
      control plane protocol may indirectly affect some of the
      information exchanged through the request interface (e.g.  URI).
   o  The content acquisition interface between CDNs (i.e. the data
      plane interface for actual delivery of a piece of content from one
      CDN to the other).  This is expected to use existing protocols
      such as HTTP or protocols defined in other forums for content
      acquisition between an origin server and a CDN (e.g.  HTTP-based
      C2 reference point of ATIS IIF CoD).  The CDN Interconnection
      solution may only concern itself with the agreement/negotiation
      aspects of which content acquisition protocol is to be used
      between two interconnected CDNs in view of facilitating
      interoperability.
   o  End User/User Agent Authentication.  End User/User Agent
      authentication and authorization are the responsibility of the
      Content Service Provider.
   o  Content preparation, including encoding and transcoding.  The CDNI
      architecture aims at allowing distribution across interconnected
      CDNs of content treated as opaque objects.  Interpretation and
      processing of the objects, as well as optimized delivery of these



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 15]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


      objects by the surrogate to the end user are outside the scope of
      CDNI.
   o  Digital Rights Management (DRM).  DRM is an end-to-end issue
      between a content protection system and the User Agent.
   o  Applications consuming CDNI logs (e.g. charging, analytics,
      reporting,...).
   o  Internal CDN Protocols. i.e. protocols within one CDN.
   o  Scalability of individual CDNs.  While scalability of the CDNI
      protocols/approach is in scope, how an individual CDN scales is
      out of scope.
   o  Actual algorithms for selection of CDNs or Surrogates by Request
      Routing systems (however, some specific parameters required as
      input to these algorithms may be in scope when they need to be
      communicated across CDNs).
   o  Surrogate algorithms.  For example caching algorithms and content
      acquisition methods are outside the scope of the CDNI work.
      Content management (e.g.  Content Deletion) as it relates to CDNI
      content management policies, is in scope but the internal
      algorithms used by a cache to determine when to no longer cache an
      item of Content (in the absence of any specific metadata to the
      contrary) is out of scope.
   o  Element management interfaces.
   o  Commercial, business and legal aspects related to the
      interconnections of CDNs.

   The third bullet in the list above places the acquisition of content
   between interconnected CDNs as out of scope for CDNI and deserves
   some additional explanation.  The consequence of such a decision is
   that a CDNI WG would be focussed on only defining the control plane
   for CDNI; and the CDNI data plane (i.e. the acquisition &
   distribution of the actual content objects) would not be addressed by
   a CDNI WG.  The rationale for such a decision is that CDNs today
   typically already use standardized protocols such as HTTP, FTP,
   rsync, etc. to acquire content from their CSP customers and it is
   expected that the same protocols could be used for acquisition
   between interconnected CDNs.  Therefore the problem of content
   acquisition is considered already solved and all that is required
   from a CDNI WG is describing within the CDNI Metadata where to go and
   which protocol to use to retrieve the content.


4.  Design Approach for Realizing the CDNI APIs

   This section expands on how CDNI protocols can reuse and leverage
   existing protocols.  First the "reuse instead of reinvent" design
   principle is restated, then each protocol is discussed individually
   with example candidate protocols that can be considered for reuse or
   leverage.  This discussion is not intended to pre-empt any WG



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 16]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   decision as to the most appropriate protocols, technologies and
   solutions to select to solve CDNI but is intended as an illustration
   of the fact that these protocols need not be created in a vacuum and
   that reuse or leverage of existing protocols is likely possible.

4.1.  Relationship to the OSI network model

   The four CDNI protocols (CDNI Control protocol, CDNI Request Routing
   protocol, CDNI Metadata protocol, CDNI Logging protocol) described in
   Section 3.1 within the CDNI problem area are all control plane
   interfaces operating at the application layer (Layer 7 in the OSI
   network model).  Since it is not expected that these protocols would
   exhibit unique session, transport or network requirements as compared
   to the many other existing applications in the Internet, it is
   expected that the CDNI protocols will be defined on top of existing
   session, transport and network protocols.

4.2.  "Reuse Instead of Reinvent" Principle

   Although a new application protocol could be designed specifically
   for CDNI we assume that this is unnecessary and it is recommended
   that existing application protocols be reused or leveraged (HTTP
   [RFC2616], Atom Publishing Protocol [RFC5023], XMPP [RFC3920], for
   example) to realize the CDNI protocols.

4.3.  CDNI Request Routing API

   The CDNI Request Routing protocol enables a Request Routing function
   in an upstream CDN to query a Request Routing function in a
   downstream CDN to determine if the downstream CDN is able (and
   willing) to accept the delegated content request and to allow the
   downstream CDN to control what the upstream Request Routing function
   should return to the User Agent in the redirection message.

   The CDNI Request Routing protocol needs to offer a mechanism for an
   upstream CDN to issue a "Redirection Request" to a downstream CDN.
   The Request Routing protocol needs to be able to support scenarios
   where the initial User Agent request to the upstream CDN is received
   over DNS as well as over a content specific application protocol
   (e.g.  HTTP, RTSP, RTMP, etc.).

   Therefore a Redirection Request needs to contain information such as:

   o  The protocol (e.g.  DNS, HTTP) over which the upstream CDN
      received the initial User Agent request
   o  Additional details of the User Agent request that are required to
      perform effective Request Routing by the Downstream CDN.  For DNS
      this would typically be the IP address of the DNS resolver making



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 17]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


      the request on behalf of the User Agent.  For requests received
      over content specific application protocols the Redirection
      Request could contain significantly more information related to
      the original User Agent request but at a minimum would need to
      contain the User Agent's IP address, the equivalent of the HTTP
      Host header and the equivalent of the HTTP abs_path defined in
      [RFC2616].

   It should be noted that, the CDNI architecture needs to consider that
   a downstream CDN may receive requests from User Agents without first
   receiving a Redirection Request from an upstream CDN, for example
   because:

   o  User Agents (or DNS resolvers) may cache DNS or application
      responses from Request Routers.
   o  Responses to Redirection Requests over the Request Routing
      protocol may be cacheable.
   o  Some CDNs may want broader policies, e.g.  CDN B agrees to always
      take CDN A's delegated redirection requests, in which case the
      necessary redirection details are exchanged out of band (of the
      CDNI protocols), e.g. configured.

   On receiving a Redirection Request, the downstream CDN will use the
   information provided in the request to determine if it is able (and
   willing) to accept the delegated content request and needs to return
   the result of its decision to the upstream CDN.

   Thus, a Redirection Response from the downstream CDN needs to contain
   information such as:

   o  Status code indicating acceptance or rejection (possibly with
      accompanying reasons).
   o  Information to allow redirection by the Upstream CDN.  In the case
      of DNS-based request routing, this is expected to include the
      equivalent of a DNS record(s) (e.g. a CNAME) that the upstream CDN
      should return to the requesting DNS resolver.  In the case of
      application based request routing, this is expected to include the
      application specific redirection response(s) to return to the
      requesting User Agent.  For HTTP requests from User Agents this
      could be in the form of a URI that the upstream CDN could return
      in a HTTP 302 response.

   The CDNI Request Routing protocol is therefore a fairly
   straightforward request/response protocol and could be implemented
   over any number of request/response protocols.  For example, it may
   be implemented as a WebService using one of the common WebServices
   methodologies (XML-RPC, HTTP query to a known URI, etc.).  This
   removes the need for a CDNI WG to define a new protocol for the



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 18]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   request/response element of the Request Routing protocol.  Thus, a
   CDNI WG would be left only with the task of specifying:

   o  The recommended request/response protocol to use along with any
      additional semantics and procedures that are specific to the CDNI
      Request Routing protocol (e.g. handling of malformed requests/
      responses).
   o  The syntax (i.e representation/encoding) of the redirection
      requests and responses.
   o  The semantics (i.e. meaning and expected contents) of the
      redirection requests and responses.

4.4.  CDNI Metadata API

   The CDNI Metadata protocol enables the Metadata function in a
   downstream CDN to obtain CDNI Metadata from an upstream CDN so that
   the downstream CDN can properly process and respond to:

   o  Redirection Requests received over the CDNI Request Routing
      protocol.
   o  Content Requests received directly from User Agents.

   The CDNI Metadata protocol needs to offer a mechanism for an Upstream
   CDN to:
   o  distribute/update/remove CDNI Metadata to a Downstream CDN

   and/or to allow a downstream CDN to:

   o  Make direct requests for CDNI Metadata records where the
      downstream CDN knows the identity of the Metadata record(s) it
      requires.
   o  Search for CDNI Metadata records where the downstream CDN does not
      know the specific Metadata record(s) it requires but does know
      some property of the record it is searching for.  For example, it
      may know the value of the HTTP Host header received in a HTTP
      request and it wants to obtain the CDNI Metadata for that host so
      that it can determine how to further process the received HTTP
      request.

   The CDNI Metadata protocol is therefore similar to the CDNI Request
   Routing protocol because it is a request/response protocol with the
   potential addition that CDNI Metadata search may have more complex
   semantics than a straightforward Request Routing redirection request.
   Therefore, like the CDNI Request Routing protocol, the CDNI Metadata
   protocol may be implemented as a WebService using one of the common
   WebServices methodologies (XML-RPC, HTTP query to a known URI, etc.)
   or possibly using other existing protocols such as XMPP [RFC3920].
   This removes the need for a CDNI WG to define a new protocol for the



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 19]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   request/response element of the Metadata protocol.

   Thus, a CDNI WG would be left only with the task of specifying:

   o  The recommended request/response protocol to use along with any
      additional semantics that are specific to the CDNI Metadata
      protocol (e.g. handling of malformed requests/responses).
   o  The syntax (i.e representation/encoding) of the CDNI Metadata
      records that will be exchanged over the protocol.
   o  The semantics (i.e. meaning and expected contents) of the
      individual properties of a Metadata record.
   o  How the relationships between different CDNI Metadata records are
      represented.

4.5.  CDNI Logging API

   The CDNI Logging protocol enables details of logs or events to be
   exchanged between interconnected CDNs, where events could be:

   o  Log lines related to the delivery of content (similar to the log
      lines recorded in a web server's access log).
   o  Real-time or near-real time events before, during or after content
      delivery, e.g. content Start/Pause/Stop events, etc.
   o  Operations and diagnostic messages.

   Within CDNs today, logs and events are used for a variety of purposes
   in addition to real-time and non real-time diagnostics and auditing
   by the CDN Operator and its customers.  Specifically CDNs use logs to
   generate Call Data Records (CDRs) for passing to billing and payment
   systems and to real-time (and near real-time) analytics systems.
   Such use cases place requirements on the CDNI Logging protocol to
   support guaranteed and timely delivery of log messages between
   interconnected CDNs.  It may also be necessary to be able to prove
   the integrity of received log messages.

   Several protocols already exist that could potentially be used to
   exchange CDNI logs between interconnected CDNs including SNMP Traps,
   syslog, ftp, HTTP POST, etc. although it is likely that some of the
   candidate protocols may not be well suited to meet all the
   requirements of CDNI.  For example SNMP traps pose scalability
   concerns and SNMP does not support guaranteed delivery of Traps and
   therefore could result in log records being lost and the consequent
   CDRs and billing records for that content delivery not being produced
   as well as that content delivery being invisible to any analytics
   platforms.

   Although it is not necessary to define a new protocol for exchanging
   logs across the CDNI Logging protocol, a CDNI WG would still need to



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 20]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   specify:

   o  The recommended protocol to use.
   o  A default set of log fields and their syntax & semantics.  Today
      there is no standard set of common log fields across different
      content delivery protocols and in some cases there is not even a
      standard set of log field names and values for different
      implementations of the same delivery protocol.
   o  A default set of events that trigger logs to be generated.

4.6.  CDNI Control API

   The CDNI Control protocol allows the "CDNI Control" system in
   interconnected CDNs to communicate.  The exact inter-CDN control
   functionality required to be supported by the CDNI Control protocol
   is less well defined than the other three CDNI interfaces at this
   time.

   However, as discussed in Section 3.1, the CDNI Control protocol may
   be required to support functionality similar to the following:
   o  Allow an upstream CDN and downstream CDN to establish, update or
      terminate their CDNI interconnection.
   o  Allow bootstrapping of the other CDNI protocols (e.g. protocol
      address discovery and establishment of security associations).
   o  Allow configuration of the other CDNI protocols (e.g.  Upstream
      CDN specifies information to be reported through the CDNI Logging
      protocol).
   o  Allow the downstream CDN to communicate information about its
      delivery capabilities, resources and policies.
   o  Allow bootstrapping of the interface between CDNs for content
      acquisition (even if that interface itself is outside the scope of
      the CDNI work).
   It is expected that for the Control protocol also, existing protocols
   can be reused or leveraged.  Those will be considered once the
   requirements for the Control protocol have been refined.


5.  Prioritizing the CDNI Work

   In order to manage the potential workload of a CDNI WG, it is
   recommended that the work be prioritized in a "walk before you run"
   approach.

   The CDNI problem area can be categorized into different solution
   scopes as follows:
   o  "Base CDNI" Scope: This solution scope comprises the solution
      elements that can be considered as the 'minimum' needed to
      actually deliver any content using interconnected CDNs.  For



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 21]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


      example, a base CDNI Request Routing protocol and a base CDNI
      Metadata protocol belong to this scope because without them the
      upstream CDN is unable to redirect User Agents to the downstream
      CDN and the downstream CDN is unable to obtain the delivery
      policies and other CDNI Metadata required to ingest and deliver
      the content.
   o  "Operationalized CDNI" Scope: This solution scope comprises the
      solution elements that can be considered as the 'minimum' needed
      to 'operationalize' CDN Interconnects.  For example, the CDNI
      Logging protocol and the base capabilities of the CDNI Control
      protocol (e.g. content file/metadata deletion) belong to this
      scope because without them CDN operators are required to
      substitute for them either with manual processes or proprietary
      interfaces.
   o  "Enhanced CDNI" Scope: This solution scope comprises the solution
      elements that can be classed as 'enhanced features'.  For example,
      the aspects of the CDNI Control protocol related to automatic
      bootstrapping and configuration belong to this scope.

   It is proposed that these solution scopes be addressed primarily
   sequentially by a CDNI WG and that the initial charter be centered
   around the "Base CDNI" scope.  However there is obvious benefit from
   having a solution for the "Base CDNI" scope that is amenable to
   extension for support of the "Operational" scope and "Enhanced"
   scope.  Therefore it is proposed that the initial CDNI WG charter
   also includes definition of (at least) the main requirements for the
   "Operationalized CDNI" scope and "Enhanced CDNI" Scope, so those can
   be kept in mind when defining the solution for the "Base CDNI" scope.


6.  Gap Analysis of relevant Standardization and Research Activities

   There are a number of other standards bodies and industry forums that
   are working in areas related to CDN, and in some cases related to
   CDNI.  This section will first outline the key standardization
   organizations undertaking related work, some related research
   projects, and will then outline any potential overlap with the
   proposed CDNI WG and any component that could potentially be reused
   by CDNI .

6.1.  Related standardization activities

6.1.1.  IETF CDI Working Group (Concluded)

   The Content Distribution Internetworking (CDI) Working Group was
   formed in the IETF following a BoF in December 2000 and closed in mid
   2003.




Niven-Jenkins, et al.  Expires September 14, 2011              [Page 22]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   For convenience, here is an extract from the CDI WG charter
   [CDI-Charter]:

   "

   o  The goal of this working group is to define protocols to allow the
      interoperation of separately-administered content networks.
   o  A content network is an architecture of network elements, arranged
      for efficient delivery of digital content.  Such content includes,
      but is not limited to, web pages and images delivered via HTTP,
      and streaming or continuous media which are controlled by RTSP.
   o  The working group will first define requirements for three modes
      of content internetworking: interoperation of request-routing
      systems, interoperation of distribution systems, and
      interoperation of accounting systems.  These requirements are
      intended to lead to a follow-on effort to define protocols for
      interoperation of these systems.
   o  In its initial form, the working group is not chartered to deliver
      those protocols [...]

   "

   Thus, the CDI WG touched on the same problem space as the present
   document.

   The CDI WG published 3 Informational RFCs:

   o  RFC 3466 [RFC3466] - "A Model for Content Internetworking (CDI)".
   o  RFC 3568 [RFC3568] - "Known Content Network (CN) Request-Routing
      Mechanisms".
   o  RFC 3570 [RFC3570] - "Content Internetworking (CDI) Scenarios".

6.1.2.  3GPP

   3GPP was the first organization that released a specification related
   to adaptive streaming over HTTP. 3GPP Release 9 specification on
   adaptive HTTP streaming was published in March 2010, and there have
   been some bug fixes on this specification since the publication.  In
   addition, 3GPP is preparing an extended version for Release 10, which
   is scheduled to be published later in 2011.  This release will
   include a number of clarifications, improvements and new features.

   [3GP-DASH] is defined as a general framework independent of the data
   encapsulation format.  It has support for fast initial startup and
   seeking, adaptive bitrate switching, re-use of HTTP origin and cache
   servers, re-use of existing media playout engines, on-demand, live
   and time-shifted delivery.  It specifies syntax and semantics of
   Media Presentation Description (MPD), format of segments and delivery



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 23]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   protocol for segments.  It does not specify content provisioning,
   client behavior or transport of MPD.

   The content retrieved by a client using [3GP-DASH] adaptive streaming
   could be obtained from a CDN but this is not discussed or specified
   in the 3GPP specifications as it is transparent to [3GP-DASH]
   operations.  Similarly, it is expected that [3GP-DASH] can be used
   transparently from the CDNs as a delivery protocol (between the
   delivering CDN surrogate and the User Agent) in a CDN Interconnect
   environment. [3GP-DASH] could also be a candidate for content
   acquisition between CDNs in a CDN Interconnect environment.

6.1.3.  ISO MPEG

   Within ISO MPEG, the Dynamic Adaptive Streaming over HTTP (DASH) ad-
   hoc group adopted the 3GPP Release 9 [3GP-DASH] specification as a
   starting point and has made some improvements and extensions.
   Similar to 3GPP SA4, the MPEG DASH ad-hoc group has been working on
   standardizing the manifest file and the delivery format.
   Additionally, the MPEG DASH ad-hoc group has also been working on the
   use of MPEG-2 Transport Streams as a media format, conversion from/to
   existing file formats, common encryption, and so on.  The MPEG DASH
   specification could also be a candidate for delivery to the user
   agent and for content acquisition between CDNs in a CDN Interconnect
   environment.  The Draft International Standard (DIS) version
   [MPEG-DASH] is currently publicly available since early February
   2011.

   In the 95th MPEG meeting in January 2011, the DASH ad-hoc group
   decided to start a new evaluation experiment called "CDN-EE".  The
   goals are to understand the requirements for MPEG DASH to better
   support CDN-based delivery, and to provide a guidelines document for
   CDN operators to better support MPEG DASH streaming services.  The
   ongoing work is still very preliminary and does not currently target
   looking into CDN Interconnect use cases.

6.1.4.  ATIS IIF

   ATIS ([ATIS]) IIF is the IPTV Interoperability Forum (within ATIS)
   that develops requirements, standards, and specifications for IPTV.

   ATIS IIF is developing the "IPTV Content on Demand (CoD) Service"
   specification.  This includes use of a CDN (referred to in ATIS IIF
   CoD as the "Content Distribution and Delivery Functions") for support
   of a Content on Demand (CoD) Service as part of a broader IPTV
   service.  However, this only covers the case of a managed IPTV
   service (in particular where the CDN is administered by the service
   provider) and does not cover the use, or interconnection, of multiple



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 24]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   CDNs.

6.1.5.  CableLabs

   "Founded in 1988 by cable operating companies, Cable Television
   Laboratories, Inc. (CableLabs) is a non-profit research and
   development consortium that is dedicated to pursuing new cable
   telecommunications technologies and to helping its cable operator
   members integrate those technical advancements into their business
   objectives."  [CableLabs]

   CableLabs has defined specifications for CoD Content Metadata as part
   of its VOD Metadata project.

6.1.6.  ETSI MCD

   ETSI MCD (Media Content Distribution) is the ETSI technical committee
   "in charge of guiding and coordinating standardization work aiming at
   the successful overall development of multimedia systems (television
   and communication) responding to the present and future market
   requests on media content distribution".

   MCD created a specific work item on interconnection of heterogeneous
   CDNs ("CDN Interconnection, use cases and requirements") in March
   2010.  MCD very recently created a working group to progress this
   work item.  However, no protocol level work has yet started in MCD
   for CDN Interconnect.

6.1.7.  ETSI TISPAN

   ETSI TISPAN has published two sets of IPTV specifications, one of
   which is based on IMS.  In addition, TISPAN is about to complete the
   specifications of a CDN architecture supporting delivery of various
   content services such as time-shifted TV and VoD to TISPAN devices
   (UEs) or regular PCs.  The use cases allow for hierarchically and
   geographically distributed CDN scenarios, along with multi-CDN
   cooperation.  As a result, the architecture contains reference points
   to support interconnection of other TISPAN CDNs.  The protocol
   definition phase for the corresponding CDN architecture was kicked-
   off at the end of 2010.  In line with its long history of leveraging
   IETF protocols, ETSI could potentially leverage CDNI protocols
   developed in the IETF for their related protocol level work on
   interconnections of CDNs.

6.1.8.  ITU-T

   SG13 is developing standards related to the support of IPTV services
   (i.e.. multimedia services such as television/VoD/audio/text/



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 25]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   graphics/data delivered over IP-based managed networks).

   ITU-T Recommendation Y.1910 [Y.1910] provides the description of the
   IPTV functional architecture.  This architecture includes functions
   and interfaces for the distribution and delivery of content.  This
   architecture is aligned with the ATIS IIF architecture.

   Based upon ITU-T Rec. Y.1910, ITU-T Rec. Y.2019 [Y.2019] describes in
   more detail the content delivery functional architecture.  This
   architecture allows CDN Interconnection: some interfaces (such as D3,
   D4) at the control level allow relationships between different CDNs,
   in the same domain or in different domains.  Generic procedures are
   described, but the choice of the protocols is open.

6.1.9.  Open IPTV Forum (OIPF)

   The Open IPTV Forum has developed an end-to-end solution to allow any
   OIPF terminal to access enriched and personalized IPTV services
   either in a managed or a non-managed network[OIPF-Overview].  Some
   OIPF services (such as Network PVR) may be hosted in a CDN.

   To that end, the Open IPTV Forum specification is made of 5 parts:

   o  Media Formats including HTTP Adaptive Streaming
   o  Content Metadata
   o  Protocols
   o  Terminal (Declarative or Procedural Application Environment)
   o  Authentication, Content Protection and Service Protection

6.1.10.  TV-Anytime Forum

   Version 1 of the TV-Anytime Forum specifications were published as
   ETSI TS 102 822-1 through ETSI TS 102 822-7 "Broadcast and On-line
   Services: Search, select, and rightful use of content on personal
   storage systems ("TV-Anytime")".  It includes the specification of
   content metadata in XML schemas (ETSI TS 102 822-3) which define
   technical parameters for the description of CoD and Live contents.
   The specification is referenced by DVB and OIPF.

   The TV-anytime Forum was closed in 2005.

6.1.11.  SNIA

   The Storage Networking Industry Association (SNIA) is an association
   of producers and consumers of storage networking products whose goal
   is to further storage networking technology and applications.

   SNIA has published the Cloud Data Management Interface (CDMI)



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 26]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   standard ([SNIA-CDMI]).

   "The Cloud Data Management Interface defines the functional interface
   that applications will use to create, retrieve, update and delete
   data elements from the Cloud.  As part of this interface the client
   will be able to discover the capabilities of the cloud storage
   offering and use this interface to manage containers and the data
   that is placed in them.  In addition, metadata can be set on
   containers and their contained data elements through this interface."

6.2.  Related Research Projects

6.2.1.  IRTF P2P Research Group

   Some information on CDN interconnection motivations and technical
   issues were presented in the P2P RG at IETF 77.  The presentation can
   be found in [P2PRG-CDNI].

6.2.2.  OCEAN

   OCEAN (http://www.ict-ocean.eu/) is an EU funded research project
   that started in February 2010 for 3 years.  Some of its objectives
   are relevant to CDNI.  It aims, among other things, at designing a
   new architectural framework for audiovisual content delivery over the
   Internet, defining public interfaces between its major building
   blocks in order to foster multi-vendor solutions and interconnection
   between Content Networks (the term "Content Networks" corresponds
   here to the definition introduced in [RFC3466], which encompasses
   CDNs).

   OCEAN has not yet published any open specifications, nor common best
   practices, defining how to achieve such CDN interconnection.

6.2.3.  Eurescom P1955

   Eurescom P1955 was a 2010 research project involving a four European
   Network operators, which studied the interests and feasibility of
   interconnecting CDNs by firstly elaborating the main service models
   around CDN interconnection, as well as analyzing an adequate CDN
   interconnection technical architecture and framework, and finally by
   providing recommendations for telcos to implement CDN
   interconnection.  The Eurescom P1955 project ended in July 2010.

   The authors are not aware of material discussing CDN interconnection
   protocols made publically available as a deliverable of this project.






Niven-Jenkins, et al.  Expires September 14, 2011              [Page 27]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


6.3.  Gap Analysis

   A number of standards bodies have produced specifications related to
   CDNs, namely:

   o  TISPAN has a dedicated specification for CDN.
   o  OIPF and ATIS specify the architecture and the protocols of an
      IPTV solution.  Although OIPF and ATIS specifications include the
      interaction with a CDN, the CDN specifications are coupled with
      their IPTV specifications.
   o  <TODO: Add a sentence on ITU>
   o  IETF CDN WG (now concluded) touched on the same problem space as
      the present document.  However, in accordance with its initial
      charter, the CDI WG did not define any protocols or interfaces to
      actually enable CDN Interconnection and at that time (2003) there
      was not enough industry interest and real life requirements to
      justify rechartering the WG to conduct the corresponding protocol
      work.

   Although some of the specifications describe multi-CDN cooperation or
   include reference points for interconnecting CDNs, none of them
   specify in sufficient detail all the CDNI protocols and CDNI Metadata
   representations required to enable even a base level of CDN
   Interconnect functionality to be implemented.

   The following sections will summarize the existing work described in
   Section 6.1 against the CDNI problem space.

6.3.1.  Content Acquisition across CDNs and Delivery to End User (Data
        plane)

   A number of standards bodies have completed work in the areas of
   content acquisition interface between a CSP and a CDN, as well as as
   on the delivery interface between the surrogate and the User Agent.
   Some of this work is summarized below.

   TISPAN, OIPF and ATIS have specified IPTV and/or CoD services,
   including the data plane aspects (typically different flavors of RTP/
   RTCP and HTTP) to obtain content and deliver it to User Agents.  For
   example, :
   o  The OIPF data plane includes both RTP and HTTP flavors (HTTP
      progressive download, HTTP Adaptive streaming [3GP-DASH],...).
   o  ATIS specification "IPTV Content on Demand (CoD) Service"
      [ATIS-COD] defines a reference point (C2) and the corresponding
      HTTP-based data plane protocol for content acquisition between an
      authoritative origin server and the CDN.
   While these protocols have not been explicitly specified for content
   acquisition across CDNs, they are suitable (in addition to others



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 28]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   such as standard HTTP) for content acquisition between CDNs in a CDN
   Interconnect environment.  Therefore for the purpose of a CDNI WG
   there are already multiple existing data plane protocols that can be
   used for content acquisition across CDNs.

   Similarly, there are multiple existing standards (e.g.  OIPTF data
   plane mentioned above, HTTP adaptive streaming [3GP-DASH]) or public
   specifications (e.g. vendor specific HTTP Adaptive streaming
   specification) so that content delivery is considered already solved
   (or at least sufficiently addressed in other forums).

   Thus, specification of the content acquisition interface between CDNs
   and the delivery interface between the surrogate and the User Agent
   are out of scope for CDNI.  CDNI may only concern itself with the
   negotiation/selection aspects of the acquisition protocol to be used
   in a CDN interonnect scenario.

6.3.2.  CDNI Metadata

   CableLabs, ITU, OIPF and TV-Anytime have work items dedicated to the
   specification of content metadata:

   o  CableLabs has defined specifications for CoD Content Metadata as
      part of its VOD Metadata project.  "The VOD Metadata project is a
      cable television industry and cross-industry-wide effort to
      specify the metadata and interfaces for distribution of video-on-
      demand (VOD) material from multiple content providers to cable
      operators."  [CableLabs-Metadata].  However, while the CableLabs
      work specifies an interface between a content provider and a
      service provider running a CDN, it does not include an interface
      that could be used between CDNs.
   o  ITU Study Group 16 has started work on a number of draft
      Recommendations (H.IPTV-CPMD, H.IPTV-CPMD, HSTP.IPTV-CMA,
      HSTP.IPTV-UMCI) specifying metadata for content distribution in
      IPTV services.
   o  An Open IPTV Terminal receives the technical description of the
      content distribution from the OIPF IPTV platform before receiving
      any content.  The Content distribution metadata is sent in the
      format of a TV-Anytime XSD including tags to describes the
      location and program type (on demand or Live) as well as
      describing the time availability of the on demand and live
      content.

   However the specifications outlined above do not include metadata
   specific to the distribution of content within a CDN or between
   interconnected CDNs, for example geo-blocking information,
   availability windows, access control mechanisms to be enforced by the
   surrogate, how to map an incoming content request to a file on the



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 29]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   origin server or acquire it from the upstream CDN etc.

   The CDMI standard ([SNIA-CDMI]) from SNIA defines metadata that can
   be associated with data that is stored by a cloud storage provider.
   While the metadata currently defined do not match the need of a CDN
   Interconnect solution, it is worth considering CDMI as one of the
   existing pieces of work that may potentially be leveraged for the
   CDNI Metadata protocol (e.g by extending the CDMI metadata to address
   more specific CDNI needs).


7.  Relationship to relevant IETF Working Groups

7.1.  ALTO

   As stated in the ALTO Working Group charter [ALTO-Charter]:

   "The Working Group will design and specify an Application-Layer
   Traffic Optimization (ALTO) service that will provide applications
   with information to perform better-than-random initial peer
   selection.  ALTO services may take different approaches at balancing
   factors such as maximum bandwidth, minimum cross-domain traffic,
   lowest cost to the user, etc.  The WG will consider the needs of
   BitTorrent, tracker-less P2P, and other applications, such as content
   delivery networks (CDN) and mirror selection."

   In particular, the ALTO service can be used by a CDN Request Routing
   system to improve its selection of a CDN surrogate to serve a
   particular User Agent request (or to serve a request from another
   surrogate).  See [I-D.penno-alto-cdn] for a detailed discussion on
   how CDN Request Routing can be used as an integration point of ALTO
   into CDNs.  It is possible that the ALTO service could be used in the
   same manner in a multi-CDN environment based on CDN Interconnect.
   For example, an upstream CDN may take advantage of the ALTO service
   in its decision for selecting a downstream CDN to which a user
   request should be delegated.

   However, the work of ALTO is complementary to and does not overlap
   with the work proposed in this document because the integration
   between ALTO and a CDN would fall under "algorithms for selection of
   CDN or Surrogate by Request-Routing systems" in Section 3.2 and is
   therefore out of scope for a CDNI WG.  One area for further study is
   whether additional information should be provided by an ALTO service
   to facilitate CDNI CDN selection.







Niven-Jenkins, et al.  Expires September 14, 2011              [Page 30]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


7.2.  DECADE

   The DECADE Working Group [DECADE-Charter] is addressing the problem
   of reducing traffic on the last-mile uplink, as well as backbone and
   transit links caused by P2P streaming and file sharing applications.
   It addresses the problem by enabling an application endpoint to make
   content available from an in-network storage service and by enabling
   other application endpoints to retrieve the content from there.

   Exchanging data through the in-network storage service in this
   manner, instead of through direct communication, provides significant
   gain where:

   o  The network capacity/bandwidth from in-network storage service to
      application endpoint significantly exceeds the capacity/bandwidth
      from application endpoint to application endpoint (e.g. because of
      an end-user uplink bottleneck); and
   o  Where the content is to be accessed by multiple instances of
      application endpoints (e.g. as is typically the case for P2P
      applications).

   While, as is the case for any other data distribution application,
   the DECADE architecture and mechanisms could potentially be used for
   exchange of CDNI control plane information via an in-network-storage
   service (as opposed to directly between the entities terminating the
   CDNI protocols in the neighbor CDNs), we observe that:

   o  CDNI would operate as a "Content Distribution Application" from
      the DECADE viewpoint (i.e. would operate on top of DECADE).
   o  There does not seem to be obvious benefits in integrating the
      DECADE control plane responsible for signaling information
      relating to control of the in-network storage service itself, and
      the CDNI control plane responsible for application-specific CDNI
      interactions (such as exchange of CDNI metadata, CDNI request
      redirection, transfer of CDNI logging information).
   o  There would typically be limited benefits in making use of a
      DECADE in-network storage service because the CDNI protocols are
      expected to be terminated by a very small number of CDNI clients
      (if not one) in each CDN, and the CDNI clients are expected to
      benefit from high bandwidth/capacity when communicating directly
      to each other (at least as high as if they were communicating via
      an in-network storage server).

   The DECADE in-network storage architecture and mechanisms may
   theoretically be used for the acquisition of the content objects
   themselves between interconnected CDNs.  It is not expected that this
   would have obvious benefits in typical situations where a content
   object is acquired only once from an Upstream CDN to a Downstream CDN



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 31]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   (and then distributed as needed inside the Downstream CDN).  But it
   might have benefits in some particular situations.  Since the
   acquisition protocol between CDNs is outside the scope of the CDNI
   work, this question is left for further study.

   The DECADE in-network storage architecture and mechanisms may
   potentially also be used within a given CDN for the distribution of
   the content objects themselves among surrogates of that CDN.  Since
   the CDNI work does not concern itself with operation within a CDN,
   this question is left for further study.

   Therefore, the work of DECADE may be complementary to but does not
   overlap with the CDNI work proposed in this document.

7.3.  PPSP

   As stated in the PPSP Working Group charter [PPSP-Charter]:

   "The Peer-to-Peer Streaming Protocol (PPSP) working group develops
   two signaling and control protocols for a peer-to-peer (P2P)
   streaming system for transmitting live and time-shifted media content
   with near real-time delivery requirements." and "The PPSP WG designs
   a protocol for signaling and control between trackers and peers (the
   PPSP "tracker protocol") and a signaling and control protocol for
   communication among the peers (the PPSP "peer protocol").  The two
   protocols enable peers to receive streaming data within the time
   constraints required by specific content items."

   Therefore PPSP is concerned with the distribution of the streamed
   content itself along with the necessary signaling and control
   required to distribute the content.  As such, it could potentially be
   used for the acquisition of streamed content across interconnected
   CDNs.  But since the acquisition protocol is outside the scope of the
   work proposed for CDNI, we leave this for further study.  Also,
   because of its streaming nature, PPSP is not seen as applicable to
   the distribution and control of the CDNI control plane and CDNI data
   representations.

   Therefore, the work of PPSP may be complementary to but does not
   overlap with the work proposed in this document for CDNI.


8.  IANA Considerations

   This document makes no request of IANA.

   Note to RFC Editor: this section may be removed on publication as an
   RFC.



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 32]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


9.  Security Considerations

   Distribution of content by a CDN comes with a range of security
   considerations such as how to enforce control of access to the
   content by users in line with the CSP policy.  These security aspects
   are already dealt with by CDN Providers and CSPs today in the context
   of standalone CDNs.  However, interconnection of CDNs introduces a
   new set of security considerations by extending the trust model (i.e.
   the CSP "trusts" a CDN that "trusts" another CDN).

   Maintaining the security of the content itself, its associated
   metadata (including distribution and delivery policies) and the CDNs
   distributing and delivering it, are critical requirements for both
   CDN Providers and CSPs and any work on CDN Interconnection must
   provide sufficient mechanisms to maintain the security of the overall
   system of interconnected CDNs as well as the information (content,
   metadata, logs, etc) distributed and delivered through any CDN
   Interconnects.


10.  Acknowledgements

   The authors would like to thank Andre Beck, Mark Carlson, Bruce
   Davie, David Ferguson, Yiu Lee, Kevin Ma, Julien Maisonneuve, Guy
   Meador, Emile Stephan, Oskar van Deventer and Mahesh Viveganandhan
   for their review comments and contributions to the text.


11.  References

11.1.  Normative References

   [I-D.bertrand-cdni-experiments]
              Bertrand, G., Faucheur, F., and L. Peterson, "Content
              Distribution Network Interconnection (CDNI) Experiments",
              draft-bertrand-cdni-experiments-00 (work in progress),
              February 2011.

   [I-D.bertrand-cdni-use-cases]
              Bertrand, G., Stephan, E., Watson, G., Burbridge, T., and
              P. Eardley, "Use Cases for Content Distribution Network
              Interconnection", draft-bertrand-cdni-use-cases-01 (work
              in progress), January 2011.

   [I-D.bertrand-cdni-use-cases-00]
              Bertrand, G. and E. Stephan, "Use Cases for Content
              Distribution Network Interconnection -
              draft-bertrand-cdni-use-cases-00 (superseded)",



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 33]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


              January 2011.

   [I-D.jenkins-cdni-names]
              Niven-Jenkins, B., "Thoughts on Naming and Referencing of
              Data Objects within Content Distribution Network
              Interconnection (CDNI) solutions",
              draft-jenkins-cdni-names-00 (work in progress),
              February 2011.

   [I-D.watson-cdni-use-cases]
              Watson, G., "CDN Interconnect Use Cases",
              draft-watson-cdni-use-cases-00 (work in progress),
              January 2011.

   [RFC2119]  Bradner, S., "Key words for use in RFCs to Indicate
              Requirement Levels", BCP 14, RFC 2119, March 1997.

11.2.  Informative References

   [3GP-DASH]
              "Transparent end-to-end Packet-switched Streaming Service
              (PSS); Progressive Download and Dynamic Adaptive Streaming
              over HTTP (3GP-DASH)
              http://www.3gpp.org/ftp/Specs/html-info/26247.htm".

   [ALTO-Charter]
              "IETF ALTO WG Charter
              (http://datatracker.ietf.org/wg/alto/charter/)".

   [ATIS]     "ATIS (http://www.atis.org/)".

   [ATIS-COD]
              "ATIS IIF: IPTV Content on Demand Service, January 2011 ht
              tp://www.atis.org/iif/_Com/Docs/Task_Forces/ARCH/
              ATIS-0800042.pdf".

   [CDI-Charter]
              "IETF CDI WG Charter
              (http://www.ietf.org/wg/concluded/cdi)".

   [CableLabs]
              "CableLabs (http://www.cablelabs.com/about/)".

   [CableLabs-Metadata]
              "CableLabs VoD Metadata Project Primer
              (http://www.cablelabs.com/projects/metadata/primer/)".

   [DECADE-Charter]



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 34]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


              "IETF DECADE WG Charter
              (http://datatracker.ietf.org/wg/decade/charter/)".

   [I-D.penno-alto-cdn]
              Penno, R., Raghunath, S., Medved, J., Alimi, R., Yang, R.,
              and S. Previdi, "ALTO and Content Delivery Networks",
              draft-penno-alto-cdn-02 (work in progress), October 2010.

   [MPEG-DASH]
              "Information technology - MPEG systems technologies - Part
              6: Dynamic adaptive streaming over HTTP (DASH), (DIS
              version), February 2011
              http://mpeg.chiariglione.org/
              working_documents.htm#MPEG-B".

   [OIPF-Overview]
              "OIPF Release 2 Specification Volume 1 - Overview",
              September 2010.

   [P2PRG-CDNI]
              Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka
              "Peering Peer-to-Peer"
              (http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf)",
              March 2010.

   [PPSP-Charter]
              "IETF PPSP WG Charter
              (http://datatracker.ietf.org/wg/ppsp/charter/)".

   [RFC2616]  Fielding, R., Gettys, J., Mogul, J., Frystyk, H.,
              Masinter, L., Leach, P., and T. Berners-Lee, "Hypertext
              Transfer Protocol -- HTTP/1.1", RFC 2616, June 1999.

   [RFC3040]  Cooper, I., Melve, I., and G. Tomlinson, "Internet Web
              Replication and Caching Taxonomy", RFC 3040, January 2001.

   [RFC3466]  Day, M., Cain, B., Tomlinson, G., and P. Rzewski, "A Model
              for Content Internetworking (CDI)", RFC 3466,
              February 2003.

   [RFC3568]  Barbir, A., Cain, B., Nair, R., and O. Spatscheck, "Known
              Content Network (CN) Request-Routing Mechanisms",
              RFC 3568, July 2003.

   [RFC3570]  Rzewski, P., Day, M., and D. Gilletti, "Content
              Internetworking (CDI) Scenarios", RFC 3570, July 2003.

   [RFC3920]  Saint-Andre, P., Ed., "Extensible Messaging and Presence



Niven-Jenkins, et al.  Expires September 14, 2011              [Page 35]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


              Protocol (XMPP): Core", RFC 3920, October 2004.

   [RFC5023]  Gregorio, J. and B. de hOra, "The Atom Publishing
              Protocol", RFC 5023, October 2007.

   [SNIA-CDMI]
              "SNIA CDMI (http://www.snia.org/tech_activities/standards/
              curr_standards/cdmi)".

   [TAXONOMY]
              Pathan, A., "A Taxonomy and Survey of Content Delivery
              Networks
              (http://www.gridbus.org/reports/CDN-Taxonomy.pdf)", 2007.

   [Y.1910]   "ITU-T Recomendation Y.1910 "IPTV functional
              architecture"", September 2008.

   [Y.2019]   "ITU-T Recomendation Y.2019 "Content delivery functional
              architecture in NGN"", September 2010.


Authors' Addresses

   Ben Niven-Jenkins
   Velocix (Alcatel-Lucent)
   326 Cambridge Science Park
   Milton Road, Cambridge  CB4 0WG
   UK

   Email: ben@velocix.com


   Francois Le Faucheur
   Cisco Systems
   Greenside, 400 Avenue de Roumanille
   Sophia Antipolis  06410
   France

   Phone: +33 4 97 23 26 19
   Email: flefauch@cisco.com











Niven-Jenkins, et al.  Expires September 14, 2011              [Page 36]


Internet-Draft    CDN Interconnection Problem Statement       March 2011


   Nabil Bitar
   Verizon
   40 Sylvan Road
   Waltham, MA  02145
   USA

   Email: nabil.bitar@verizon.com












































Niven-Jenkins, et al.  Expires September 14, 2011              [Page 37]


Html markup produced by rfcmarkup 1.129c, available from https://tools.ietf.org/tools/rfcmarkup/