tech-invite   World Map     

IETF     RFCs     Groups     SIP     ABNFs    |    3GPP     Specs     Gloss.     Arch.     IMS     UICC    |    Misc.    |    search     info

RFC 7336

 
 
 

Framework for Content Distribution Network Interconnection (CDNI)

Part 3 of 4, p. 38 to 53
Prev RFC Part       Next RFC Part

 


prevText      Top      Up      ToC       Page 38 
4.  Main Interfaces

   Figure 1 illustrates the 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, but see [RFC6707] and
   [RFC7337] for some discussion of the interfaces.

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

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

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

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

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

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

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

Top      Up      ToC       Page 40 
4.2.  Cross-Interface Concerns

   Although the CDNI interfaces are largely independent, there are a set
   of conventions practiced consistently across all interfaces.  Most
   important among these is how resources are named, for example, how
   the CDNI Metadata and Control interfaces identify the set of
   resources to which a given directive applies or the CDNI Logging
   interface identifies the set of resources for which a summary record
   applies.

   While, theoretically, the CDNI interfaces could explicitly identify
   every individual resource, in practice, they name resource aggregates
   (sets of URIs) that are to be treated in a similar way.  For example,
   URI aggregates can be identified by a CDN-Domain (i.e., the FQDN at
   the beginning of a URI) or by a URI-Filter (i.e., a regular
   expression that matches a subset of URIs contained in some CDN-
   Domain).  In other words, CDN-Domains and URI-Filters provide a
   uniform means to aggregate sets (and subsets) of URIs for the purpose
   of defining the scope for some operation in one of the CDNI
   interfaces.

4.3.  Request Routing Interfaces

   The Request Routing interface comprises two parts: the Asynchronous
   interface used by a dCDN to advertise footprint and capabilities
   (denoted FCI) to a uCDN, allowing the uCDN to decide whether to
   redirect particular user requests to that dCDN; and the Synchronous
   interface used by the uCDN to redirect a user request to the dCDN
   (denoted RI).  (These are somewhat analogous to the operations of
   routing and forwarding in IP.)

   As illustrated in Section 3, the RI part of request routing 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.

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

   In support of these redirection requests, it is necessary for CDN
   peers to exchange additional information with each other, and this is
   the role of the FCI part of request routing.  Depending on the
   method(s) supported, this might include:

Top      Up      ToC       Page 41 
   o  The operator's unique id (operator-id) or distinguished CDN-Domain
      (operator-domain);

   o  NS records for the operator's set of externally visible Request
      Routers;

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

   o  Additional capabilities of the dCDN, such as its ability to
      support different CDNI Metadata requests.

   Note that the set of requests that a dCDN is willing to serve could
   in some cases be relatively static (e.g., a set of IP prefixes),
   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 the exchange supported by FCI would be helpful.  A further
   discussion of the Footprint & Capability Advertisement interface can
   be found in [FOOTPRINT-CAPABILITY].

4.4.  CDNI Logging Interface

   It is necessary for the Upstream CDN to have visibility into the
   delivery of content that it redirected to a 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 LI.

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

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

   o  Domain - the full domain name of the origin server

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

   o  End time - the ending time of the transfer

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

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

Top      Up      ToC       Page 42 
   o  URL - the requested URL

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

   o  Response - a numeric response code indicating transfer result

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

   o  Request ID - a unique identifier for this transfer

   o  User agent - the user agent, if supplied

   o  Duration - the duration of the transfer in milliseconds

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

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

   Of these, only the Domain field is indirect in the Downstream CDN --
   it is set to the CDN-Domain used by the Upstream CDN rather than the
   actual origin server.  This field could then used to filter traffic
   log entries so only those entries matching the Upstream CDN are
   reported to the corresponding operator.  Further discussion of the LI
   can be found in [LOGGING].

   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 know the set of CDN-Domains that belong to each Upstream peer.
   If this information is already exchanged between peers as part of
   another interface, then direct peer-to-peer reporting is
   straightforward.  If it is not available, and operators do not wish
   to advertise the set of CDN-Domains they serve to their peers, then
   the second option is for each CDN to send both its non-local traffic
   records and the set of CDN-Domains it serves to an independent third
   party (i.e., a CDN Exchange), which subsequently filters, merges, and
   distributes traffic records on behalf of each participating CDN
   operator.

   A second open question is how timely traffic information should be.
   For example, in addition to offline 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

