Tech-invite3GPPspaceIETFspace
959493929190898887868584838281807978777675747372717069686766656463626160595857565554535251504948474645444342414039383736353433323130292827262524232221201918171615141312111009080706050403020100
in Index   Prev   Next

RFC 7336

Framework for Content Distribution Network Interconnection (CDNI)

Pages: 58
Informational
Obsoletes:  3466
Part 2 of 4 – Pages 12 to 38
First   Prev   Next

Top   ToC   RFC7336 - Page 12   prevText

3. Overview of CDNI Operation

To provide a big-picture overview of the various components of CDNI, 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 show how additional capabilities, such as recursive request redirection and content removal, might be added. Before walking through the specific examples, we present a high-level view of the operations that may take place. This high-level overview is illustrated in Figure 2. Note that most operations will involve only a subset of all the messages shown below, and that the order and number of operations may vary considerably, as the more detailed examples illustrate. 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 is the CDN selected by Operator A to deliver content to the end user. The interconnection relationship may be symmetric between these two CDN operators, but each direction can be considered as operating independently of the other; for simplicity, we show the interaction in one direction only.
Top   ToC   RFC7336 - Page 13
         End User                  Operator B                Operator A
             |                         |                         |
             |                         |                         |
             |                         |  [Async FCI Push]       | (1)
             |                         |                         |
             |                         |  [MI pre-positioning]   | (2)
             |                         |                         |
             | CONTENT REQUEST         |                         |
             |-------------------------------------------------->| (3)
             |                         |                         |
             |                         |   [Sync RI Pull]        | (4)
             |                         |                         |
             | CONTENT REQUEST REDIRECTION                       |
             |<--------------------------------------------------| (5)
             |                         |                         |
             |                         |                         |
             | CONTENT REQUEST         |                         |
             |------------------------>|                         | (6)
             |                         |                         |
             |                         |   [Sync MI Pull]        | (7)
             |                         |                         |
             |                         | ACQUISITION REQUEST     |
             |                         X------------------------>| (8)
             |                         X                         |
             |                         X CONTENT DATA            |
             |                         X<------------------------| (9)
             |                         |                         |
             | CONTENT DATA            |                         |
             |<------------------------|                         | (10)
             |                         |                         |
             :                         :                         :
             :          [Other content requests]                 :
             :                         :                         :
             |                         |  [CI: Content Purge]    | (11)
             :                         :                         :
             |                         |  [LI: Log exchange]     | (12)
             |                         |                         |

                      Figure 2: Overview of Operation

   The operations shown in the figure are as follows:

   1.   The dCDN uses the FCI to advertise information relevant to its
        delivery footprint and capabilities prior to any content
        requests being redirected.
Top   ToC   RFC7336 - Page 14
   2.   Prior to any content request, the uCDN uses the MI to pre-
        position CDNI Metadata to the dCDN, thereby making that metadata
        available in readiness for later content requests.

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

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

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

   6.   The user agent requests the content from the dCDN.

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

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

   9.   The content is delivered to the dCDN from the uCDN.

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

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

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

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

3.1. Preliminaries

Initially, we assume that there is at least one CSP that has contracted with an Upstream CDN (uCDN) to deliver content on its behalf. We are not particularly concerned with the interface between the CSP and uCDN, other than to note that it is expected to be the same as in the "traditional" (non-interconnected) CDN case. Existing mechanisms such as DNS CNAMEs or HTTP redirects (Section 2) can be used to direct a user request for a piece of content from the CSP towards the CSP's chosen Upstream CDN.
Top   ToC   RFC7336 - Page 15
   We assume Operator A provides an Upstream CDN that serves content on
   behalf of a CSP with CDN-Domain cdn.csp.example.  We assume that
   Operator B provides a Downstream CDN.  An end user at some point
   makes a request for URL

   http://cdn.csp.example/...rest of URL...

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

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

3.2. Iterative HTTP Redirect Example

