Content delivery network interconnection (CDNI) is a set of interfaces and mechanisms required for interconnecting two independent content delivery networks (CDNs) that enables one to deliver content on behalf of the other. Interconnected CDNs offer many benefits, such as footprint extension, reduced infrastructure costs, higher availability, etc., for content service providers (CSPs), CDNs, and end users. Among its many use cases, it allows small CDNs to interconnect and provides services for CSPs that allows them to compete against the CDNs of global CSPs.
Rationale
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.
Example of operation 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.
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.
Use cases
Below is an incomplete list of use cases for which CDNI was presented.G. Bertrand, E. Stephan, T. Burbridge, P. Eardley, K. Ma, and G. Watson. Use Cases for Content Delivery Network Interconnection. RFC 6770 (Informational), November 2012. The use cases seem to be convergent among the standardisation approaches (see Standardisation status section).
Footprint extension
Footprint is defined as a region for which a CDN is able to deliver content. With a deployed CDNI, non-global CDN providers may offer CSPs an extended geographical footprint without
compromising the quality of delivery; additional transit costs, if the content is to be served from geographically or topologically remote surrogates; and deploying and operating surrogates not justified in the corresponding region, e.g. high investments costs and low delivery volume.
An interconnection may be attractive to a large CDN provider who possesses many CDNs in various locations and who may want to make them interoperable.
A CDNI footprint extension is also beneficial for cases in which CDN providers deliver a lot of popular content to networks of a few ISPs. If so, interconnection of such CDNs would offer improved QoS and QoE to end users, reduce and allow control of ingress traffic in the ISP's network, reduce hardware capacity and footprint of uCDN and allow the ISP to derive some revenue.
Additionally, interconnected networks may allow nomadic end users to access content with a consistent QoE across a range of devices and/or geographic regions.
Offload
A CDNI can be very useful in overload handling because it allows the unexpected spikes in traffic, e.g. a flash crowd that exceeds the peaks for which a CDN was dimensioned, to be spread between the uCDN and the dCDN. If the CDNs share their resources, they may benefit from dimensioning savings. For such a mechanism to work properly, the uCDN requires information in real time from a dCDN on the amount of traffic it can offload. Whereas for planned events, such as maintenance or special event distribution, a static resource reservation can be sufficient.
Additionally, a CDNI provides means for resiliency against content delivery and acquisition failure. Deploying it, for cases in which the CSPs' surrogates and origin servers are unavailable, allows delivery requests to be redirected towards another CDN. Similarly, with a deployed CDNI, if a default acquisition source fails, other sources within the interconnection, e.g. an alternate uCDN, can be used. This, in turn, provides load balancing between content acquisition sources.
Capability
A CDNI can be a means of extending a supported range of devices and network technologies if a CDN is not able to support them or if its provider is not willing to provide them. For example, a CDN provider may want to extend its portfolio of services to HTTP Adaptive streaming and/or IPv6 while supporting HTTP streaming and/or IPv4 only. This extension can be realized by interconnecting to a CDN that can provide the requested protocols. Similarly, an interconnection may enable a fixed-line CDN provider to extend its services to mobile devices.
When a CDN provider runs many networks in different technologies, has a multi-vendor strategy or deploys separate networks for many CSPs an interconnection can ease its establishing technology and vendor interoperability by simplification or automatisation of some inter-CDN operations.
Another use case would be an improvement of QoS and QoE for a CDN provider if an interconnection option with a network of surrogates closer to end users existed.
Interfaces in CDNI
The Internet Engineering Task Force (IETF) (see Standardisation status section) 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. 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.B. Niven-Jenkins, F. Le Faucheur, and N. Bitar. Content Distribution Network Interconnection (CDNI) Problem Statement. RFC 6707 (Informational), September 2012.F. Le Faucher, G. Bertrand, I. Oprescu, and R. Peterkofsky. CDNI Logging Interface. draft-ietf-cdni-logging-08 (Active Internet-Draft), October 2013.R. Murray and B. Niven-Jenkins. CDNI Control Interface / Triggers. draft-ietf-cdni-control-triggers-01 (Active Internet-Draft), October 2013.B. Niven-Jenkins, R. Murray, G. Watson, M. Caulfield, K. Leung, and K. Ma. CDN Interconnect Metadata. draft-ietf-cdni-metadata-03 (Active Internet-Draft), October 2013.Danhua. Wang, B. Niven-Jenkins, Xiaoyan. He, Chen. Ge, and Wei. Ni. Request Routing Redirection Interface for CDN Interconnection. draft-ietf-cdni-redirection-01 (Active Internet-Draft), October 2013. The defined interfaces are briefly described as follows.
Control interface (CI)
The CI is designed to initiate an interconnection across two CDNs and bootstrap the other CDNI interfaces. For example, the control interface can be used to provide the address of the logging server in order to bootstrap the logging interface, or it can be used to establish security associations for other interfaces. It can also allow an uCDN to preposition, revalidate or purge metadata and content on a dCDN.
Request routing redirection interface (RI)
Redirects and selects a delivery dCDN for a given user request. This interface provides loop prevention and detection mechanism for the served requests.
Footprint and capabilities advertisement interface (FCI)
Enables asynchronous exchange of routing information on capabilities and footprint to support dCDN selection for subsequent user requests. The union of the RI and FCI interfaces denotes the request interface.
Metadata interface (MI)
Allows a dCDN to provide content metadata from an uCDN. The metadata may include information on required authorization, geo-blocking, availability windows and delegation white- and blacklists. This information can, for example, limit the distribution to a given country or make content intended for adults available only in late-night hours. The collected metadata is used later for CDNI redirection and user content request responses.
Logging interface (LI)
Enables content distribution and delivery activity details to be exchanged via interconnection. Real-time exchange can be used for traffic monitoring and offline exchange can be used for billing of end user or billing between interconnected CDNs.
Downstream CDN selection criteria
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.J. Seedorf, J. Peterson, S. Previdi, R. van Brandenburg, and K. Ma. CDNI Request Routing: Footprint and Capabilities Semantics. draft-ietf-cdni-footprint-capabilities-semantics-01 (Active Internet-Draft), October 2013. 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.