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

Versions: 00 01 draft-ietf-cdni-framework

Network Working Group                                      B. Davie, Ed.
Internet-Draft                                       Cisco Systems, Inc.
Intended status: Informational                          L. Peterson, Ed.
Expires: May 3, 2012                                       Verivue, Inc.
                                                        October 31, 2011


                   Framework for CDN Interconnection
                     draft-davie-cdni-framework-01

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.  CDN Interconnection requires the specification of several
   interfaces and mechanisms to address issues such as request routing,
   metadata exchange, and the acquisition of content by one CDN from
   another.  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.

Status of this Memo

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

   Internet-Drafts are working documents of the Internet Engineering
   Task Force (IETF).  Note that other groups may also distribute
   working documents as Internet-Drafts.  The list of current Internet-
   Drafts is at http://datatracker.ietf.org/drafts/current/.

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

   This Internet-Draft will expire on May 3, 2012.

Copyright Notice

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

   This document is subject to BCP 78 and the IETF Trust's Legal
   Provisions Relating to IETF Documents



Davie & Peterson           Expires May 3, 2012                  [Page 1]


Internet-Draft               CDNI Framework                 October 2011


   (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.












































Davie & Peterson           Expires May 3, 2012                  [Page 2]


Internet-Draft               CDNI Framework                 October 2011


Table of Contents

   1.  Introduction . . . . . . . . . . . . . . . . . . . . . . . . .  4
     1.1.  Terminology  . . . . . . . . . . . . . . . . . . . . . . .  4
     1.2.  Reference Model  . . . . . . . . . . . . . . . . . . . . .  5
     1.3.  Structure Of This Document . . . . . . . . . . . . . . . .  8
   2.  Building Blocks  . . . . . . . . . . . . . . . . . . . . . . .  8
     2.1.  Request Redirection  . . . . . . . . . . . . . . . . . . .  8
       2.1.1.  DNS Redirection  . . . . . . . . . . . . . . . . . . .  8
       2.1.2.  HTTP Redirection . . . . . . . . . . . . . . . . . . .  9
   3.  Overview of CDNI Operation . . . . . . . . . . . . . . . . . . 10
     3.1.  Preliminaries  . . . . . . . . . . . . . . . . . . . . . . 12
     3.2.  HTTP Redirect Example  . . . . . . . . . . . . . . . . . . 13
       3.2.1.  Comments on the example  . . . . . . . . . . . . . . . 17
     3.3.  Recursive Redirection Example  . . . . . . . . . . . . . . 18
       3.3.1.  Comments on the example  . . . . . . . . . . . . . . . 22
     3.4.  DNS-based redirection example  . . . . . . . . . . . . . . 22
       3.4.1.  Comments on the example  . . . . . . . . . . . . . . . 25
     3.5.  Dynamic Footprint Discovery  . . . . . . . . . . . . . . . 26
     3.6.  Content Removal  . . . . . . . . . . . . . . . . . . . . . 28
     3.7.  Pre-Positioned Content Acquisition Example . . . . . . . . 28
     3.8.  Asynchronous CDNI Metadata Example . . . . . . . . . . . . 30
     3.9.  Synchronous CDNI Metadata Acquisition Example  . . . . . . 32
   4.  Main Interfaces  . . . . . . . . . . . . . . . . . . . . . . . 35
     4.1.  In-Band versus Out-of-Band Interfaces  . . . . . . . . . . 35
     4.2.  Request Routing Interface  . . . . . . . . . . . . . . . . 36
     4.3.  Logging Interface  . . . . . . . . . . . . . . . . . . . . 37
     4.4.  Control Interface  . . . . . . . . . . . . . . . . . . . . 39
     4.5.  Metadata Interface . . . . . . . . . . . . . . . . . . . . 39
   5.  Deployment Models  . . . . . . . . . . . . . . . . . . . . . . 41
     5.1.  Meshed CDNs  . . . . . . . . . . . . . . . . . . . . . . . 41
     5.2.  CSP combined with CDN  . . . . . . . . . . . . . . . . . . 42
     5.3.  CSP using CDNI Request Routing Interface . . . . . . . . . 43
     5.4.  CDN Federations and CDN Exchanges  . . . . . . . . . . . . 44
   6.  Trust Model  . . . . . . . . . . . . . . . . . . . . . . . . . 47
   7.  IANA Considerations  . . . . . . . . . . . . . . . . . . . . . 48
   8.  Security Considerations  . . . . . . . . . . . . . . . . . . . 48
     8.1.  Security of CDNI Interfaces  . . . . . . . . . . . . . . . 49
     8.2.  Digital Rights Management  . . . . . . . . . . . . . . . . 50
   9.  Contributors . . . . . . . . . . . . . . . . . . . . . . . . . 50
   10. Acknowledgements . . . . . . . . . . . . . . . . . . . . . . . 50
   11. Informative References . . . . . . . . . . . . . . . . . . . . 50
   Authors' Addresses . . . . . . . . . . . . . . . . . . . . . . . . 51








Davie & Peterson           Expires May 3, 2012                  [Page 3]


Internet-Draft               CDNI Framework                 October 2011


1.  Introduction

   The interconnection of Content Distribution Networks (CDNs) is
   motivated by several use cases, such as those described in
   [I-D.ietf-cdni-use-cases].  The overall problem space for CDN
   Interconnection is described in [I-D.ietf-cdni-problem-statement].
   The purpose of this document is to provide an overview of the various
   components necessary to interconnect CDNs.  CDN Interconnection
   requires the specification of several interfaces and mechanisms to
   address issues such as request routing, metadata exchange, and the
   acquisition of content by one CDN from another.  The intent of this
   document is to describe how these interfaces and mechanisms fit
   together, leaving their detailed specification to other documents.
   We make extensive use of message flow examples to illustrate the
   operation of interconnected CDNs, but these examples should be
   considered illustrative rather than prescriptive.

1.1.  Terminology

   This document draws freely on the terminology defined in [RFC3466]
   and [I-D.ietf-cdni-problem-statement].

   We also introduce the following terms:

   CDN Domain: a host name (FQDN) at the beginning of a URL,
   representing a set of content that is served by a given CDN.  For
   example, in the URL http://cdn.csp.com/...rest of url..., the CDN
   domain is cdn.csp.com.

   Distinguished CDN Domain: a CDN domain that is allocated by a CDN for
   the purposes of communication with a peer CDN, but which 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.

   Recursive CDNI request routing: 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 interface (or use information cached from earlier similar
   queries) to find out how the Downstream CDN wants the request to be
   redirected, which 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 routing.  Note that the
   Downstream CDN may elect to have the request redirected directly to a
   Surrogate inside the Downstream CDN, to the Request-Routing System of
   the Downstream CDN, to another CDN, or to any other system that the
   Downstream CDN sees as fit for handling the redirected request.




Davie & Peterson           Expires May 3, 2012                  [Page 4]


Internet-Draft               CDNI Framework                 October 2011


   Iterative CDNI Request Routing: 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 routing.

   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.

1.2.  Reference Model

   This document uses the reference model in Figure 1 as originally
   created in [I-D.ietf-cdni-problem-statement].




























Davie & Peterson           Expires May 3, 2012                  [Page 5]


Internet-Draft               CDNI Framework                 October 2011


     --------
    /        \
    |   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: CDNI Model and CDNI Interfaces




Davie & Peterson           Expires May 3, 2012                  [Page 6]


Internet-Draft               CDNI Framework                 October 2011


   We note that 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 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 uCDN 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 connect to more than one CDN today.

   Definitions of the four CDNI interfaces follow.  More discussion of
   these interfaces appears in Section 4.

   o  Control Interface: Operations to discover, initialize, and
      parameterize the other CDNI interfaces.  Once established, all
      runtime control over CDNI behavior is under the purview of one of
      these other interfaces.

   o  Request Routing Interface: Operations to determine what CDN (and
      optionally what surrogate within a CDN) is to serve end-user's
      requests.  May include a combination of:

      *  Asynchronous operations to exchange routing information (e.g.,
         the network footprint served by a given CDN) that enables CDN
         selection for subsequent user requests; and

      *  Synchronous operations to select a delivery CDN (surrogate) for
         a given user request.

   o  Metadata Interface: Operations to communicate metadata that
      governs the how content is delivered by interconnected CDNs.
      Examples of CDNI metadata include geo-blocking directives,
      availability windows, access control mechanisms, and purge
      directives.  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.

   o  Logging Interface: Operations that allow interconnected CDNs to
      exchange relevant activity logs.  May include a combination of:

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





Davie & Peterson           Expires May 3, 2012                  [Page 7]


Internet-Draft               CDNI Framework                 October 2011


      *  Off-line exchanges, suitable for analytics and billing.

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 four 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, CDN Interconnection 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 in-protocol redirection mechanisms such as the HTTP 302
   redirection response.  We discuss these below as background before
   discussing 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).




Davie & Peterson           Expires May 3, 2012                  [Page 8]


Internet-Draft               CDNI Framework                 October 2011


   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 modify the path
   component of the URL being accessed by the client.  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 delivery nodes a single DNS server
   can manage; and (2) DNS responses are cached by downstream servers so
   the TTL on the response must be set to an appropriate value so as to
   preserve the timeliness 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.