Top      Up      ToC       Page 43 
   to record that a request has been issued for the purpose of real-time
   traffic monitoring.  The Upstream CDN can also use this information
   to validate the traffic logs received later from the Downstream CDN.

   There is obviously a trade-off between accuracy of such monitoring
   and the overhead of the Downstream CDN having to go back to the
   Upstream CDN for every request.

   Another design trade-off in the LI is the degree of aggregation or
   summarization of data.  One situation that lends itself to
   summarization is the delivery of HTTP Adaptive Streaming (HAS), since
   the large number of individual chunk requests potentially results in
   large volumes of logging information.  This case is discussed below,
   but other forms of aggregation may also be useful.  For example,
   there may be situations where bulk metrics such as bytes delivered
   per hour may suffice rather than the detailed per-request logs
   outlined above.  It seems likely that a range of granularities of
   logging will be needed along with ways to specify the type and degree
   of aggregation required.

4.5.  CDNI Control Interface

   The CDNI 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 the dCDN to the uCDN in order to
   bootstrap the CDNI Logging interface.  It may also be used, for
   example, to establish security associations for the other interfaces.

   The other role the CI 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 [CONTROL-TRIGGERS].

4.6.  CDNI Metadata Interface

   The role of the CDNI Metadata interface is to enable CDNI
   distribution metadata to be conveyed to the Downstream CDN by the
   Upstream CDN.  Such metadata includes geo-blocking restrictions,
   availability windows, access-control policies, and so on.  It may
   also include information to facilitate acquisition of content by a
   dCDN (e.g., alternate sources for the content, authorization
   information needed to acquire the content from the source).  For a
   full discussion of the CDNI Metadata interface, see [METADATA]

   Some distribution metadata may be partially emulated using in-band
   mechanisms.  For example, in case of any geo-blocking restrictions or
   availability windows, the Upstream CDN can elect to redirect a
   request to the Downstream CDN only if that CDN's advertised delivery

Top      Up      ToC       Page 44 
   footprint is acceptable for the requested URL.  Similarly, the
   request could be forwarded only if the current time is within the
   availability window.  However, such approaches typically come with
   shortcomings such as inability to prevent from replay outside the
   time window or inability to make use of a Downstream CDN that covers
   a broader footprint than the geo-blocking restrictions.

   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.

   All of these in-band techniques serve to illustrate that uCDNs have
   the option of enforcing some of their access control policies
   themselves (at the expense of increased inter-CDN signaling load),
   rather than delegating enforcement to dCDNs using the MI.  As a
   consequence, the MI could provide a means for the uCDN to express its
   desire to retain enforcement for itself.  For example, this might be
   done by including a "check with me" flag in the metadata associated
   with certain content.  The realization of such in-band techniques
   over the various inter-CDN acquisition protocols (e.g., HTTP)
   requires further investigation and may require small extensions or
   semantic changes to the acquisition protocol.

4.7.  HTTP Adaptive Streaming Concerns

   We consider HTTP Adaptive Streaming (HAS) and the impact it has on
   the CDNI interfaces because large objects (e.g., videos) are broken
   into a sequence of small, independent chunks.  For each of the
   following, a more thorough discussion, including an overview of the
   trade-offs involved in alternative designs, can be found in RFC 6983.

   First, with respect to Content Acquisition and File Management, which
   are out of scope for the CDNI interfaces but, nonetheless, relevant
   to the overall operation, we assume no additional measures are
   required to deal with large numbers of chunks.  This means that the
   dCDN is not explicitly made aware of any relationship between
   different chunks, and the dCDN handles each chunk as if it were an
   individual and independent content item.  The result is that content
   acquisition between uCDN and dCDN also happens on a per-chunk basis.
   This approach is in line with the recommendations made in RFC 6983,
   which also identifies potential improvements in this area that might
   be considered in the future.

