Content delivery network interconnection

Interconnection between content delivery networks to mutually reduce costs

This article needs additional citations for verification. Please help improve this article by adding citations to reliable sources. Unsourced material may be challenged and removed.
Find sources: "Content delivery network interconnection" – news · newspapers · books · scholar · JSTOR (February 2024) (Learn how and when to remove this message)

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

Redirection of content request in CDN

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.

Exemplary operation of CDNI interfaces in content delivery

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.

Before any request redirection, the CDN-B (dCDN) announces information on supported footprint and capabilities.
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.
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.
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.
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.
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.
If the metadata for content /foo is not available in dCDN, the metadata interface is used to request it from the uCDN.
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.
The content /foo is delivered to the delivery node in dCDN from the delivery node in uCDN.
The content /foo is delivered to the UE from the delivery node in dCDN.
After some time, the uCDN may instruct the dCDN to purge the content /foo to ensure that it is not delivered again.
After the content is delivered a log of delivery actions is provided to the uCDN.

HTTP adaptive streaming

If addressed in CDNI specifications, support of HTTP adaptive streaming (HAS) 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.

Security

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.

Standardisation status

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 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. 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 as a foundation for using multicast as a means for distributing content across two CDN providers and for joining together a multiple of CDN providers to form a CDN federation.

References

^ 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.
^ L. Peterson and B. Davie. Framework for CDN Interconnection. draft-ietf-cdni-framework-06 (Active Internet-Draft), October 2013.
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.
K. Leung and Y. Lee. Content Distribution Network Interconnection (CDNI) Requirements. draft-ietf-cdni-requirements-11 (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.
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.
E. Stephan and S. Ellouze. ALTO session for CDN Interconnection. draft-stephan-cdni-alto-session-ext-04 (Active Internet-Draft), October 2013.
R. van Brandenburg, O. van Deventer, F. Le Faucheur, and K. Leung. Models for HTTP-Adaptive-Streaming-Aware Content Distribution Network Interconnection (CDNI). RFC 6983 (Informational), July 2013.
Media Content Distribution (MCD); CDN Interconnection, use cases and requirements. Technical report, ETSI, 2012. TS 102 990.
CDN Interconnection Architecture. Technical report, ETSI, 2013. TS 182 032.
D3.1 OCEAN Functional Architecture and Open Interface Specification. Technical report, OCEAN, 2012.
Deliverable D2.2 Final requirements for Open Content Aware Networks. Technical report, OCEAN, 2013.
CDN Interconnection Use Case Specification and High Level Requirements. Technical report, ATIS, 2011. ATIS-0200003.
CDN Interconnection Use Cases and Requirements for Multicast-Based Content Distribution. Technical report, ATIS, 2012. ATIS-0200004.
CDN Interconnection Use Cases and Requirements in a Multi-Party Federation Environment. Technical report, ATIS, 2012. ATIS-0200010.

External links

Categories:

Misplaced Pages