<?xml version="1.0" encoding="US-ASCII"?>
<!DOCTYPE rfc SYSTEM "rfc2629.dtd">
<?rfc toc="yes"?>
<?rfc tocompact="yes"?>
<?rfc tocdepth="3"?>
<?rfc tocindent="yes"?>
<?rfc symrefs="yes"?>
<?rfc sortrefs="yes"?>
<?rfc comments="yes"?>
<?rfc inline="yes"?>
<?rfc compact="yes"?>
<?rfc subcompact="no"?>
<rfc category="info" docName="draft-ietf-cdni-framework-00" ipr="trust200902">
  <front>
    <title abbrev="CDNI Framework">Framework for CDN Interconnection</title>

    <author fullname="Larry Peterson" initials="L. " role="editor"
            surname="Peterson">
      <organization>Verivue, Inc.</organization>

      <address>
        <postal>
          <street>2 Technology Park Drive</street>

          <city>Westford</city>

          <region>MA</region>

          <code></code>

          <country>USA</country>
        </postal>

        <phone>+1 978 303 8032</phone>

        <email>lpeterson@verivue.com</email>
      </address>
    </author>
    
    <author fullname="Bruce Davie" initials="B."  surname="Davie">
     <organization>Nicira Networks, Inc.</organization>

     <address>
       <postal>
         <street>3460 W. Bayshore Rd.</street>

         <!-- Reorder these if your country does things differently -->

         <city>Palo Alto</city>

         <region>CA</region>

         <code>94303</code>

         <country>USA</country>
       </postal>

       <email>bsd@nicira.com</email>

       <!-- uri and facsimile elements may also be added -->
     </address>
   </author>


    <date day="27" month="April" year="2012" />

    <abstract>
      <t>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.</t>
    </abstract>
  </front>

  <middle>
    <section title="Introduction">
      <t>The interconnection of Content Distribution Networks (CDNs) is
      motivated by several use cases, such as those described in <xref
      target="I-D.ietf-cdni-use-cases"></xref>. The overall problem space for
      CDN Interconnection is described in <xref
      target="I-D.ietf-cdni-problem-statement"></xref>. 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.</t>

      <section title="Terminology">
        <t>This document draws freely on the terminology defined in <xref
        target="RFC3466"></xref> and <xref
        target="I-D.ietf-cdni-problem-statement"></xref>.</t>

        <t>We also introduce the following terms:</t>

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

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

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

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

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

        <t>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.</t>
        
        <t>Trigger Interface: a sub-set of the Control Interface that 
        includes operations to pre-position, revalidate, and purge both 
        metadata and content. These operations are typically called in
        response to some action (trigger) by the CSP on the upstream CDN.</t>
        
      </section>

      <section title="Reference Model">
        <t>This document uses the reference model in <xref
        target="refmod"></xref> as originally created in <xref
        target="I-D.ietf-cdni-problem-statement"></xref>.</t>

        <figure anchor="refmod" title="CDNI Model and CDNI Interfaces">
          <preamble></preamble>

          <artwork><![CDATA[   -------- 
  /        \
  |   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
]]></artwork>
        </figure>

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

	<t>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 currently connect to more than one CDN. </t>

        <t>Definitions of the four CDNI interfaces follow. More discussion of
        these interfaces appears in <xref target="interfaces"></xref>. <list
            style="symbols">
            <t>Control Interface: Operations to discover, initialize, and
            parameterize the other CDNI interfaces, as well as operations
            to pre-position, revalidate, and purge both metadata and content.
            The latter sub-set of operations is sometimes collectively
            called the &ldquo;trigger interface.&rdquo;
            </t>

            <t>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: <list style="symbols">
                <t>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</t>

                <t>Synchronous operations to select a delivery CDN (surrogate)
                for a given user request.</t>
              </list></t>

            <t>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: <list style="symbols">
                <t>Asynchronous operations to exchange metadata that govern
                subsequent user requests for content; and</t>

                <t>Synchronous operations that govern behavior for a given
                user request for content.</t>
              </list></t>

            <t>Logging Interface: Operations that allow interconnected CDNs to
            exchange relevant activity logs. May include a combination of:
            <list style="symbols">
                <t>Real-time exchanges, suitable for runtime traffic
                monitoring; and</t>

                <t>Off-line exchanges, suitable for analytics and billing.</t>
              </list></t>
          </list></t>
          
          <t>There is some ambiguity as to the line between the set of
          trigger-based operations in the Control interface and the 
          Metadata interface. For both cases, the information passed
          from the upstream CDN to the downstream CDN can broadly be 
          viewed as metadata that describes how content is to be managed
          by the downstream CDN. For example, the information conveyed by
          Control operations to pre-position, revalidate or purge
          metadata is similar to the information conveyed by posting
          updated metadata via the Metadata interface? Even the Control
          operation to purge content could be viewed as an metadata update 
          for that content: purge simply says that the availability window 
          for the named content ends now. The two interfaces share much in
          common, so minimally, there will need to be a consistent data 
          model that spans both.</t>
          
          <t>The distinction we draw has to do with what the caller knows
          the metadata being applied to content delivery by the callee.
          In the case of the Control interface, the downstream
          CDN returning a successful status message guarantees that the
          operation has been successfully completed; e.g., the content
          has been purged or pre-positioned. This implies that the 
          downstream CDN accepts responsibility for having successfully
          completed the requested operation. In contrast, metadata passed 
          between CDNs via the Metadata interface 
          carries no such completion guarantee. Returning
          success implies successful receipt of the metadata,
          but nothing can be inferred about precisely when the metadata
          will take effect in the downstream CDN, only that it will take
          effect eventually. This is because of the challenge in globally
          synchronizing updates to metadata with end-user requests that
          are currently in progress (or indistinguishable from currently
          being in progress). Clearly, a CDN will not be viewed as
          a trusted peer if &ldquo;eventually&rdquo; often becomes an
          indefinite period of time, but the acceptance of responsibility
          cannot be as crisp for the Metadata interface.</t>
          
      </section>

      <section title="Structure Of This Document">
        <t>The remainder of this document is organized as follows: <list
            style="symbols">
            <t><xref target="blocks"></xref> describes some essential building
            blocks for CDNI, notably the various options for redirecting user
            requests to a given CDN.</t>

            <t><xref target="operation"></xref> provides a number of
            illustrative examples of various CDNI operations.</t>

            <t><xref target="interfaces"></xref> describes the functionality
            of the four main CDNI interfaces.</t>

            <t><xref target="deploy"></xref> shows how various deployment
            models of CDNI may be achieved using the defined interfaces.</t>

            <t><xref target="trust"></xref> describes the trust model of CDNI
            and the issues of transitive trust in particular that CDNI
            raises.</t>
          </list></t>
      </section>
    </section>

    <section anchor="blocks" title="Building Blocks">
      <section anchor="redirection" title="Request Redirection">
        <t>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 <xref
        target="operation"></xref>.</t>

        <section title="DNS Redirection">
          <t>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&rsquo;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).</t>

          <t>The advantage of DNS redirection is that it is completely
          transparent to the end user&mdash;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&rsquo;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.</t>

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

          <t>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&mdash;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.</t>
        </section>

        <section title="HTTP Redirection">
          <t>HTTP redirection makes use of the &ldquo;302&rdquo; 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.</t>

          <t>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) the results of HTTP redirection are not cached so
          that all redirections must go through to the server.</t>
        </section>
      </section>
    </section>

    <section anchor="operation" title="Overview of CDNI Operation">
      <t>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.</t>

      <t>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 <xref target="high-level-ops"></xref>. 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.</t>

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

      <figure anchor="high-level-ops" title="Overview of Operation">
        <artwork><![CDATA[


      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)
          |                         |                         |


]]></artwork>
      </figure>

      <t>The operations shown in the Figure are as follows: <list
          style="numbers">
          <t>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.</t>

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

          <t>A content request from a user agent arrives at uCDN.</t>

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

          <t>uCDN redirects the request to dCDN by sending some response (DNS,
          HTTP) to the user agent.</t>

          <t>The user agent requests the content from dCDN.</t>

          <t>dCDN may synchronously request metadata related to this
          content from uCDN, e.g. to decide whether to serve it.</t>

          <t>If the content is not already in a suitable cache in dCDN, dCDN
          may acquire it from uCDN.</t>

          <t>The content is delivered to dCDN from uCDN.</t>

          <t>The content is delivered to the user agent by dCDN.</t>

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

          <t>After one or more content delivery actions by dCDN, a log of
          delivery actions may be provided to uCDN.</t>
        </list></t>

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

      <section title="Preliminaries">
        <t>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 (<xref
        target="blocks"></xref>) can be used to direct a user request for a
        piece of content from the CSP towards the CSP's chosen upstream
        CDN.</t>

        <t>We use the term "CDN-domain" to refer to the host name (a FQDN) at
        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</t>

        <t>http://cdn.csp.com/...rest of url...</t>

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

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

        <t></t>
      </section>

      <section anchor="http-redir" title="HTTP Redirect Example">
        <t>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.</t>

        <t>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.)</t>

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

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

        <t>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 interface.</t>

        <t>DNS must be configured in the following way:<list style="symbols">
            <t>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).</t>

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

            <t>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.</t>
          </list></t>

        <t><xref target="simple-http"></xref> illustrates how a client request
        for</t>

        <t>http://cdn.csp.com/...rest of url...</t>

        <t>is handled.</t>

        <figure anchor="simple-http"
                title="Request Trace for HTTP redirection method">
          <artwork><![CDATA[
      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                        |
          |<------------------------|                         |
          |                         |                         |
          |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                     |                         |
          |<------------------------|                         |
]]></artwork>
        </figure>

        <t>The steps illustrated in the figure are as follows:<list
            style="numbers">
            <t>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.</t>

            <t>A Request Router for Operator A processes the HTTP request and
            recognizes that the end-user is best served by another
            CDN&mdash;specifically one provided by Operator B&mdash;and so it
            returns a 302 redirect message for a new URL constructed by
            &ldquo;stacking&rdquo; Operator B&rsquo;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.)</t>

            <t>The end-user does a DNS lookup using Operator B&rsquo;s
            distinguished CDN-domain (peer-a.op-b.net). B&rsquo;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.</t>

            <t>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&rsquo;s distinguished CDN-domain that points to the
            selected delivery node.</t>

            <t>The end-user does a DNS lookup using Operator B&rsquo;s
            delivery node subdomain (node1.peer-a.op-b.net). B&rsquo;s DNS
            resolver returns the IP address of the delivery node.</t>

            <t>The end-user requests the content from B&rsquo;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).</t>

            <t>Operator A's DNS resolver processes the DNS request and returns
            the IP address of a request router in operator A.</t>

            <t>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&rsquo;s distinguished inter-CDN acquisition domain that
            points to the selected delivery node.</t>

            <t>Operator A DNS resolver processes the DNS request and returns
            the IP address of the delivery node in operator A.</t>

            <t>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.</t>
          </list></t>

        <section title="Comments on the example">
          <t>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 &ldquo;pushing&rdquo; the downstream CDN-domain
          onto the URL as part of its redirect (step 2) and the downstream CDN
          &ldquo;popping&rdquo; 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).</t>

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

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

          <t>We also note that the step of deciding when a request
          should be redirected to dCDN rather than served by uCDN has
          been somewhat 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.</t>

          <t>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.</t>
        </section>
      </section>

      <section anchor="recurse" title="Recursive Redirection Example">

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

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

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

        <t>DNS must be configured in the following way:<list style="symbols">
            <t>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).</t>

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

            <t>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.</t>
          </list></t>

        <t><xref target="simple-http"></xref> illustrates how a client
        request for</t>

        <t>http://cdn.csp.com/...rest of url...</t>

        <t>is handled.</t>

        <figure anchor="recurse-http"
                title="Request Trace for Recursive HTTP redirection method">
          <artwork><![CDATA[      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                     |                         |
          |<------------------------|                         |
]]></artwork>
        </figure>

        <t>The steps illustrated in the figure are as follows:<list
            style="numbers">
            <t>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.</t>

            <t>A Request Router for Operator A processes the HTTP request and
            recognizes that the end-user is best served by another
            CDN&mdash;specifically one provided by Operator B&mdash;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.</t>

            <t>Operator A returns a 302 redirect message for a new URL
            obtained from the Request Routing Interface.</t>

            <t>The end-user does a DNS lookup using the host name of the URL
            just provided (node1.op-b.net). B&rsquo;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.)</t>

            <t>The end-user requests the content from B&rsquo;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
            &ldquo;distinguished&rdquo; CDN-domain as agreed above (in this
            case, op-b-acq.op-a.net).</t>

            <t>Operator A DNS resolver processes the DNS request and returns
            the IP address of a request router in operator A.</t>

            <t>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&rsquo;s distinguished inter-CDN acquisition domain that
            points to the selected delivery node.</t>

            <t>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.)</t>

            <t>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.</t>
          </list></t>

        <section title="Comments on the example">
          <t>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. </t>

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

	  <t>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 <xref
	  target="interfaces"></xref></t>
        </section>
      </section>

      <section anchor="DNS-eg" title="DNS-based redirection example">
        <t>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 <xref
        target="redirection"></xref>, 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 request router).</t>

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

        <t>DNS must be configured in the following way:<list style="symbols">
            <t>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).</t>

            <t>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.)</t>

            <t>dCDN must be configured so that a request for "b.cdn.csp.com"
            returns a delivery node in dCDN.</t>

            <t>uCDN must be configured so that a request for
            "op-b-acq.op-a.net" returns a delivery node in uCDN.</t>
          </list></t>

        <t><xref target="simple-DNS"></xref> depicts the exchange of DNS and
        HTTP requests. The main differences from <xref
        target="simple-http"></xref> are the lack of HTTP redirection and
        transparency to the end-user.</t>

        <figure anchor="simple-DNS"
                title="Request Trace for DNS-based Redirection Example">
          <artwork><![CDATA[      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                     |                         |
          |<------------------------|                         |
]]></artwork>
        </figure>

        <t>The steps illustrated in the figure are as follows:<list
            style="numbers">
            <t>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
            &ldquo;stacking&rdquo; 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&rsquo;s Request Router.</t>

            <t>The end-user does a DNS lookup using the modified CDN-domain
            (i.e., b.cdn.csp.com). This causes B&rsquo;s Request Router to
            respond with a suitable delivery node.</t>

            <t>The end-user requests the content from B&rsquo;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
            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 &ldquo;internal&rdquo;
            CDN-domain as agreed above (op-b-acq.op-a.net).</t>

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

            <t>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.</t>
          </list></t>

        <section title="Comments on the example">
          <t>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&mdash;e.g., the end-user uses a global DNS
          service&mdash;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 &ldquo;fall
          back&rdquo; 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 <xref
          target="I-D.vandergaast-edns-client-subnet"></xref>.</t>

          <t>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,
          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.</t>
        </section>
      </section>

      <section title="Dynamic Footprint Discovery">
        <t>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.</t>

        <t></t>

        <figure anchor="dynamic-footprint"
                title="Request Trace for Dynamic Footprint Discovery Example">
          <artwork><![CDATA[      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                     |                         |
          |<------------------------|                         |
]]></artwork>
        </figure>

        <t>This example differs from the one in <xref
        target="simple-DNS"></xref> 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 from DNS requests, as
        described above, are exactly the same here as in <xref
        target="DNS-eg"></xref>.)</t>

        <t>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).</t>
      </section>

      <section title="Content Removal">
        <t>The following example illustrates how the Control 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 Control Interface to request that content identified by a
        particular URL be removed from dCDN. The following diagram illustrates
        the operation.</t>

        <figure anchor="removal" title="Request Trace for Content Removal">
          <artwork><![CDATA[      End-User                 Operator B                Operator A
          |                         |CI purge cdn.csp.com/... |
          |                         |<------------------------|
          |                         |                         |(1)
          |                         |CI OK                    |
          |                         |------------------------>|
          |                         |                         |(2)
     
]]></artwork>
        </figure>

        <t>The Control 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 <xref
        target="DNS-eg"></xref>. If HTTP-based redirection had been used, the
        URL for removal would be of the form
        peer-a.op-b.net/cdn.csp.com/...</t>

        <t>The dCDN is expected to confirm to the uCDN, as illustrated by the
        CI OK message, the completion of the removal of the targeted content
        from all the caches in dCDN.</t>
      </section>

      <section title="Pre-Positioned Content Acquisition Example">
        <t>The following example illustrates how the Control 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 content
        identified by a particular URL be pre-positioned into Operator B
        CDN.</t>

        <t></t>

        <figure anchor="pre-positioning"
                title="Request Trace for Content Pre-Positioning">
          <artwork><![CDATA[      End-User                 Operator B                Operator A

          |                         |CI pre-position cdn.csp.com/...
          |                         |<------------------------|
          |                         |                         |(1)
          |                         |CI 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                     |                         |
          |<------------------------|                         |
]]></artwork>
        </figure>

        <t>The steps illustrated in the figure are as follows:<list
            style="numbers">
            <t>Operator A uses the Control Interface to request that
            Operator B pre-positions a particular content item
            identified by its URL. Operator B responds by confirming
            that it is willing to perform this operation.</t>
          </list>Steps 2 and 3 are exactly the same as steps 5 and 6 of <xref
        target="simple-http"></xref>, only this time those steps happen as the
        result of the Pre-positioning request instead of as the result of a
        cache miss.</t>

        <t>Steps 4, 5, 6, 7 are exactly the same as steps 1, 2, 3, 4 of <xref
        target="simple-http"></xref>, 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.</t>

        <t></t>
      </section>

      <section title="Asynchronous CDNI Metadata Example">
        <t>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 <xref target="recurse"></xref>. 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).</t>

        <figure anchor="meta-pre-positioning"
                title="Request Trace for Asynchronous CDNI Metadata">
          <artwork><![CDATA[  
      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)

]]></artwork>
        </figure>

        <t>The steps illustrated in the figure are as follows:<list
            style="numbers">
            <t>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: <list style="symbols">
                <t>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
                <xref target="DNS-eg"></xref>).</t>

                <t>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).</t>
              </list></t>

            <t>A Content Request occurs as usual.</t>

            <t>A CDNI Request Routing Request (RRI REQ) is issued by operator
            A CDN, as discussed in <xref target="recurse"></xref>. 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.</t>

            <t>Operator B's request router issues a CDNI Request Routing
            Response (RRI RESP) as in <xref target="recurse"></xref>.</t>

            <t>Operator B performs content redirection as discussed in <xref
            target="recurse"></xref>.</t>

            <t>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.)</t>

            <t>Assuming successful per-request authorization, serving of
            Content Data (possibly preceded by inter-CDN acquisition) proceeds
            as in <xref target="recurse"></xref>.</t>
          </list></t>
      </section>

      <section title="Synchronous CDNI Metadata Acquisition Example">
        <t>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 <xref
        target="recurse"></xref>), but dynamic CDNI metadata acquisition is
        applicable to other variations of request routing.</t>

        <figure anchor="meta-pull"
                title="Request Trace for Synchronous CDNI Metadata Acquisition">
          <artwork><![CDATA[  
    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)

]]></artwork>
        </figure>

        <t>The steps illustrated in the figure are as follows:</t>

        <t><list style="numbers">
            <t>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 Step 3.)</t>

            <t>A Content Request arrives as normal.</t>

            <t>A Request Routing Interface request occurs as in the prior
            example.</t>

            <t>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).</t>

            <t>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.)</t>

            <t>Response to the RRI request as normal.</t>

            <t>Redirection message is sent to the end user.</t>

            <t>A delivery node of Operator B receives the end user
            request.</t>

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

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

            <t>Content is served (possibly preceded by inter-CDN acquisition)
            as in <xref target="recurse"></xref>.</t>
          </list></t>
      </section>
    </section>

    <section anchor="interfaces" title="Main Interfaces">
      <t><xref target="refmod"></xref> 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 <xref
      target="I-D.ietf-cdni-problem-statement"></xref> and <xref
      target="I-D.ietf-cdni-requirements"></xref> for some discussion of the
      interfaces).</t>

      <t>One interface that is not shown in <xref target="refmod"></xref> 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.</t>

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

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

      <section title="In-Band versus Out-of-Band Interfaces">
        <t>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.</t>

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

        <t>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
        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.</t>
      </section>

      <section title="Request Routing Interface">
        <t>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.)</t>

        <t>As illustrated in <xref target="operation"></xref>, 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.</t>

        <t>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 <list style="symbols">
            <t>The operator&rsquo;s unique id (operator-id) or distinguished
            CDN-domain (operator-domain);</t>

            <t>NS records for the operator&rsquo;s set of externally visible
            request routers;</t>

            <t>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).</t>
          </list></t>

        <t>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&mdash;DNS&mdash;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&rsquo;s
        redirection service.</t>

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

        <t>A variety of options exist for the dCDN operator to advertise its
        footprint to uCDN. As discussed in 
        <xref target="I-D.previdi-cdni-footprint-advertisement"></xref>,
        footprint is comprised of two components: <list style="symbols">
            <t>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;</t>

            <t>the connectivity of the dCDN to other CDNs that may be able to
            serve content to users on behalf of dCDN.</t>
          </list> <xref
        target="I-D.previdi-cdni-footprint-advertisement"></xref> 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. <xref
        target="I-D.xiaoyan-cdni-request-routing-protocol"></xref> describes
        an approach that exchanges CDN "capabilities" over HTTP, while
        <xref target="I-D.seedorf-alto-for-cdni"></xref> describes how
        ALTO <xref target="RFC5693"></xref> may be used to obtain
        request routing information.</t> 

        <t>We also note that the Request Routing interface plays a key role
        in enabling recursive redirection, as illustrated in <xref
        target="recurse"></xref>. 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.</t>
        
        <t>One final issue is how HTTP adaptive streaming impacts the 
        Request Routing interface, and in particular, the interplay
        between the request router and manifest files, which may contain 
        either absolute or relative URLs. These issues are discussed in 
        more detail in <xref target="I-D.brandenburg-cdni-has"></xref>.</t>
      </section>

      <section title="Logging Interface">
        <t>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.</t>

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

        <t>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: <list
            style="symbols">
            <t hangText="Domain:">Domain &ndash; the full domain name of the
            origin server</t>

            <t hangText="Domain:">IP address &ndash; the IP address of the
            client making the request</t>

            <t hangText="Domain:">End time &ndash; the ending time of the
            transfer</t>

            <t hangText="Domain:">Time zone &ndash; any time zone modifier for
            the end time</t>

            <t hangText="Domain:">Method &ndash; the transfer command itself
            (e.g., GET, POST, HEAD)</t>

            <t hangText="Domain:">URL &ndash; the requested URL</t>

            <t hangText="Domain:">Version &ndash; the protocol version, such
            as HTTP/1.0</t>

            <t hangText="Domain:">Response &ndash; a numeric response code
            indicating transfer result</t>

            <t hangText="Domain:">Bytes Sent &ndash; the number of bytes in
            the body sent to the client</t>

            <t hangText="Domain:">Request ID &ndash; a unique identifier for
            this transfer</t>

            <t hangText="Domain:">User agent &ndash; the user agent, if
            supplied</t>

            <t hangText="Domain:">Duration &ndash; the duration of the
            transfer in milliseconds</t>

            <t hangText="Domain:">Cached Bytes &ndash; the number of body
            bytes served from the cache</t>

            <t hangText="Domain:">Referrer &ndash; the referrer string from
            the client, if supplied</t>
          </list></t>

        <t>Of these, only the Domain field is indirect in the downstream
        CDN&mdash;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. Further discussion of
        the Logging interface can be found in
        <xref target="I-D.bertrand-cdni-logging"></xref> and
        <xref target="I-D.lefaucheur-cdni-logging-delivery"></xref>.</t>

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

        <t>A second open question is how timely traffic information should be.
        For example, in addition to off-line traffic logs, accurate real-time
        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.</t>

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

        <t>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 two-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. The implications of HTTP
        adaptive streaming are discussed further in
        <xref target="I-D.brandenburg-cdni-has"></xref>.</t>

        <t>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.</t>
      </section>

      <section title="Control Interface">
        <t>The control interface is initially used to bootstrap the
        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.</t>
        
         <t>The other role the Control interface plays is to allow the
         uCDN to pre-position, revalidate, or purge metadata and content
         on a dCDN. These operations, sometimes collectively called the
         trigger interface, are discussed further in
         <xref target="I-D.murray-cdni-triggers"></xref>.</t>
         
      </section>

      <section title="Metadata Interface">
        <t>The role of the metadata interface is to enable CDNI distribution
        metadata to be conveyed to the downstream CDN by the upstream CDN.
        For example, see <xref target="I-D.ma-cdni-metadata"></xref> and
        <xref target="I-D.caulfield-cdni-metadata-core"></xref>.
        Such metadata includes geo-blocking restrictions, availability
        windows, access control policies, and so on. It may also include
        policy information such as the desire to pre-position content rather
        than fetch it on demand.</t>

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

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

        <t>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&rsquo;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.</t>
        
        <t>All of these in-band techniques serve to illustrate that uCDNs 
        have the option of enforcing their access control policies 
        themselves, rather than delegating enforcement to dCDNs
        using the Metadata interface. As a consequence, the Metadata
        interface must provide a means for the uCDN to express this
        its desire to retain enforcement for itself. 
        For example, this might be done by including a 
        &ldquo;check with me&ldquo;      
        flag in the metadata associated with certain content.</t>

      </section>
    </section>

    <section anchor="deploy" title="Deployment Models">
      <t>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.  </t>
      
      <t>Although the reference model of <xref target="refmod"></xref> 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 <xref target="operation"></xref>, effective CDNI
      deployments can be built without necessarily implementing all four
      interfaces. Some examples of such deployments  are shown below.</t>

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

      <section title="Meshed CDNs">

      <t>Although the reference model illustrated in <xref
      target="refmod"></xref> 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 <xref
      target="depmodmesh"></xref>. (Support for arbitrary meshing may or may
      not be in the initial scope for the working group, but the model allows
      for it.)</t>

      <figure anchor="depmodmesh"
              title="CDNI Deployment Model: CDN Meshing Example">
        <artwork><![CDATA[
      -------------             -----------
     /    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
]]></artwork>
      </figure>
      </section>
      <section title="CSP combined with CDN">


      <t>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 <xref target="depmodcombined"></xref>.</t>

      <figure anchor="depmodcombined"
              title="CDNI Deployment Model: Organization combining CSP &amp; uCDN">
        <artwork><![CDATA[#####################################       ##################
#                                   #       #                #
#       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
]]></artwork>
      </figure>
      </section>
      <section title="CSP using CDNI Request Routing Interface" anchor="csp-rri">

      <t>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 <xref
      target="depmodsplit"></xref>, 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).</t>

      <t></t>

      <figure anchor="depmodsplit"
              title="CDNI Deployment Model: Organization combining CSP and partial CDN">
        <artwork><![CDATA[#####################################       ##################
#                                   #       #                #
#       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
]]></artwork>
      </figure>
      </section>
      <section title="CDN Federations and CDN Exchanges">

      <t>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&rsquo;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.</t>

      <t>The second concept often used in the context of CDN Federation is CDN
      Exchange&mdash;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-lateral (federated) agreement, but that this machinery is built on
      top of the core CDNI interconnection mechanisms. For example, as
      illustrated in <xref target="depmodexchange"></xref>, 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&mdash;operate exactly as in a pair-wise peering arrangement. Turning
      to <xref target="depmodexchange"></xref>, we observe that in this
      example:</t>

      <t><list style="symbols">
          <t>each CDN supports a direct CDNI Control interface to every other
          CDN</t>

          <t>each CDN supports a direct CDNI Metadata interface to every other
          CDN</t>

          <t>each CDN supports a CDNI Logging interface with the CDN
          Exchange</t>

          <t>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).</t>
        </list></t>

      <figure anchor="depmodexchange"
              title="CDNI Deployment Model: CDN Exchange">
        <artwork><![CDATA[
          ----------                            ---------
         /    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
]]></artwork>
      </figure>

      <t>Note that a CDN exchange may alternatively support a different set of
      functionality (e.g. Logging only, or Logging and full request routing,
      or all the functionality of a CDN including content distribution). All
      these options are expected to be allowed by the IETF CDNI
      specifications.</t>

      </section>
    </section>

    <section anchor="trust" title="Trust Model">
      <t>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.</t>

      <t>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).</t>

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

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

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

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

      <t>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.</t>
    </section>

    <section anchor="IANA" title="IANA Considerations">
      <t>This memo includes no request to IANA.</t>
    </section>

    <section anchor="Security" title="Security Considerations">

      <t>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 single CDN case.</t>

      <t>Many of the security issues that arise in CDNI are related to the
      transitivity of trust (or lack thereof) described in <xref
      target="trust"></xref>. 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.</t>

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

      <t>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.)</t>

      <t>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.)</t>

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

      <section title="Security of CDNI Interfaces">
        <t>It is noted in <xref target="I-D.ietf-cdni-requirements"></xref>
        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 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.</t>
      </section>
      <section title="Digital Rights Management">
	<t>
	  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 <xref target="I-D.ietf-cdni-problem-statement"></xref>
	  and does not introduce additional security issues for CDNI.
	</t>
      </section>
    </section>

    <section title="Contributors">
      <t>The following individuals contributed to this document:</t>

      <t><list style="symbols">
          <t>Francois le Faucheur</t>
          <t>Aaron Falk</t>
          <t>David Ferguson</t>
          <t>John Hartman</t>
          <t>Ben Niven-Jenkins</t>
        </list></t>
    </section>

    <section title="Acknowledgements">
      <t>We thank Huw Jones for their helpful input to the draft.</t>
    </section>
  </middle>

  <back>
    <references title="Informative References">
      <?rfc include='reference.RFC.3466'?>

      <?rfc include='reference.RFC.5693'?>

      <?rfc include='reference.I-D.ietf-cdni-problem-statement'?>

      <?rfc include='reference.I-D.ietf-cdni-use-cases'?>

      <?rfc include='reference.I-D.vandergaast-edns-client-subnet'?>

      <?rfc include='reference.I-D.ietf-cdni-requirements'?>

      <?rfc include='reference.I-D.previdi-cdni-footprint-advertisement'?>
      
      <?rfc include='reference.I-D.murray-cdni-triggers'?>

      <?rfc include='reference.I-D.bertrand-cdni-logging'?>
      
      <?rfc include='reference.I-D.lefaucheur-cdni-logging-delivery'?>
      
      <?rfc include='reference.I-D.brandenburg-cdni-has'?>
      
      <?rfc include='reference.I-D.ma-cdni-metadata'?>
      
      <?rfc include='reference.I-D.caulfield-cdni-metadata-core'?>

      <?rfc include='reference.I-D.xiaoyan-cdni-request-routing-protocol'?>

      <?rfc include='reference.I-D.seedorf-alto-for-cdni'?>
    </references>
  </back>
</rfc>