In this section, we walk through a simple, illustrative example using HTTP redirection from a uCDN to a dCDN. The example also assumes the use of HTTP redirection inside the 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 the uCDN to dCDN but using DNS for the handling of the request inside each CDN. For this example, we assume that Operators A and B have established an agreement to interconnect their CDNs, with A being Upstream and B being Downstream. The operators agree that a CDN-Domain peer-a.op-b.example will be used as the target of redirections from the uCDN to dCDN. We assume the name of this domain is 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 used directly by a CSP. We assume the operators also agree on some distinguished CDN-Domain that will be used for inter-CDN acquisition of the CSP's content from the uCDN by the dCDN. In this example, we'll use op-b-acq.op-a.example.
Top   ToC   RFC7336 - Page 16
   We assume the operators also exchange information regarding which
   requests the dCDN is prepared to serve.  For example, the 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 CDNI interface.

   We assume DNS is configured in the following way:

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

   o  Operator A is configured so that a DNS request for
      op-b-acq.op-a.example returns a Request Router in Operator A.

   o  Operator B is configured so that a DNS request for
      peer-a.op-b.example/cdn.csp.example returns a Request Router in
      Operator B.

   Figure 3 illustrates how a client request for

   http://cdn.csp.example/...rest of URL...

   is handled.


         End User                 Operator B                Operator A
             |DNS cdn.csp.example      |                         |
             |-------------------------------------------------->|
             |                         |                         |(1)
             |IPaddr of A's Request Router                       |
             |<--------------------------------------------------|
             |HTTP cdn.csp.example     |                         |
             |-------------------------------------------------->|
             |                         |                         |(2)
             |302 peer-a.op-b.example/cdn.csp.example            |
             |<--------------------------------------------------|
             |DNS peer-a.op-b.example  |                         |
             |------------------------>|                         |
             |                         |(3)                      |
             |IPaddr of B's Request Router                       |
             |<------------------------|                         |
             |                         |                         |
             |HTTP peer-a.op-b.example/cdn.csp.example           |
             |------------------------>|                         |
Top   ToC   RFC7336 - Page 17
             |                         |(4)                      |
             |302 node1.peer-a.op-b.example/cdn.csp.example      |
             |<------------------------|                         |
             |DNS node1.peer-a.op-b.example                      |
             |------------------------>|                         |
             |                         |(5)                      |
             |IPaddr of B's Delivery Node                        |
             |<------------------------|                         |
             |                         |                         |
             |HTTP node1.peer-a.op-b.example/cdn.csp.example     |
             |------------------------>|                         |
             |                         |(6)                      |
             |                         |DNS op-b-acq.op-a.example|
             |                         |------------------------>|
             |                         |                         |(7)
             |                         |IPaddr of A's Request Router
             |                         |<------------------------|
             |                         |HTTP op-b-acq.op-a.example
             |                         |------------------------>|
             |                         |                         |(8)
             |                         |302 node2.op-b-acq.op-a.example
             |                         |<------------------------|
             |                         |DNS node2.op-b-acq.op-a.example
             |                         |------------------------>|
             |                         |                         |(9)
             |                         |IPaddr of A's Delivery Node
             |                         |<------------------------|
             |                         |                         |
             |                         |HTTP node2.op-b-acq.op-a.example
             |                         |------------------------>|
             |                         |                         |(10)
             |                         |Data                     |
             |                         |<------------------------|
             |Data                     |                         |
             |<------------------------|                         |

           Figure 3: Message Flow for Iterative HTTP Redirection

   The steps illustrated in the figure are as follows:

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

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

   3.   The end user does a DNS lookup using Operator B's distinguished
        CDN-Domain (peer-a.op-b.example).  B's DNS resolver returns the
        IP address of a Request Router for Operator B.  Note that if
        request routing within the 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.

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

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

   6.   The end user requests the content from B's delivery node.  In
        the case of a cache hit, steps 6, 7, 8, 9, and 10 below do not
        happen, and the content data is directly returned by the
        delivery node to the end user.  In the case of a cache miss, the
        content needs to be acquired by the dCDN from the uCDN (not the
        CSP).  The distinguished CDN-Domain peer-a.op-b.example
        indicates to the dCDN that this content is to be acquired from
        the uCDN; stripping the CDN-Domain reveals the original CDN-
        Domain cdn.csp.example, and the 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.example).

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

   8.   The Request Router for Operator A processes the HTTP request
        from Operator B's delivery node.  Operator A's 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.example).  (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
Top   ToC   RFC7336 - Page 19
        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 with a subdomain of
        the Operator A's distinguished inter-CDN acquisition domain that
        points to the selected delivery node.

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

   10.  Operator B requests (acquires) the content from Operator A.
        Although not shown, 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.

   The main advantage of this design is that it is simple: each CDN need
   only know the distinguished CDN-Domain for each peer, with the
   Upstream CDN "pushing" the Downstream CDN-Domain onto the URL as part
   of its redirect (step 2), and the Downstream CDN "popping" its CDN-
   Domain off the URL to expose a CDN-Domain that the Upstream CDN can
   correctly process.  Neither CDN need 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 need be
   aware of the other's internal redirection mechanism (i.e., whether it
   is DNS or HTTP based).

   One disadvantage is that the end user's browser is redirected to a
   new URL that is not in the same domain of the original URL.  This has
   implications on a number of security or validation mechanisms
   sometimes used on endpoints.  For example, it is important that any
   redirected URL be in the same domain (e.g., csp.example) 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 accommodate the domains involved in the
   CDN redirection.  These problems are generally solvable, but the
   solutions complicate the example, so we do not discuss them further
   in this document.

   We note that this example begins to illustrate some of the interfaces
   that may be required for CDNI, but it does not require all of them.
   For example, obtaining information from a dCDN regarding the set of
   client IP addresses or geographic regions it might be able to serve
   is an aspect of request routing (specifically of the CDNI Footprint &
   Capabilities Advertisement interface).  Important configuration
   information such as the distinguished names used for redirection and