Top      Up      ToC       Page 45 
   Second, with respect to request routing, we note that HAS manifest
   files have the potential to interfere with request routing since
   manifest files contain URLs pointing to the location of content
   chunks.  To make sure that a manifest file does not hinder CDNI
   request routing and does not place excessive load on CDNI resources,
   either the use of manifest files could be limited to those containing
   relative URLs or the uCDN could modify the URLs in the manifest.  Our
   approach for dealing with these issues is twofold.  As a mandatory
   requirement, CDNs should be able to handle unmodified manifest files
   containing either relative or absolute URLs.  To limit the number of
   redirects, and thus the load placed on the CDNI interfaces, as an
   optional feature uCDNs can use the information obtained through the
   CDNI Request Routing Redirection interface to modify the URLs in the
   manifest file.  Since the modification of the manifest file is an
   optional uCDN-internal process, this does not require any
   standardization effort beyond being able to communicate chunk
   locations in the CDNI Request Routing Redirection interface.

   Third, with respect to the CDNI Logging interface, there are several
   potential issues, including the large number of individual chunk
   requests potentially resulting in large volumes of logging
   information, and the desire to correlate logging information for
   chunk requests that correspond to the same HAS session.  For the
   initial CDNI specification, our approach is to expect participating
   CDNs to support per-chunk logging (e.g., logging each chunk request
   as if it were an independent content request) over the CDNI Logging
   interface.  Optionally, the LI may include a Content Collection
   IDentifier (CCID) and/or a Session IDentifier (SID) as part of the
   logging fields, thereby facilitating correlation of per-chunk logs
   into per-session logs for applications benefiting from such session
   level information (e.g., session-based analytics).  This approach is
   in line with the recommendations made in RFC 6983, which also
   identifies potential improvements in this area that might be
   considered in the future.

   Fourth, with respect to the CDNI Control interface, and in particular
   purging HAS chunks from a given CDN, our approach is to expect each
   CDN supports per-chunk content purge (e.g., purging of chunks as if
   they were individual content items).  Optionally, a CDN may support
   content purge on the basis of a "Purge IDentifier (Purge-ID)"
   allowing the removal of all chunks related to a given Content
   Collection with a single reference.  It is possible that this Purge-
   ID could be merged with the CCID discussed above for HAS Logging, or
   alternatively, they may remain distinct.

Top      Up      ToC       Page 46 
4.8.  URI Rewriting

   When using HTTP redirection, content URIs may be rewritten when
   redirection takes place within a uCDN, from a uCDN to a dCDN, and
   within the dCDN.  In the case of cascaded CDNs, content URIs may be
   rewritten at every CDN hop (e.g., between the uCDN and the dCDN
   acting as the transit CDN, and between the transit CDN and the dCDN
   serving the request).  The content URI used between any uCDN/dCDN
   pair becomes a common handle that can be referred to without
   ambiguity by both CDNs in all their inter-CDN communications.  This
   handle allows the uCDN and dCDN to correlate information exchanged
   using other CDNI interfaces in both the Downstream direction (e.g.,
   when using the MI) and the Upstream direction (e.g., when using the
   LI).

   Consider the simple case of a single uCDN/dCDN pair using HTTP
   redirection.  We introduce the following terminology for content URIs
   to simplify the discussion:

      "u-URI" represents a content URI in a request presented to the
      uCDN;

      "ud-URI" is a content URI acting as the common handle across uCDN
      and dCDN for requests redirected by the uCDN to a specific dCDN;

      "d-URI" represents a content URI in a request made within the
      delegate dCDN.

   In our simple pair-wise example, the "ud-URI" effectively becomes the
   handle that the uCDN/dCDN pair use to correlate all CDNI information.
   In particular, for a given pair of CDNs executing the HTTP
   redirection, the uCDN needs to map the u-URI to the ud-URI handle for
   all MI message exchanges, while the dCDN needs to map the d-URI to
   the ud-URI handle for all LI message exchanges.

   In the case of cascaded CDNs, the transit CDN will rewrite the
   content URI when redirecting to the dCDN, thereby establishing a new
   handle between the transit CDN and the dCDN, that is different from
   the handle between the uCDN and transit CDN.  It is the
   responsibility of the transit CDN to manage its mapping across
   handles so the right handle for all pairs of CDNs is always used in
   its CDNI communication.

   In summary, all CDNI interfaces between a given pair of CDNs need to
   always use the "ud-URI" handle for that specific CDN pair as their
   content URI reference.