2.1.2.  HTTP Redirection

   HTTP redirection makes use of the "302" redirection response of the
   HTTP protocol.  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 302 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; and (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.

   The disadvantages of HTTP redirection are (1) it is visible to the
   application, so it requires application support and may affect the
   application behavior (e.g., web browsers will not send cookies if the
   URL changes to a different domain); (2) HTTP is a heavy-weight
   protocol layered on TCP so it has relatively high overhead; and (3)



Davie & Peterson           Expires May 3, 2012                  [Page 9]


Internet-Draft               CDNI Framework                 October 2011


   the results of HTTP redirection are not cached so that all
   redirections must go through to the server.


3.  Overview of CDNI Operation

   To provide a big-picture overview of the various components of CDN
   Interconnection, we walk through a "day in the life" of a content
   item that is made available via a pair of interconnected CDNs.  This
   will serve to illustrate many of the functions that need to be
   supported in a complete CDNI solution.  We give examples using both
   DNS-based and HTTP-based redirection.  We begin with very simple
   examples and then how additional capabilities, such as recursive
   request redirection and content removal, might be added.

   Before walking through some specific examples, we present a high-
   level view of the operations that may take place.  This high-level
   overview is illustrated in Figure 2.  Note that most operations will
   involve only a subset of all the messages shown below, and that the
   order and number of operations may vary considerably, as more
   detailed examples illustrate below.

   The following shows Operator A as the upstream CDN (uCDN) and
   Operator B as the downstream CDN (dCDN), where the former has a
   relationship with a content provider and the latter being the best
   CDN to deliver content to the end-user.  The interconnection
   relationship may be symmetric between these two CDN operators, but
   for simplicity we show the interaction in one direction only.























Davie & Peterson           Expires May 3, 2012                 [Page 10]


Internet-Draft               CDNI Framework                 October 2011


         End-User                  Operator B                Operator A
             |                         |                         |
             |                         |                         |
             |                         |  [Async Metadata Push]  | (1)
             |                         |                         |
             |                         |  [Async RRI Push]       | (2)
             |                         |                         |
             | CONTENT REQUEST         |                         |
             |-------------------------------------------------->| (3)
             |                         |                         |
             |                         | [Sync RRI Pull]         | (4)
             |                         |                         |
             | CONTENT REDIRECTION     |                         |
             |<--------------------------------------------------| (5)
             |                         |                         |
             |                         |                         |
             | CONTENT REQUEST         |                         |
             |------------------------>|                         | (6)
             |                         |                         |
             |                         | [Sync Metadata Pull]    | (7)
             |                         |                         |
             |                         | ACQUISITION REQUEST     |
             |                         X------------------------>| (8)
             |                         X                         |
             |                         X CONTENT DATA            |
             |                         X<------------------------| (9)
             |                         |                         |
             | CONTENT DATA            |                         |
             |<------------------------|                         | (10)
             |                         |                         |
             :                         :                         :
             :    [Other content requests  ]                     :
             :                         :                         :
             |                         |  [Content Purge]        | (11)
             :                         :                         :
             |                         |  [Logging exchange]     | (12)
             |                         |                         |



                      Figure 2: Overview of Operation

   The operations shown in the Figure are as follows:

   1.   Prior to any content request, metadata may be asynchronously
        pushed from uCDN to dCDN so that it is available in readiness
        for later content requests.




Davie & Peterson           Expires May 3, 2012                 [Page 11]


Internet-Draft               CDNI Framework                 October 2011


   2.   dCDN may advertise information relevant to its delivery
        capabilities (e.g. geographic footprint, reachable address
        prefixes) prior to any content requests being redirected.

   3.   A content request from a user agent arrives at uCDN.

   4.   uCDN may synchronously request information from dCDN regarding
        its delivery capabilities to decide if dCDN is a suitable target
        for redirection of this request.

   5.   uCDN redirects the request to dCDN by sending some response
        (DNS, HTTP) to the user agent.

   6.   The user agent requests the content from dCDN.

   7.   dCDN may synchronously request metadata related to this content
        from uCDN, e.g. to decide whether to serve it.

   8.   If the content is not already in a suitable cache in dCDN, dCDN
        may acquire it from uCDN.

   9.   The content is delivered to dCDN from uCDN.

   10.  The content is delivered to the user agent by dCDN.

   11.  Some time later, perhaps at the request of the CSP (not shown)
        uCDN may instruct dCDN to purge the content to ensure it is not
        delivered again.

   12.  After one or more content delivery actions by dCDN, a log of
        delivery actions may be provided to uCDN.

   The following sections show some more specific examples of how these
   operations may be combined to perform various delivery, control and
   logging operations across a pair of CDNs.

3.1.  Preliminaries

   Initially, we assume that there is at least one CSP that has
   contracted with an upstream CDN (uCDN) to deliver content on its
   behalf.  We are not particularly concerned with the interface between
   the CSP and uCDN, other than to note that it is expected to be the
   same as in the "traditional" (non-interconnected) CDN case.  Existing
   mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be
   used to direct a user request for a piece of content from the CSP
   towards the CSP's chosen upstream CDN.

   We use the term "CDN-domain" to refer to the host name (a FQDN) at



Davie & Peterson           Expires May 3, 2012                 [Page 12]


Internet-Draft               CDNI Framework                 October 2011


   the beginning of each URL.  We assume Operator A provides an upstream
   CDN that serves content on behalf of a CSP with CDN-domain
   cdn.csp.com.  We assume that Operator B provides a downstream CDN.
   An end user at some point makes a request for URL

   http://cdn.csp.com/...rest of url...

   It may well be the case that cdn.csp.com is just a CNAME for some
   other CDN-domain (such as csp.op-a.net).  Nevertheless, the HTTP
   request in the examples that follow is assumed to be for the example
   URL above.

   Our goal is to enable content identified by the above URL to be
   served by the CDN of operator B. In the following sections we will
   walk through some scenarios in which content is served, as well as
   other CDNI operations such as the removal of content from a
   downstream CDN.

3.2.  HTTP Redirect Example

   In this section we walk through a simple, illustrative example using
   HTTP redirection from uCDN to dCDN.  The example also assumes the use
   of HTTP redirection inside uCDN and dCDN; however, this is
   independent of the choice of redirection approach across CDNs, so an
   alternative example could be constructed still showing HTTP
   redirection from uCDN to dCDN but using DNS for handling of request
   inside each CDN.

   We assume for this example that Operators A and B have established an
   agreement to interconnect their CDNs, with A being upstream and B
   being downstream.  (It is likely that the agreement would be made in
   both directions, but we focus on just one here for clarity.)

   The operators agree that a CDN-domain peer-a.op-b.net will be used as
   the target of redirections from uCDN to dCDN.  The name of this
   domain must be communicated by some means to each CDN.  (This could
   be established out-of-band or via a CDNI interface.)  We refer to
   this domain as a "distinguished" CDN domain to convey the fact that
   its use is limited to the interconnection mechanism; such a domain is
   never embedded in URLs that end-users request.

   The operators must also agree on some distinguished CDN-domain that
   will be used for inter-CDN acquisition of CSP's content from uCDN by
   dCDN.  In this example, we'll use op-b-acq.op-a.net.

   The operators must also exchange information regarding which requests
   dCDN is prepared to serve.  For example, dCDN may be prepared to
   serve requests from clients in a given geographical region or a set



Davie & Peterson           Expires May 3, 2012                 [Page 13]


Internet-Draft               CDNI Framework                 October 2011


   of IP address prefixes.  This information may again be provided out
   of band or via a defined interface.

   DNS must be configured in the following way:

   o  The content provider must be configured to make operator A the
      authoritative DNS server for cdn.csp.com (or to return a CNAME for
      cdn.csp.com for which operator A is the authoritative DNS server).

   o  Operator A must be configured so that a DNS request for op-b-
      acq.op-a.net returns a request router in Operator A.

   o  Operator B must be configured so that a DNS request for peer-a.op-
      b.net/cdn.csp.com returns a request router in Operator B.

   Figure 3 illustrates how a client request for

   http://cdn.csp.com/...rest of url...

   is handled.

         End-User                 Operator B                Operator A
             |DNS cdn.csp.com          |                         |
             |-------------------------------------------------->|
             |                         |                         |(1)
             |IPaddr of A's Request Router                       |
             |<--------------------------------------------------|
             |HTTP cdn.csp.com         |                         |
             |-------------------------------------------------->|
             |                         |                         |(2)
             |302 peer-a.op-b.net/cdn.csp.com                    |
             |<--------------------------------------------------|
             |DNS peer-a.op-b.net      |                         |
             |------------------------>|                         |
             |                         |(3)                      |
             |IPaddr of B's Request Router                       |
             |<------------------------|                         |
             |                         |                         |
             |HTTP peer-a.op-b.net/cdn.csp.com                   |
             |------------------------>|                         |
             |                         |(4)                      |
             |302 node1.peer-a.op-b.net/cdn.csp.com              |
             |<------------------------|                         |
             |DNS node1.peer-a.op-b.net|                         |
             |------------------------>|                         |
             |                         |(5)                      |
             |IPaddr of B's Delivery Node                        |
             |<------------------------|                         |



Davie & Peterson           Expires May 3, 2012                 [Page 14]


Internet-Draft               CDNI Framework                 October 2011


             |                         |                         |
             |HTTP node1.peer-a.op-b.net/cdn.csp.com             |
             |------------------------>|                         |
             |                         |(6)                      |
             |                         |DNS op-b-acq.op-a.net    |
             |                         |------------------------>|
             |                         |                         |(7)
             |                         |IPaddr of A's Request Router
             |                         |<------------------------|
             |                         |HTTP op-b-acq.op-a.net   |
             |                         |------------------------>|
             |                         |                         |(8)
             |                         |302 node2.op-b.acq.op-A.net
             |                         |<------------------------|
             |                         |DNS node2.op-b-acq.op-a.net
             |                         |------------------------>|
             |                         |                         |(9)
             |                         |IPaddr of A's Delivery Node
             |                         |<------------------------|
             |                         |                         |(10)
             |                         |Data                     |
             |                         |<------------------------|
             |Data                     |                         |
             |<------------------------|                         |

            Figure 3: Request Trace for HTTP redirection method

   The steps illustrated in the figure are as follows:

   1.   A DNS resolver for Operator A processes the DNS request for its
        customer based on CDN-domain cdn.csp.com.  It returns the IP
        address of a request router in Operator A.

   2.   A Request Router for Operator A processes the HTTP request and
        recognizes that the end-user is best served by another CDN--
        specifically one provided by Operator B--and so it returns a 302
        redirect message for a new URL constructed by "stacking"
        Operator B's distinguished CDN-domain (peer-a.op-b.net) on the
        front of the original URL.  (Note that more complex URL
        manipulations are possible, such as replacing the initial CDN-
        domain by some opaque handle.)

   3.   The end-user does a DNS lookup using Operator B's distinguished
        CDN-domain (peer-a.op-b.net).  B's DNS resolver returns the IP
        address of a request router for Operator B. Note that if request
        routing within dCDN was performed using DNS instead of HTTP
        redirection, B's DNS resolver would also behave as the request
        router and directly return the IP address of a delivery node.



Davie & Peterson           Expires May 3, 2012                 [Page 15]


Internet-Draft               CDNI Framework                 October 2011


   4.   The request router for Operator B processes the HTTP request and
        selects a suitable delivery node to serve the end-user request,
        and returns a 302 redirect message for a new URL constructed by
        replacing the hostname by a subdomain of the Operator B's
        distinguished CDN-domain that points to the selected delivery
        node.

   5.   The end-user does a DNS lookup using Operator B's delivery node
        subdomain (node1.peer-a.op-b.net).  B's DNS resolver returns the
        IP address of the delivery node.

   6.   The end-user requests the content from B's delivery node.  In
        the case of a cache hit, steps 6, 7, 8, 9 and 10 below do not
        happen, and the content data is directly returned by the
        delivery node to the end-user.  In the case of a cache miss, the
        content needs to be acquired by dCDN from uCDN (not the CSP).
        The distinguished CDN-domain peer-a.op-b.net indicates to dCDN
        that this content is to be acquired from uCDN; stripping the
        CDN-domain reveals the original CDN-domain cdn.csp.com and dCDN
        may verify that this CDN-domain belongs to a known peer (so as
        to avoid being tricked into serving as an open proxy).  It then
        does a DNS request for an inter-CDN acquisition CDN-domain as
        agreed above (in this case, op-b-acq.op-a.net).

   7.   Operator A's DNS resolver processes the DNS request and returns
        the IP address of a request router in operator A.

   8.   The request router for Operator A processes the HTTP request
        from Operator B delivery node.  Operator A request router
        recognizes that the request is from a peer CDN rather than an
        end-user because of the dedicated inter-CDN acquisition domain
        (op-b-acq.op-a.net).  (Note that without this specially defined
        inter-CDN acquisition domain, operator A would be at risk of
        redirecting the request back to operator B, resulting in an
        infinite loop).  The request router for Operator A selects a
        suitable delivery node in uCDN to serve the inter-CDN
        acquisition request and returns a 302 redirect message for a new
        URL constructed by replacing the hostname by a subdomain of the
        Operator A's distinguished inter-CDN acquisition domain that
        points to the selected delivery node.

   9.   Operator A DNS resolver processes the DNS request and returns
        the IP address of the delivery node in operator A.

   10.  Operator A serves content for the requested CDN-domain to dCDN.
        Although not shown, it is at this point that Operator A
        processes the rest of the URL: it extracts information
        identifying the origin server, validates that this server has



Davie & Peterson           Expires May 3, 2012                 [Page 16]


Internet-Draft               CDNI Framework                 October 2011


        been registered, and determines the content provider that owns
        the origin server.  It may also perform its own content
        acquisition steps if needed before returning the content to
        dCDN.

3.2.1.  Comments on the example

   The main advantage of this design is that it is simple: each CDN need
   only know the distinguished CDN-domain for each peer, with the
   upstream CDN "pushing" the downstream CDN-domain onto the URL as part
   of its redirect (step 2) and the downstream CDN "popping" its CDN-
   domain off the URL to expose a CDN-domain that the upstream CDN can
   correctly process.  Neither CDN needs to be aware of the internal
   structure of the other's URLs.  Moreover, the inter-CDN redirection
   is entirely supported by a single HTTP redirect; neither CDN needs to
   be aware of the other's internal redirection mechanism (i.e., whether
   it is DNS or HTTP based).

   One disadvantage is that the end-user's browser is redirected to a
   new URL that is not in the same domain of the original URL.  This has
   implications on a number of security or validation mechanisms
   sometimes used on endpoints.  For example, it is important that any
   redirected URL be in the same domain (e.g., csp.com) if the browser
   is expected to send any cookies associated with that domain.  As
   another example, some video players enforce validation of a cross
   domain policy that needs to allow for the domains involved in the CDN
   redirection.  These problems are generally soluble, but the solutions
   complicate the example, so we do not discuss them further in this
   version of the draft.

   We note that this example begins to illustrate some of the interfaces
   that may be required for CDNI, but does not require all of them.  For
   example, obtaining information from dCDN regarding the set of client
   IP addresses or geographic regions it might be able to serve is an
   aspect of the request routing interface.  Important configuration
   information such as the distinguished names used for redirection and
   inter-CDN acquisition could also be conveyed via a CDNI interface
   (e.g., perhaps the control interface).  The example also shows how
   existing HTTP-based methods suffice for the acquisition interface.
   Arguably, the absolute minimum metadata required for CDNI is the
   information required to acquire the content, and this information was
   provided "in-band" in this example by means of the URI handed to the
   client in the HTTP 302 response.  Hence, there is no explicit
   metadata interface invoked in this example.  There is also no
   explicit logging interface discussed in this example.

   We also note that the step of deciding when a request should be
   redirected to dCDN rather than served by uCDN has been somewhat