Top   ToC   RFC7336 - Page 20
   inter-CDN acquisition could also be conveyed via a CDNI interface
   (e.g., perhaps the CDNI 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.  The example also
   assumes that the CSP does not require any distribution policy (e.g.,
   time window or geo-blocking) or delivery processing to be applied by
   the interconnected CDNs.  Hence, there is no explicit CDNI Metadata
   interface invoked in this example.  There is also no explicit CDNI
   Logging interface discussed in this example.

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

   This example uses the "iterative" CDNI request redirection approach.
   That is, a uCDN performs part of the request redirection function by
   redirecting the client to a Request Router in the dCDN, which then
   performs the rest of the redirection function by redirecting to a
   suitable Surrogate.  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 redirection 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.

   While the example above uses HTTP, the iterative HTTP redirection
   mechanism would work over HTTPS in a similar fashion.  In order to
   make sure an end user's HTTPS request is not downgraded to HTTP along
   the redirection path, it is necessary for every Request Router along
   the path from the initial uCDN Request Router to the final Surrogate
   in the dCDN to respond to an incoming HTTPS request with an HTTP
   redirect containing an HTTPS URL.  It should be noted that using
   HTTPS will have the effect of increasing the total redirection
   process time and increasing the load on the Request Routers,
   especially when the redirection path includes many redirects and thus
   many Secure Socket Layer/Transport Layer Security (SSL/TLS) sessions.
   In such cases, a recursive HTTP redirection mechanism, as described
   in an example in the next section, might help to reduce some of these
   issues.
Top   ToC   RFC7336 - Page 21

3.3. Recursive HTTP Redirection Example

The following example builds on the previous one to illustrate the use of the request routing interface (specifically, the CDNI Request Routing Redirection interface) to enable "recursive" CDNI request routing. We build on the HTTP-based redirection approach because it illustrates the principles and benefits clearly, but it is equally possible to perform recursive redirection when DNS-based redirection is employed. In contrast to the prior example, the operators need not agree in advance on a CDN-Domain to serve as the target of redirections from the uCDN to dCDN. We assume that the operators agree on some distinguished CDN-Domain that will be used for inter-CDN acquisition of the CSP's content by dCDN. In this example, we'll use op-b-acq.op-a.example. We assume the operators also exchange information regarding which requests the dCDN is prepared to serve. For example, the 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. We assume DNS is configured in the following way: o The content provider is configured to make Operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which Operator A is the authoritative DNS server). o Operator A is configured so that a DNS request for op-b-acq.op-a.example returns a Request Router in Operator A. o Operator B is configured so that a request for node1.op-b.example/ cdn.csp.example returns the IP address of a delivery node. Note that there might be a number of such delivery nodes. Figure 3 illustrates how a client request for http://cdn.csp.example/...rest of URL... is handled.
Top   ToC   RFC7336 - Page 22
         End User                 Operator B                Operator A
             |DNS cdn.csp.example      |                         |
             |-------------------------------------------------->|
             |                         |                         |(1)
             |IPaddr of A's Request Router                       |
             |<--------------------------------------------------|
             |HTTP cdn.csp.example     |                         |
             |-------------------------------------------------->|
             |                         |                         |(2)
             |                         |RR/RI REQ cdn.csp.example|
             |                         |<------------------------|
             |                         |                         |
             |                         |RR/RI RESP node1.op-b.example
             |                         |------------------------>|
             |                         |                         |(3)
             |302 node1.op-b.example/cdn.csp.example             |
             |<--------------------------------------------------|
             |DNS node1.op-b.example   |                         |
             |------------------------>|                         |
             |                         |(4)                      |
             |IPaddr of B's Delivery Node                        |
             |<------------------------|                         |
             |HTTP node1.op-b.example/cdn.csp.example            |
             |------------------------>|                         |
             |                         |(5)                      |
             |                         |DNS op-b-acq.op-a.example|
             |                         |------------------------>|
             |                         |                         |(6)
             |                         |IPaddr of A's Request Router
             |                         |<------------------------|
             |                         |HTTP op-b-acq.op-a.example
             |                         |------------------------>|
             |                         |                         |(7)
