Content Delivery Networks Interconnection Standardization Activities in IETF

1. Introduction

To support the recent growing demand for streaming services on Internet protocol (IP) networks, various standards developing organizations are conducting standardization activities for content delivery network (CDN) technologies. The Internet Engineering Task Force (IETF), which is a large open international community of network designers, operators, vendors, and researchers concerned with the evolution of the Internet architecture and the smooth operation of the Internet, formed a Working Group (WG) on CDN interconnection called CDNi-WG [1]. This WG was officially established in 2011 at the 81st meeting of the IETF in Quebec City, Canada. Its purpose is to define protocol for CDN interconnection. The IETF is divided into eight functional areas: CDNi-WG is in the Transport Area, which covers protocol standards related to the transmission of streams of data over the Internet. The activities of CDNi-WG are overviewed below.

2. Demand for CDN interconnection

In the broad sense, a CDN represents a particularly optimized network coverage layer for delivering content. CDNs were originally designed to improve network and web server performance (or cost) as well to eliminate network delays by placing web servers at distributed locations and redirecting a user’s request to these distribution points according to the user’s location. This enables a CDN to deliver content to a large number of users effectively.

Along with the recent widespread of digital content such as streaming video delivered over IP networks, CDN service providers are extending the scope of their business. In addition, Internet service providers, telecommunications carriers, and even enterprises are building their own CDNs. If these individual CDNs were interconnected, the scope of their services could be expanded without the CDNs themselves being extended.

An example of CDN interconnection between two CDN providers (CDN A and CDN B) located in two different countries is illustrated in Fig. 1. CDN interconnection enables CDN A to deliver content held within country A to end users in country B by forming a business alliance with CDN B.

Fig. 1. CDN interconnection: Use case 1.

Recently, telecommunications carriers providing various services in a particular geographic area have established their own CDNs in order to provide digital services such as IPTV (Internet protocol television). However, CDN interconnection of multiple carriers lets carriers expand their service areas without further investment in their own networks.

Meanwhile, content service providers obviously face huge demand for providing more people with their own contents. One of the advantages of CDN interconnection for content service providers is that it enables them to increase their number of users without forming business alliances with multiple CDN providers.

Another use case illustrating mobility support known as “TV Everywhere” is shown in Fig. 2. As is often the case with end users in a fixed network, subscribed users can access the same content seen at home when outside the home on their smartphones or tablets. In this case, CDN interconnection between the fixed-line CDN and the mobile CDN enables them to view the content as if they were at home. CDNi-WG is currently working on various use cases, including temporary load distribution.

Fig. 2. CDN interconnection: Use case 2.

As described above, CDN interconnection provides benefits to CDN service providers as well as advantages to end users. However, since legacy CDNs were implemented using proprietary technology, there has not been any support for an open interface for connecting with other CDNs. Even though several CDNs could be interconnected, it was still difficult to achieve interconnection in the way that met operational requirements such as being able to exchange billing information. CDNi-WG is aggressively pursuing solutions to these problems.

3. Scope of CDNi-WG

The scope of current discussions in CDNi-WG is shown in Fig. 3 [2]. It models two CDN providers, interconnected between a content service provider and a user agent, providing CDN service. CDNi-WG is focusing mainly on the interfaces between CDNs, in particular, the interfaces between four fundamental functionalities:

Fig. 3. Scope of CDNi.

Other interfaces including ones for content acquisition between interconnected CDNs are out of the scope of CDNi-WG. The reason of such a decision is that those interfaces in today’s CDNs typically use standardized protocols: consequently CDNi-WG will focus on the control plane between interconnected CDNs.

4. Milestones of CDNi-WG

At the moment, CDN service providers, consisting of telecommunications carriers and cable operators, as well as CDN-related vendors are involved in discussions mainly via email lists. There is one upcoming milestone for CDNi-WG. By June 2012, this WG will finalize four informational documents: the problem statement, use cases, requirements, and framework. The WG will continue to work to define the specifications of three of the interfaces (Control, Logging, and Request Routing) by December 2012 and of the fourth (Metadata Distribution) by June 2013.

5. Conclusion

This article gave an overview of the activities of CDNi-WG, which has recently been established in the IETF. Standardization activities related to CDN interconnection will continue to be addressed in IETF with liaison among various standards developing organizations such as ETSI (European Telecommunication Standards Institute) in Europe and ATIS (Alliance for Telecommunications Industry Solutions) in North America.

References

Takeshi Kuwahara Senior Research Engineer, NGN System Architecture Project, NTT Service Integration Laboratories. He received the B.E. and M.E. degrees from Waseda University, Tokyo, in 1995 and 1997, respectively. Since joining NTT in 1997, he has been engaged in R&D of ATM networks, IP VPNs, VPS systems, network security, and NGN architecture. He is a member of the Institute of Electronics, Information and Communication Engineers. He is currently based in Washington D.C., USA.