Davie & Peterson           Expires May 3, 2012                 [Page 17]


Internet-Draft               CDNI Framework                 October 2011


   glossed over.  It may be as simple as checking the client IP address
   against a list of prefixes, or it may be considerably more complex,
   involving a wide range of factors, such as the geographic location of
   the client (perhaps determined from a third party service), CDN load,
   or specific business rules.

   This example uses the "iterative" CDNI request routing approach.
   That is, uCDN performs part of the request routing function to
   determine that dCDN should serve the request, and then redirects the
   client to a request router in dCDN to perform the rest of the request
   routing function.  If request routing is performed in the dCDN using
   HTTP redirection, this translates in the end-user experiencing two
   successive HTTP redirections.  By contrast, the alternative approach
   of "recursive" CDNI request routing effectively coalesces these two
   successive HTTP redirections into a single one, sending the end-user
   directly to the right delivery node in the dCDN.  This "recursive"
   CDNI request routing approach is discussed in the next section.

3.3.  Recursive Redirection Example

   The following example builds on the previous one to illustrate the
   use of the Request Routing interface to enable "recursive" CDNI
   request routing.  We build on the HTTP-based redirection approach
   because it illustrates the principles and benefits clearly, but it is
   equally possible to perform recursive redirection when DNS-based
   redirection is employed.

   In contrast to the prior example, the operators need not agree in
   advance on a CDN-domain to serve as the target of redirections from
   uCDN to dCDN.  The operators still must agree on some distinguished
   CDN-domain that will be used for inter-CDN acquisition of CSP's
   content by dCDN.  In this example, we'll use op-b-acq.op-a.net.

   The operators must also exchange information regarding which requests
   dCDN is prepared to serve.  For example, dCDN may be prepared to
   serve requests from clients in a given geographical region or a set
   of IP address prefixes.  This information may again be provided out
   of band or via a defined protocol.

   DNS must be configured in the following way:

   o  The content provider must be configured to make operator A the
      authoritative DNS server for cdn.csp.com (or to return a CNAME for
      cdn.csp.com for which operator A is the authoritative DNS server).

   o  Operator A must be configured so that a DNS request for op-b-
      acq.op-a.net returns a request router in Operator A.




Davie & Peterson           Expires May 3, 2012                 [Page 18]


Internet-Draft               CDNI Framework                 October 2011


   o  Operator B must be configured so that a request for node1.op-
      b.net/cdn.csp.com returns the IP address of a delivery node.  Note
      that there might be a number of such delivery nodes.

   Figure 3 illustrates how a client request for

   http://cdn.csp.com/...rest of url...

   is handled.










































Davie & Peterson           Expires May 3, 2012                 [Page 19]


Internet-Draft               CDNI Framework                 October 2011


         End-User                 Operator B                Operator A
             |DNS cdn.csp.com          |                         |
             |-------------------------------------------------->|
             |                         |                         |(1)
             |IPaddr of A's Request Router                       |
             |<--------------------------------------------------|
             |HTTP cdn.csp.com         |                         |
             |-------------------------------------------------->|
             |                         |                         |(2)
             |                         |RRI REQ cdn.csp.com      |
             |                         |<------------------------|
             |                         |                         |
             |                         |RRI RESP node1.op-b.net  |
             |                         |------------------------>|
             |                         |                         |(3)
             |302 node1.op-b.net/cdn.csp.com                     |
             |<--------------------------------------------------|
             |DNS mode1.op-b.net       |                         |
             |------------------------>|                         |
             |                         |(4)                      |
             |IPaddr of B's Delivery Node                        |
             |<------------------------|                         |
             |HTTP node1.op-b.net/cdn.csp.com                    |
             |------------------------>|                         |
             |                         |(5)                      |
             |                         |DNS op-b-acq.op-a.net    |
             |                         |------------------------>|
             |                         |                         |(6)
             |                         |IPaddr of A's Request Router
             |                         |<------------------------|
             |                         |HTTP op-b-acq.op-a.net   |
             |                         |------------------------>|
             |                         |                         |(7)
             |                         |302 node2.op-b.acq.op-A.net
             |                         |<------------------------|
             |                         |DNS node2.op-b-acq.op-a.net
             |                         |------------------------>|
             |                         |                         |(8)
             |                         |IPaddr of A's Delivery Node
             |                         |<------------------------|
             |                         |                         |(9)
             |                         |Data                     |
             |                         |<------------------------|
             |Data                     |                         |
             |<------------------------|                         |

       Figure 4: Request Trace for Recursive HTTP redirection method




Davie & Peterson           Expires May 3, 2012                 [Page 20]


Internet-Draft               CDNI Framework                 October 2011


   The steps illustrated in the figure are as follows:

   1.  A DNS resolver for Operator A processes the DNS request for its
       customer based on CDN-domain cdn.csp.com.  It returns the IP
       address of a Request Router in Operator A.

   2.  A Request Router for Operator A processes the HTTP request and
       recognizes that the end-user is best served by another CDN--
       specifically one provided by Operator B--and so it queries the
       CDNI Request Routing interface of Operator B, providing a set of
       information about the request including the URL requested.
       Operator B replies with the DNS name of a delivery node.

   3.  Operator A returns a 302 redirect message for a new URL obtained
       from the Request Routing Interface.

   4.  The end-user does a DNS lookup using the host name of the URL
       just provided (node1.op-b.net).  B's DNS resolver returns the IP
       address of the corresponding delivery node.  Note that, since the
       name of the delivery node was already obtained from B using the
       CDNI Request Routing Interface, there should not be any further
       redirection here (in contrast to the iterative method described
       above.)

   5.  The end-user requests the content from B's delivery node,
       potentially resulting in a cache miss.  In the case of a cache
       miss, the content needs to be acquired from uCDN (not the CSP.)
       The distinguished CDN-domain op-b.net indicates to dCDN that this
       content is to be acquired from another CDN; stripping the CDN-
       domain reveals the original CDN-domain cdn.csp.com, dCDN may
       verify that this CDN-domain belongs to a known peer (so as to
       avoid being tricked into serving as an open proxy).  It then does
       a DNS request for the inter-CDN Acquisition "distinguished" CDN-
       domain as agreed above (in this case, op-b-acq.op-a.net).

   6.  Operator A DNS resolver processes the DNS request and returns the
       IP address of a request router in operator A.

   7.  The request router for Operator A processes the HTTP request from
       Operator B delivery node.  Operator A request router recognizes
       that the request is from a peer CDN rather than an end-user
       because of the dedicated inter-CDN acquisition domain (op-b-
       acq.op-a.net).  (Note that without this specially defined inter-
       CDN acquisition domain, operator A would be at risk of
       redirecting the request back to operator B, resulting in an
       infinite loop).  The request router for Operator A selects a
       suitable delivery node in uCDN to serve the inter-CDN acquisition
       request and returns a 302 redirect message for a new URL



Davie & Peterson           Expires May 3, 2012                 [Page 21]


Internet-Draft               CDNI Framework                 October 2011


       constructed by replacing the hostname by a subdomain of the
       Operator A's distinguished inter-CDN acquisition domain that
       points to the selected delivery node.

   8.  Operator A recognizes that the DNS request is from a peer CDN
       rather than an end-user (due to the internal CDN-domain) and so
       returns the address of a delivery node.  (Note that without this
       specially defined internal domain, Operator A would be at risk of
       redirecting the request back to Operator B, resulting in an
       infinite loop.)

   9.  Operator A serves content for the requested CDN-domain to dCDN.
       Although not shown, it is at this point that Operator A processes
       the rest of the URL: it extracts information identifying the
       origin server, validates that this server has been registered,
       and determines the content provider that owns the origin server.
       It may also perform its own content acquisition steps if needed
       before returning the content to dCDN.

3.3.1.  Comments on the example

   Recursive redirection has the advantage over iterative of being more
   transparent from the end-user's perspective, but the disadvantage of
   each CDN exposing more of its internal structure (in particular, the
   addresses of edge caches) to peer CDNs.  By contrast, iterative
   redirection does not require dCDN to expose the addresses of its edge
   caches to uCDN.

   This example happens to use HTTP-based redirection in both CDN A and
   CDN B, but a similar example could be constructed using DNS-based
   redirection in either CDN.  Hence, the key point to take away here is
   simply that the end user only sees a single redirection of some type,
   as opposed to the pair of redirections in the prior (iterative)
   example.

   The use of the Request Routing Interface requires that interface to
   be appropriately configured and bootstrapped, which is not shown
   here.  More discussion on the bootstrapping of interfaces is provided
   in Section 4