Top   ToC   RFC7336 - Page 23
             |                         |302 node2.op-b-acq.op-a.example
             |                         |<------------------------|
             |                         |DNS node2.op-b-acq.op-a.example
             |                         |------------------------>|
             |                         |                         |(8)
             |                         |IPaddr of A's Delivery Node
             |                         |<------------------------|
             |                         |                         |
             |                         |HTTP node2.op-b-acq.op-a.example
             |                         |------------------------>|
             |                         |                         |(9)
             |                         |Data                     |
             |                         |<------------------------|
             |Data                     |                         |
             |<------------------------|                         |

           Figure 4: Message Flow for Recursive HTTP Redirection

   The steps illustrated in the figure are as follows:

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

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

   3.  Operator A returns a 302 redirect message for a new URL obtained
       from the RI.

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

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

   6.  Operator A's DNS resolver processes the DNS request and returns
       the IP address of a Request Router in Operator A.

   7.  The Request Router for Operator A processes the HTTP request from
       Operator B's delivery node.  Operator A's 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.example).  (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 the uCDN to serve the inter-CDN
       acquisition request and returns a 302 redirect message for a new
       URL constructed by replacing the hostname with a subdomain of the
       Operator A's distinguished inter-CDN acquisition domain that
       points to the selected delivery node.

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

   9.  Operator B requests (acquires) the content from Operator A.
       Operator A serves content for the requested CDN-Domain to the
       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 the
       dCDN.

   Recursive redirection has the advantage (over iterative redirection)
   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 the dCDN to expose the
   addresses of its edge caches to the uCDN.
Top   ToC   RFC7336 - Page 25
   This example happens to use HTTP-based redirection in both CDN A and
   CDN B, but a similar example could be constructed using DNS-based
   redirection in either CDN.  Hence, the key point to take away here is
   simply that the end user only sees a single redirection of some type,
   as opposed to the pair of redirections in the prior (iterative)
   example.

   The use of the RI requires that the request routing mechanism be
   appropriately configured and bootstrapped, which is not shown here.
   More discussion on the bootstrapping of interfaces is provided in
   Section 4

3.4. Iterative DNS-Based Redirection Example

In this section we walk through a simple example using DNS-based redirection for request redirection from the uCDN to the dCDN (as well as for request routing inside the dCDN and the uCDN). As noted in Section 2.1, DNS-based redirection has certain advantages over HTTP-based redirection (notably, it is transparent to the end user) as well as some drawbacks (notably, the client IP address is not visible to the Request Router). As before, Operator A has to learn the set of requests that the dCDN is willing or able to serve (e.g., which client IP address prefixes or geographic regions are part of the dCDN footprint). We assume Operator B has and makes 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 Autonomous System (AS) number assigned to B, is one easy way to achieve that.) Also, Operator A obtains 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.example, must be assigned for inter-CDN acquisition. We assume DNS is configured in the following way: o The CSP is configured to make Operator A the authoritative DNS server for cdn.csp.example (or to return a CNAME for cdn.csp.example for which Operator A is the authoritative DNS server). o When uCDN sees a request best served by the dCDN, it returns CNAME and NS records for "b.cdn.csp.example", where "b" is the unique identifier assigned to Operator B. (It may, for example, be an AS number assigned to Operator B.)
Top   ToC   RFC7336 - Page 26
   o  The dCDN is configured so that a request for "b.cdn.csp.example"
      returns a delivery node in the dCDN.

   o  The uCDN is configured so that a request for
      "op-b-acq.op-a.example" returns a delivery node in the uCDN.

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

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

             Figure 5: Message Flow for DNS-Based Redirection