Top      Up      ToC       Page 47 
5.  Deployment Models

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

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

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

5.1.  Meshed CDNs

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

Top      Up      ToC       Page 48 
         -------------             -----------
        /    CDN A    \<==CDNI===>/   CDN B   \
        \             /           \           /
         -------------             -----------
              /\      \\                 /\
              ||       \\                ||
             CDNI       \==CDNI===\\    CDNI
              ||                   \\    ||
              \/                   \/    \/
         -------------             -----------
        /    CDN C    \===CDNI===>/   CDN D   \
        \             /           \           /
         -------------             -----------
              /\
              ||
             CDNI
              ||
              \/
         -------------
        /    CDN E    \
        \             /
         -------------

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

           Figure 11: CDNI Deployment Model: CDN Meshing Example

5.2.  CSP Combined with CDN

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

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

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

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

5.3.  CSP Using CDNI Request Routing Interface

   As another example, a content provider organization may choose to run
   its own Request Routing function as a way to select among multiple
   candidate CDN providers; in this case, the content provider may be
   modeled as the combination of a CSP and of a special, restricted case
   of a CDN.  In that case, as illustrated in Figure 13, the CDNI
   Request Routing interfaces 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).

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

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

         Figure 13: CDNI Deployment Model: Organization Combining
                            CSP and Partial CDN

5.4.  CDN Federations and CDN Exchanges

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

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

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

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

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

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

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

Top      Up      ToC       Page 52 
             ----------                            ---------
            /    CDN A \                          /   CDN B  \
            | +----+   |                         |  +----+   |
   //========>| C  |<==============CDNI============>| C  |<==========\\
   ||       | +----+   |            C            |  +----+   |       ||
   ||       | +----+   |                         |  +----+   |       ||
   || //=====>| D  |<==============CDNI============>| D  |<=======\\ ||
   || ||    | +----+   |            M            |  +----+   |    || ||
   || ||    |          |     /------------\      |           |    || ||
   || ||    | +----+   |     | +--+ CDN Ex|      |  +----+   |    || ||
   || || //==>| RR |<===CDNI==>|RR|<=======CDNI====>| RR |<====\\ || ||
   || || || | +----+   | RR  | +--+       | RR   |  +----+   | || || ||
   || || || |          |     |  /\        |      |           | || || ||
   || || || | +----+   |     |  ||  +---+ |      |  +----+   | || || ||
   || || || | | L  |<===CDNI=======>| L |<=CDNI====>| L  |   | || || ||
   || || || | +----+   |  L  |  ||  +---+ |  L   |  +----+   | || || ||
   || || || \          /     \  ||    /\  /      \           / || || ||
   || || || -----------       --||----||--        -----------  || || ||
   || || ||                     ||    ||                       || || ||
   || || ||                  CDNI RR  ||                       || || ||
   || || ||                     ||   CDNI L                    || || ||
   || || ||                     ||    ||                       || || ||
   || || ||                  ---||----||----                   || || ||
   || || ||                 /   \/    ||    \                  || || ||
   || || ||                 |  +----+ ||    |                  || || ||
   || || \\=====CDNI==========>| RR |<=============CDNI========// || ||
   || ||         RR         |  +----+ \/    |       RR            || ||
   || ||                    |        +----+ |                     || ||
   || ||                    |        | L  | |                     || ||
   || ||                    |        +----+ |                     || ||
   || ||                    |  +----+       |                     || ||
   || \\=======CDNI===========>| D  |<=============CDNI===========// ||
   ||           M           |  +----+       |       M                ||
   ||                       |  +----+       |                        ||
   \\==========CDNI===========>| C  |<=============CDNI==============//
                C           |  +----+       |       C
                            \        CDN C  /
                             --------------

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

              Figure 14: CDNI Deployment Model: CDN Exchange

Top      Up      ToC       Page 53 
   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.



(page 53 continued on part 4)

Next RFC Part