Interconnection between content delivery networks to mutually reduce costs
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.
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.
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.
Use cases
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).
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) [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.
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.[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.
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.
An example of iterative DNS redirection of content request in CDNI.
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) [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.
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 [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]
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.
Related Research Articles
The Domain Name System (DNS) is a hierarchical and distributed naming system for computers, services, and other resources in the Internet or other Internet Protocol (IP) networks. It associates various information with domain names assigned to each of the associated entities. Most prominently, it translates readily memorized domain names to the numerical IP addresses needed for locating and identifying computer services and devices with the underlying network protocols. The Domain Name System has been an essential component of the functionality of the Internet since 1985.
Quality of service (QoS) is the description or measurement of the overall performance of a service, such as a telephony or computer network, or a cloud computing service, particularly the performance seen by the users of the network. To quantitatively measure quality of service, several related aspects of the network service are often considered, such as packet loss, bit rate, throughput, transmission delay, availability, jitter, etc.
Universal Plug and Play (UPnP) is a set of networking protocols on the Internet Protocol (IP) that permits networked devices, such as personal computers, printers, Internet gateways, Wi-Fi access points and mobile devices, to seamlessly discover each other's presence on the network and establish functional network services. UPnP is intended primarily for residential networks without enterprise-class devices.
Zero-configuration networking (zeroconf) is a set of technologies that automatically creates a usable computer network based on the Internet Protocol Suite (TCP/IP) when computers or network peripherals are interconnected. It does not require manual operator intervention or special configuration servers. Without zeroconf, a network administrator must set up network services, such as Dynamic Host Configuration Protocol (DHCP) and Domain Name System (DNS), or configure each computer's network settings manually.
Anycast is a network addressing and routing methodology in which a single IP address is shared by devices in multiple locations. Routers direct packets addressed to this destination to the location nearest the sender, using their normal decision-making algorithms, typically the lowest number of BGP network hops. Anycast routing is widely used by content delivery networks such as web and name servers, to bring their content closer to end users.
Akamai Technologies, Inc. is an American company that provides content delivery network (CDN), cybersecurity, DDoS mitigation, and cloud services. Akamai is headquartered in Cambridge, Massachusetts. The company operates a network of servers worldwide, renting the capacity of the servers to customers running websites or other web services, in order to provide greater speed or availability to the end user by using an Akamai owned server that is located closer to the user.
Multihoming is the practice of connecting a host or a computer network to more than one network. This can be done in order to increase reliability or performance.
The GPRS core network is the central part of the general packet radio service (GPRS) which allows 2G, 3G and WCDMA mobile networks to transmit Internet Protocol (IP) packets to external networks such as the Internet. The GPRS system is an integrated part of the GSM network switching subsystem.
A content delivery network, or content distribution network (CDN), is a geographically distributed network of proxy servers and their data centers. The goal is to provide high availability and performance by distributing the service spatially relative to end users. CDNs came into existence in the late 1990s as a means for alleviating the performance bottlenecks of the Internet as the Internet was starting to become a mission-critical medium for people and enterprises. Since then, CDNs have grown to serve a large portion of the Internet content today, including web objects, downloadable objects, applications, live streaming media, on-demand streaming media, and social media sites.
The IP Multimedia Subsystem or IP Multimedia Core Network Subsystem (IMS) is a standardised architectural framework for delivering IP multimedia services. Historically, mobile phones have provided voice call services over a circuit-switched-style network, rather than strictly over an IP packet-switched network. Various voice over IP technologies are available on smartphones; IMS provides a standard protocol across vendors.
System Architecture Evolution (SAE) is the core network architecture of mobile communications protocol group 3GPP's LTE wireless communication standard.
DNS hijacking, DNS poisoning, or DNS redirection is the practice of subverting the resolution of Domain Name System (DNS) queries. This can be achieved by malware that overrides a computer's TCP/IP configuration to point at a rogue DNS server under the control of an attacker, or through modifying the behaviour of a trusted DNS server so that it does not comply with internet standards.
Founded in 2000, CDNetworks is a full-service content delivery network (CDN) which provides technology, network infrastructure, and customer services for the delivery of Internet content and applications. The company is positioning itself as a multinational provider of content delivery services, with a particular emphasis on emerging Internet markets, including South America, India and China. The company's content delivery network consists of 1,500 Point of Presence (PoPs) on five continents. Services include CDN, video acceleration, DDoS protection, cloud storage, cloud access security broker (CASB), web application firewall (WAF) and managed DNS with cloud load balancing. Key differentiators include a large number of global PoPs, good network presence in China and Russia, and high-profile clients such as Forbes, Samsung and Hyundai. CDNetworks has offices in the U.S., South Korea, China, Japan, UK and Singapore.
Network intelligence (NI) is a technology that builds on the concepts and capabilities of deep packet inspection (DPI), packet capture and business intelligence (BI). It examines, in real time, IP data packets that cross communications networks by identifying the protocols used and extracting packet content and metadata for rapid analysis of data relationships and communications patterns. Also, sometimes referred to as Network Acceleration or piracy.
Adaptive bitrate streaming is a technique used in streaming multimedia over computer networks. While in the past most video or audio streaming technologies utilized streaming protocols such as RTP with RTSP, today's adaptive streaming technologies are based almost exclusively on HTTP, and are designed to work efficiently over large distributed HTTP networks. Adaptive bitrate streaming works by detecting a user's bandwidth and CPU capacity in real time, adjusting the quality of the media stream accordingly. It requires the use of an encoder which encodes a single source media at multiple bit rates. The player client switches between streaming the different encodings depending on available resources. "The result: very little buffering, fast start time and a good experience for both high-end and low-end connections."
HTTP/2 is a major revision of the HTTP network protocol used by the World Wide Web. It was derived from the earlier experimental SPDY protocol, originally developed by Google. HTTP/2 was developed by the HTTP Working Group of the Internet Engineering Task Force (IETF). HTTP/2 is the first new version of HTTP since HTTP/1.1, which was standardized in RFC 2068 in 1997. The Working Group presented HTTP/2 to the Internet Engineering Steering Group (IESG) for consideration as a Proposed Standard in December 2014, and IESG approved it to publish as Proposed Standard on February 17, 2015. The HTTP/2 specification was published as RFC 7540 on May 14, 2015.
The Session Initiation Protocol (SIP) is the signaling protocol selected by the 3rd Generation Partnership Project (3GPP) to create and control multimedia sessions with multiple participants in the IP Multimedia Subsystem (IMS). It is therefore a key element in the IMS framework.
Domain fronting is a technique for Internet censorship circumvention that uses different domain names in different communication layers of an HTTPS connection to discreetly connect to a different target domain than is discernable to third parties monitoring the requests and connections.
The SAML metadata standard belongs to the family of XML-based standards known as the Security Assertion Markup Language (SAML) published by OASIS in 2005. A SAML metadata document describes a SAML deployment such as a SAML identity provider or a SAML service provider. Deployments share metadata to establish a baseline of trust and interoperability.
DNS over HTTPS (DoH) is a protocol for performing remote Domain Name System (DNS) resolution via the HTTPS protocol. A goal of the method is to increase user privacy and security by preventing eavesdropping and manipulation of DNS data by man-in-the-middle attacks by using the HTTPS protocol to encrypt the data between the DoH client and the DoH-based DNS resolver. By March 2018, Google and the Mozilla Foundation had started testing versions of DNS over HTTPS. In February 2020, Firefox switched to DNS over HTTPS by default for users in the United States.
References
1 2 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.
1 2 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.
This page is based on this Wikipedia article Text is available under the CC BY-SA 4.0 license; additional terms may apply. Images, videos and audio are available under their respective licenses.