Top   ToC   RFC7336 - Page 27
   The steps illustrated in the figure are as follows:

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

   2.  The end user sends a DNS query for the modified CDN-Domain (i.e.,
       b.cdn.csp.example) to Operator A's DNS server.  The Request
       Router for Operator A processes the DNS request and returns a
       delegation to b.cdn.csp.example by sending an NS record plus glue
       records pointing to Operator B's DNS server.  (This extra step is
       necessary since typical DNS implementation won't follow an NS
       record when it is sent together with a CNAME record, thereby
       necessitating a two-step approach.)

   3.  The end user sends a DNS query for the modified CDN-Domain (i.e.,
       b.cdn.csp.example) to Operator B's DNS server, using the NS and
       AAAA/A records received in step 2.  This causes B's Request
       Router to respond with a suitable delivery node.

   4.  The end user requests the content from B's delivery node.  The
       requested URL contains the name cdn.csp.example.  (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 "internal" CDN-
       Domain as agreed above (op-b-acq.op-a.example).

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

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

   The advantages of this approach are that it is more transparent to
   the end user and requires fewer round trips than HTTP-based
   redirection (in its worst case, i.e., when none of the needed DNS
   information is cached).  A potential problem is that the Upstream CDN
Top   ToC   RFC7336 - Page 28
   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, the uCDN will only obtain the address of the client's
   LDNS resolver, which is not guaranteed to be in the same network (or
   geographic region) as the client.  If not (e.g., the end user uses a
   global DNS service), then the Upstream CDN cannot determine the
   appropriate Downstream CDN to serve the end user.  In this case, and
   assuming the uCDN is capable of detecting that situation, one option
   is for the Upstream CDN to treat the end user as it would any user
   not connected to a peer CDN.  Another option is for the Upstream CDN
   to "fall back" to a pure HTTP-based redirection strategy in this case
   (i.e., use the first method).  Note that this problem affects
   existing CDNs that rely on DNS to determine where to redirect client
   requests, but the consequences are arguably less serious for CDNI
   since the LDNS is likely in the same network as the dCDN serves.

   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 CDNI Footprint & Capabilities
   Advertisement 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 CDNI Logging interface discussed in this example.

3.4.1. Notes on Using DNSSEC

Although it is possible to use DNSSEC in combination with the Iterative DNS-based Redirection mechanism explained above, it is important to note that the uCDN might have to sign records on the fly, since the CNAME returned, and thus the signature provided, can potentially be different for each incoming query. Although there is nothing preventing a uCDN from performing such on-the-fly signing, this might be computationally expensive. In the case where the number of dCDNs, and thus the number of different CNAMEs to return, is relatively stable, an alternative solution would be for the uCDN to pre-generate signatures for all possible CNAMEs. For each incoming query, the uCDN would then determine the appropriate CNAME and return it together with the associated pre-generated signature. Note: In the latter case, maintaining the serial number and signature of Start of Authority (SOA) might be an issue since, technically, it should change every time a different CNAME is used. However, since,
Top   ToC   RFC7336 - Page 29
   in practice, direct SOA queries are relatively rare, a uCDN could
   defer incrementing the serial number and resigning the SOA until it
   is queried and then do it on-the-fly.

   Note also that the NS record and the glue records used in step 2 in
   the previous section should generally be identical to those of their
   authoritative zone managed by Operator B.  Even if they differ, this
   will not make the DNS resolution process fail, but the client DNS
   server will prefer the authoritative data in its cache and use it for
   subsequent queries.  Such inconsistency is a general operational
   issue of DNS, but it may be more important for this architecture
   because the uCDN (Operator A) would rely on the consistency to make
   the resulting redirection work as intended.  In general, it is the
   administrator's responsibility to make them consistent.

3.5. Dynamic Footprint Discovery Example

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.
Top   ToC   RFC7336 - Page 30
         End User                 Operator B                Operator A
             |DNS cdn.csp.example      |                         |
             |-------------------------------------------------->|
             |                         |                         |(1)
             |                         |   RI REQ op-b.example   |
             |                         |<------------------------|
             |                         |                         |(2)
             |                         |    RI REPLY             |
             |                         |------------------------>|
             |                         |                         |(3)
             |CNAME b.cdn.csp.example  |                         |
             |NS records for b.cdn.csp.example                   |
             |<--------------------------------------------------|
             |DNS b.cdn.csp.example    |                         |
             |------------------------>|                         |
             |                         |(2)                      |
             |IPaddr of B's Delivery Node                        |
             |<------------------------|                         |
             |HTTP cdn.csp.example     |                         |
             |------------------------>|                         |
             |                         |(3)                      |
             |                         |DNS op-b-acq.op-a.example|
             |                         |------------------------>|
             |                         |                         |(4)
             |                         |IPaddr of A's Delivery Node
             |                         |<------------------------|
             |                         |HTTP op-b-acq.op-a.example
             |                         |------------------------>|
             |                         |                         |(5)
             |                         |Data                     |
             |                         |<------------------------|
             |Data                     |                         |
             |<------------------------|                         |

          Figure 6: Message Flow for Dynamic Footprint Discovery

   This example differs from the one in Figure 5 only in the addition of
   an RI request (step 2) and corresponding response (step 3).  The RI
   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 RR/RI REPLY messages that are not
Top   ToC   RFC7336 - Page 31
   in direct response to a corresponding RR/RI 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 Section 3.4.)

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

