Tech-invite3GPPspaceIETF RFCsSIP
93929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7336

Framework for Content Distribution Network Interconnection (CDNI)

Pages: 58
Informational
Obsoletes:  3466
Part 1 of 4 – Pages 1 to 12
None   None   Next

Top   ToC   RFC7336 - 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.
Top   ToC   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   ToC   RFC7336 - 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   RFC7336 - 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   RFC7336 - 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   RFC7336 - 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   RFC7336 - 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   RFC7336 - 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   RFC7336 - 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   RFC7336 - 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   RFC7336 - 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   RFC7336 - 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 Section