Home | Skip to Content | Skip to Search | Skip to Navigation | Skip to Footer |
Worldwide [change] |Register |About Cisco
Guest

Hierarchical Navigation

Cisco Internet CDN

Chapter 1: Understanding CDNs

Downloads

Table of Contents

Understanding CDNs

Understanding CDNs

This chapter provides a conceptual background to the Cisco Internet CDN product and contains the following sections:

What a CDN Does

When end users experience technical problems the first time they go to a website, they often lose patience, often moving on to another site that offers similar information and never returning to the original site.

The most basic technical problem that users encounter is slow content delivery. To help solve the problem of slow content delivery, Cisco Internet CDN Software enables your service provider to create and maintain Content Delivery Networks (CDNs) for your website content. By choosing to deploy your website content on a CDN, you offer your end users website content they can quickly and reliably access—even high-impact, high-bandwidth video and multimedia content that has historically been difficult to deliver reliably over the public Internet.

A Cisco Internet CDN is a collection of hardware devices and proprietary software that, together, significantly improves the delivery of web content to users of the Internet

The Cisco Internet CDN allows web content to be distributed to caches at various locations on the Internet and then accessed from those caches. Service providers can ensure better access to their content, because end users are able to obtain it from a cache that is both closer to them (in terms of network distance) and less heavily loaded than the web server where the content originates. In addition, these caches reduce the load on the web server that belongs to the content provider where content originates (the origin server).

See the "Mechanics of Content Routing" section and the "Distributing Content" section for more information on how the CDN software improves access to high bandwidth content on the Internet.

Security

The Cisco Internet CDN Software uses Secure Socket Layer (SSL) for Java to encrypt all inter-device communications.

Developed by Netscape, the SSL protocol is supported by both the Netscape and Microsoft browsers and is a widely accepted and deployed encryption technology on the Internet. SSL uses the sockets method of communication between client and server, coupled with RSA Security's public key encryption technology to secure data using digital certificates as it is transmitted between CDN devices over the Internet.

Mechanics of Content Routing

The primary job of the Cisco Internet CDN is to deliver content. With content distributed to up to 2000 geographically dispersed Content Engines, it is vital that client requests for cached content be handled by Content Engines that are suitable for the client. Suitability, for the CDN software, means that Content Engines are online, nearby, and cheap to communicate with. The selected Content Engines must also be authorized to store the requested content (the hosted domain). Thus, the job of the routing subsystem is to choose the most suitable Content Engines to handle a particular client request.

The following sections explain how content is routed on a Cisco Internet CDN and contain information on the following topics:

End Users Requesting Content

When end users attempt to access content on your CDN hosted domain, their client machines communicate with a local domain name system (DNS) proxy.

If the proxy does not have information on how to properly route the hosted domain, it communicates through normal DNS mechanisms with one of the Content Routers that make up the CDN, which begins the routing process.

Routing End User Requests

This section describes how end user requests are processed by the CDN. See the numbered steps in Figure 1-1 as you read.

Content routing happens as part of the DNS lookup that occurs when a clientmachine requests content from a web page by clicking a URL (1). If the requesting client does not know the IP address associated with a particular DNS name (a hosted domain), it communicates with a DNS proxy (2), which either knows how to route the client request to a Content Engine (because of prior communication with one of the Content Routers) or does not know how to route the request. If it does not know how to route the request, it sends iterative name server (NS) requeststo each authoritative server, eventually reaching (3) one of the Content Routers, which are the authoritative DNS servers for the hosted domain.

In response, the Content Router consults its proxy tables to find the preferred Content Engines that can serve the content from among those Content Engines that are authorized to serve content for the requested hosted domain. After the Content Router selects suitable Content Engines, it returns NS records (4) for the authorized devices.

Next, the DNS proxy sends an NS request to one of the Content Engines named by the Content Router (5), typically the first one. The Content Engine responds with its own A-record.

Next, the DNS proxy passes (6) the Content Engine A-record, which contain the Content Engine IP address, to the client.

Finally, the client makes its content request directly to the Content Engine (7) identified in the A-record, and the Content Engine serves the content.


Figure 1-1: Cisco Internet CDN Routing


Choosing Content Engines to Serve End User Requests

The Content Router chooses Content Engines that are suitable for the client request from its proxy tables—automatically maintained lists that contain information about the proximity of Content Engines to particular DNS proxies. Content routing decisions are based on DNS proximity of the client's DNS server to Content Engines on the network that can serve the requested content. DNS proximity is measured by Round Trip Time (RTT) probes.

The Content Router returns information about the Content Engines it has selected from its routing tables to the DNS proxy in the form of NS records.

Each record identifies a Content Engine that can cache the desired content. The Content Router also returns Address ("glue") records for the Content Engines so that the DNS proxy knows the IP addresses of the Content Engines.

Several NS records are sent in the reply. The number of records returned and the length of time that they can be used by the proxy (the Time To Live, or TTL value) are controlled by the Content Router. The Content Router adjusts these values depending on how confident it is that its choices are suitable. For example, if the Content Router is certain that particular Content Engines are appropriate for the client, then just two or three name server records are provided to the DNS proxy, with relatively long TTL values. If, however, the Content Router is uncertain about which Content Engines can best provide the requested content, then up to eight name server records are provided to the DNS proxy, with relatively short TTL values.

Distributing Content