3.4.  DNS-based redirection example

   In this section we walk through a simple example using DNS-based
   redirection for request redirection from uCDN to dCDN (as well as for
   request routing inside dCDN and uCDN).  As noted in Section 2.1, DNS-
   based redirection has certain advantages over HTTP-based redirection
   (notably, it is transparent to the end-user) as well as some
   drawbacks (notably the client IP address is not visible to the



Davie & Peterson           Expires May 3, 2012                 [Page 22]


Internet-Draft               CDNI Framework                 October 2011


   request router).

   As before, Operator A must learn the set of requests that dCDN is
   willing or able to serve (e.g. which client IP address prefixes or
   geographic regions are part of the dCDN footprint).  Operator B must
   have and make known to operator A some unique identifier that can be
   used for the construction of a distinguished CDN domain, as shown in
   more detail below.  (This identifier strictly needs only to be unique
   within the scope of Operator A, but a globally unique identifier,
   such as an AS number assigned to B, is one easy way to achieve that.)
   Also, Operator A must obtain the NS records for Operator B's
   externally visible redirection servers.  Also, as before, a
   distinguished CDN-domain, such as op-b-acq.op-a.net, must be assigned
   for inter-CDN acquisition.

   DNS must be configured in the following way:

   o  The CSP must be configured to make Operator A the authoritative
      DNS server for cdn.csp.com (or to return a CNAME for cdn.csp.com
      for which operator A is the authoritative DNS server).

   o  When uCDN sees a request best served by dCDN, it returns CNAME and
      NS records for "b.cdn.csp.com", where "b" is the unique identifier
      assigned to Operator B. (It may, for example, be an AS number
      assigned to Operator B.)

   o  dCDN must be configured so that a request for "b.cdn.csp.com"
      returns a delivery node in dCDN.

   o  uCDN must be configured so that a request for "op-b-acq.op-a.net"
      returns a delivery node in uCDN.

   Figure 5 depicts the exchange of DNS and HTTP requests.  The main
   differences from Figure 3 are the lack of HTTP redirection and
   transparency to the end-user.
















Davie & Peterson           Expires May 3, 2012                 [Page 23]