3.6. Content Removal Example

The following example illustrates how the CDNI Control interface may be used to achieve pre-positioning of an item of content in the dCDN. 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 CI to request that content identified by a particular URL be removed from dCDN. The following diagram illustrates the operation. It should be noted that a uCDN will typically not know whether a dCDN has cached a given content item; however, it may send the content removal request to make sure no cached versions remain to satisfy any contractual obligations it may have. End User Operator B Operator A | |CI purge cdn.csp.example/... | |<------------------------| | | | | |CI OK | | |------------------------>| | | | Figure 7: Message Flow for Content Removal The CI is used to convey the request from the uCDN to the dCDN that some previously acquired content should be deleted. The URL in the request specifies which content to remove. This example corresponds to a DNS-based redirection scenario such as Section 3.4. If HTTP- based redirection had been used, the URL for removal would be of the form peer-a.op-b.example/cdn.csp.example/... 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 the dCDN.
Top   ToC   RFC7336 - Page 32

3.7. Pre-positioned Content Acquisition Example

The following example illustrates how the CI may be used to pre- position an item of content in the dCDN. In this example, Operator A uses the CDNI Metadata interface to request that content identified by a particular URL be pre-positioned into Operator B CDN. End User Operator B Operator A | |CI pre-position cdn.csp.example/... | |<------------------------| | | |(1) | |CI OK | | |------------------------>| | | | | |DNS op-b-acq.op-a.example| | |------------------------>| | | |(2) | |IPaddr of A's Delivery Node | |<------------------------| | |HTTP op-b-acq.op-a.example | |------------------------>| | | |(3) | |Data | | |<------------------------| |DNS cdn.csp.example | | |--------------------------------------------->| | | |(4) |IPaddr of A's Request Router | |<---------------------------------------------| |HTTP cdn.csp.example| | |--------------------------------------------->| | | |(5) |302 peer-a.op-b.example/cdn.csp.example | |<---------------------------------------------| |DNS peer-a.op-b.example | |------------------->| | | |(6) | |IPaddr of B's Delivery Node | |<-------------------| | |HTTP peer-a.op-b.example/cdn.csp.example | |------------------->| | | |(7) | |Data | | |<-------------------| | Figure 8: Message Flow for Content Pre-Positioning
Top   ToC   RFC7336 - Page 33
   The steps illustrated in the figure are as follows:

   1.  Operator A uses the CI to request that Operator B pre-position a
       particular content item identified by its URL.  Operator B
       responds by confirming that it is willing to perform this
       operation.

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

   Steps 4, 5, 6, and 7 are exactly the same as steps 1, 2, 3, and 4 of
   Figure 3, only this time, Operator B's CDN can serve the end-user
   request without triggering dynamic content acquisition, since the
   content has been pre-positioned in the 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-positioned; however, such intra-CDN dynamic acquisition
   would not involve the uCDN.

