Table of Contents

Introduction to Cisco Internet CDN Software

Introduction to Cisco Internet CDN Software

This chapter describes Cisco Internet CDN Software and tells you how to use your web browser to access the Cisco Internet CDN Software user interface.

This chapter contains the following sections:

• About Cisco Internet CDN Software
  
  
• CDN Components
  
  
• CDN Users
  
  
• CDN Architecture
  
  
• CDN Terminology
  
  
• Routing End User Requests to Content Engines
  
  
• Importing and Pre-positioning Content
  
  
• About the Cisco Internet CDN Software User Interface
  
  

About Cisco Internet CDN Software

Meeting the Needs of Internet Users and Service Providers

When end users experience technical problems the first time they go to a website, they often lose patience. Many users go to another site and never return 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 you, the service provider, to create and maintain Content Delivery Networks (CDNs) for your customers, who are content providers. When content providers use CDNs, they benefit because end users can quickly and reliably access their content. You benefit because CDNs are a premium revenue-generating Internet service that you can offer your customers.

What a CDN Does

A Cisco Content Delivery Network (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 belonging to the content provider where content originates (the origin server).

Hosted Domains

You can define one or more hosted domains for a content provider. From the perspective of a content provider, a hosted domain is a set of related content that the content provider wants to treat as a unit for the purposes of caching. All content for a hosted domain is stored on the same set of Content Engine caches. For each hosted domain, a content provider must define:

• An origin server, which is the Domain Name System (DNS) name of the web server where the actual content for that hosted domain is stored
  
• An XML-format file, referred to as a manifest file, that identifies which live, video-on-demand, and static content on the origin server will be accessible from the hosted domain
  

From the perspective of an end user, 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. As a service provider, you must provide the authoritative DNS for each hosted domain that your customers, the content providers, will be using.

The Cisco Internet CDN Software routing system provides a way of translating a fourth-level hosted domain 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, the cache obtains the content from the origin server for the requested hosted domain.

For more information, see the "Routing End User Requests to Content Engines" section.

Web Browser-Based User Interface

CDNs can change dynamically at runtime: new Content Engines can be added to the system, content providers come and go, new hosted domains are defined, and assignments of hosted domains to caches can change. The Cisco Internet CDN is designed to make it easy to handle such changes through interaction with the web browser-based Content Distribution Manager graphical user interface. It is not necessary to log on to particular nodes in the system to change what they do; instead, devices can be managed remotely through the Content Distribution Manager.

Supported Content Types

Cisco Internet CDN Software supports any standard static content type. In addition, the CDN supports live streaming of the following file formats:

• Audio Visual Interleaved (AVI)
  
• Graphics Interchange Format (GIF)
  
• Hypertext Markup Language (HTML, HTM)
  
• Joint Photographic Experts Group (JPG)
  
• Microsoft PowerPoint (PPT)
  
• Microsoft Word (DOC)
  
• Motion Pictures Expert Group (MPEG, MPG)
  
• MP3 (MP3)
  
• Portable Document Format (PDF)
  
• QuickTime (QT)
  
• QuickTime Movie (MOV)
  
• RealAudio (RA)
  
• RealMedia (RM)
  
• RealPix (RP)
  
• RealText (RT)
  
• RealVideo (RV)
  
• RealNetworks synchronized container format (SMIL)
  

About Cisco Internet CDN Software Version 2.0

Version 2.0 of the Cisco Internet CDN Software extends the capabilities of earlier releases in several ways by:

• Providing streaming access to video-on-demand (VOD) and live content
  
  
• Storing ("pre-positioning") VOD content on Content Engines
  
  
• Supporting next-click failover, so requests directed to Content Engines that suddenly go offline are passed automatically to an available device
  
  
• Scaling up to 2000 Content Engine caches
  
  
• Providing secure communication of all internal system data
  
  
• Updating and expanding the graphical user interface of the Content Distribution Manager
  
  

CDN Components

Cisco Internet CDN Software is preinstalled on three or, optionally, five types of hardware platforms from the Cisco CDN product line:

• Cisco Content Distribution Manager 4670
  
  
• Cisco Content Engine 500- Series or 7320 Series
  
  
• Cisco Content Router 4450
  
  
• Cisco Content Services Switch 11800 (optional)
  
  
• Cisco Catalyst 4000 Family or 5000 Family switch (optional)
  
  

In addition, an external Oracle 8i database is used.

Cisco CDN Devices

A CDN contains five types of Cisco devices:

• Content Distribution Manager
  
  
• Content Router
  
  
• Content Engine
  
  
• Content Services Switch (optional)
  
  
• Catalyst switch (optional)
  
  

A configuration of the system consists of 1 Content Distribution Manager, some Content Routers (2 to 8), and many Content Engines (up to 2000). Additionally, Content Engines can be grouped into clusters behind a Content  Services Switch, forming supernodes that provide fault tolerance and load balancing for the hosted domains located on the clustered Content Engines.

Every device runs a Simple Network Management Protocol (SNMP) agent, allowing you to obtain information about the system through an SNMP console.

Content Distribution Manager

The Content Distribution Manager provides a central point of control for system administrators. A web browser-based graphical user interface makes it easy for administrators to perform system management such as adding and monitoring CDN devices and managing the CDN itself.

Using the Content Distribution Manager graphical user interface, administrators can perform actions including:

• Controlling content placement in the system (adding and removing content providers, adding and removing hosted domains, assigning hosted domains to Content Engines)
  
  
• Controlling the membership of the system (adding and removing Content Engines and Content Routers)
  
  
• Controlling the members of the system (upgrading software, rebooting Content Engines and Content Routers)
  
  
• Controlling the system configuration and changing system parameters, such as the partitioning and allocation of disk storage on Content Engines for pre-positioned video-on-demand and static content
  
  

The Content Distribution Manager uses an Oracle 8i policy database to store device configuration information and content serving policy information that you provide to it. For more information, see the "Oracle 8i Policy Database" section.

The Oracle 8i database belongs to you, the service provider. You are not required to use a separate database; the database can be used for your other database needs as well.

Content Router

A Content Router is a device that selects suitable Content Engines within a distribution network to serve end user requests. Content Routers redirect requests to an appropriate Content Engine based on geographic location, network location and conditions, and content placement. Content Routers are deployed to provide redundant configuration for multinetwork, wide-area fault tolerance and load balancing.

Content Routers send the Content Distribution Manager frequent "keepalive," or "heartbeat," messages that are used to determine which Content Routers in the system are down. You can view this information in the web-based user interface.

A CDN can contain between two and eight Content Routers. If a Content Router fails, DNS proxies that would have communicated with it begin communicating with another Content Router, and the system continues to function normally. When a Content Router is down, the load at other Content Routers is likely to increase, but Content Routers are able to handle a large number of DNS requests, so no performance problems should occur.

Content Engine

A Content Engine stores cached media. Content Engines are responsible for on-demand caching of static HTTP content and pre-positioned video-on-demand content, and for delivering content to end users. Content Engines provide access to content through HTTP, RealServer, and QuickTime and participate in routing under the direction of the Content Routers.

A CDN can have 1 or more Content Engines, up to a maximum of 2000.

Content Engines are located at the edge of the network (Internet service provider points of presence [ISP POPs]). Through the Content Distribution Manager graphical user interface, you control the distribution of content by assigning particular Content Engines to store the static and video-on-demand content of particular hosted domains. Only these Content Engines can store and serve this content. Although live, streamed content can also be delivered from hosted domains, by its very nature this content is not stored on Content Engines, but delivered directly from the streaming server to the requesting client.

If a Content Engine fails, the routing subsystem routes around it for DNS requests. For example, a DNS proxy that has received the Content Engine in one of its name server records does not route to it because its probe message fails. Instead, it returns the IP address of some other Content Engine that it received in one of the other name server records sent to it.

In addition, Content Engines can be grouped into "clusters" behind Content Services Switches, which help manage user requests to the device using load balancing and which provide next-click failover if a Content Engine goes offline.

A Content Engine logs information about all the HTTP requests that it handles and can send this information to a remote logging site periodically. Using the Cisco Internet CDN Software web-based user interface, you can control both the identity of the site and the logging period. You can then use the information for billing content providers.

Content Services Switch

The Cisco Content Services Switch is an optional component of the CDN. When deployed, the Content Services Switch makes it possible to group (or cluster) Content Engines hosting the same content, and then to balance requests among the Content Engines and recover quickly should a Content Engine unexpectedly go offline.

Through the use of load-balancing technology and the fail-safe routing that detects problems with Content Engines and routes requests around them, the Content Services Switch can cut response time and improve the reliability of content delivery to customers accessing a particular hosted domain. Figure 1-1 shows how user requests are routed to a supernode.

Supernode

A supernode is a collection of Content Engines clusters grouped behind a Content Services Switch and joined to a CDN.

As opposed to standalone Content Engines (referred to as standalone nodes), supernodes make it possible to provide improved response time for user requests through the use of load balancing among clusters of Content Engines hosting the same content.

In addition, supernodes provide data redundancy and next-click failover, meaning that if one Content Engine fails while trying to serve a user request, other Content Engines in the same cluster can be used to fulfill the user request.

Cluster

Clusters are groups of Content Engines hosting identical content and grouped behind a Content Services Switch. Grouping Content Engines into clusters allows content providers to better service end user requests with the load balancing and next-click failover features of the Content Services Switch.

Oracle 8i Policy Database

The Content Distribution Manager uses an external Oracle 8i database to store current CDN policies. The term "policies" refers to the information that you provide to the Content Distribution Manager using its graphical user interface. The database also stores information about CDN use and CDN status.

Because the database provides persistent storage, modifications you make are not lost in system failures. Because the database also provides transaction processing, modifications that consist of several changes are certain to occur either completely or not at all.

The Oracle database management system does not come with Cisco Internet CDN Software. You use an Oracle 8i database management system from Oracle, create the database, and configure it. For information about configuring the database, refer to the Cisco Internet CDN Software Configuration Guide.

Because the Oracle policy database is an integral part of your CDN, you the service provider should also develop formal procedures for backing up the CDN policy database, and a schedule according to which backups will take place once your CDN is online.

CDN Users

Cisco Internet CDN Software has two types of users:

• CDN administrators
  
  
• CDN users
  
  

CDN Administrators

CDN administrators use Cisco Internet CDN Software to create CDNs. For example, administrators add new hosted domains and remove Content Engines.

Administrators interact with CDN devices using the web browser-based graphical user interface to the Content Distribution Manager. The Content Distribution Manager provides web pages that make it easy to perform administrative functions, and uses Hypertext Transfer Protocol Secure (HTTPS) to protect communications between itself and CDN devices.

For example, a CDN administrator controls:

• Content—By adding and removing content providers, adding and removing hosted domains, and assigning hosted domains to Content Engines
  
  
• Membership—By adding and removing Content Engines and Content Routers
  
  
• Members—By upgrading software and rebooting Content Engines and Content Routers
  
  
• Configuration—By changing system parameters, such as the frequency of various kinds of communication among the members of the system
  
  

When an administrator uses the web-based user interface to enter new information, the Content Distribution Manager validates the new information, adds it to the policy database, propagates changes to the Content Engines and Content Routers, and examines the system state.

End Users Requesting Content

When an end user client machine needs to access content in a hosted domain served by a Cisco CDN, the client communicates with a local DNS proxy if it does not already have an IP address of a Content Engine. If the proxy also does not know how to route the hosted domain, it communicates through normal DNS mechanisms with one of the Content Routers. The Content Router selects some Content Engines (standalone nodes) or groups of Content Engines (supernodes) to satisfy the client request (see the "Routing End User Requests to Content Engines" section) and returns a list of these selections to the DNS proxy as name server (NS) records. The DNS proxy then communicates with one of the selected Content Engines. The Content Engine returns its IP address or, in a supernode, possibly the address of another Content Engine that can best serve the request, which the DNS proxy then returns to the client.

With the IP address of the Content Engine storing the content, the requesting client now sends an HTTP request to the Content Engine. The Content Engine responds immediately if it already has the requested content in its cache. Otherwise, if the requested content is not present in the Content Engine cache or has not been pre-positioned on the Content Engine, or if the request is for a live broadcast, the Content Engine obtains the requested content from the origin server or live streaming server associated with the hosted domain and returns the content to the client, caching it if possible.

CDN Architecture

Figure 1-2 shows CDNs in the context of a larger network that includes origin servers, clients, DNS servers, and other sites.

In addition to what is shown in Figure 1-2, each Cisco device (Content Distribution Manager, Content Engines, and Content Routers) runs an SNMP agent and servers for Secure Shell (SSH) and Hypertext Transfer Protocol Secure (HTTPS), which allow administrators to query individual devices securely with a variety of tools.

CDN Terminology

Table 1-1 defines terms that you need to know when you work with CDNs.

Routing End User Requests to Content Engines

A Cisco CDN system can contain up to 2000 Content Engines that can be distributed across a geographically dispersed area. In such an environment, it is vital that client requests for cached content be handled by Content Engines that are suitable for the client, which means that they are online, nearby, cheap to communicate with, and not overloaded. 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.

Cisco Internet CDN Software does routing as part of the DNS lookup that occurs when a client machine does not know the IP address associated with a particular DNS name (a hosted domain). The client communicates with a DNS proxy, which either knows how to route the client request to a Content Engine (because of prior communication with one of the Content Routers) or communicates with one of the Content Routers. The Content Routers act as authoritative DNS servers for the hosted domains served by Cisco CDNs. Modifications are not needed for the software running on clients, DNS proxies, other servers within the DNS system, or the content provider servers.

When a client request arrives at a DNS proxy that does not know how to translate the requested DNS name, the proxy consults other DNS servers on the Internet. Normal DNS mechanisms lead the proxy to communicate with one of the Content Routers in the CDN. The Content Router then chooses Content Engines that are suitable for the client request. It returns information about the selected Content Engines to the DNS proxy in the form of name server records.

Each record identifies a Content Engine that can cache the desired content. The Content Router also returns address records so that the DNS proxy knows the IP addresses of the Content Engines.

Several 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 Time To Live 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 Time To Live values.

The Content Routers make their decision based on the IP address of the DNS proxy that sends the request. The routing subsystem is based on the assumption that choices which are suitable for a DNS proxy are also suitable for the client which is using the proxy to resolve the DNS name.

Routing a Request

Routing a request is a two-step process. The first step is communication between the DNS proxy and a Content Router, and the result is a number of name server records with associated Time-To-Live values. The second step occurs at the DNS proxy, which contacts the Content Engine identified in one of the returned records. The contacted Content Engine replies with an actual IP address in an address record. When the DNS proxy receives a response from the contacted Content Engine, the DNS proxy returns the IP address provided by that Content Engine to the requesting client. If the DNS proxy receives no response, it tries another Content Engine (one listed in one of the other name server records). The record has a very short Time-To-Live value (20 seconds), so the DNS proxy continues to probe the Content Engines in the name server records for subsequent requests.

If the DNS proxy receives subsequent requests for the same DNS name before the Time-To-Live values on the name server records expire, it continues to contact the Content Engines identified in the name server records it has already received. Returning several name server records to the DNS proxy allows the system to fine-tune the response to the client. All name server records identify appropriate Content Engines for the client request, so returning several name server Content Engine records provides additional fault tolerance and load balancing; the DNS proxy does not select a Content Engine that fails to reply, and if several Content Engines are equally close to the DNS proxy, it cycles through them.

Routing Decisions

The success of the routing decisions depends on what happens at the Content Routers, since this outcome controls which Content Engines are ultimately selected. The Content Routers base their decisions on a database of proxy tables that contain information about the proximity of Content Engines to particular DNS proxies. Each proxy table actually stores information for a group of proxies, which provides a way of keeping the number of proxy tables under control. All proxies in a group are considered to be nearby one another; proxies with IP addresses that agree in the most significant 25 or 26 bits are considered to be in the same group.

A proxy table ranks the appropriateness of locations for the proxy group. A location contains a number of Content Engines that are geographically nearby, for example at a single POP or a closely related group of POPs. Storing information for locations rather than individual Content Engines enables control of the size of the tables. Cisco Internet CDN Software allows a maximum of 192 locations. Content Engines are assigned to locations when they are first added to a CDN.

The proxy tables are maintained automatically. Periodically, a Content Router directs certain Content Engines to communicate with particular DNS proxies. Only one Content Engine per location is asked to do these probes. This Content Engine is the leader of the location. Leaders communicate with the specified proxies by pinging them. If ping messages fail, leaders send the proxies DNS requests, compute the time taken to complete the exchange, and send the collected information back to the Content Routers. The Content Routers then update their proxy tables using the new information.

Data collection for routing occurs during each routing period, for example every 2 minutes. All leaders communicate with all Content Routers during each routing period to report their probe results. The reply to the communication gives the leader its probe instructions for the next period.

Other Content Engines also communicate with the Content Routers during each routing period. This communication provides a list of the hosted domains that a Content Engine is authorized to serve. (Responses from leaders also contain this information.) Content Routers use this information to ensure that Content Engines are selected that are authorized to serve the requested content. If the Content Routers do not receive this information from a Content Engine, they conclude that this Content Engine is not currently serving content.

Since Content Engines communicate with all Content Routers in each routing period, location leaders carry out probe requests chosen by all the Content Routers, and the Content Routers learn the results of all the probes, even those requested by different Content Routers. The communication is not synchronized, and therefore it is possible that the proxy tables at different Content Routers may diverge. Divergence is not a serious concern, however, because routing depends only on having reasonably accurate information, and it does not matter that different Content Routers might make different decisions.

Additionally, the communication from Content Engines to Content Routers is offset in time. The goal is to have the communication occur evenly across the routing period, so that Content Routers do not become overwhelmed with the communications from the Content Engines.

Importing and Pre-positioning Content

In Version 1.0 of the Cisco CDN Software Service Provider Edition, content was cached on Content Engines based on hosted domain records received from the Content Distribution Manager.

In order to be able to serve pre-positioned content and live, streamed media, Cisco Internet CDN Software Version 2.0 uses a new XML-based manifest file to identify live content versus static or pre-positioned video-on-demand content on the origin servers of the content provider. This manifest serves as a road map for all content that will be imported to a content provider's hosted domain and stored on the Content Engines hosting the hosted domain.

For instructions on creating manifest files, see the "Creating a Manifest File for Importing Media" section. For instructions on importing the content named in the manifest file, see the "Creating a Hosted Domain for a Content Provider" section or "Working with Hosted Domains" section.

About the Cisco Internet CDN Software User Interface

A CDN is a constantly changing system. Content Engines and Content Routers are added and removed. Content providers come and go. New hosted domains are defined, old ones are removed, and assignments of Content Engines to hosted domains and virtual CDNs change; the Cisco CDN software may need updating and devices may need to be rebooted.

Changes to your CDN are managed using a web browser-based management interface that is part of the Content Distribution Manager. (See Figure 1-3.)

The Content Distribution Manager is a central location from which much of the work of creating and managing CDNs and hosted content can be controlled. All modifications made through the Content Distribution Manager are added to the Oracle policy database and then propagated to the Content Routers, Content Engines, and Content Services Switches that make up your CDN.

Table 1-2 describes the five primary groups of features associated with the Content Distribution Manager user interface:

Accessing the Content Distribution Manager User Interface

All functions related to managing your CDNs are done using the web browser-based management interface that is installed on the Content Distribution Manager.

To access the Content Distribution Manager user interface from your workstation, follow these steps:

https://Name_of_Content_Distribution_Manager 

 

Alternatively, enter the IP address:

https://IP_address_of_Content_Distribution_Manager
 

If you are prompted to accept the server certificate, click Yes.

A request for a username and password appears.

Step 2   Enter your username and password.

User name: admin
Password: <password>
 

---

Note   The default username is admin and the default password is default. If the defaults have been changed by another Content Distribution Manager administrator, you need to get the new username and password.

---

Step 3   Click OK.

Exiting the Content Distribution Manager User Interface

When you have finished managing your CDNs, you exit the user interface.

To exit the Content Distribution Manager user interface, follow these steps:

Step 2   From the File menu, choose Close, or click the browser Close button.