Internet-Draft               CDNI Framework                 October 2011


         End-User                 Operator B                Operator A
             |DNS cdn.csp.com          |                         |
             |-------------------------------------------------->|
             |                         |                         |(1)
             |CNAME b.cdn.csp.com      |                         |
             |NS records for b.cdn.csp.com                       |
             |<--------------------------------------------------|
             |DNS b.cdn.csp.com        |                         |
             |------------------------>|                         |
             |                         |(2)                      |
             |IPaddr of B's Delivery Node                        |
             |<------------------------|                         |
             |HTTP cdn.csp.com         |                         |
             |------------------------>|                         |
             |                         |(3)                      |
             |                         |DNS op-b-acq.op-a.net    |
             |                         |------------------------>|
             |                         |                         |(4)
             |                         |IPaddr of A's Delivery Node
             |                         |<------------------------|
             |                         |HTTP op-b-acq.op-a.net   |
             |                         |------------------------>|
             |                         |                         |(5)
             |                         |Data                     |
             |                         |<------------------------|
             |Data                     |                         |
             |<------------------------|                         |

         Figure 5: Request Trace for DNS-based Redirection Example

   The steps illustrated in the figure are as follows:

   1.  Request Router for Operator A processes the DNS request for CDN-
       domain cdn.csp.com and recognizes that the end-user is best
       served by another CDN.  (This may depend on the IP address of the
       user's local DNS resolver, or other information discussed below.)
       The Request Router returns a DNS CNAME response by "stacking" the
       distinguished identifier for Operator B onto the original CDN-
       domain (e.g., b.cdn.csp.com), plus an NS record that maps
       b.cdn.csp.com to B's Request Router.

   2.  The end-user does a DNS lookup using the modified CDN-domain
       (i.e., b.cdn.csp.com).  This causes B's Request Router to respond
       with a suitable delivery node.

   3.  The end-user requests the content from B's delivery node.  The
       requested URL contains the name cdn.csp.com.  (Note that the
       returned CNAME does not affect the URL.)  At this point the



Davie & Peterson           Expires May 3, 2012                 [Page 24]


Internet-Draft               CDNI Framework                 October 2011


       delivery node has the correct IP address of the end-user and can
       do an HTTP 302 redirect if the redirections in steps 2 and 3 were
       incorrect.  Otherwise B verifies that this CDN-domain belongs to
       a known peer (so as to avoid being tricked into serving as an
       open proxy).  It then does a DNS request for an "internal" CDN-
       domain as agreed above (op-b-acq.op-a.net).

   4.  Operator A recognizes that the DNS request is from a peer CDN
       rather than an end-user (due to the internal CDN-domain) and so
       returns the address of a delivery node in uCDN.

   5.  Operator A serves content to dCDN.  Although not shown, it is at
       this point that Operator A processes the rest of the URL: it
       extracts information identifying the origin server, validates
       that this server has been registered, and determines the content
       provider that owns the origin server.

3.4.1.  Comments on the example

   The advantages of this approach are that it is more transparent to
   the end-user and requires fewer round trips than HTTP-based
   redirection.  A potential problem is that the upstream CDN depends on
   being able to learn the correct downstream CDN that serves the end-
   user from the client address in the DNS request.  In standard DNS
   operation, uCDN will only obtain the address of the client's local
   DNS resolver (LDNS), which is not guaranteed to be in the same
   network (or geographic region) as the client.  If not--e.g., the end-
   user uses a global DNS service--then the upstream CDN cannot
   determine the appropriate downstream CDN to serve the end-user.  In
   this case, one option is for the upstream CDN to treat the end-user
   as it would any user not connected to a peer CDN.  Another option is
   for the upstream CDN to "fall back" to a pure HTTP-based redirection
   strategy in this case (i.e., use the first method).  Note that this
   problem affects existing CDNs that rely on DNS to determine where to
   redirect client requests, but the consequences are arguably less
   serious since the LDNS is likely in the same network as the dCDN
   serves.  One approach to ensuring that the client's IP address prefix
   is correctly determined in such situations is described in
   [I-D.vandergaast-edns-client-subnet].

   As with the prior example, this example partially illustrates the
   various interfaces involved in CDNI.  Operator A could learn
   dynamically from Operator B the set of prefixes or regions that B is
   willing and able to serve via the request routing interface.  The
   distinguished name used for acquisition and the identifier for
   Operator B that is prepended to the CDN domain on redirection are
   examples of information elements that might also be conveyed by CDNI
   interfaces (or, alternatively, statically configured).  As before,



Davie & Peterson           Expires May 3, 2012                 [Page 25]


Internet-Draft               CDNI Framework                 October 2011


   minimal metadata sufficient to obtain the content is carried "in-
   band" as part of the redirection process, and standard HTTP is used
   for inter-CDN acquisition.  There is no explicit logging interface
   discussed in this example.

3.5.  Dynamic Footprint Discovery

   There could be situations where being able to dynamically discover
   the set of requests that a given dCDN is willing and able to serve is
   beneficial.  For example, a CDN might at one time be able to serve a
   certain set of client IP prefixes, but that set might change over
   time due to changes in the topology and routing policies of the IP
   network.  The following example illustrates this capability.  We have
   chosen the example of DNS-based redirection, but HTTP-based
   redirection could equally well use this approach.




































Davie & Peterson           Expires May 3, 2012                 [Page 26]


Internet-Draft               CDNI Framework                 October 2011


         End-User                 Operator B                Operator A
             |DNS cdn.csp.com          |                         |
             |-------------------------------------------------->|
             |                         |                         |(1)
             |                         | RRI REQ op-b.net        |
             |                         |<------------------------|
             |                         |                         |(2)
             |                         | RRI REPLY               |
             |                         |------------------------>|
             |                         |                         |(3)
             |CNAME b.cdn.csp.com      |                         |
             |NS records for b.cdn.csp.com                       |
             |<--------------------------------------------------|
             |DNS b.cdn.csp.com        |                         |
             |------------------------>|                         |
             |                         |(2)                      |
             |IPaddr of B's Delivery Node                        |
             |<------------------------|                         |
             |HTTP cdn.csp.com         |                         |
             |------------------------>|                         |
             |                         |(3)                      |
             |                         |DNS op-b-acq.op-a.net    |
             |                         |------------------------>|
             |                         |                         |(4)
             |                         |IPaddr of A's Delivery Node
             |                         |<------------------------|
             |                         |HTTP op-b-acq.op-a.net   |
             |                         |------------------------>|
             |                         |                         |(5)
             |                         |Data                     |
             |                         |<------------------------|
             |Data                     |                         |
             |<------------------------|                         |

      Figure 6: Request Trace for Dynamic Footprint Discovery Example

   This example differs from the one in Figure 5 only in the addition of
   a CDNI Request Routing Interface request (step 2) and corresponding
   response (step 3).  The RRI Req could be a message such as "Can you
   serve clients from this IP Prefix?" or it could be "Provide the list
   of client IP prefixes you can currently serve".  In either case the
   response might be cached by operator A to avoid repeatedly asking the
   same question.  Alternatively, or in addition, Operator B may
   spontaneously advertise to Operator A information (or changes) on the
   set of requests it is willing and able to serve on behalf of operator
   A; in that case, Operator B may spontaneously issue RRI REPLY
   messages that are not in direct response to a corresponding RRI REQ
   message.  (Note that the issues of determining the client's subnet



Davie & Peterson           Expires May 3, 2012                 [Page 27]


Internet-Draft               CDNI Framework                 October 2011


   from DNS requests, as described above, are exactly the same here as
   in Section 3.4.)

   Once Operator A obtains the RRI response, it is now able to determine
   that Operator B's CDN is an appropriate dCDN for this request and
   therefore a valid candidate dCDN to consider in its Redirection
   decision.  If that dCDN is selected, the redirection and serving of
   the request proceeds as before (i.e. in the absence of dynamic
   footprint discovery).

3.6.  Content Removal

   The following example illustrates how the Metadata interface may be
   used to remove an item of content.  In this example, user requests
   for a particular content, and corresponding redirection of such
   requests from Operator A to Operator B CDN, may (or may not) have
   taken place earlier.  Then, at some point in time, the uCDN (for
   example, in response to a corresponding trigger from the Content
   Provider) uses the Metadata Interface to request that content
   identified by a particular URL be removed from dCDN.  The following
   diagram illustrates the operation.
         End-User                 Operator B                Operator A
             |                         |MI purge cdn.csp.com/... |
             |                         |<------------------------|
             |                         |                         |(1)
             |                         |MI OK                    |
             |                         |------------------------>|
             |                         |                         |(2)


                Figure 7: Request Trace for Content Removal

   The metadata interface is used to convey the request from uCDN to
   dCDN that some previously acquired content should be deleted.  The
   URL in the request specifies which content to remove.  This example
   corresponds to a DNS-based redirection scenario such as Section 3.4.
   If HTTP-based redirection had been used, the URL for removal would be
   of the form peer-a.op-b.net/cdn.csp.com/...

   The dCDN is expected to confirm to the uCDN, as illustrated by the MI
   OK message, the completion of the removal of the targeted content
   from all the caches in dCDN.

3.7.  Pre-Positioned Content Acquisition Example

   The following example illustrates how the metadata interface may be
   used to pre-position an item of content in the dCDN.  In this
   example, Operator A uses the Metadata Interface to request that



Davie & Peterson           Expires May 3, 2012                 [Page 28]


Internet-Draft               CDNI Framework                 October 2011


   content identified by a particular URL be pre-positioned into
   Operator B CDN.

         End-User                 Operator B                Operator A

             |                         |MI pre-position cdn.csp.com/...
             |                         |<------------------------|
             |                         |                         |(1)
             |                         |MI OK                    |
             |                         |------------------------>|
             |                         |                         |
             |                         |DNS op-b-acq.op-a.net    |
             |                         |------------------------>|
             |                         |                         |(2)
             |                         |IPaddr of A's Delivery Node
             |                         |<------------------------|
             |                         |HTTP op-b-acq.op-a.net   |
             |                         |------------------------>|
             |                         |                         |(3)
             |                         |Data                     |
             |                         |<------------------------|
             |DNS cdn.csp.com          |                         |
             |-------------------------------------------------->|
             |                         |                         |(4)
             |IPaddr of A's Request Router                       |
             |<--------------------------------------------------|
             |HTTP cdn.csp.com         |                         |
             |-------------------------------------------------->|
             |                         |                         |(5)
             |302 peer-a.op-b.net/cdn.csp.com                    |
             |<--------------------------------------------------|
             |DNS peer-a.op-b.net      |                         |
             |------------------------>|                         |
             |                         |(6)                      |
             |IPaddr of B's Delivery Node                        |
             |<------------------------|                         |
             |HTTP peer-a.op-b.net/cdn.csp.com                   |
             |------------------------>|                         |
             |                         |(7)                      |
             |Data                     |                         |
             |<------------------------|                         |

            Figure 8: Request Trace for Content Pre-Positioning

   The steps illustrated in the figure are as follows:

   1.  Operator A uses the Metadata Interface to request that Operator B
       pre-positions a particular content item identified by its URL.



Davie & Peterson           Expires May 3, 2012                 [Page 29]


Internet-Draft               CDNI Framework                 October 2011


       Operator B responds by confirming that it is willing to perform
       this operation.

   Steps 2 and 3 are exactly the same as steps 5 and 6 of Figure 3, only
   this time those steps happen as the result of the Pre-positioning
   request instead of as the result of a cache miss.

   Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of
   Figure 3, only this time Operator B CDN can serve the end-user
   request without triggering dynamic content acquisition, since the
   content has been pre-positioned in dCDN.  Note that, depending on
   dCDN operations and policies, the content pre-positioned in the dCDN
   may be pre-positioned to all, or a subset of, dCDN caches.  In the
   latter case, intra-CDN dynamic content acquisition may take place
   inside the dCDN serving requests from caches on which the content has
   not been pre-positioning; however, such intra-CDN dynamic acquisition
   would not involve the uCDN.

3.8.  Asynchronous CDNI Metadata Example

   In this section we walk through a simple example illustrating a
   scenario of asynchronously exchanging CDNI metadata, where the
   downstream CDN obtains CDNI metadata for content ahead of a
   corresponding content request.  The example that follows assumes that
   HTTP-based inter-CDN redirection and recursive CDNI request-routing
   are used, as in Section 3.3.  However, asynchronous exchange of CDNI
   Metadata is similarly applicable to DNS-based inter-CDN redirection
   and iterative request routing (in which cases the CDNI metadata may
   be used at slightly different processing stages of the message
   flows).





















Davie & Peterson           Expires May 3, 2012                 [Page 30]


Internet-Draft               CDNI Framework                 October 2011


         End-User                 Operator B                Operator A
             |                         |                         |
             |                         |MI push (cdn.csp.com/...,|
             |                         |   distribution policy)  |
             |                         |<------------------------|(1)
             |                         |                         |
             |                         |                         |
             | CONTENT REQUEST         |                         |
             |-------------------------------------------------->| (2)
             |                         |                         |
             |                         |RRI REQ                  |
             |                      (3)|<------------------------|
             |                         |                         |
             |                         |                         |
             |                         |RRI RESP                 |
             |                         |------------------------>|(4)
             |                         |                         |
             | CONTENT REDIRECTION     |                         |
             |<--------------------------------------------------| (5)
             |                         |                         |
             | CONTENT REQUEST         |                         |
             |------------------------>| (6)                     |
             |                         |                         |
             :                         :                         :
             | CONTENT DATA            |                         |
             |<------------------------|                         | (7)


          Figure 9: Request Trace for Asynchronous CDNI Metadata

   The steps illustrated in the figure are as follows:

   1.  Operator A uses the Metadata Interface to asynchronously push
       CDNI metadata to Operator B. The present document does not
       constrain how the CDNI metadata information is actually
       represented.  For the purposes of this example, we assume that
       Operator A provides CDNI metadata to Operator B indicating that:

       *  this CDNI Metadata is applicable to any content referenced by
          "cdn.csp.com/op-b.net/..." (assuming HTTP redirection is used
          - it would be applicable to "cdn.csp.com/..." if DNS
          redirection were used as in Section 3.4).

       *  this CDNI metadata consists of a distribution policy requiring
          enforcement by the delivery node of a specific per-request
          authorization mechanism (e.g.  URI signature or token
          validation).




Davie & Peterson           Expires May 3, 2012                 [Page 31]


Internet-Draft               CDNI Framework                 October 2011


   2.  A Content Request occurs as usual.

   3.  A CDNI Request Routing Request (RRI REQ) is issued by operator A
       CDN, as discussed in Section 3.3.  Operator B's request router
       can access the CDNI Metadata that are relevant to the requested
       content and that have been pre-positioned as per Step 1, which
       may or may not affect the response.

   4.  Operator B's request router issues a CDNI Request Routing
       Response (RRI RESP) as in Section 3.3.

   5.  Operator B performs content redirection as discussed in
       Section 3.3.

   6.  On receipt of the Content Request by the end user, the delivery
       node detects that previously acquired CDNI metadata is applicable
       to the requested content.  In accordance with the specific CDNI
       metadata of this example, the delivery node will invoke the
       appropriate per-request authorization mechanism, before serving
       the content.  (Details of this authorization are not shown.)

   7.  Assuming successful per-request authorization, serving of Content
       Data (possibly preceded by inter-CDN acquisition) proceeds as in
       Section 3.3.

3.9.  Synchronous CDNI Metadata Acquisition Example

   In this section we walk through a simple example illustrating a
   scenario of synchronous CDNI metadata acquisition, in which the
   downstream CDN obtains CDNI metadata for content at the time of
   handling a first request for the corresponding content.  As in the
   preceding section, this example assumes that HTTP-based inter-CDN
   redirection and recursive CDNI request-routing are used (as in
   Section 3.3), but dynamic CDNI metadata acquisition is applicable to
   other variations of request routing.
















Davie & Peterson           Expires May 3, 2012                 [Page 32]


Internet-Draft               CDNI Framework                 October 2011


     End-User                 Operator B                Operator A
           |                         |                         |
           |                         |MI push (cdn.csp.com/...,|
           |                         |   CDNI metadata acquisition info)
           |                         |<------------------------|(1)
           |                         |                         |
           :                         :                         :
           | CONTENT REQUEST         |                         |
           |-------------------------------------------------->|(2)
           |                         |                         |
           |                         |RRI REQ                  |
           |                      (3)|<------------------------|
           |                         |                         |
           |                         |MI REQ                   |
           |                      (4)|------------------------>|
           |                         |MI RESP                  |
           |                         |<------------------------|(5)
           |                         |                         |
           |                         |RRI RESP                 |
           |                         |------------------------>|(6)
           |                         |                         |
           |                         |                         |
           | CONTENT REDIRECTION     |                         |
           |<--------------------------------------------------|(7)
           |                         |                         |
           | CONTENT REQUEST         |                         |
           |------------------------>| (8)                     |
           |                         |                         |
           |                         |MI REQ                   |
           |                      (9)|------------------------>|
           |                         |MI RESP                  |
           |                         |<------------------------|(10)
           |                         |                         |
           :                         :                         :
           | CONTENT DATA            |                         |
           |<------------------------|                         | (11)


    Figure 10: Request Trace for Synchronous CDNI Metadata Acquisition

   The steps illustrated in the figure are as follows:

   1.   Operator A initially uses the Metadata Interface to
        asynchronously push seed metadata to Operator B. For example,
        this seed information may include a URI indicating where CDNI
        Metadata can later be pulled from for some content set.  (There
        are alternative ways that this seeding information may be
        provided, such as piggybacking on the CDNI RRI REQ message of



Davie & Peterson           Expires May 3, 2012                 [Page 33]


Internet-Draft               CDNI Framework                 October 2011


        Step 3.)

   2.   A Content Request arrives as normal.

   3.   A Request Routing Interface request occurs as in the prior
        example.

   4.   On receipt of the CDNI Request Routing Request, Operator B's CDN
        initiates synchronous acquisition of CDNI Metadata that are
        needed for routing of the end-user request.  The seeding
        information provided in Step 1 is used to determine how to
        obtain the metadata.  Note that there may exist cases in which
        this step does not occur (e.g., because the CDNI metadata
        seeding information indicates CDNI metadata are not needed at
        that stage).

   5.   On receipt of a CDNI Metadata MI Request, Operator A's CDN
        responds, making the corresponding CDNI metadata information
        available to Operator B's CDN.  This metadata is considered by
        operator B's CDN before responding to the Request Routing
        request.  (In a simple case, the metadata could simply be an
        allow or deny response for this particular request.)

   6.   Response to the RRI request as normal.

   7.   Redirection message is sent to the end user.

   8.   A delivery node of Operator B receives the end user request.

   9.   The delivery node triggers dynamic acquisition of additional
        CDNI metadata that are needed to process the end-user content
        request.  Again the seeding information provided in Step 1 is
        used to determine how to acquire the needed CDNI metadata.  Note
        that there may exist cases where this step need not happen,
        either because the metadata were already acquired previously, or
        because the seeding information indicates no metadata are
        required.

   10.  Operator A's CDN responds to the CDNI Metadata Request and makes
        the corresponding CDNI metadata available to Operator B. This
        metadata influence how Operator B's CDN processes the end-user
        request.

   11.  Content is served (possibly preceded by inter-CDN acquisition)
        as in Section 3.3.






Davie & Peterson           Expires May 3, 2012                 [Page 34]


Internet-Draft               CDNI Framework                 October 2011


4.  Main Interfaces

   Figure 1 illustrates the four main interfaces that are in scope for
   the CDNI WG, along with several others.  The detailed specifications
   of these interfaces are left to other documents (mostly still to be
   written, but see [I-D.ietf-cdni-problem-statement] and
   [I-D.ietf-cdni-requirements] for some discussion of the interfaces).

   One interface that is not shown in Figure 1 is the interface between
   the user and the CSP.  While for the purposes of CDNI that interface
   is out of scope, it is worth noting that it does exist and can
   provide useful functions, such as end-to-end performance monitoring
   and some forms of authentication and authorization.

   There is also an important interface between the user and the Request
   Routing function of both uCDN and dCDN.  As we saw in some of the
   preceding examples, that interface can be used as a way of passing
   information such as the metadata that is required to obtain the
   content in dCDN from uCDN.

   In this section we will provide an overview of the functions
   performed by each of the CDNI interfaces and discuss how they fit
   into the overall solution.  We also examine some of the design
   tradeoffs.  We begin with an examination of one such tradeoff that
   affects all the interfaces - the use of in-band or out-of-band
   communication.

4.1.  In-Band versus Out-of-Band Interfaces

   Before getting to the individual interfaces, we observe that there is
   a high-level design choice for each, involving the use of existing
   in-band communication channels versus defining new out-of-band
   interfaces.

   It is possible that the information needed to carry out various
   interconnection functions can be communicated between peer CDNs using
   existing in-band protocols.  The use of HTTP 302 redirect is an
   example of how certain aspects of request routing can be implemented
   in-band (embedded in URIs).  Note that using existing in-band
   protocols does not imply that the CDNI interfaces are null; it is
   still necessary to establish the rules (conventions) by which such
   protocols are used to implement the various interface functions.

   There are other opportunities for in-band communication beyond HTTP
   redirects.  For example, many of the HTTP directives used by proxy
   servers can also be used by peer CDNs to inform each other of caching
   activity.  Of these, one that is particularly relevant is the If-
   Modified-Since directive, which is used with the GET method to make



Davie & Peterson           Expires May 3, 2012                 [Page 35]


Internet-Draft               CDNI Framework                 October 2011


   it conditional: if the requested object has not been modified since
   the time specified in this field, a copy of the object will not be
   returned, and instead, a 304 (not modified) response will be
   returned.

4.2.  Request Routing Interface

   We may think of the request routing interface as comprising two
   parts: the asynchronous advertisement of footprint and capabilities
   by a dCDN that allows a uCDN to decide whether to redirect particular
   user requests to that dCDN; and the synchronous operation of actually
   redirecting a user request.  (These are somewhat analogous to the
   operations of routing and forwarding in IP.)

   As illustrated in Section 3, the synchronous part of the request
   routing interface may be implemented in part by DNS and HTTP.  Naming
   conventions may be established by which CDN peers communicate whether
   a request should be routed or content served.

   In support of these exchanges, it is necessary for CDN peers to
   exchange additional information with each other.  Depending on the
   method(s) supported, this includes

   o  The operator's unique id (operator-id) or distinguished CDN-domain
      (operator-domain);

   o  NS records for the operator's set of externally visible request
      routers;

   o  The set of requests the dCDN operator is prepared to serve (e.g. a
      set of client IP prefixes or geographic regions that may be served
      by dCDN).

   Of these, the two operator identifiers are fixed, and can be
   exchanged off-line as part of a peering agreement.  The NS records
   potentially change with some frequency, but an existing protocol--
   DNS--can be used to dynamically track this information.  That is, a
   peer can do a DNS lookup on operator-domain to retrieve the set of NS
   records corresponding to the peer's redirection service.

   The set of requests that dCDN is willing to serve could in some cases
   be relatively static (e.g., a set of IP prefixes) which could be
   exchanged off-line, or might even be negotiated as part of a peering
   agreement.  However, it may also be more dynamic, in which case an
   explicit protocol for its exchange would be be helpful.

   A variety of options exist for the dCDN operator to advertise its
   footprint to uCDN.  As discussed in



Davie & Peterson           Expires May 3, 2012                 [Page 36]


Internet-Draft               CDNI Framework                 October 2011


   [I-D.previdi-cdni-footprint-advertisement], footprint is comprised of
   two components:

   o  a class of end user requests (represented, for example, by a set
      of IP prefixes, or a geographic region) that the dCDN is willing
      and able to serve directly, without use of another dCDN;

   o  the connectivity of the dCDN to other CDNs that may be able to
      serve content to users on behalf of dCDN.

   [I-D.previdi-cdni-footprint-advertisement] describes an approach to
   advertising such footprint information asynchronously using BGP.  In
   addition to this sort of information, a dCDN might also advertise
   "capabilities" such as the ability to handle certain types of content
   (e.g. specific streaming formats) or quality of service (QoS)
   capabilities.  [I-D.xiaoyan-cdni-request-routing-protocol] describes
   an approach that exchanges CDN "capabilities" over HTTP, while
   [I-D.seedorf-alto-for-cdni] describes how ALTO [RFC5693] may be used
   to obtain request routing information.

   We also note that the Request Routing interface plays a key role in
   enabling recursive redirection, as illustrated in Section 3.3.  It
   enables the user to be redirected to the correct delivery node in
   dCDN with only a single redirection step (as seen by the user).  This
   may be particularly valuable as the chain of interconnected CDNs
   increases beyond two CDNs.

4.3.  Logging Interface

   It is necessary for the upstream CDN to have visibility into the
   delivery of content it originates to end-users connected to the
   downstream CDN.  This allows the upstream CDN to properly bill its
   customers for multiple deliveries of content cached by the downstream
   CDN, as well as to report accurate traffic statistics to those
   content providers.  This is one role of the Logging interface.

   Other operational data that may be relevant to CDNI can also be
   exchanged by the Logging interface.  For example, dCDN may report the
   amount of content it has acquired from uCDN, and how much cache
   storage has been consumed by content cached on behalf of uCDN.

   Traffic logs are easily exchanged off-line.  For example, the
   following traffic log is a small deviation from the Apache log file
   format, where entries include the following fields:

   o  Domain - the full domain name of the origin server





Davie & Peterson           Expires May 3, 2012                 [Page 37]


Internet-Draft               CDNI Framework                 October 2011


   o  IP address - the IP address of the client making the request

   o  End time - the ending time of the transfer

   o  Time zone - any time zone modifier for the end time

   o  Method - the transfer command itself (e.g., GET, POST, HEAD)

   o  URL - the requested URL

   o  Version - the protocol version, such as HTTP/1.0

   o  Response - a numeric response code indicating transfer result

   o  Bytes Sent - the number of bytes in the body sent to the client

   o  Request ID - a unique identifier for this transfer

   o  User agent - the user agent, if supplied

   o  Duration - the duration of the transfer in milliseconds

   o  Cached Bytes - the number of body bytes served from the cache

   o  Referrer - the referrer string from the client, if supplied

   Of these, only the Domain field is indirect in the downstream CDN--it
   is set to the CDN-domain used by the upstream CDN rather than the
   actual origin server.  This field could then used to filter traffic
   log entries so only those entries matching the upstream CDN are
   reported to the corresponding operator.

   One open question is who does the filtering.  One option is that the
   downstream CDN filters its own logs, and passes the relevant records
   directly to each upstream peer.  This requires that the downstream
   CDN knows the set of CDN-domains that belong to each upstream peer.
   If this information is already exchanged between peers as part of the
   request routing interface, then direct peer-to-peer reporting is
   straightforward.  If it is not available, and operators do not wish
   to advertise the set of CDN-domains they serve to their peers, then
   the second option is for each CDN to send both its non-local traffic
   records and the set of CDN-domains it serves to an independent third-
   party (i.e., a CDN Exchange), which subsequently filters, merges, and
   distributes traffic records on behalf of each participating CDN
   operator.

   A second open question is how timely traffic information should be.
   For example, in addition to off-line traffic logs, accurate real-time



Davie & Peterson           Expires May 3, 2012                 [Page 38]


Internet-Draft               CDNI Framework                 October 2011


   traffic monitoring might also be useful, but such information
   requires that the downstream CDN inform the upstream CDN each time it
   serves upstream content from its cache.  The downstream CDN can do
   this, for example, by sending a conditional HTTP GET request (If-
   Modified-Since) to the upstream CDN each time it receives an HTTP GET
   request from one of its end-users.  This allows the upstream CDN to
   record that a request has been issued for the purpose of real-time
   traffic monitoring.  The upstream CDN can also use this information
   to validate the traffic logs received later from the downstream CDN.

   There is obviously a tradeoff between accuracy of such monitoring and
   the overhead of the downstream CDN having to go back to the upstream
   CDN for every request.

   Another design tradeoff in the Logging interface is the degree of
   aggregation or summarization of data.  One situation that lends
   itself to summarization is the delivery of HTTP-based adaptive bit-
   rate video.  Most schemes to deliver such video use a large number of
   relatively small HTTP requests (e.g. one request per 2-second chunk
   of video.)  It may be desirable to aggregate logging information so
   that a single log entry is provided for the entire video rather than
   for each chunk.  Note however that such aggregation requires a degree
   of application awareness in dCDN to recognize that the many HTTP
   requests correspond to a single video.

   Other forms of aggregation may also be useful.  For example, there
   may be situations where bulk metrics such as bytes delivered per hour
   may suffice rather than the detailed per-request logs outlined above.
   It seems likely that a range of granularities of logging will be
   needed along with ways to specify the type and degree of aggregation
   required.

4.4.  Control Interface

   The control interface is primarily used for the bootstrapping of
   other interfaces.  As a simple example, it could be used to provide
   the address of the logging server in dCDN to uCDN in order to
   bootstrap the logging interface.  It may also be used, for example,
   to establish security associations for the other interfaces.  We
   discuss the relationship between the Control and Metadata interfaces
   in the next section.

4.5.  Metadata Interface

   The role of the metadata interface is to enable CDNI distribution
   metadata to be conveyed to the downstream CDN by the upstream CDN.
   Such metadata includes geo-blocking restrictions, availability
   windows, access control policies, and so on.  It may also include



Davie & Peterson           Expires May 3, 2012                 [Page 39]


Internet-Draft               CDNI Framework                 October 2011


   policy information such as the desire to pre-position content rather
   than fetch it on demand.

   Some metadata may be able to be conveyed using in-band mechanisms.
   For example, to inform the downstream CDN of any geo-blocking
   restrictions or availability windows, the upstream can elect to
   redirect a request to the downstream CDN only if that CDN's
   advertised delivery footprint is acceptable for the requested URL.
   Similarly, the request could be forwarded only if the current time is
   within the availability window.

   Similarly, some forms of access control may also be performed on a
   per-request basis using HTTP directives.  For example, being able to
   respond to a conditional GET request gives the upstream CDN an
   opportunity to influence how the downstream CDN delivers its content.
   Minimally, the upstream CDN can invalidate (purge) content previously
   cached by the downstream CDN.

   Fine-grain control over how the downstream CDN delivers content on
   behalf of the upstream CDN is also possible.  For example, by
   including the X-Forwarded-For HTTP header with the conditional GET
   request, the downstream CDN can report the end-user's IP address to
   the upstream CDN, giving it an opportunity to control whether the
   downstream CDN should serve the content to this particular end-user.
   The upstream CDN would communicate its directive through its response
   to the conditional GET.  The downstream CDN can cache information for
   a period of time specified by the upstream CDN, thereby reducing
   control overhead.

   Thinking beyond what metadata operations can be done in-line, we note
   that all CDNs already export a "content purge" operation to their
   customers.  The CDNI metadata interface could support a similar
   "content purge" API call.  When a CSP invokes purge on the upstream
   CDN, that CDN in turn invokes purge on all downstream CDNs that might
   be caching the content.  Of course, agreement as to the syntax and
   semantics of this call is required.

   One open question is how to distinguish between what functionality is
   supported by the Metadata interface and what functionality is
   supported by the Control interface.  The approach taken in this
   document is to assume a minimal Control interface that is used to
   bootstrap the other interfaces.  We assume all information that
   governs peer CDN behavior at the granularity of individual content
   items is exchanged via the Metadata interface.  We note that some
   other documents have suggested that the purge operation should be
   part of the Control Interface.  The authors' view is that purging a
   piece of content is just another form of metadata, similar to an
   availability window.  In effect, a purge is equivalent to a statement



Davie & Peterson           Expires May 3, 2012                 [Page 40]


Internet-Draft               CDNI Framework                 October 2011


   that the availability window for that content has now expired.  The
   timeliness requirements for purge operations may affect the detailed
   design of the metadata interface.


5.  Deployment Models

   In this section we describe a number of possible deployment models
   that may be achieved using the CDNI interfaces described above.  We
   note that these models are by no means exhaustive, and that may other
   models may be possible.

   Although the reference model of Figure 1 shows all CDN functions on
   each side of the CDNI interface, deployments can rely on entities
   that are involved in any subset of these functions, and therefore
   only support the relevant subset of CDNI interfaces.  As already
   noted in Section 3, effective CDNI deployments can be built without
   necessarily implementing all four interfaces.  Some examples of such
   deployments are shown below.

   Note that, while we refer to upstream and downstream CDNs, this
   distinction applies to specific content items and transactions.  That
   is, a given CDN may be upstream for some transactions and downstream
   for others, depending on many factors such as location of the
   requesting client and the particular piece of content requested.

5.1.  Meshed CDNs

   Although the reference model illustrated in Figure 1 shows a
   unidirectional CDN interconnection with a single uCDN and a single
   dCDN, any arbitrary CDNI meshing can be built from this, such as the
   example meshing illustrated in Figure 11.  (Support for arbitrary
   meshing may or may not be in the initial scope for the working group,
   but the model allows for it.)

















Davie & Peterson           Expires May 3, 2012                 [Page 41]


Internet-Draft               CDNI Framework                 October 2011


         -------------             -----------
        /    CDN A    \<==CDNI===>/   CDN B   \
        \             /           \           /
         -------------             -----------
              /\      \\                 /\
              ||       \\                ||
             CDNI       \==CDNI===\\    CDNI
              ||                   \\    ||
              \/                   \/    \/
         -------------             -----------
        /    CDN C    \===CDNI===>/   CDN D   \
        \             /           \           /
         -------------             -----------
              /\
              ||
             CDNI
              ||
              \/
         -------------
        /    CDN E    \
        \             /
         -------------

      ===>  CDNI interfaces, with right-hand side CDN acting as dCDN
            to left-hand side CDN
      <==>  CDNI interfaces, with right-hand side CDN acting as dCDN
            to left-hand side CDN and with left-hand side CDN acting
            as dCDN to right-hand side CDN

           Figure 11: CDNI Deployment Model: CDN Meshing Example

5.2.  CSP combined with CDN

   Note that our terminology refers to functional roles and not economic
   or business roles.  That is, a given organization may be operating as
   both a CSP and a fully-fledged uCDN when we consider the functions
   performed, as illustrated in Figure 12.














Davie & Peterson           Expires May 3, 2012                 [Page 42]


Internet-Draft               CDNI Framework                 October 2011


   #####################################       ##################
   #                                   #       #                #
   #       Organization A              #       # Organization B #
   #                                   #       #                #
   #     --------       -------------  #       #  -----------   #
   #    /   CSP  \     /   uCDN      \ #       # /   dCDN    \  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |     |  | C  |     | #       # |  | C  |   |  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |     |  | L  |     | #       # |  | L  |   |  #
   #    |        |*****|  +----+     |===CDNI===>|  +----+   |  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |     |  | RR |     | #       # |  | RR |   |  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |     |  | D  |     | #       # |  | D  |   |  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    \        /     \             / #       # \           /  #
   #     --------       -------------  #       #  -----------   #
   #                                   #       #                #
   #####################################       ##################

   ===>  CDNI interfaces, with right-hand side CDN acting as dCDN
         to left-hand side CDN
   ****  interfaces outside the scope of CDNI
   C     Control component of the CDN
   L     Logging component of the CDN
   RR    Request Routing component of the CDN
   D     Distribution component of the CDN

    Figure 12: CDNI Deployment Model: Organization combining CSP & uCDN

5.3.  CSP using CDNI Request Routing Interface

   As another example, a content provider organization may choose to run
   its own request routing function as a way to select among multiple
   candidate CDN providers; In this case the content provider may be
   modeled as the combination of a CSP and of a special, restricted case
   of a CDN.  In that case, as illustrated in Figure 13, the CDNI
   Request Routing interface can be used between the restricted CDN
   operated by the content provider Organization and the CDN operated by
   the full-CDN organization acting as a dCDN in the request routing
   control plane.  Interfaces outside the scope of the CDNI work can be
   used between the CSP functional entities of the content provider
   organization and the CDN operated by the full-CDN organization acting
   as a uCDN) in the CDNI control planes other than the request routing
   plane (i.e.  Control, Distribution, Logging).



