tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Glossaries     Architecture     IMS     UICC    |    search     info

RFC 7336

Informational
Pages: 58
Top     in Index     Prev     Next
in Group Index     Prev in Group     Next in Group     Group: CDNI

Framework for Content Distribution Network Interconnection (CDNI)

Part 1 of 4, p. 1 to 12
None       Next RFC Part

Obsoletes:    3466


Top       ToC       Page 1 
Internet Engineering Task Force (IETF)                       L. Peterson
Request for Comments: 7336                     Akamai Technologies, Inc.
Obsoletes: 3466                                                 B. Davie
Category: Informational                                     VMware, Inc.
ISSN: 2070-1721                                  R. van Brandenburg, Ed.
                                                                     TNO
                                                             August 2014


   Framework for Content Distribution Network Interconnection (CDNI)

Abstract

   This document presents a framework for Content Distribution Network
   Interconnection (CDNI).  The purpose of the framework is to provide
   an overall picture of the problem space of CDNI and to describe the
   relationships among the various components necessary to interconnect
   CDNs.  CDNI requires the specification of interfaces and mechanisms
   to address issues such as request routing, distribution metadata
   exchange, and logging information exchange across CDNs.  The intent
   of this document is to outline what each interface needs to
   accomplish and to describe how these interfaces and mechanisms fit
   together, while leaving their detailed specification to other
   documents.  This document, in combination with RFC 6707, obsoletes
   RFC 3466.

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

Page 2 
Copyright Notice

   Copyright (c) 2014 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.

Top       Page 3 
Table of Contents

   1. Introduction ....................................................4
      1.1. Terminology ................................................4
      1.2. Reference Model ............................................6
      1.3. Structure of This Document ................................10
   2. Building Blocks ................................................10
      2.1. Request Redirection .......................................10
           2.1.1. DNS Redirection ....................................10
           2.1.2. HTTP Redirection ...................................12
   3. Overview of CDNI Operation .....................................12
      3.1. Preliminaries .............................................14
      3.2. Iterative HTTP Redirect Example ...........................15
      3.3. Recursive HTTP Redirection Example ........................21
      3.4. Iterative DNS-Based Redirection Example ...................25
           3.4.1. Notes on Using DNSSEC ..............................28
      3.5. Dynamic Footprint Discovery Example .......................29
      3.6. Content Removal Example ...................................31
      3.7. Pre-positioned Content Acquisition Example ................32
      3.8. Asynchronous CDNI Metadata Example ........................33
      3.9. Synchronous CDNI Metadata Acquisition Example .............35
      3.10. Content and Metadata Acquisition with Multiple
            Upstream CDNs ............................................37
   4. Main Interfaces ................................................38
      4.1. In-Band versus Out-of-Band Interfaces .....................39
      4.2. Cross-Interface Concerns ..................................40
      4.3. Request Routing Interfaces ................................40
      4.4. CDNI Logging Interface ....................................41
      4.5. CDNI Control Interface ....................................43
      4.6. CDNI Metadata Interface ...................................43
      4.7. HTTP Adaptive Streaming Concerns ..........................44
      4.8. URI Rewriting .............................................46
   5. Deployment Models ..............................................47
      5.1. Meshed CDNs ...............................................47
      5.2. CSP Combined with CDN .....................................48
      5.3. CSP Using CDNI Request Routing Interface ..................49
      5.4. CDN Federations and CDN Exchanges .........................50
   6. Trust Model ....................................................53
   7. Privacy Considerations .........................................54
   8. Security Considerations ........................................55
      8.1. Security of CDNI Interfaces ...............................56
      8.2. Digital Rights Management .................................56
   9. Contributors ...................................................56
   10. Acknowledgements ..............................................57
   11. Informative References ........................................57

