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

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.

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 [I-D.ietf-cdni-requirements] for some discussion of the interfaces.

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

There is also an important interface between the user and the Request Routing function of both uCDN and dCDN (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 information a subset of metadata such as the minimum information that is required for dCDN to obtain the content from uCDN.

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

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

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

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

There are other opportunities for in-band communication beyond HTTP redirects. For example, many of the HTTP directives used by proxy servers can also be used by peer CDNs to inform each other of caching activity. Of these, one that is particularly relevant is the If-Modified-Since directive, which is used with the GET method to make it conditional: if the requested object has not been modified since the time specified in this field, a copy of the object will not be returned, and instead, a 304 (not modified) response will be returned.

4.2. 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 exampmle, 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 in the limit 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-Doman). 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 advertize 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 [I-D.ietf-cdni-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:

• The operator’s unique id (operator-id) or distinguished CDN-Domain (operator-domain);
• NS records for the operator’s set of externally visible request routers;
• The set of requests the dCDN operator is prepared to serve (e.g. a set of client IP prefixes or geographic regions that may be served by dCDN).
• Additional capabilities of the dCDN, such as its ability to support different CDNI Metadata requests.

Note that the set of requests that dCDN is willing to serve could in some cases be relatively static (e.g., a set of IP prefixes) which could be exchanged off-line, or might even be negotiated as part of a peering agreement. However, it may also be more dynamic, in which case the exchange supported by FCI would be be helpful. A further discussion of the Footprint & Capability Advertisement interface can be found in [I-D.ietf-cdni-footprint-capabilities-semantics].

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, 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:

• Domain – the full domain name of the origin server
• IP address – the IP address of the client making the request
• End time – the ending time of the transfer
• Time zone – any time zone modifier for the end time
• Method – the transfer command itself (e.g., GET, POST, HEAD)
• URL – the requested URL
• Version – the protocol version, such as HTTP/1.0
• Response – a numeric response code indicating transfer result
• Bytes Sent – the number of bytes in the body sent to the client
• Request ID – a unique identifier for this transfer
• User agent – the user agent, if supplied
• Duration – the duration of the transfer in milliseconds
• Cached Bytes – the number of body bytes served from the cache
• 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 [I-D.ietf-cdni-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 knows 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 to record that a request has been issued for the purpose of real-time traffic monitoring. The upstream CDN can also use this information to validate the traffic logs received later from the downstream CDN.

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

Another design tradeoff in the 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 dCDN to 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 [I-D.ietf-cdni-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 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 [I-D.ietf-cdni-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 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.

Fine-grain control over how the downstream CDN delivers content on behalf of the upstream CDN is also possible. For example, by including the Forwarded HTTP header [I-D.ietf-appsawg-http-forwarded] with the conditional GET request, the downstream CDN can report the end-user’s IP address to the upstream CDN, giving it an opportunity to control whether the downstream CDN should serve the content to this particular end-user. The upstream CDN would communicate its directive through its response to the conditional GET. The downstream CDN can cache information for a period of time specified by the upstream CDN, thereby reducing control overhead, but then preventing per-request control during the corresponding caching period.

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 tradeoffs 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 nontheless 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.

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, the use of manifest files could either 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 CNDI 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.

4.8. URI Rewriting

When using HTTP redirection, content URIs may be rewritten when redirection takes place within an uCDN, from an 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 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 a 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.

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

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

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

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

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