Davie & Peterson           Expires May 3, 2012                 [Page 43]


Internet-Draft               CDNI Framework                 October 2011


   #####################################       ##################
   #                                   #       #                #
   #       Organization A              #       # Organization B #
   #                                   #       #                #
   #     --------       -------------  #       #  -----------   #
   #    /   CSP  \     /  uCDN(RR)   \ #       # /  dCDN(RR) \  #
   #    |        |     |  +----+     | #       # |  +----+   |  #
   #    |        |*****|  | RR |==========CDNI=====>| RR |   |  #
   #    |        |     |  +----+     | #   RR  # |  +----+   |  #
   #    |        |     \             / #       # |           |  #
   #    |        |      -------------  #       # |uCDN(C,L,D)|  #
   #    |        |                     #       # |  +----+   |  #
   #    |        |                     #       # |  | C  |   |  #
   #    |        |*******************************|  +----+   |  #
   #    |        |                     #       # |  +----+   |  #
   #    |        |                     #       # |  | L  |   |  #
   #    |        |                     #       # |  +----+   |  #
   #    |        |                     #       # |  +----+   |  #
   #    |        |                     #       # |  | D  |   |  #
   #    |        |                     #       # |  +----+   |  #
   #    \        /                     #       # \           /  #
   #     --------                      #       #  -----------   #
   #                                   #       #                #
   #####################################       ##################

   ===>  CDNI Request Routing interface
   ****  interfaces outside the scope of CDNI

     Figure 13: CDNI Deployment Model: Organization combining CSP and
                                partial CDN