Top      ToC       Page 4 
1.  Introduction

   This document provides an overview of the various components
   necessary to interconnect CDNs, expanding on the problem statement
   and use cases introduced in [RFC6770] and [RFC6707].  It describes
   the necessary interfaces and mechanisms in general terms and outlines
   how they fit together to form a complete system for CDN
   Interconnection.  Detailed specifications are left to other
   documents.  This document makes extensive use of message flow
   examples to illustrate the operation of interconnected CDNs, but
   these examples should be considered illustrative rather than
   prescriptive.

   [RFC3466] uses different terminology and models for "Content
   (distribution) Internetworking (CDI)".  It is also less prescriptive
   in terms of interfaces.  To avoid confusion, this document obsoletes
   [RFC3466].

1.1.  Terminology

   This document uses the core terminology defined in [RFC6707].  It
   also introduces the following terms:

   CDN-Domain:  a hostname (Fully Qualified Domain Name -- FQDN) at the
      beginning of a URL (excluding port and scheme), representing a set
      of content that is served by a given CDN.  For example, in the URL
      http://cdn.csp.example/...rest of URL..., the CDN-Domain is
      cdn.csp.example.  A major role of CDN-Domain is to identify a
      region (subset) of the URI space relative to which various CDNI
      rules and policies apply.  For example, a record of CDNI Metadata
      might be defined for the set of resources corresponding to some
      CDN-Domain.

   Distinguished CDN-Domain:  a CDN-Domain that is allocated by a CDN
      for the purposes of communication with a peer CDN but that is not
      found in client requests.  Such CDN-Domains may be used for inter-
      CDN acquisition, or as redirection targets, and enable a CDN to
      distinguish a request from a peer CDN from an end-user request.

   Delivering CDN:  the CDN that ultimately delivers a piece of content
      to the end user.  The last in a potential sequence of Downstream
      CDNs.

Top      ToC       Page 5 
   Iterative CDNI Request Redirection:  When an Upstream CDN elects to
      redirect a request towards a Downstream CDN, the Upstream CDN can
      base its redirection purely on a local decision (and without
      attempting to take into account how the Downstream CDN may in turn
      redirect the user agent).  In that case, the Upstream CDN
      redirects the request to the Request Routing system in the
      Downstream CDN, which in turn will decide how to redirect that
      request: this approach is referred to as "Iterative" CDNI Request
      Redirection.

   Recursive CDNI Request Redirection:  When an Upstream CDN elects to
      redirect a request towards a Downstream CDN, the Upstream CDN can
      query the Downstream CDN Request Routing system via the CDNI
      Request Routing Redirection interface (or use information cached
      from earlier similar queries) to find out how the Downstream CDN
      wants the request to be redirected.  This allows the Upstream CDN
      to factor in the Downstream CDN response when redirecting the user
      agent.  This approach is referred to as "Recursive" CDNI Request
      Redirection.  Note that the Downstream CDN may elect to have the
      request redirected directly to a Surrogate inside the Downstream
      CDN, or to any other element in the Downstream CDN (or in another
      CDN), to handle the redirected request appropriately.

   Synchronous CDNI operations:  operations between CDNs that happen
      during the process of servicing a user request, i.e., between the
      time that the user agent begins its attempt to obtain content and
      the time at which that request is served.

   Asynchronous CDNI operations:  operations between CDNs that happen
      independently of any given user request, such as advertisement of
      footprint information or pre-positioning of content for later
      delivery.

   Trigger Interface:  a subset of the CDNI Control interface that
      includes operations to pre-position, revalidate, and purge both
      metadata and content.  These operations are typically called in
      response to some action (Trigger) by the Content Service Provider
      (CSP) on the Upstream CDN.

   We also sometimes use uCDN and dCDN as shorthand for Upstream CDN and
   Downstream CDN (see [RFC6707]), respectively.

   At various points in this document, the concept of a CDN footprint is
   used.  For a discussion on what constitutes a CDN footprint, the
   reader is referred to [FOOTPRINT-CAPABILITY].