3.8. Asynchronous CDNI Metadata Example

In this section, we walk through a simple example illustrating a scenario of asynchronously exchanging CDNI Metadata, where the Downstream CDN obtains CDNI Metadata for content ahead of a corresponding content request. The example that follows assumes that HTTP-based inter-CDN redirection and recursive CDNI request routing are used, as in Section 3.3. However, Asynchronous exchange of CDNI Metadata is similarly applicable to DNS-based inter-CDN redirection and iterative request routing (in which cases the CDNI Metadata may be used at slightly different processing stages of the message flows).
Top   ToC   RFC7336 - Page 34
         End User                 Operator B                Operator A
             |                         |                         |
             |                         |CI pre-position (Trigger)|
             |                         |<------------------------|(1)
             |                         |                         |
             |                         |CI OK                    |
             |                         |------------------------>|(2)
             |                         |                         |
             |                         |MI pull REQ              |
             |                         |------------------------>|(3)
             |                         |                         |
             |                         |MI metadata REP          |(4)
             |                         |                         |
             |                         |                         |
             | CONTENT REQUEST         |                         |
             |-------------------------------------------------->|(5)
             |                         |                         |
             |                         |   RI REQ                |
             |                         |<------------------------|(6)
             |                         |                         |
             |                         |   RI RESP               |
             |                         |------------------------>|(7)
             |                         |                         |
             | CONTENT REDIRECTION     |                         |
             |<--------------------------------------------------|(8)
             |                         |                         |
             | CONTENT REQUEST         |                         |
             |------------------------>|(9)                      |
             |                         |                         |
             :                         :                         :
             | CONTENT DATA            |                         |
             |<------------------------|                         |(10)


           Figure 9: Message Flow for Asynchronous CDNI Metadata

   The steps illustrated in the figure are as follows:

   1.   Operator A uses the CI to trigger the signaling of the
        availability of CDNI Metadata to Operator B.

   2.   Operator B acknowledges the receipt of this Trigger.

   3.   Operator B requests the latest metadata from Operator A using
        the MI.
Top   ToC   RFC7336 - Page 35
   4.   Operator A replies with the requested metadata.  This document
        does not constrain how the CDNI Metadata information is actually
        represented.  For the purposes of this example, we assume that
        Operator A provides CDNI Metadata to Operator B indicating that:

        *  this CDNI Metadata is applicable to any content referenced by
           some CDN-Domain.

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

   5.   A Content Request occurs as usual.

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

   7.   Operator B's Request Router issues a CDNI Request Routing
        Redirection response (RI RESP) as in Section 3.3.

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

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

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