5.4.  CDN Federations and CDN Exchanges

   There are two additional concepts related to, but distinct from CDN
   Interconnection.  The first is CDN Federation.  Our view is that CDNI
   is the more general concept, involving two or more CDNs serving
   content to each other's users, while federation implies a multi-
   lateral interconnection arrangement, but other CDN interconnection
   agreements are also possible (e.g., symmetric bilateral, asymmetric
   bilateral).  An important conclusion is that CDNI technology should
   not presume (or bake in) a particular interconnection agreement, but
   should instead be general enough to permit alternative
   interconnection arrangements to evolve.

   The second concept often used in the context of CDN Federation is CDN
   Exchange--a third party broker or exchange that is used to facilitate
   a CDN federation.  Our view is that a CDN exchange offers valuable
   machinery to scale the number of CDN operators involved in a multi-



Davie & Peterson           Expires May 3, 2012                 [Page 44]


Internet-Draft               CDNI Framework                 October 2011


   lateral (federated) agreement, but that this machinery is built on
   top of the core CDNI interconnection mechanisms.  For example, as
   illustrated in Figure 14, the exchange might aggregate and
   redistribute information about each CDN footprint and capacity, as
   well as collect, filter, and re-distribute traffic logs that each
   participant needs for interconnection settlement, but inter-CDN
   request routing, inter-CDN content distribution (including inter-CDN
   acquisition) and inter-CDN control which fundamentally involve a
   direct interaction between an upstream CDN and a downstream CDN--
   operate exactly as in a pair-wise peering arrangement.  Turning to
   Figure 14, we observe that in this example:

   o  each CDN supports a direct CDNI Control interface to every other
      CDN

   o  each CDN supports a direct CDNI Metadata interface to every other
      CDN

   o  each CDN supports a CDNI Logging interface with the CDN Exchange

   o  each CDN supports both a CDNI request Routing interface with the
      CDN Exchange (for aggregation and redistribution of dynamic CDN
      footprint discovery information) and a direct CDNI Request Routing
      interface to every other CDN (for actual request redirection).



























Davie & Peterson           Expires May 3, 2012                 [Page 45]


Internet-Draft               CDNI Framework                 October 2011


             ----------                            ---------
            /    CDN A \                          /   CDN B  \
            | +----+   |                         |  +----+   |
   //========>| C  |<==============CDNI============>| C  |<==========\\
   ||       | +----+   |            C            |  +----+   |       ||
   ||       | +----+   |                         |  +----+   |       ||
   || //=====>| D  |<==============CDNI============>| D  |<=======\\ ||
   || ||    | +----+   |            M            |  +----+   |    || ||
   || ||    |          |     /------------\      |           |    || ||
   || ||    | +----+   |     | +--+ CDN Ex|      |  +----+   |    || ||
   || || //==>| RR |<===CDNI==>|RR|<=======CDNI====>| RR |<====\\ || ||
   || || || | +----+   | RR  | +--+       | RR   |  +----+   | || || ||
   || || || |          |     |  /\        |      |           | || || ||
   || || || | +----+   |     |  ||  +---+ |      |  +----+   | || || ||
   || || || | | L  |<===CDNI=======>| L |<=CDNI====>| L  |   | || || ||
   || || || | +----+   |  L  |  ||  +---+ |  L   |  +----+   | || || ||
   || || || \          /     \  ||    /\  /      \           / || || ||
   || || || -----------       --||----||--        -----------  || || ||
   || || ||                     ||    ||                       || || ||
   || || ||                  CDNI RR  ||                       || || ||
   || || ||                     ||   CDNI L                    || || ||
   || || ||                     ||    ||                       || || ||
   || || ||                  ---||----||----                   || || ||
   || || ||                 /   \/    ||    \                  || || ||
   || || ||                 |  +----+ ||    |                  || || ||
   || || \\=====CDNI==========>| RR |<=============CDNI========// || ||
   || ||         RR         |  +----+ \/    |       RR            || ||
   || ||                    |        +----+ |                     || ||
   || ||                    |        | L  | |                     || ||
   || ||                    |        +----+ |                     || ||
   || ||                    |  +----+       |                     || ||
   || \\=======CDNI===========>| D  |<=============CDNI===========// ||
   ||           M           |  +----+       |       M                ||
   ||                       |  +----+       |                        ||
   \\==========CDNI===========>| C  |<=============CDNI==============//
                C           |  +----+       |       C
                            \        CDN C  /
                             --------------

   <=CDNI RR=>     CDNI Request Routing interface
   <=CDNI M==>     CDNI Metadata interface
   <=CDNI C==>     CDNI Control interface
   <=CDNI L==>     CDNI Logging interface

              Figure 14: CDNI Deployment Model: CDN Exchange

   Note that a CDN exchange may alternatively support a different set of
   functionality (e.g.  Logging only, or Logging and full request



Davie & Peterson           Expires May 3, 2012                 [Page 46]


Internet-Draft               CDNI Framework                 October 2011


   routing, or all the functionality of a CDN including content
   distribution).  All these options are expected to be allowed by the
   IETF CDNI specifications.