Top      ToC       Page 6 
1.2.  Reference Model

   This document uses the reference model in Figure 1, which expands the
   reference model originally defined in [RFC6707].  (The difference is
   that the expanded model splits the Request Routing interface into its
   two distinct parts: the Request Routing Redirection interface and the
   Footprint & Capabilities Advertisement interface, as described
   below.)

Top      ToC       Page 7 
      --------
     /        \
     |   CSP  |
     \        /
      --------
          *
          *
          *                         /\
          *                        /  \
      ----------------------      |CDNI|       ----------------------
     /     Upstream CDN     \     |    |      /    Downstream CDN    \
     |      +-------------+ |     | CI |      | +-------------+      |
     |*******   Control   |<======|====|=======>|   Control   *******|
     |*     +------*----*-+ |     |    |      | +-*----*------+     *|
     |*            *    *   |     |    |      |   *    *            *|
     |*     +------*------+ |     | LI |      | +------*------+     *|
     |* *****   Logging   |<======|====|=======>|   Logging   ***** *|
     |* *   +-*-----------+ |     |    |      | +-----------*-+   * *|
     |* *     *         *   |     |    |      |   *         *     * *|
   .....*...+-*---------*-+ |     | RI |      | +-*---------*-+...*.*...
   . |* *   |             |<======|====|=======>|             |   * *| .
   . |* *   | Req-Routing | |     |FCI |      | | Req-Routing |   * *| .
   . |* * ***             |<======|====|=======>|             |** * *| .
   . |* * * +-------------+.|     |    |      | +-------------+ * * *| .
   . |* * *                 .     |    |      |                 * * *| .
   . |* * * +-------------+ |.    | MI |      | +-------------+ * * *| .
   . |* * * | Distribution|<==.===|====|=======>| Distribution| * * *| .
   . |* * * |             | |  .   \  /       | |             | * * *| .
   . |* * * |+---------+  | |   .   \/        | |  +---------+| * * *| .
   . |* * ***| +---------+| |    ...Request......+---------+ |*** * *| .
   . |* *****+-|Surrogate|***********************|Surrogate|-+***** *| .
   . |*******  +---------+| |   Acquisition   | |+----------+ *******| .
   . |      +-------------+ |                 | +-------*-----+      | .
   . \                      /                 \         *            / .
   .  ----------------------                   ---------*------------  .
   .                                                    *              .
   .                                                    * Delivery     .
   .                                                    *              .
   .                                                 +--*---+          .
   ...............Request............................| User |..Request..
                                                     | Agent|
                                                     +------+

            <==> interfaces inside the scope of CDNI

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

             Figure 1: CDNI Expanded Model and CDNI Interfaces

Top      ToC       Page 8 
   While some interfaces in the reference model are "out of scope" for
   the CDNI WG (in the sense that there is no need to define new
   protocols for those interfaces), we note that we still need to refer
   to them in this document to explain the overall operation of CDNI.

   We also note that, while we generally show only one Upstream CDN
   serving a given CSP, it is entirely possible that multiple uCDNs can
   serve a single CSP.  In fact, this situation effectively exists today
   in the sense that a single CSP can currently delegate its content
   delivery to more than one CDN.

   The following briefly describes the five CDNI interfaces,
   paraphrasing the definitions given in [RFC6707].  We discuss these
   interfaces in more detail in Section 4.

   o  CDNI Control interface (CI): Operations to bootstrap and
      parameterize the other CDNI interfaces, as well as operations to
      pre-position, revalidate, and purge both metadata and content.
      The latter subset of operations is sometimes collectively called
      the "Trigger interface".

   o  CDNI Request Routing interface: Operations to determine what CDN
      (and optionally what Surrogate within a CDN) is to serve end-user
      requests.  This interface is actually a logical bundling of two
      separate, but related, interfaces:

      *  CDNI Footprint & Capabilities Advertisement interface (FCI):
         Asynchronous operations to exchange routing information (e.g.,
         the network footprint and capabilities served by a given CDN)
         that enables CDN selection for subsequent user requests; and

      *  CDNI Request Routing Redirection interface (RI): Synchronous
         operations to select a delivery CDN (Surrogate) for a given
         user request.

   o  CDNI Metadata interface (MI): Operations to communicate metadata
      that governs how the content is delivered by interconnected CDNs.
      Examples of CDNI Metadata include geo-blocking directives,
      availability windows, access control mechanisms, and purge
      directives.  It may include a combination of:

      *  Asynchronous operations to exchange metadata that govern
         subsequent user requests for content; and

      *  Synchronous operations that govern behavior for a given user
         request for content.

