doc: Add RFC documents

1 files changed, 1795 insertions, 0 deletions

diff --git a/doc/rfc/rfc6707.txt b/doc/rfc/rfc6707.txt
new file mode 100644
index 0000000..d302432
--- /dev/null
+++ b/doc/rfc/rfc6707.txt
@@ -0,0 +1,1795 @@
+
+
+
+
+
+
+Internet Engineering Task Force (IETF)                  B. Niven-Jenkins
+Request for Comments: 6707                      Velocix (Alcatel-Lucent)
+Category: Informational                                   F. Le Faucheur
+ISSN: 2070-1721                                                    Cisco
+                                                                N. Bitar
+                                                                 Verizon
+                                                          September 2012
+
+
+ Content Distribution Network Interconnection (CDNI) Problem Statement
+
+Abstract
+
+   Content Delivery Networks (CDNs) provide numerous benefits for
+   cacheable content: reduced delivery cost, 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 is the motivation 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 of CDN
+   Interconnection for the IETF CDNI (CDN Interconnection) working
+   group.
+
+Status of This Memo
+
+   This document is not an Internet Standards Track specification; it is
+   published for informational purposes.
+
+   This document is a product of the Internet Engineering Task Force
+   (IETF).  It represents the consensus of the IETF community.  It has
+   received public review and has been approved for publication by the
+   Internet Engineering Steering Group (IESG).  Not all documents
+   approved by the IESG are a candidate for any level of Internet
+   Standard; see Section 2 of RFC 5741.
+
+   Information about the current status of this document, any errata,
+   and how to provide feedback on it may be obtained at
+   http://www.rfc-editor.org/info/rfc6707.
+
+
+
+
+Niven-Jenkins, et al.         Informational                     [Page 1]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+Copyright Notice
+
+   Copyright (c) 2012 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.
+
+Table of Contents
+
+   1. Introduction ....................................................3
+      1.1. Terminology ................................................4
+      1.2. CDN Background .............................................9
+   2. CDN Interconnection Use Cases ...................................9
+   3. CDN Interconnection Model and Problem Area for IETF ............11
+   4. Scoping the CDNI Problem .......................................15
+      4.1. CDNI Control Interface ....................................16
+      4.2. CDNI Request Routing Interface ............................16
+      4.3. CDNI Metadata Interface ...................................17
+      4.4. CDNI Logging Interface ....................................17
+   5. Security Considerations ........................................17
+      5.1. Security of the CDNI Control Interface ....................18
+      5.2. Security of the CDNI Request Routing Interface ............18
+      5.3. Security of the CDNI Metadata Interface ...................19
+      5.4. Security of the CDNI Logging Interface ....................19
+   6. Acknowledgements ...............................................19
+   7. Informative References .........................................20
+   Appendix A. Design Considerations for Realizing the CDNI
+               Interfaces ............................................22
+     A.1. CDNI Control Interface .....................................22
+     A.2. CDNI Request Routing Interface .............................23
+     A.3. CDNI Metadata Interface ....................................25
+     A.4. CDNI Logging Interface .....................................26
+   Appendix B. Additional Material ...................................27
+     B.1. Non-Goals for IETF .........................................27
+     B.2. Relationship to Relevant IETF Working Groups and IRTF
+          Research Groups ............................................29
+       B.2.1. ALTO WG ................................................29
+       B.2.2. DECADE WG ..............................................29
+       B.2.3. PPSP WG ................................................31
+       B.2.4. IRTF P2P Research Group ................................31
+
+
+
+Niven-Jenkins, et al.         Informational                     [Page 2]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+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 for cacheable content: reduced
+   delivery cost, improved quality of experience for End Users (EUs),
+   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 EU regardless of that EU's location or the network they are
+   attached to.  However, a given CDN in charge of delivering a given
+   content may not have a footprint that expands close enough to the
+   EU's current location or attachment network, or may not have the
+   necessary resources, to realize the user experience and cost benefit
+   that a more distributed CDN infrastructure would allow.  This is the
+   motivation for interconnecting standalone CDNs so that their
+   collective CDN footprint and resources can be leveraged for the
+   end-to-end delivery of content from Content Service Providers (CSPs)
+   to EUs.  As an example, a CSP could contract with an "authoritative"
+   CDN Provider for the delivery of content, and that Authoritative CDN
+   Provider could contract with one or more downstream CDN Providers to
+   distribute and deliver some or all of the content on behalf of the
+   Authoritative CDN Provider.
+
+   A typical end-to-end content delivery scenario would then involve the
+   following business arrangements:
+
+   o  A business arrangement between the EU and his CSP, authorizing
+      access by the EU to content items controlled by the CSP.
+
+   o  A business arrangement between the CSP and an "authoritative" CDN
+      Provider where the CSP mandates that the CDN Provider perform the
+      content delivery on behalf of the CSP.
+
+   o  A business arrangement between the Authoritative CDN Provider and
+      another (or other) CDN(s) where the Authoritative CDN may delegate
+      the actual serving of some of the content delivery requests to the
+      other CDN(s).  A particular case is where this other CDN Provider
+      happens to also be the Network Service Provider providing network
+      access to the EU, in which case there is also a separate and
+      independent business relationship between the EU and the NSP for
+      the corresponding network access.
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                     [Page 3]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   The formation and details of any business relationships between a CSP
+   and a CDN Provider as well as between one CDN Provider and another
+   CDN Provider are out of scope of this document.  However, this
+   document concerns itself with the fact that no standards or open
+   specifications currently exist to facilitate such CDN Interconnection
+   from a technical perspective.
+
+   One possible flow for performing an end-to-end content delivery
+   across a CDN Interconnection is described below:
+
+   o  The initial content request from an EU's User Agent is first
+      received by the authoritative (upstream) CDN, which is the CDN
+      with a business arrangement with the CSP.
+
+   o  The authoritative (upstream) CDN may serve the request itself, or
+      it may elect to use CDN Interconnection to redirect the request to
+      a Downstream CDN that is in a better position to do so (e.g., a
+      Downstream CDN that is "closer" to the EU).
+
+   o  The EU's User Agent will "follow" the redirect returned by the
+      Authoritative CDN and request the content from the Downstream CDN.
+      If required, the Downstream CDN will acquire the requested content
+      from the authoritative (upstream) CDN, and if necessary the
+      Authoritative CDN will acquire the requested content from the
+      Content Service Provider.
+
+   The goal of this document is to outline the problem area of CDN
+   Interconnection.  Section 2 discusses the use cases for CDN
+   Interconnection.  Section 3 presents the CDNI model and problem area
+   being considered by the IETF.  Section 4 describes each CDNI
+   interface individually and highlights example candidate protocols
+   that could be considered for reuse or leveraging to implement the
+   CDNI interfaces.  Appendix B.2 describes the relationships between
+   the CDNI problem space and other relevant IETF working groups and
+   IRTF research groups.
+
+1.1.  Terminology
+
+   This document uses the following terms:
+
+   Authoritative CDN: A CDN that has a direct relationship with a CSP
+   for the distribution and delivery of that CSP's content by the
+   Authoritative CDN or by Downstream CDNs of the Authoritative CDN.
+
+   CDN Interconnection (CDNI): A relationship between a pair of CDNs
+   that enables one CDN to provide content delivery services on behalf
+   of another CDN.  A CDN Interconnection may be wholly or partially
+   realized through a set of interfaces over which a pair of CDNs
+
+
+
+Niven-Jenkins, et al.         Informational                     [Page 4]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   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).
+
+   CDN Provider: The service provider who operates a CDN and offers a
+   service of content delivery, typically used by a Content Service
+   Provider or another CDN Provider.  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.
+
+   CDNI Metadata: The subset of Content Distribution Metadata that
+   has an 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., pre-positioned vs dynamic acquisition) and about where/
+   how a CDN can acquire the content.
+
+   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).
+
+   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 may have an inter-CDN scope (and
+   therefore needs to be communicated between CDNs).
+
+   Content Distribution Network (CDN) / Content Delivery Network (CDN):
+   Network infrastructure in which the network elements cooperate at
+   Layers 4 through 7 for more effective delivery of Content to 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.
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                     [Page 5]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   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 or content
+       representation, and not directly relevant to the distribution of
+       that Content.  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 Service: The service offered by a Content Service Provider.
+   The Content Service encompasses the complete service, which may be
+   wider than just providing access to items of Content; e.g., the
+   Content Service also includes any middleware, key distribution,
+   program guide, etc. that may not require any direct interaction with
+   the CDN, or CDNs, involved in the distribution and delivery of the
+   content.
+
+   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.
+
+   Control system: The function within a CDN responsible for
+   bootstrapping and controlling the other components of the CDN as well
+   as for handling interactions with external systems (e.g., handling
+   delivery service creation/update/removal requests, or specific
+   service provisioning requests).
+
+   Delivery: The function within CDN Surrogates responsible for
+   delivering a piece of content to the User Agent.  For example,
+   delivery may be based on HTTP progressive download or HTTP adaptive
+   streaming.
+
+   Distribution system: The function within a CDN responsible for
+   distributing Content Distribution Metadata as well as the Content
+   itself inside the CDN (e.g., down to the Surrogates).
+
+   Downstream CDN: For a given End 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
+
+
+
+Niven-Jenkins, et al.         Informational                     [Page 6]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   (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).
+
+   Dynamic CDNI Metadata acquisition: In the context of CDN
+   Interconnection, dynamic CDNI Metadata acquisition means that a
+   Downstream CDN acquires CDNI Metadata for content from the Upstream
+   CDN at some point in time after a request for that content is
+   delegated to the Downstream CDN by an Upstream CDN (and that specific
+   CDNI Metadata is not yet available in the Downstream CDN).  See also
+   the definitions for Downstream CDN and Upstream CDN.
+
+   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
+   Interconnection, dynamic acquisition means that a Downstream CDN
+   acquires the content from content sources (including Upstream CDNs)
+   at some point in time after a request for that content is delegated
+   to the Downstream CDN by an Upstream CDN (and that specific content
+   is not yet available in 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.).
+
+   Logging system: The function within a CDN responsible for collecting
+   the 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.
+
+   Metadata: Metadata in general is data about data.
+
+   Network Service Provider (NSP): Provides network-based connectivity/
+   services to End Users.
+
+   Over-the-top (OTT): A service, e.g., content delivery using a CDN,
+   operated by a different operator than the NSP to which the users of
+   that service are attached.
+
+   Pre-positioned CDNI Metadata acquisition: In the context of CDN
+   Interconnection, CDNI Metadata pre-positioning is where the
+   Downstream CDN acquires CDNI Metadata for content prior to, or
+   independently of, any End User requesting that content from the
+   Downstream CDN.
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                     [Page 7]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   Pre-positioned content acquisition: Content pre-positioning is where
+   a CDN acquires content from the content source prior to, or
+   independently of, any End User requesting that content from the CDN.
+   In the context of CDN Interconnection, the Upstream CDN instructs the
+   Downstream CDN to acquire the content from content sources (including
+   Upstream CDNs) in advance of, or independently of, any End User
+   requesting it.
+
+   Quality of Experience (QoE): As defined in Section 2.4 of [RFC6390].
+
+   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 Interconnection, the
+   Request Routing system must also be capable of handling User Agent
+   Content Requests passed to it by another CDN.
+
+   Surrogate: A device/function (often called a cache) 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.  Typically, Surrogates will cache requested
+   content so that they can directly deliver the same content in
+   response to requests from multiple User Agents (and their End Users),
+   avoiding the need for the content to transit multiple times through
+   the network core (i.e., from the content origin to the Surrogate).
+
+   Upstream CDN: For a given End User request, the CDN (within a pair of
+   directly interconnected CDNs) that redirects the request to the
+   other CDN.
+
+   User Agent (UA): Software (or a combination of hardware and software)
+   through which the End User interacts with a Content Service.  The
+   User Agent will communicate with a Content 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 (STBs), dedicated content applications (e.g., media
+   players), etc.
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                     [Page 8]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+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 Distribution Internetworking (CDI) working group,
+      which was closed in 2003.
+
+   Note: Some of the terms used in this document are similar to terms
+   used in the above referenced documents.  When reading this document,
+   terms should be interpreted as having the definitions provided in
+   Section 1.1.
+
+2.  CDN Interconnection 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 of a network 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 in 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
+   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
+
+
+
+
+Niven-Jenkins, et al.         Informational                     [Page 9]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   need for interconnection of these CDNs; this represents a first use
+   case for CDNI.  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 numbers of End Users, who are often distributed across a number
+   of geographies, while maintaining 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.  This represents a second use case for
+   CDNI.  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, CDN
+   Providers (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, representing a third use case for CDNI.
+   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), which results in a fourth use case for CDNI
+   because CDN Providers (over-the-top CDN Providers or NSPs) are faced
+   with a lack of open specifications and best practices.
+
+   Use cases for CDN Interconnection are further discussed in
+   [CDNI-USE-CASES].
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 10]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+3.  CDN Interconnection Model and Problem Area for IETF
+
+   This section discusses the problem area for the IETF work on CDN
+   Interconnection.
+
+   Interconnecting CDNs involves interactions among multiple different
+   functions and components that form each CDN.  Only some of those
+   require additional specification by the IETF.
+
+   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
+   [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 with the necessary level of
+   functionality such as those discussed in this document is preventing
+   the deployment of CDN Interconnection.
+
+   Listed below are the four interfaces required to interconnect a pair
+   of CDNs and that constitute the problem space of CDN Interconnection
+   along with the required functionality of each interface for which
+   standards do not currently exist.  As part of the development of the
+   CDNI interfaces, 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.
+
+   The use of the term "interface" is meant to encompass the protocol
+   over which CDNI data representations (e.g., CDNI Metadata objects)
+   are exchanged as well as the specification of the data
+   representations themselves (i.e., what properties/fields each object
+   contains, its structure, etc.).
+
+   o  CDNI Control interface: This interface allows the "CDNI Control"
+      system in interconnected CDNs to communicate.  This interface may
+      support the following:
+
+      *  Allow bootstrapping of the other CDNI interfaces (e.g.,
+         interface address/URL discovery and establishment of security
+         associations).
+
+      *  Allow configuration of the other CDNI interfaces (e.g.,
+         Upstream CDN specifies information to be reported through the
+         CDNI Logging interface).
+
+      *  Allow the Downstream CDN to communicate static (or fairly
+         static) information about its delivery capabilities and
+         policies.
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 11]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+      *  Allow bootstrapping of the interface between CDNs for content
+         acquisition (even if that interface itself is outside the scope
+         of the CDNI work).
+
+      *  Allow an Upstream CDN to initiate or request specific actions
+         to be undertaken in the Downstream CDN.  For example, to allow
+         an Upstream CDN to initiate content or CDNI Metadata
+         acquisition (pre-positioning) or to request the invalidation
+         or purging of content files and/or CDNI Metadata in a
+         Downstream CDN.
+
+   o  CDNI Request Routing interface: This interface allows the Request
+      Routing systems 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,
+      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 Downstream CDN).  In particular, the
+      functions of the CDN Request Routing interface may be divided as
+      follows:
+
+      *  A CDNI Request Routing Redirection interface, which allows the
+         Upstream CDN to query the Downstream CDN at request routing
+         time before redirecting the request to the Downstream CDN.
+
+      *  A CDNI Footprint & Capabilities advertisement interface, which
+         allows 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 interface: This interface allows the Distribution
+      system in interconnected CDNs to communicate to ensure that CDNI
+      Metadata can be exchanged across CDNs.  See Section 1.1 for the
+      definition and examples of CDNI Metadata.
+
+   o  CDNI Logging interface: This interface 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 environment.  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.
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 12]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   Note that the actual grouping of functionalities under these four
+   interfaces is considered tentative at this stage and may be changed
+   after further study (e.g., some subset of functionality may be moved
+   from one interface 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 interfaces need not be defined from scratch and instead can
+   reuse or leverage existing protocols to a very significant extent;
+   this is discussed further in Section 4.
+
+   The interfaces that form the CDNI problem area are illustrated in
+   Figure 1.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 13]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+     --------
+    /        \
+    |   CSP  |
+    \        /
+     --------
+         *
+         *
+         *                         /\
+         *                        /  \
+     ----------------------      |CDNI|        ----------------------
+    /     Upstream CDN     \     |    |       /    Downstream CDN    \
+    |      +-------------+ | Control Interface| +-------------+      |
+    |*******   Control   |<======|====|========>|   Control   *******|
+    |*     +------*----*-+ |     |    |       | +-*----*------+     *|
+    |*            *    *   |     |    |       |   *    *            *|
+    |*     +------*------+ | Logging Interface| +------*------+     *|
+    |* *****   Logging   |<======|====|========>|   Logging   ***** *|
+    |* *   +-*-----------+ |     |    |       | +-----------*-+   * *|
+    |* *     *         *   | Request Routing  |   *         *     * *|
+  .....*...+-*---------*-+ |    Interface     | +-*---------*-+...*.*...
+  . |* * *** Req-Routing |<======|====|========>| Req-Routing *** * *| .
+  . |* * * +-------------+.|     |    |       | +-------------+ * * *| .
+  . |* * *                 .  CDNI Metadata   |                 * * *| .
+  . |* * * +-------------+ |.   Interface     | +-------------+ * * *| .
+  . |* * * | Distribution|<==.===|====|========>| Distribution| * * *| .
+  . |* * * |             | |  .   \  /        | |             | * * *| .
+  . |* * * |+---------+  | |   .   \/         | |  +---------+| * * *| .
+  . |* * ***| +---------+| |    ....Request......+---------+ |*** * *| .
+  . |* *****+-|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: A Model for the CDNI Problem Area
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 14]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   As illustrated in Figure 1, the acquisition of content between
+   interconnected CDNs is out of scope for CDNI; this deserves some
+   additional explanation.  The consequence of such a decision is that
+   the CDNI problem space described in this document is focused on only
+   defining the control plane for CDNI, and the CDNI data plane (i.e.,
+   the acquisition and distribution of the actual content objects) is
+   out of scope.  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
+   with respect to content acquisition from specifications developed by
+   the CDNI working group is to describe within the CDNI Metadata the
+   parameters to use to retrieve the content -- for example, the IP
+   address/hostname to connect to, what protocol to use to retrieve the
+   content, etc.
+
+4.  Scoping the CDNI Problem
+
+   This section outlines how the scope of work addressing the CDNI
+   problem space can be constrained through reuse or leveraging of
+   existing protocols to implement the CDNI interfaces.  This discussion
+   is not intended to preempt any working group decision as to the most
+   appropriate protocols, technologies, and solutions to select to
+   realize the CDNI interfaces but is intended as an illustration of the
+   fact that the CDNI interfaces need not be created in a vacuum and
+   that reuse or leverage of existing protocols is likely possible.
+
+   The four CDNI interfaces (CDNI Control interface, CDNI Request
+   Routing interface, CDNI Metadata interface, and CDNI Logging
+   interface) described in Section 3 within the CDNI problem area are
+   all control plane interfaces operating at the application layer
+   (Layer 7 in the OSI network model).  Firstly, since it is not
+   expected that these interfaces 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
+   interfaces will be defined on top of existing session, transport, and
+   network protocols.
+
+   Secondly, although a new application protocol could be designed
+   specifically for CDNI, our analysis below shows that this is
+   unnecessary, and it is recommended that existing application
+   protocols be reused or leveraged (HTTP [RFC2616], the Atom Publishing
+   Protocol [RFC5023], the Extensible Messaging and Presence Protocol
+   (XMPP) [RFC6120], for example) to realize the CDNI interfaces.
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 15]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+4.1.  CDNI Control Interface
+
+   The CDNI Control interface allows the Control system in
+   interconnected CDNs to communicate.  The exact inter-CDN control
+   functionality required to be supported by the CDNI Control interface
+   is less well defined than the other three CDNI interfaces at this
+   time.
+
+   It is expected that for the Control interface, as for the other CDNI
+   interfaces, existing protocols can be reused or leveraged.
+
+4.2.  CDNI Request Routing Interface
+
+   The CDNI Request Routing interface 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.  It also allows the
+   Downstream CDN to control what should be returned to the User Agent
+   in the redirection message by the upstream Request Routing function.
+
+   The CDNI Request Routing interface is therefore a fairly
+   straightforward request/response interface 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 (Extensible Markup Language-Remote Procedure Calling
+   (XML-RPC), HTTP query to a known URI, etc.).  This removes the need
+   for the CDNI working group to define a new protocol for the request/
+   response element of the CDNI Request Routing interface.
+
+   Additionally, as discussed in Section 3, the CDNI Request Routing
+   interface is also expected to enable a 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.  It is expected that such
+   functionality of the CDNI request routing could be specified by the
+   CDNI working group with significant leveraging of existing IETF
+   protocols supporting the dynamic distribution of reachability
+   information (for example, by leveraging existing routing protocols)
+   or supporting application-level queries for topological information
+   (for example, by leveraging Application-Layer Traffic Optimization
+   (ALTO) [RFC5693]).
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 16]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+4.3.  CDNI Metadata Interface
+
+   The CDNI Metadata interface enables the Distribution system in a
+   Downstream CDN to request CDNI Metadata from an Upstream CDN so that
+   the Downstream CDN can properly process and respond to redirection
+   requests received over the CDNI Request Routing interface and Content
+   Requests received directly from User Agents.
+
+   The CDNI Metadata interface is therefore similar to the CDNI Request
+   Routing interface because it is a request/response interface 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 interface, the CDNI Metadata
+   interface 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 [RFC6120].
+   This removes the need for the CDNI working group to define a new
+   protocol for the request/response element of the CDNI Metadata
+   interface.
+
+4.4.  CDNI Logging Interface
+
+   The CDNI Logging interface enables details of content distribution
+   and delivery activities to be exchanged between interconnected CDNs
+   -- for example, the exchange of log records related to the delivery
+   of content, similar to the log records recorded in a web server's
+   access log.
+
+   Several protocols already exist that could potentially be used to
+   exchange CDNI logs between interconnected CDNs, including the Simple
+   Network Management Protocol (SNMP), syslog, FTP (and secure
+   variants), HTTP POST, etc.
+
+5.  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 End Users in line with the CSP policy, or how to trust the
+   logging information generated by the CDN for the purposes of charging
+   the CSP.  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 to a chain of trust
+   (i.e., the CSP "trusts" a CDN that "trusts" another CDN).  The
+   mechanisms used to mitigate these risks in multi-CDN environments may
+   be similar to those used in the single-CDN case, but their
+   suitability in this more complex environment must be validated.
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 17]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   The interconnection of CDNs may also introduce additional privacy
+   considerations on top of those that apply to the single-CDN case.  In
+   a multi-CDN environment, the different CDNs may reside in different
+   legal regimes that require differing privacy requirements to be
+   enforced.  Such privacy requirements may impact the granularity of
+   information that can be exchanged across the CDNI interfaces.  For
+   example, the Logging system in a Downstream CDN may need to apply
+   some degree of anonymization, obfuscation, or even the complete
+   removal of some fields before exchanging log records containing
+   details of End User deliveries with an Upstream CDN.
+
+   Maintaining the security of the content itself, its associated
+   metadata (including delivery policies), and the CDNs distributing and
+   delivering it, are critical requirements for both CDN Providers and
+   CSPs, and the CDN Interconnection interfaces 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 set of
+   interconnected CDNs.
+
+5.1.  Security of the CDNI Control Interface
+
+   Information exchanged between interconnected CDNs over this interface
+   is of a sensitive nature.  A pair of CDNs use this interface to allow
+   bootstrapping of all the other CDNI interfaces, possibly including
+   establishment of the mechanisms for securing these interfaces.
+   Therefore, corruption of that interface may result in corruption of
+   all other interfaces.  Using this interface, an Upstream CDN may
+   pre-position or delete content or metadata in a Downstream CDN, a
+   Downstream CDN may provide administrative information to an Upstream
+   CDN, etc.  All of these operations require that the peer CDNs are
+   appropriately authenticated and that the confidentiality and
+   integrity of information flowing between them can be ensured.
+
+5.2.  Security of the CDNI Request Routing Interface
+
+   Appropriate levels of authentication and confidentiality must be used
+   in this interface because it allows an Upstream CDN to query the
+   Downstream CDN in order to redirect requests, and conversely, allows
+   the Downstream CDN to influence the Upstream CDN's Request Routing
+   function.
+
+   In the absence of appropriate security on this interface, a rogue
+   Upstream CDN could inundate Downstream CDNs with bogus requests or
+   have the Downstream CDN send the rogue Upstream CDN private
+   information.  Also, a rogue Downstream CDN could influence the
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 18]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   Upstream CDN so the Upstream CDN redirects requests to the rogue
+   Downstream CDN or another Downstream CDN in order to, for example,
+   attract additional delivery revenue.
+
+5.3.  Security of the CDNI Metadata Interface
+
+   This interface allows a Downstream CDN to request CDNI Metadata from
+   an Upstream CDN, and therefore the Upstream CDN must ensure that the
+   former is appropriately authenticated before sending the data.
+   Conversely, a Downstream CDN must authenticate an Upstream CDN before
+   requesting metadata to insulate itself from poisoning by rogue
+   Upstream CDNs.  The confidentiality and integrity of the information
+   exchanged between the peers must be protected.
+
+5.4.  Security of the CDNI Logging Interface
+
+   Logging data consists of potentially sensitive information (which End
+   User accessed which media resource, IP addresses of End Users,
+   potential names and subscriber account information, etc.).
+   Confidentiality of this information must be protected as log records
+   are moved between CDNs.  This information may also be sensitive from
+   the viewpoint that it can be the basis for charging across CDNs.
+   Therefore, appropriate levels of protection are needed against
+   corruption, duplication, and loss of this information.
+
+6.  Acknowledgements
+
+   The authors would like to thank Andre Beck, Gilles Bertrand, Mark
+   Carlson, Bruce Davie, David Ferguson, Yiu Lee, Kent Leung, Will Li,
+   Kevin Ma, Julien Maisonneuve, Guy Meador, Larry Peterson, Emile
+   Stephan, Oskar van Deventer, Mahesh Viveganandhan, and Richard Woundy
+   for their review comments and contributions to the text.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 19]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+7.  Informative References
+
+   [ALTO-CDN-USE-CASES]
+              Niven-Jenkins, B., Ed., Watson, G., Bitar, N., Medved, J.,
+              and S. Previdi, "Use Cases for ALTO within CDNs", Work
+              in Progress, June 2012.
+
+   [ALTO-Charter]
+              "IETF ALTO WG Charter",
+              <http://datatracker.ietf.org/wg/alto/charter/>.
+
+   [CDNI-EXPERIMENTS]
+              Bertrand, G., Ed., Le Faucheur, F., and L. Peterson,
+              "Content Distribution Network Interconnection (CDNI)
+              Experiments", Work in Progress, February 2012.
+
+   [CDNI-USE-CASES]
+              Bertrand, G., Ed., Emile, S., Burbridge, T., Eardley, P.,
+              Ma, K., and G. Watson, "Use Cases for Content Delivery
+              Network Interconnection", Work in Progress, August 2012.
+
+   [DECADE-Charter]
+              "IETF DECADE WG Charter",
+              <http://datatracker.ietf.org/wg/decade/charter/>.
+
+   [P2PRG-CDNI]
+              Davie, B. and F. Le Faucheur, "Interconnecting CDNs aka
+              'Peering Peer-to-Peer'", March 2010,
+              <http://www.ietf.org/proceedings/77/slides/P2PRG-2.pdf>.
+
+   [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.
+
+   [RFC3570]  Rzewski, P., Day, M., and D. Gilletti, "Content
+              Internetworking (CDI) Scenarios", RFC 3570, July 2003.
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 20]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   [RFC5023]  Gregorio, J., Ed., and B. de hOra, Ed., "The Atom
+              Publishing Protocol", RFC 5023, October 2007.
+
+   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
+              Optimization (ALTO) Problem Statement", RFC 5693,
+              October 2009.
+
+   [RFC6120]  Saint-Andre, P., "Extensible Messaging and Presence
+              Protocol (XMPP): Core", RFC 6120, March 2011.
+
+   [RFC6390]  Clark, A. and B. Claise, "Guidelines for Considering New
+              Performance Metric Development", BCP 170, RFC 6390,
+              October 2011.
+
+   [TAXONOMY] Pathan, A. and R. Buyya, "A Taxonomy and Survey of Content
+              Delivery Networks", 2007,
+              <http://www.cloudbus.org/reports/CDN-Taxonomy.pdf>.
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 21]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+Appendix A.  Design Considerations for Realizing the CDNI Interfaces
+
+   This section expands on how CDNI interfaces can reuse and leverage
+   existing protocols before describing each CDNI interface individually
+   and highlighting example candidate protocols that could be considered
+   for reuse or leveraging to implement the CDNI interfaces.  However,
+   the options discussed here are purely examples and do not present any
+   consensus on protocols to be used later on.
+
+A.1.  CDNI Control Interface
+
+   The CDNI Control interface allows the Control system in
+   interconnected CDNs to communicate.  The exact inter-CDN control
+   functionality required to be supported by the CDNI Control interface
+   is less well defined than the other three CDNI interfaces at this
+   time.
+
+   However, as discussed in Section 3, the CDNI Control interface 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 interfaces (e.g., protocol
+      address discovery and establishment of security associations).
+
+   o  Allow configuration of the other CDNI interfaces (e.g., Upstream
+      CDN specifies information to be reported through the CDNI Logging
+      interface).
+
+   o  Allow the Downstream CDN to communicate static 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 interface, as for the other CDNI
+   interfaces, existing protocols can be reused or leveraged.  Those
+   will be considered once the requirements for the Control interface
+   have been refined.
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 22]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+A.2.  CDNI Request Routing Interface
+
+   The CDNI Request Routing interface 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.
+
+   Therefore, the CDNI Request Routing interface needs to offer a
+   mechanism for an Upstream CDN to issue a "Redirection Request" to a
+   Downstream CDN.  The Request Routing interface 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, the Real Time Streaming Protocol
+   (RTSP), the Real Time Messaging Protocol (RTMP), etc.).
+
+   Therefore, a Redirection Request is expected 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
+      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 is expected to
+      include the User Agent's IP address, the equivalent of the HTTP
+      Host header, and the equivalent of the HTTP abs_path as 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 the
+   corresponding User Agent request because, for example:
+
+   o  User Agents (or DNS resolvers) may cache DNS or application
+      responses from Request Routers.
+
+   o  Responses to Redirection Requests over the Request Routing
+      interface may be cacheable.
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 23]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   o  Some CDNs may rely on simple coarse policies, e.g., CDN B agrees
+      to always serve CDN A's delegated redirection requests, in which
+      case the necessary redirection details are exchanged out of band
+      (of the CDNI interfaces), 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 is expected 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
+      information necessary to construct the application-specific
+      redirection response(s) to return to the requesting User Agent.
+      For HTTP requests from User Agents, this could include a URI that
+      the Upstream CDN could return in an HTTP 3xx response.
+
+   The CDNI Request Routing interface is therefore a fairly
+   straightforward request/response interface 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 the CDNI working group to define a new protocol
+   for the request/response element of the CDNI Request Routing
+   interface.  Thus, the CDNI working group 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 interface (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.
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 24]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   Additionally, as discussed in Section 3, the CDNI Request Routing
+   interface is also expected to enable a 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.  It is expected that such
+   functionality of the CDNI request routing could be specified by the
+   CDNI working group with significant leveraging of existing IETF
+   protocols supporting the dynamic distribution of reachability
+   information (for example, by leveraging existing routing protocols)
+   or supporting application-level queries for topological information
+   (for example, by leveraging ALTO).
+
+A.3.  CDNI Metadata Interface
+
+   The CDNI Metadata interface enables the Distribution system 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
+      interface.
+
+   o  Content Requests received directly from User Agents.
+
+   The CDNI Metadata interface 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 objects.
+
+   o  Make recursive requests for CDNI Metadata -- for example, to
+      enable a Downstream CDN to walk down a tree of objects with
+      inter-object relationships.
+
+   The CDNI Metadata interface is therefore similar to the CDNI Request
+   Routing interface because it is a request/response interface 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 interface, the CDNI Metadata
+   interface 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 [RFC6120].
+   This removes the need for the CDNI working group to define a new
+   protocol for the request/response element of the CDNI Metadata
+   interface.
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 25]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   Thus, the CDNI working group 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
+      interface (e.g., handling of malformed requests/responses).
+
+   o  The syntax (i.e., representation/encoding) of the CDNI Metadata
+      objects that will be exchanged over the interface.
+
+   o  The semantics (i.e., meaning and expected contents) of the
+      individual properties of a Metadata object.
+
+   o  How the relationships between different CDNI Metadata objects are
+      represented.
+
+A.4.  CDNI Logging Interface
+
+   The CDNI Logging interface enables details of content distribution
+   and delivery activities to be exchanged between interconnected CDNs,
+   such as log records related to the delivery of content (similar to
+   the log records recorded in a web server's access log).
+
+   Within CDNs today, log records are used for a variety of purposes.
+   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 applications place requirements
+   on the CDNI Logging interface 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.
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 26]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   Although it is not necessary to define a new protocol for exchanging
+   logs across the CDNI Logging interface, the CDNI working group would
+   still need to specify:
+
+   o  The recommended protocol to use.
+
+   o  A default set of log fields and of their syntax and 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 conditions that trigger log records to be
+      generated.
+
+Appendix B.  Additional Material
+
+   This section records related information that was produced as part of
+   defining the CDNI problem statement.
+
+B.1.  Non-Goals for IETF
+
+   Listed below are aspects of content delivery that the authors propose
+   be kept outside of the scope of the CDNI working group:
+
+   o  The interface between the 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 interface 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 the Alliance for Telecommunications Industry
+      Solutions IPTV Interoperability Forum Content on Demand service
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 27]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+      (ATIS IIF CoD)).  The CDN Interconnection problem space described
+      in this document may therefore 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
+      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 interfaces and protocols (i.e., interfaces and
+      protocols within one CDN).
+
+   o  Scalability of individual CDNs.  While scalability of the CDNI
+      interfaces/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.
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 28]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+B.2.  Relationship to Relevant IETF Working Groups and IRTF Research
+      Groups
+
+B.2.1.  ALTO WG
+
+   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 working group 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).  [ALTO-CDN-USE-CASES] describes a number of use cases for
+   a CDN to be able to obtain network topology and cost information from
+   an ALTO server(s) and discusses how CDN Request Routing could 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 Interconnection.  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 current work of ALTO is complementary to and does not
+   overlap with the work described in this document because the
+   integration between ALTO and a CDN is an internal decision for a
+   specific CDN and is therefore out of scope for the CDNI working
+   group.  One area for further study is whether additional information
+   should be provided by an ALTO service to facilitate CDNI CDN
+   selection.
+
+B.2.2.  DECADE WG
+
+   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 peer-to-peer (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.
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 29]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   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 the in-network storage service
+      to the application endpoint significantly exceeds the capacity/
+      bandwidth from application endpoint to application endpoint (e.g.,
+      because of an end-user uplink bottleneck); and
+
+   o  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 interfaces 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 do 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, and 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 interfaces 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
+   (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.
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 30]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+   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 described in this document.
+
+B.2.3.  PPSP WG
+
+   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...
+
+      ...  The PPSP working group 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 described in this document for CDNI.
+
+B.2.4.  IRTF P2P Research Group
+
+   Some information on CDN Interconnection motivations and technical
+   issues were presented in the P2P research group at IETF 77.  The
+   presentation can be found in [P2PRG-CDNI].
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 31]
+
+RFC 6707          CDN Interconnection Problem Statement   September 2012
+
+
+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
+
+
+   Nabil Bitar
+   Verizon
+   60 Sylvan Road
+   Waltham, MA  02145
+   USA
+
+   EMail: nabil.n.bitar@verizon.com
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+
+Niven-Jenkins, et al.         Informational                    [Page 32]
+