6.  Trust Model

   There are a number of trust issues that need to be addressed by a
   CDNI solution.  Many of them are in fact similar or identical to
   those in a simple CDN without interconnection.  In a standard CDN
   environment (without CDNI), the CSP places a degree of trust in a
   single CDN operator to perform many functions.  The CDN is trusted to
   deliver content with appropriate quality of experience for the end
   user.  The CSP trusts the CDN operator not to corrupt or modify the
   content.  The CSP often relies on the CDN operator to provide
   reliable accounting information regarding the volume of delivered
   content.  The CSP may also trust the CDN operator to perform actions
   such as timely invalidation of content and restriction of access to
   content based on certain criteria such as location of the user and
   time of day, and to enforce per-request authorization performed by
   the CSP using techniques such as URI signing.

   A CSP also places trust in the CDN not to distribute any information
   that is confidential to the CSP (e.g., how popular a given piece of
   content is) or confidential to the end user (e.g., which content has
   been watched by which user).

   A CSP does not necessarily have to place complete trust in a CDN.  A
   CSP will in some cases take steps to protect its content from
   improper distribution by a CDN, e.g. by encrypting it and
   distributing keys in some out of band way.  A CSP also depends on
   monitoring (possibly by third parties) and reporting to verify that
   the CDN has performed adequately.  A CSP may use techniques such as
   client-based metering to verify that accounting information provided
   by the CDN is reliable.  HTTP conditional requests may be used to
   provide the CSP with some checks on CDN operation.  In other words,
   while a CSP may trust a CDN to perform some functions in the short
   term, the CSP is able in most cases to verify whether these actions
   have been performed correctly and to take action (such as moving the
   content to a different CDN) if the CDN does not live up to
   expectations.

   The main trust issue raised by CDNI is that it introduces transitive
   trust.  A CDN that has a direct relationship with a CSP can now
   "outsource" the delivery of content to another (downstream) CDN.
   That CDN may in term outsource delivery to yet another downstream
   CDN, and so on.




Davie & Peterson           Expires May 3, 2012                 [Page 47]


Internet-Draft               CDNI Framework                 October 2011


   The top level CDN in such a chain of delegation is responsible for
   ensuring that the requirements of the CSP are met.  Failure to do so
   is presumably just as serious as in the traditional single CDN case.
   Hence, an upstream CDN is essentially trusting a downstream CDN to
   perform functions on its behalf in just the same way as a CSP trusts
   a single CDN.  Monitoring and reporting can similarly be used to
   verify that the downstream CDN has performed appropriately.  However,
   the introduction of multiple CDNs in the path between CSP and end
   user complicates the picture.  For example, third party monitoring of
   CDN performance (or other aspects of operation, such as timely
   invalidation) might be able to identify the fact that a problem
   occurred somewhere in the chain but not point to the particular CDN
   at fault.

   In summary, we assume that an upstream CDN will invest a certain
   amount of trust in a downstream CDN, but that it will verify that the
   downstream CDN is performing correctly, and take corrective action
   (including potentially breaking off its relationship with that CDN)
   if behavior is not correct.  We do not expect that the trust
   relationship between a CSP and its "top level" CDN will differ
   significantly from that found today in single CDN situations.
   However, it does appear that more sophisticated tools and techniques
   for monitoring CDN performance and behavior will be required to
   enable the identification of the CDN at fault in a particular
   delivery chain.

   We expect that the detailed designs for the specific interfaces for
   CDNI will need to take the transitive trust issues into account.  For
   example, explicit confirmation that some action (such as content
   removal) has taken place in a downstream CDN may help to mitigate
   some issues of transitive trust.


7.  IANA Considerations

   This memo includes no request to IANA.


8.  Security Considerations

   While there is a variety of security issues introduced by a single
   CDN, we are concerned here specifically with the additional issues
   that arise when CDNs are interconnected.  For example, when a single
   CDN has the ability to distribute content on behalf of a CSP, there
   may be concerns that such content could be distributed to parties who
   are not authorized to receive it, and there are mechanisms to deal
   with such concerns.  Our focus in this section is on how CDN
   interconnection introduces new security issues not found in the



Davie & Peterson           Expires May 3, 2012                 [Page 48]


Internet-Draft               CDNI Framework                 October 2011


   single CDN case.

   Many of the security issues that arise in CDNI are related to the
   transitivity of trust (or lack thereof) described in Section 6.  As
   noted above, the design of the various interfaces for CDNI must take
   account of the additional risks posed by the fact that a CDN with
   whom a CSP has no direct relationship is now potentially distributing
   content for that CSP.  The mechanisms used to mitigate these risks
   may be similar to those used in the single CDN case, but their
   suitability in this more complex environment must be validated.

   Another concern that arises in any CDN is that information about the
   behavior of users (what content they access, how much content they
   consume, etc.) may be gathered by the CDN.  This risk certainly
   exists in inter-connected CDNs, but it should be possible to apply
   the same techniques to mitigate it as in the single CDN case.

   CDNs today offer a variety of means to control access to content,
   such as time-of-day restrictions, geo-blocking, and URI signing.
   These mechanisms must continue to function in CDNI environments, and
   this consideration is likely to affect the design of certain CDNI
   interfaces (e.g. metadata, request routing.)

   Just as with a single CDN, each peer CDN must ensure that it is not
   used as an "open proxy" to deliver content on behalf of a malicious
   CSP.  Whereas a single CDN typically addresses this problem by having
   CSPs explicitly register content (or origin servers) that is to be
   served, simply propagating this information to peer downstream CDNs
   may be problematic because it reveals more information than the
   upstream CDN is willing to specify.  (To this end, the content
   acquisition step in the earlier examples force the dCDN to retrieve
   content from the uCDN rather than go directly to the origin server.)

   There are several approaches to this problem.  One is for the uCDN to
   encoded a signed token generated from a shared secret in each URL
   routed to a dCDN, and for the dCDN to validate the request based on
   this token.  Another one is to have each upstream CDN advertise the
   set of CDN-domains they serve, where the downstream CDN checks each
   request against this set before caching and delivering the associated
   object.  Although straightforward, this approach requires operators
   to reveal additional information, which may or may not be an issue.

8.1.  Security of CDNI Interfaces

   It is noted in [I-D.ietf-cdni-requirements] that all CDNI interfaces
   must be able to operate securely over insecure IP networks.  Since it
   is expected that the CDNI interfaces will be implemented using
   existing application protocols such as HTTP or XMPP, we also expect



Davie & Peterson           Expires May 3, 2012                 [Page 49]


Internet-Draft               CDNI Framework                 October 2011


   that the security mechanisms available to those protocols may be used
   by the CDNI interfaces.  Details of how these interfaces are secured
   will be specified in the relevant interface documents.

8.2.  Digital Rights Management

   Issues of digital rights management (DRM, also sometimes called
   digital restrictions management) is often employed for content
   distributed via CDNs.  In general, DRM relies on the CDN to
   distribute encrypted content, with decryption keys distributed to
   users by some other means (e.g. directly from the CSP to the end
   user.)  For this reason, DRM is considered out of scope for the CDNI
   WG [I-D.ietf-cdni-problem-statement] and does not introduce
   additional security issues for CDNI.


9.  Contributors

   The following individuals contributed to this document:

   o  Francois le Faucheur

   o  Ben Niven-Jenkins

   o  David Ferguson

   o  John Hartman


10.  Acknowledgements

   We thank Aaron Falk and Huw Jones for their helpful input to the
   draft.


11.  Informative References

   [I-D.ietf-cdni-problem-statement]
              Niven-Jenkins, B., Faucheur, F., and N. Bitar, "Content
              Distribution Network Interconnection (CDNI) Problem
              Statement", draft-ietf-cdni-problem-statement-01 (work in
              progress), October 2011.

   [I-D.ietf-cdni-requirements]
              Leung, K. and Y. Lee, "Content Distribution Network
              Interconnection (CDNI) Requirements",
              draft-ietf-cdni-requirements-01 (work in progress),
              October 2011.



Davie & Peterson           Expires May 3, 2012                 [Page 50]


Internet-Draft               CDNI Framework                 October 2011


   [I-D.ietf-cdni-use-cases]
              Bertrand, G., Emile, S., Watson, G., Burbridge, T.,
              Eardley, P., and K. Ma, "Use Cases for Content Delivery
              Network Interconnection", draft-ietf-cdni-use-cases-00
              (work in progress), September 2011.

   [I-D.previdi-cdni-footprint-advertisement]
              Previdi, S., Faucheur, F., Faucheur, L., and J. Medved,
              "CDNI Footprint Advertisement",
              draft-previdi-cdni-footprint-advertisement-00 (work in
              progress), October 2011.

   [I-D.seedorf-alto-for-cdni]
              Seedorf, J., "ALTO for CDNi Request Routing",
              draft-seedorf-alto-for-cdni-00 (work in progress),
              October 2011.

   [I-D.vandergaast-edns-client-subnet]
              Contavalli, C., Gaast, W., Leach, S., and D. Rodden,
              "Client subnet in DNS requests",
              draft-vandergaast-edns-client-subnet-00 (work in
              progress), January 2011.

   [I-D.xiaoyan-cdni-request-routing-protocol]
              He, X., Li, J., Dawkins, S., and G. Chen, "Request Routing
              Protocol for CDN Interconnection",
              draft-xiaoyan-cdni-request-routing-protocol-00 (work in
              progress), October 2011.

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

   [RFC5693]  Seedorf, J. and E. Burger, "Application-Layer Traffic
              Optimization (ALTO) Problem Statement", RFC 5693,
              October 2009.


Authors' Addresses

   Bruce Davie (editor)
   Cisco Systems, Inc.
   1414 Mass. Ave.
   Boxborough, MA  01719
   USA

   Email: bsd@cisco.com




Davie & Peterson           Expires May 3, 2012                 [Page 51]


Internet-Draft               CDNI Framework                 October 2011


   Larry Peterson (editor)
   Verivue, Inc.
   2 Research Way
   Princeton, NJ
   USA

   Phone: +1 978 303 8032
   Email: lpeterson@verivue.com











































Davie & Peterson           Expires May 3, 2012                 [Page 52]


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