Top      ToC       Page 9 
   o  CDNI Logging interface (LI): Operations that allow interconnected
      CDNs to exchange relevant activity logs.  It may include a
      combination of:

      *  Real-time exchanges, suitable for runtime traffic monitoring;
         and

      *  Offline exchanges, suitable for analytics and billing.

   The division between the sets of Trigger-based operations in the CDNI
   Control interface and the CDNI Metadata interface is somewhat
   arbitrary.  For both cases, the information passed from the Upstream
   CDN to the Downstream CDN can broadly be viewed as metadata that
   describes how content is to be managed by the Downstream CDN.  For
   example, the information conveyed by the CI to pre-position,
   revalidate, or purge metadata is similar to the information conveyed
   by posting updated metadata via the MI.  Even the CI operation to
   purge content could be viewed as a metadata update for that content:
   purge simply says that the availability window for the named content
   ends now.  The two interfaces share much in common, so minimally,
   there will need to be a consistent data model that spans both.

   The distinction we draw has to do with what the uCDN knows about the
   successful application of the metadata by the dCDN.  In the case of
   the CI, the Downstream CDN returning a successful status message
   guarantees that the operation has been successfully completed; for
   example, the content has been purged or pre-positioned.  This implies
   that the Downstream CDN accepts responsibility for having
   successfully completed the requested operation.  In contrast,
   metadata passed between CDNs via the MI carries no such completion
   guarantee.  Returning success implies successful receipt of the
   metadata, but nothing can be inferred about precisely when the
   metadata will take effect in the Downstream CDN, only that it will
   take effect eventually.  This is because of the challenge in globally
   synchronizing updates to metadata with end-user requests that are
   currently in progress (or indistinguishable from currently being in
   progress).  Clearly, a CDN will not be viewed as a trusted peer if
   "eventually" often becomes an indefinite period of time, but the
   acceptance of responsibility cannot be as crisply defined for the MI.

   Finally, there is a practical issue that impacts all of the CDNI
   interfaces, and that is whether or not to optimize CDNI for HTTP
   Adaptive Streaming (HAS).  We highlight specific issues related to
   delivering HAS content throughout this document, but for a more
   thorough treatment of the topic, see [RFC6983].

Top      ToC       Page 10 
1.3.  Structure of This Document

   The remainder of this document is organized as follows:

   o  Section 2 describes some essential building blocks for CDNI,
      notably the various options for redirecting user requests to a
      given CDN.

   o  Section 3 provides a number of illustrative examples of various
      CDNI operations.

   o  Section 4 describes the functionality of the main CDNI interfaces.

   o  Section 5 shows how various deployment models of CDNI may be
      achieved using the defined interfaces.

   o  Section 6 describes the trust model of CDNI and the issues of
      transitive trust in particular that CDNI raises.

2.  Building Blocks

2.1.  Request Redirection

   At its core, CDNI requires the redirection of requests from one CDN
   to another.  For any given request that is received by an Upstream
   CDN, it will either respond to the request directly, or somehow
   redirect the request to a Downstream CDN.  Two main mechanisms are
   available for redirecting a request to a Downstream CDN.  The first
   leverages the DNS name resolution process and the second uses
   application-layer redirection mechanisms such as the HTTP 302 or
   Real-Time Streaming Protocol (RTSP) 302 redirection responses.  While
   there exists a large variety of application-layer protocols that
   include some form of redirection mechanism, this document will use
   HTTP (and HTTPS) in its examples.  Similar mechanisms can be applied
   to other application-layer protocols.  What follows is a short
   discussion of both DNS- and HTTP-based redirection, before presenting
   some examples of their use in Section 3.

