Content delivery network interconnection

Thanks to the many benefits of CDNs, e.g. reduced delivery cost, improved quality of experience (QoE), and increased robustness of delivery, CDNs have become popular for large-scale content delivery of cacheable content. For this reason, CDN providers are scaling up their infrastructure and many Internet service providers (ISPs)/network service providers (NSPs) have deployed or are deploying their own CDNs for their own use or for lease, if a business and technical arrangement between them and a CDN provider were made. Those stand-alone CDNs with well-defined request routing, delivery, acquisition, accounting systems and protocols may sooner or later face either footprint, resource or capability limits. The CDNI targets at leveraging separate CDNs to provide end-to-end delivery of content from CSPs to end users, regardless of their location or attachment network.

Let's consider an interconnection of two CDNs as presented in the below figure. The ISP-A deploys an authoritative upstream CDN (uCDN), and he has established a technical and business arrangement with the CSP. Because the CDN-A is authorised to serve on behalf of the CSP, a user in the network of ISP-B requests content from CDN-A (1). The uCDN can either serve the request itself or redirect it to a downstream CDN (dCDN) if, for example, dCDN is closer to the user equipment (UE). If the request is redirected, the interconnected CDNs must provide the requested content to the dCDN. If the content is not available in the uCDN, it can be acquired first from CSP (2) and then submitted to a surrogate in the dCDN (3). The UE following the redirection will request the content from the dCDN (4), and finally, the requested content will be distributed from the surrogate.

An example of end-to-end content delivery using CDNI.

In this example, all four parties can benefit from the interconnection: the end users can benefit from better quality of service (QoS); the CSP benefits because it has to make only one business and technical arrangement with uCDN; the uCDN benefits because it does not have to deploy such an extensive CDN; and the dCDN will receive some compensation for the delivery. The procedures and algorithms responsible for choosing the right dCDN, choosing a surrogate and the procedure for acquiring the content to be submitted to the surrogate can differ, but the dCDN serves the content on behalf of the uCDN.

Below is an incomplete list of use cases for which CDNI was presented.[1] The use cases seem to be convergent among the standardisation approaches (see Standardisation status section).

The Internet Engineering Task Force (IETF) (see Standardisation status section) [1][2] defines five interfaces required to interconnect a pair of CDNs from a technical perspective, as depicted in Figure 2. The interfaces are control plane interfaces operating at the application layer that aim to reuse or leverage existing protocols, e.g. HTTP, rather than to define a new one. This model of the CDNI does not define content acquisition, delivery, request interfaces and mechanisms because today CDNs already use standardised protocols for them, e.g. HTTP, FTP, rsync, etc. are used for content acquisition. The interconnection allows a number of CDNs to be connected in various topologies, such as line, mesh or start topology. It is important to note that in order to deploy a CDNI, additional business arrangements have to be established between the CSP and the uCDN and between the uCDN and the dCDN. At the time of this writing detailed operations of interfaces and the structure of exchanged objects are under standardisation process.[2][3][4][5][6][7][8] The defined interfaces are briefly described as follows.

A CDNI model as defined by the IETF.

For selection of a dCDN, the information on its footprint and capabilities is mainly used. The footprint can be specified with the use of IP subnets, autonomous systems (AS) numbers or country, state and code combinations.[9] The capabilities describe features, services and states a CDN can or cannot meet and includes network and administrative capabilities, information about caches and the resources. The network information may disclose details on QoS or the supported streaming bandwidth. The administrative capabilities may inform on established limits and policies. The data about the caches may inform about the load and the available resources. The resource information may specify supported delivery technologies and content types, such as the ability to stream video to a particular device type.

Given the information on footprint and capabilities, the uCDN may proceed to the initial selection of a dCDN—first on the basis of footprint and then on the basis of capabilities. However, such procedures may lead to suboptimal or incorrect decisions; for example when the dCDN is selected on the basis of footprint, it cannot provide the requested delivery technology. Therefore, a more approved procedure involves making the footprint information part of the capabilities requirements.

Various protocols are considered for exchange of information on either footprint, such as BGP, on capabilities, such as HTTP, or on both footprint and capabilities, such as Application Layer Traffic Optimization (ALTO).[10]

For user request redirection, two mechanisms, among others, are used in CDNs: mainly HTTP and DNS redirection.

The HTTP method uses the HTTP redirection response, e.g. 302, containing a new URL to visit. Besides the option of changing the name of the server in the new URL, the URL can contain the name of the original server, which provides a means for an in-band communication. Moreover, the redirection mechanism can use the information on the IP address of a client, the requested content type or user agent for target surrogate selection. Unfortunately, change of a URL's domain will cause web browsers to not send cookies.

The DNS redirection is completely transparent to the end user in comparison to the HTTP method. In the simple DNS redirection, the authoritative DNS server for the name returns an IP address based on the characteristic of a client. Which IP address is returned as a result depends, among other factors, on either the localisation of the end user or the surrogate server's load. There is another DNS redirection method in which the authoritative server returns a CNAME response. This forces the peer to restart the name lookup using a new name. To preserve the freshness of the redirection in case of cached DNS responses, an appropriate value of the time-to-live parameter is set. A drawback of this method is that DNS caches hide the end user's IP address.

Both redirection methods, HTTP and DNS based, can be performed in the CDNI, either iteratively or recursively. The recursive redirection is more transparent for the end user because it involves only one UE redirection, but it has other dependencies on the interconnection realisation. A single UE redirection may be preferable if the number of interconnected CDNs exceeds two.