3.9. Synchronous CDNI Metadata Acquisition Example

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

       End User                 Operator B                Operator A
           |                         |                         |
           | CONTENT REQUEST         |                         |
           |-------------------------------------------------->|(1)
           |                         |                         |
           |                         |   RI REQ                |
           |                      (2)|<------------------------|
           |                         |                         |
           |                         |   MI REQ                |
           |                      (3)|------------------------>|
           |                         |   MI RESP               |
           |                         |<------------------------|(4)
           |                         |                         |
           |                         |   RI RESP               |
           |                         |------------------------>|(5)
           |                         |                         |
           |                         |                         |
           | CONTENT REDIRECTION     |                         |
           |<--------------------------------------------------|(6)
           |                         |                         |
           | CONTENT REQUEST         |                         |
           |------------------------>|(7)                      |
           |                         |                         |
           |                         |   MI REQ                |
           |                      (8)|------------------------>|
           |                         |   MI RESP               |
           |                         |<------------------------|(9)
           |                         |                         |
           :                         :                         :
           | CONTENT DATA            |                         |
           |<------------------------|                         |(10)


     Figure 10: Message Flow for Synchronous CDNI Metadata Acquisition

   The steps illustrated in the figure are as follows:

   1.   A Content Request arrives as normal.

   2.   An RI request occurs as in the prior example.
Top   ToC   RFC7336 - Page 37
   3.   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.  We assume the URI
        for the a metadata server is known ahead of time through some
        out-of-band means.

   4.   On receipt of a CDNI Metadata 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.)

   5.   Response to the RI request as normal.

   6.   Redirection message is sent to the end user.

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

   8.   The delivery node Triggers dynamic acquisition of additional
        CDNI Metadata that are needed to process the end-user content
        request.  Note that there may exist cases where this step need
        not happen, for example, because the metadata were already
        acquired previously.

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

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

3.10. Content and Metadata Acquisition with Multiple Upstream CDNs

A single dCDN may receive end-user requests from multiple uCDNs. When a dCDN receives an end-user request, it must determine the identity of the uCDN from which it should acquire the requested content. Ideally, the acquisition path of an end-user request will follow the redirection path of the request. The dCDN should acquire the content from the same uCDN that redirected the request. Determining the acquisition path requires the dCDN to reconstruct the redirection path based on information in the end-user request. The method for reconstructing the redirection path differs based on the redirection approach: HTTP or DNS.
Top   ToC   RFC7336 - Page 38
   With HTTP-redirection, the rewritten URI should include sufficient
   information for the dCDN to directly or indirectly determine the uCDN
   when the end-user request is received.  The HTTP-redirection approach
   can be further broken-down based on the how the URL is rewritten
   during redirection: HTTP redirection with or without Site
   Aggregation.  HTTP redirection with Site Aggregation hides the
   identity of the original CSP.  HTTP redirection without Site
   Aggregation does not attempt to hide the identity of the original
   CSP.  With both approaches, the rewritten URI includes enough
   information to identify the immediate neighbor uCDN.

   With DNS-redirection, the dCDN receives the published URI (instead of
   a rewritten URI) and does not have sufficient information for the
   dCDN to identify the appropriate uCDN.  The dCDN may narrow the set
   of viable uCDNs by examining the CDNI Metadata from each to determine
   which uCDNs are hosting metadata for the requested content.  If there
   is a single uCDN hosting metadata for the requested content, the dCDN
   can assume that the request redirection is coming from this uCDN and
   can acquire content from that uCDN.  If there are multiple uCDNs
   hosting metadata for the requested content, the dCDN may be ready to
   trust any of these uCDNs to acquire the content (provided the uCDN is
   in a position to serve it).  If the dCDN is not ready to trust any of
   these uCDNs, it needs to ensure via out of band arrangements that,
   for a given content, only a single uCDN will ever redirect requests
   to the dCDN.

   Content acquisition may be preceded by content metadata acquisition.
   If possible, the acquisition path for metadata should also follow the
   redirection path.  Additionally, we assume metadata is indexed based
   on rewritten URIs in the case of HTTP redirection and is indexed
   based on published URIs in the case of DNS-redirection.  Thus, the RI
   and the MI are tightly coupled in that the result of request routing
   (a rewritten URI pointing to the dCDN) serves as an input to metadata
   lookup.  If the content metadata includes information for acquiring
   the content, then the MI is also tightly coupled with the acquisition
   interface in that the result of the metadata lookup (an acquisition
   URL likely hosted by the uCDN) should serve as input to the content
   acquisition.



(page 38 continued on part 3)

Next Section