2.1.1.  DNS Redirection

   DNS redirection is based on returning different IP addresses for the
   same DNS name, for example, to balance server load or to account for
   the client's location in the network.  A DNS server, sometimes called
   the Local DNS (LDNS), resolves DNS names on behalf of an end user.
   The LDNS server in turn queries other DNS servers until it reaches
   the authoritative DNS server for the CDN-Domain.  The network
   operator typically provides the LDNS server, although the user is
   free to choose other DNS servers (e.g., OpenDNS, Google Public DNS).

Top      ToC       Page 11 
   This latter possibility is important because the authoritative DNS
   server sees only the IP address of the DNS server that queries it,
   not the IP address of the original end user.

   The advantage of DNS redirection is that it is completely transparent
   to the end user; the user sends a DNS name to the LDNS server and
   gets back an IP address.  On the other hand, DNS redirection is
   problematic because the DNS request comes from the LDNS server, not
   the end user.  This may affect the accuracy of server selection that
   is based on the user's location.  The transparency of DNS redirection
   is also a problem in that there is no opportunity to take the
   attributes of the user agent or the URI path component into account.
   We consider two main forms of DNS redirection: simple and CNAME-
   based.

   In simple DNS redirection, the authoritative DNS server for the name
   simply returns an IP address from a set of possible IP addresses.
   The answer is chosen from the set based on characteristics of the set
   (e.g., the relative loads on the servers) or characteristics of the
   client (e.g., the location of the client relative to the servers).
   Simple redirection is straightforward.  The only caveats are (1)
   there is a limit to the number of alternate IP addresses a single DNS
   server can manage; and (2) DNS responses are cached by Downstream
   servers so the Time to Live (TTL) on the response must be set to an
   appropriate value so as to preserve the freshness of the redirection.

   In CNAME-based DNS redirection, the authoritative server returns a
   CNAME response to the DNS request, telling the LDNS server to restart
   the name lookup using a new name.  A CNAME is essentially a symbolic
   link in the DNS namespace, and like a symbolic link, redirection is
   transparent to the client; the LDNS server gets the CNAME response
   and re-executes the lookup.  Only when the name has been resolved to
   an IP address does it return the result to the user.  Note that DNAME
   would be preferable to CNAME if it becomes widely supported.

   One of the advantages of DNS redirection compared to HTTP redirection
   is that it can be cached, reducing load on the redirecting CDN's DNS
   server.  However, this advantage can also be a drawback, especially
   when a given DNS resolver doesn't strictly adhere to the TTL, which
   is a known problem in some real-world environments.  In such cases,
   an end user might end up at a dCDN without first having passed
   through the uCDN, which might be an undesirable scenario from a uCDN
   point of view.

Top      ToC       Page 12 
2.1.2.  HTTP Redirection

   HTTP redirection makes use of the redirection response of the HTTP
   protocol (e.g.,"302" or "307").  This response contains a new URL
   that the application should fetch instead of the original URL.  By
   changing the URL appropriately, the server can cause the user to
   redirect to a different server.  The advantages of HTTP redirection
   are that (1) the server can change the URL fetched by the client to
   include, for example, both the DNS name of the particular server to
   use, as well as the original HTTP server that was being accessed; (2)
   the client sends the HTTP request to the server, so that its IP
   address is known and can be used in selecting the server; and (3)
   other attributes (e.g., content type, user agent type) are visible to
   the redirection mechanism.

   Just as is the case for DNS redirection, there are some potential
   disadvantages of using HTTP redirection.  For example, it may affect
   application behavior; web browsers will not send cookies if the URL
   changes to a different domain.  In addition, although this might also
   be an advantage, results of HTTP redirection are not cached so that
   all redirections must go through to the uCDN.



(page 12 continued on part 2)

Next RFC Part