In addition to understanding how content is routed between CDN devices, you must also understand what type of content is placed on the CDN to begin with, and how it is placed there. The following sections explain how content distribution from your origin server to the CDN typically occurs and contain information on the following topics:

Proxy Cached and Pre-Positioned Content

The Cisco Internet CDN distributes content in two ways:

After it is retrieved from the origin server, the cached content is periodically refreshed as indicated by an expires attribute associated with the content item.

Subsequent requests for the content are retrieved from the Content Engine cache, assuming the TTL of the object has not expired.

When to Pre-Position and When to Proxy Cache

The CDN software allows content providers to pre-position and cache large amounts of content. In theory, an entire web site could be placed on a Internet CDN hosted domain. However, depending on the availability and cost of network bandwidth versus storage and CPU time on your service provider's Content Engines, this may or may not be prudent. For example, while it is possible to cache a series of small JPG files from your web site on your CDN hosted domain, it may not be necessary to do so.

Although the needs of each content provider are different, consider certain guidelines when deciding whether to proxy-cache or pre-position a particular piece of content on your CDN:

  • All streamed content must be pre-positioned using the manifest file.

  • Large content items should be proxy-cached to provide good quality service to the first customer who requests the content item.

  • Content that must always be available, even when it is not being accessed very often, should be pre-positioned. The content expiration tags in the manifest allow vital content to avoid being purged even when it has not been accessed in a while. See the "Manifest File Structure and Syntax" section for instructions on setting the expiration time for content items.

  • Content that should be generally available to users and may be frequently requested may be proxy-cached.

  • Content for which you want to control the availability by specifying start- and stop serving times should be pre-positioned. See the "Manifest File Structure and Syntax" section for instructions on setting start and stop times for CDN content items.

  • Single files larger than 500 MB cannot be proxy-cached. This ceiling can be raised by your service provider. If you will be proxy-caching very large files, first coordinate with your service provider on the maximum allowable file size.

About Hosted Domains

As a content provider, your web site content will be stored on one or more subdomains or "hosted domains," of your web site.

Each hosted domain is created by the administrator for the authoritative DNS servers for your CDN. Subdomains are created as branches in the DNS tree for the web site you are hosting. For example, the following might be hosted domains for some popular web sites:

http://www.videos.cnn.com  


http://www.sports.bbc.co.uk/

Each hosted domain contains a set of related content that you want to treat as a unit for the purposes of caching. That content is stored in the caches of Content Engines associated with the hosted domain.

For each hosted domain, you must define an origin server, which is the fully qualified domain name (FQDN) of the web server where the actual content for that hosted domain is stored.

See the "About Creating the CDN Subdomain" section for more information on configuring DNS for CDN deployment.

If live, video-on-demand, or pre-positioned content will be distributed from the hosted domain, a manifest file is also required to identify which live and video-on-demand content on the origin server will be pre-positioned on a hosted domain.

See the "Pre-Positioning Web Site Content" section for more information on creating and validating manifest file content.

From the perspective of your end users, a hosted domain is identified by its DNS name. The end user accesses content either by entering a URL in a web browser or by clicking a link on a web page. When the user requests content, the DNS server returns the IP address of a cache that is storing the requested content and the user receives the content.

The Cisco Internet CDN Software routing system provides a way of translating a subdomain name into the IP address of a cache that stores content and is a good choice for the client making the request. The client can then send Hypertext Transfer Protocol (HTTP) requests directly to the selected cache. If the cache does not already contain the cached content, it obtains the content from the origin server for the requested hosted domain.

About the Manifest File

The manifest file is an XML-based reference file that you, the content provider, will use to list content that is to be served for a hosted domain. Each hosted domain has only one manifest file.

Manifest files are positioned on a web server at a location that you choose. The URL of this location is provided to the Internet CDN administrator when the hosted domain is created, and a link is created between the hosted domain and manifest file using the CDM graphical user interface. The CDN software fetches the manifest first from the origin server using this URL.

After it has been uploaded to the CDN, the manifest is copied out to each Content Engine assigned to the hosted domain according to a set distribution hierarchy.

Manifest files solve the following problems:

  • They allow administrators to fetch content from multiple origin servers and fail-over to backup origin servers and/or the default origin server specified on the Hosted Domain Configuration page of the Content Distribution Manager user interface, thus providing for a degree of fault tolerance.

  • They allow the system to import items via HTTP, while serving them using another streaming protocol based on a designated server-type to play the requested file.

  • They allow content retrieval and distribution to be controlled by setting specific dates and times when it is to be available or not available.

  • They allow the use of wildcards ("*") when specifying live content. This permits you to broadcast new live streams without having to update the manifest with a new item description.

    • Note   Any number of origin servers can be defined in a manifest file. The number of content items, however, is limited to 10,000.

Administrators must be very careful to not make syntax mistakes when creating manifests. Like HTML, even a small mistake will cause errors when the file is imported and parsed. For this reason, Cisco provides a manifest file syntax validator. See the "Validating Manifest File Syntax" section for directions on obtaining and using this utility to check your manifest file syntax.

For more information on the role of the content provider in deploying web site content on a CDN, see "Understanding the Content Provider Role."

Supported Content Types

Cisco Internet CDN Software supports delivery of the following file formats:

HTTP Content Types

The Cisco CDN Software supports any standard content type served by an HTTP server, including:

Apple QuickTime Content Types

Microsoft Windows Media Content Types

RealNetworks RealServer Content Types

RealNetworks synchronized container format (SMIL)