The sequence diagram presented in the figure below provides some details on CDNI and the iterative DNS redirection operation. In the depicted example, a UE downloads content from the address cdn.csp.com/foo, which is primarily delivered by the CDN-A on behalf of a CSP with the address csp.com.

An example of iterative DNS redirection of content request in CDNI.

1. Before any request redirection, the CDN-B (dCDN) announces information on supported footprint and capabilities.
2. The UE performs a DNS lookup for a server cdn.csp.com in the domain of the CSP from which it is going to download the content.
3. A request router in CDN-A (uCDN) servicing the domain cdn.csp.com processes the request and recognises, based on the source IP address of the request, that the end user could be better served by the dCDN. Therefore, it performs an inquiry in dCDN to determine if it is willing and able to serve this request.
4. If the dCDN is able to handle the request, the request router in uCDN returns a DNS CNAME response. This response contains a new domain, e.g. b.cdn.csp.com, indicating dCDN and the original domain and an NS record that maps this new domain to a request router in dCDN.
5. The UE does a DNS lookup using the new domain (b.cdn.csp.com). A request router in dCDN responds to this request with the IP address of a suitable delivery node.
6. The UE requests the content /foo from the delivery node in dCDN. At this point, the delivery node receives the real IP address of the UE and the information on the requested content. If the redirections in previous steps were incorrect, the delivery node could perform a HTTP redirection.
7. If the metadata for content /foo is not available in dCDN, the metadata interface is used to request it from the uCDN.
8. If the request is going to be served, i.e. metadata restrictions were met and a cache miss occurs, the delivery node in dCDN must start the acquisition process. The delivery node does a DNS lookup for an internal domain address op-b-acq.op-a.net. The uCDN recognises that the request is from a dCDN, rather than from a UE, and returns an IP address of a delivery node in the uCDN.
9. The content /foo is delivered to the delivery node in dCDN from the delivery node in uCDN.
10. The content /foo is delivered to the UE from the delivery node in dCDN.
11. After some time, the uCDN may instruct the dCDN to purge the content /foo to ensure that it is not delivered again.
12. After the content is delivered a log of delivery actions is provided to the uCDN.

If addressed in CDNI specifications, support of HTTP adaptive streaming (HAS) [11] is particularly realised. Large objects are broken into a sequence of small, independent chunks, e.g. videos, that are perceived as if there were no relationship between the chunks. As a result, content acquisition and chunk purging are performed on a per-chunk basis. In order to reduce the CDNI load, specifications either allow relative Uniform Resource Locators (URLs) or modify absolute URLs in the manifest file of a resource distributed via HAS.

The security of the CDNI is optional, and its support is introduced as a capability of a CDN. Security of the CDNI involves content confidentiality protection, authenticated peers communication and data origin authentication. The data origin authentication is of high importance if the trust of the link between CDN is questioned. The security is enforced by switching to secure versions of protocols deployed in the CDNI, e.g. HTTPS. Usually, if a CDNI is established via secure protocols, secure protocols are also used for content acquisition and distribution.

Further issues related to security could be various end user privacy requirements in relation to the exchanged logs across different countries or authenticity of logs for delivery charging across CDNs. What consequences a security breakage would have depends on the interface and its function; for example, a corruption of the control interface could corrupt other interfaces, while a corrupted logging interface could enable a fraud in charging.

A number of organisations and projects, i.e. IETF, European Telecommunications Standards Institute (ETSI), Alliance for Telecommunications Industry Solutions (ATIS) and Open ContEnt Aware Networks (OCEAN), have been working or are working on the standardisation of CDNI interfaces and methods. There exist some mismatches and differences between the specifications in the defined interfaces as well as in terminology.

The ETSI specifications [12] [13] describe three CDNI interfaces. The first one, the interconnection control, seems to map on the union of ETSI's control and logging interfaces. The next one, the request and content control, seems to map in turn on the union of ETSI's request routing and metadata interfaces. The third one is the distribution of content interface.

The OCEAN framework exhaustively specifies the open interfaces and processes of the proposed CDNI.[14][15] The documents define additional business, acquisition and inner metadata interfaces. Further, the metadata interface as defined by the ETSI is split into two more specialised interfaces that, together, result in the reference model with nine interfaces.

The paid ATIS standards and technical reports define specification of use cases and high-level requirements for a CDNI. According to the freely available abstracts these specifications cover, among other aspects, the interconnection of two CDN providers [16] as a foundation for using multicast as a means for distributing content across two CDN providers [17] and for joining together a multiple of CDN providers to form a CDN federation.[18]

• Content delivery network
• Interconnection
• Federation (information technology)
• Load balancing (computing)
• Country code
• URL redirection
• CNAME record
• Dynamic Adaptive Streaming over HTTP

• S. Puopolo, M. Latouche, F. Le Faucheur, and J. Defour. Content Delivery Network (CDN) Federations How SPs Can Win the Battle for Content-Hungry Consumers, 2011.
• A. Pathan and R. Buyya. A Taxonomy and Survey of Content Delivery Networks. Technical Report, GRIDS-TR-2007-4, Grid Computing and Distributed Systems Laboratory, The University of Melbourne, Australia., Feb. 2007.

• Content Delivery Networks Interconnection (cdni)
• OpenCDN | CDN Federation | EdgeCast
• SwiftServe - Transparent Caching and Content Delivery Network (CDN) Technology
• Multi-CDN Federation | Cedexis - Real time data for real time decisions
• CDN strategy blog, CDN news, CDN industry news, content delivery network strategies