Cisco Internet CDN Software User Guide
Creating Content Delivery Networks

Table of Contents

Creating Content Delivery Networks

Creating Content Delivery Networks

A Content Delivery Network (CDN) is a coordinated system made up of three types of machines: a Content Distribution Manager, a Content Engine, and a Content Router. Optionally a fourth element, the Content Services Switch, may be implemented and used to group Content Engines into supernodes, providing next-click failover for cached content.

The first step in setting up a CDN is to unpack and properly configure your hardware devices and CDN database by following the instructions in the hardware documents that shipped with the devices, as well as the Cisco Internet CDN Software Configuration Guide.

Once the hardware devices and database that make up your CDN are properly installed and configured, you are ready to use the information contained in this chapter to organize those devices into a CDN that is capable of serving pre-positioned or live media to end users.

This chapter contains the following sections:

Before Setting Up CDNs

To set up a CDN, you need to define:

  • Your content in the form of URLs that point to pre-positioned content and live streamed content on one or more origin servers

  • Your customers (the content providers that will be using the Internet CDN product to help deliver media to end users)

  • Regional groupings for your Content Engines, Content Engine clusters, and Content Routers

  • Locations (smaller, local groupings within regions that organize Content Engines and Content Routers)

  • Supernodes and Content Engine clusters (only if using a Content Services Switch)

  • Hosted domains (the content which is cached on one or more Content Engines or clusters and which is delivered by content providers to end users)

  • Virtual CDNs (user-defined groupings of Content Engines and clusters)

The following sections describe how to define and configure these various elements.

The order in which topics are presented in this document is designed to minimize possible conflicts or confusion. Although the Content Distribution Manager does not require you to follow a specific order when setting up your CDN, certain tasks need to be performed before others. For example, because a location must have an associated region, information on defining regions is presented before information for defining locations. Because Content Engines and Content Routers must be placed in locations, you define these devices after you define locations.

Setting Up a CDN

In each Cisco Internet CDN, content is imported to hosted domains from web-based origin servers associated with a particular third-level domain name, for example:

http://www.cisco.com  
 

Each hosted domain is associated with a specific content provider and corresponds to a particular collection of live and pre-positioned video-on-demand content being distributed on the CDN. Content providers may have one or more hosted domains on a CDN at a time.

After they are created, hosted domains are associated with one or more Content Engines that cache the pre-positioned content named in the hosted domain manifest file and copied (or replicated) from the origin server. This content is then used to serve user requests.

These sections detail the steps that must be taken to set up your Internet CDN.

Creating a Manifest File for Importing Media

Although each hosted domain is mapped to a single origin server when it is created, the Cisco Internet CDN actually allows content to be pulled from multiple servers and placed on a hosted domain. In order to be able to map content from more than one location and to filter and configure media that is placed on a hosted domain, an Extensible Markup Language (XML)-based reference file called the manifest file is used.

About the Manifest File

The manifest file, which is linked to the hosted domain using the Content Distribution Manager user interface, allows you to define a series of servers from which content can be fetched, as well as a list of content items on each server to be fetched.

Written in XML, a finished manifest file contains a series of URLs pointing to live and pre-positioned content from the various origin servers.

Each hosted domain is associated with a single manifest file.

Because XML files, like HTML files, are simple text-format files that use special tags to designate how content is to be handled and represented on the web, it is possible to create manifest files manually using any ASCII text editor. A variety of third-party XML authoring tools also exist, and may speed the process of generating manifest files.

This section explains the structure of the XML-based manifest file. In the manifest file syntax examples that follow, note the capitalization and data formats used. In order for your finished manifest file to work, your XML tags and tag attributes must use the format outlined in this document. Errors in capitalization on a tag or tag attribute, or incorrectly formatted data will result in errors.

After you are comfortable with its structure and the various methods for generating a manifest file, see the "Creating a Hosted Domain for a Content Provider" section for instructions on creating a hosted domain and pointing it to a manifest file that names content you wish to bring in to your CDN.

Manifest File Structure and Syntax

The Cisco Internet CDN manifest file is an XML-based file that provides powerful features for representing and manipulating CDN data, while remaining comprehensible and easy for CDN administrators to edit manually using any text editor. Example 2-1 provides type definitions for the various elements of an Internet CDN manifest file. Details on each manifest file element follow.


Example 2-1: Manifest Document Type Definitions (DTDs)
<!-- CdnManifest DTD-->
<!ENTITY % playServerTable SYSTEM "PlayServerTable.dtd">
%playServerTable;
<!ELEMENT CdnManifest playServerTable?, options?, server*,(item | item-group)*)>
<!ELEMENT options EMPTY>
<!ATTLIST options
	clearlog (true | false) "false"
	noRedirectToOrigin (true | false) "false"
	timeZone CDATA #IMPLIED
manifest-id #IMPLIED
>
<!ELEMENT host EMPTY>
<!ATTLIST host
	name CDATA #REQUIRED
	proto (http) "http"
	port CDATA #IMPLIED
	user CDATA #IMPLIED
	password CDATA #IMPLIED
>
<!ELEMENT server (host+)>
<!ATTLIST server
	name CDATA #REQUIRED
>
<!ELEMENT contains EMPTY>
<!ATTLIST contains
	cdn-url CDATA #REQUIRED
>
 
<!ELEMENT item (contains*)>
<!ATTLIST item
	cdn-url CDATA #IMPLIED
	src CDATA #REQUIRED
	server CDATA #IMPLIED
	playserver (real | http | qtss) #IMPLIED
	type (prepos | live) #IMPLIED
	ttl CDATA #IMPLIED
	serve CDATA #IMPLIED
	prefetch CDATA #IMPLIED
	expires CDATA #IMPLIED
	alternateUrl CDATA #IMPLIED
	noRedirectToOrigin (true | false) #IMPLIED
>
<!ELEMENT item-group (item | item-group)*>
<!ATTLIST item-group
	server CDATA #IMPLIED
	playserver (real | http | qtss) #IMPLIED
	type (prepos | live) #IMPLIED
	ttl CDATA #IMPLIED
	alternateUrl CDATA #IMPLIED
	cdnPrefix CDATA #IMPLIED
	srcPrefix CDATA #IMPLIED
	noRedirectToOrigin (true | false) "false"
>
<CdnManifest> </CdnManifest>

The <CdnManifest> tag marks the beginning and end of the manifest file content. At a minimum, each <CdnManifest> tag set must contain at least one item that will be fetched and stored on the hosted domain, and may optionally reference a list of host servers from which content will be fetched. (See Example 2-2.)

Any number of servers, hosts, and items can be defined, up to a limit of 10,000 items in the manifest file.


Example 2-2: CdnManifest Tag
<CdnManifest>
<playServerTable> ... </playServerTable>
<options ...>
<server ...>
    <host.../>
</server>
<item> ... </item>
</CdnManifest>
<playServerTable> </playServerTable>

Playserver tables provide a way for you to set default mappings for a variety of media types on your hosted domains. Mappings can be set for both MIME content types (the preferred mapping) and file extensions. Playserver tables allow you to override default mappings on the Content Engine for content types on a particular hosted domain.

Using the manifest file, you can map groups of content items as well as individual pieces of content to an installed playserver. Playserver mappings can be made at the following locations (listed in order of precedence):

  • Content item URL—Playserver mappings appear right after the hosted domain name in place of the default cdn-media tag.

  • In the manifest file as an attribute of the <item> or <item-group> tags—Playserver mappings placed here are identified using the playserver attribute and only apply to the named item or group of items.

  • In the manifest file as a PlayServerTable—Mappings here are grouped within the <playServerTable> and <playServer> tags and are applied to all content served from the hosted domain using the manifest file.

  • In the system-level playserver map configured during CDN startup.

<playServerTable> tags are enclosed within the <CdnManifest> tags and name at least one playserver, for example, RealServer, to which certain MIME types and file extensions are mapped.

Example 2-3 shows a PlayServerTable as it might appear in a manifest file. The following table would provide content mappings for RealServer for the hosted domain using the manifest file in which the table appears:


Example 2-3: PlayServerTable Tag
<playServerTable>
<playServer name="real">
<contentType name="application/x-pn-realaudio"/>
<contentType name="application/vnd.rn-rmadriver"/>
<extension name="ra"/>
<extension name="smi"/>
</playServer>
</playServerTable>

<playServer></playServer>

The <playServer> tag names a media server type on the Content Engine that will be responsible for playing the content types and files with extensions that are mapped to it using the <content-type> tags. The <playServer> tag is enclosed within <playServerTable> tags.


Note   Do not confuse the <playServer> tag with the playserver setting in an <item> or <item-group>, which specifies a server type to be used for an individual piece of content or group of related content items. Although both playserver settings accomplish the same task, <item>-level playserver settings take precedence over the content type and file extension mappings specified by the <playServer> tags in the <playServerTable> area.

name (required)

Each <playServer> tag names the type of server to which content will be mapped using the name attribute. Content Engines support three types of playservers:

  • real (RealMedia RealServer)

  • http (web server)

  • qtss (Apple QuickTime)

<contentType>

The <contentType> tag names a MIME content type that is being mapped to a playserver.

The <contentType> tag must be enclosed within a <playServer> tag set. When both <contentType> and <extension> tags are present in a PlayServerTable for a particular media type, the <contentType> mapping takes precedence.

name (required)

Each <contentType> tag names a type of media that will be mapped to the playserver using the name attribute. See Table 2-1 for a list of supported media types.


Table 2-1: Supported Media File Formats Grouped by Manifest File contentType
Extension Supported Formats Notes

http

The content item will be handled by an HTTP server; this tag is used for content that cannot be streamed by any of the servers listed in the previous section, for example, Adobe PDF, PostScript (PS), and MPG files.

media

This is the default value used by the Cisco Internet CDN Software. Use the media tag when no playserver is specified to handle a content item; the linked item may be a pre-positioned or a live content item.

real

The content item will be handled by RealServer.

qtss

The content item will be handled by the Apple QuickTime Darwin Streaming Server.



<extension>

The <extension> tag names a file extension that is being mapped to a playserver.

The <extension> tag comes after the <playServer> tag. When both <contentType> and <extension> tags are present in a playServerTable for a particular media type, the <contentType> mapping takes precedence.

name (required)

The name attribute provides the file extension for a mapped content type. When files with the named extension are requested, the mapped playserver will be used to serve them.

<options/>

The <options/> tag (see Example 2-4) is a manifest designation that allows you to specify global settings for the hosted domain using the predefined attributes described in the paragraphs that follow.

The <options> tag is enclosed within the <CdnManifest> tags and specifies at least one global setting for the hosted domain. When omitted, default values or <item>-level equivalents are used.

If parameters are defined in both the manifest file <options> tag and the <item> tag for a particular piece of content, the <item>-level designation takes precedence.


Example 2-4: Options Tag

<options timeZone="EST" noRedirectToOrigin="false" />

manifest-id

This user-defined attribute specifies a unique, numeric identifier for the manifest file that is used to distinguish it from other manifest files on your CDN. Providing a unique identifier for each manifest makes the job of distinguishing one manifest file from another simpler.

noRedirectToOrigin (optional)

When set to false, this attribute allows the CDN to redirect requests for a content item to the origin server if it has not been pre-positioned yet.

When set to true, this attribute prevents the CDN from redirecting content to the origin server if it has not been pre-positioned on the hosted domain cache.

timeZone (optional)

This attribute specifies the time zone that is used by all content items and item groups on the hosted domain. When not specified, the default time zone is Greenwich Mean Time (GMT). Accepted values for this attribute include any standard time zone ID or abbreviation supported by the Java language, for example:

EST 
 

which is the abbreviation for Eastern Standard Time.

See "CDN Supported Time Zones," for a list of supported time zone abbreviations that can be used in the manifest file.

<server></server>

The <server> tags (see Example 2-5) define a host or set of hosts from which content is to be retrieved.

The <server> tags are contained within <CdnManifest> tags and contain one or more <host> tags, which identify hosts (server locations) from which content will be retrieved.

Within each <server> tag set, be sure to list hosts in order of importance.


Example 2-5: Server Tag
<server name="origin-server">

<host name="www.cisco.com" .../>

<server name="origin-server">

name (required)

Each <server> tag set provides a name that individual content items and item groups use to point to the list of hosts. This name is specified using the name attribute.

<host />

The <host/> tag (see Example 2-6) defines a web or live server from which content is to be retrieved for hosting on the hosted domain. Multiple host servers can be defined within a single <server> tag set.

The <host> tag must be enclosed within <server> tags. Multiple <host> tags may appear within the same <server> tag set, and should be listed according to their importance, with the most important host listed first.


Example 2-6: Host Tag

<host name="www.cisco.com" .../>

For each <host> tag, there are a variety of required and optional attributes, which are described below.

name (required)

The name attribute identifies the DNS name or IP address of the host. This attribute may also point to a particular directory on the host.

password (optional)

The password attribute identifies the password for the user account required to access the host server. Defining a user account and password is optional, and is dependent on the protocol being used.

port (required)

The port attribute identifies the TCP port through which traffic to and from the host will pass. The port used is dependent on the protocol used to communicate with the host.

proto (required)

The proto attribute identifies the communication protocol that is used to fetch content from the host. The only supported protocol for the Cisco Internet CDN Software is HTTP.

user (optional)

The user attribute identifies the secure login used to access the host. Defining a user account and password is optional, and is dependent on the protocol being used.

<item /> and <item></item>

The <item> tag names a single piece of content on the hosted domain, for example, a graphic (see Example 2-7), MPEG video, or RealAudio sound file. Content items may be listed individually, or grouped using the <item-group> tag.

The <item> tag must be enclosed within <CdnManifest> tags and may also be enclosed within <item-group> tags.


Example 2-7: Item Tag
<item cdn-url= "logo.jpg"
server="origin-web-server"
src= "images/ciscologo256_colors.jpg"
type="prepos"
playserver="http"
ttl=300/>

For each <item> tag, there are a variety of required and optional attributes, which are described below.

alternateUrl (optional)

The alternateUrl attribute names a location that will be displayed in the place of the content item if the src (source) location is invalid. For example, the alternateUrl tag might point to an HTML-format help page.

cdn-url (optional)

The cdn-url attribute identifies the public location for the content item on the hosted domain. The cdn-url attribute can use wildcard (*) values in the manifest file only when the content item is live (streamed) content. The published content URL must of course point to the live content item on the live server.

The value supplied for the cdn-url attribute becomes one part of the published request URL that end users see and link to. If no cdn-url value is supplied, the cdn-url is set to the src attribute.

contains (optional)

The <contains.../> tag (see Example 2-8) identifies other pieces of content that are embedded within the content item currently being described. For example, a SMIL-format file may contain links to JPEG and RealAudio files that are crucial components of the finished SMIL presentation. Using the <contains.../> tag to name each component file ensures that these items are ready to be served when the SMIL file is requested.

Requests for an item with links to other pieces of content are only accepted after the CDN determines that all dependent content items are present in the cache.


Example 2-8: Item Tag with Contained Elements
<item cdn-url="house.rp"
  	src="house/house.rp">
    <contains cdn-url="image08.jpg"/>
    <contains cdn-url="image09.jpg"/>
    <contains cdn-url="image11.jpg"/>
    <contains cdn-url="image12.jpg"/>
    <contains cdn-url="image13.jpg"/>

</item>

expires (optional)

The expires attribute designates a time in yyyy-mm-dd hh:mm:ss format after which the content item will no longer be served from the CDN. If no time zone is specified using the timeZone tag, the default time zone of Greenwich Mean Time (GMT) is used to determine the point after which the content item will no longer be available.

At some point after the expiration date and time have been reached, the expired content is removed from the cache.

If the expires attribute designates a time in the future, the content item will continue to be served from the CDN.

noRedirectToOrigin (optional)

When set to false, the noRedirectToOrigin attribute allows the CDN to redirect requests for a content item to the origin server if the content item is not yet pre-positioned at the location specified by the src attribute tag.

When set to true, this attribute prevents the CDN from redirecting content to the origin server if it cannot be found in the hosted domain cache.

playserver (optional)

The playserver attribute names the server that will be used to play this media item. When specified, this value overrides any content mapping in the <playServerTable> area. See the "<playServer></playServer>" section for supported playserver designations.

RealServer is the only supported platform for delivering live content. Thus, when the type is live, the playserver must be real.

prefetch (optional)

The prefetch attribute designates a time in yyyy-mm-dd hh:mm:ss format after which a content item should be retrieved from the origin server and repositioned on the Content Engine.

If no time zone is specified using the timeZone tag, the default time zone of Greenwich Mean Time (GMT) is used to determine the point at which the content will be retrieved from the origin server.

If the prefetch attribute designates a time in the future, the content item is not updated.

serve (optional)

The serve attribute specifies the date and time after which grouped content items can be requested from the Content Engine in yyyy-mm-dd hh:mm:ss format. The default time zone is GMT unless otherwise specified using the <options> tag.

server (optional)

The server attribute identifies the server from which the content item will be fetched. The name specified must match the server name in the <server> tag. If omitted, the origin server of the hosted domain is assumed to be the server.

src (required)

The src attribute names the relative URL on the origin server from which content will be fetched. When no cdn-url value is specified, the src attribute is used in the published content URL.

ttl (optional)

The ttl attribute identifies the period, in minutes, for which the content item should be controlled for changes before release. The default value is 30 minutes.

type (optional)

The type attribute indicates how the content should be handled. Two options are supported:

<item-group></item-group>

The<item-group> tag (see Example 2-9) names a collection of content items with shared attributes on the hosted domain, for example, a group of graphics on the same host with the same Time To Live (TTL) value. If an attribute is specified in both the <item-group> tag and separately for a grouped content item, the <item>-level attribute takes precedence over the group attribute.

The <item-group> tag must be enclosed within <CdnManifest> tags and contain two or more <item> tags identifying content items that share the attributes named by the <item-group> tag.


Example 2-9: Item-Group Tag
<item-group server="origin-web-server" type="prepos" ttl="300">
    <item cdn-url="wild.ram" src="wildlife.ram" /> <item cdn-url="gg.mpeg" src="GoldenGate.mpeg" /> <item cdn-url="jbg.mp3" src="JohnnyBeGood.mp3" /> <item cdn-url="paul.asx" src="fin371k.asx" />
</item-group>
 

For each <item-group> tag, there are a variety of required and optional attributes, which are described in the paragraphs that follow.

alternateUrl (optional)

The alternateUrl attribute names a location that will be displayed in the place of the content item if the src (source) location is invalid. For example, the alternateUrl tag might point to an HTML-format help page.

cdnPrefix (optional)

The cdnPrefix attribute names a directory or partial path that is placed in the published request URL immediately before the value named by the item's cdn-url attribute.

noRedirectToOrigin (optional)

When set to false, the noRedirectToOrigin attribute allows the CDN to redirect requests to serve grouped content items to the origin server if they cannot be found at the location specified by the src attribute.

When set to true, this attribute prevents the CDN from redirecting requests for grouped content items to the origin server if they cannot be found in the hosted domain cache.

playserver (optional)

The playserver attribute names the server that will be used to play the grouped content items. When specified for grouped content items, this value overrides any content mapping in the <playServerTable> area. See the "<playServer></playServer>" section for supported playserver designations.

RealServer is the only supported platform for delivering live content. When the type is live, the playserver must be real.

serve (optional)

The serve attribute specifies the date and time after which the content item can be requested from the Content Engine in yyyy-mm-dd hh:mm:ss format. The default time zone is GMT unless otherwise specified using the <options> tag.

server (optional)

The server attribute identifies the server from which the grouped content items will be fetched. The name specified must match the server name in the <server> tag. If omitted, the origin server from the hosted domain is assumed to be the server.

srcPrefix (optional)

The srcPrefix attribute names a directory or partial path that is used to build a directory structure for the items in the content item group. The value specified by the srcPrefix attribute is placed in the published request URL immediately before the item's src attribute.

ttl (optional)

The ttl attribute identifies the period, in minutes, for which the grouped content item should be controlled for changes before release. The default value is 30 minutes.

type (optional)

The type attribute indicates how each grouped content item should be handled. Two options are supported:

  • prepos—Content should be pre-positioned on the hosted domain. This is the default value, which is applied in the event that no type is specified.

  • live—Content is a live broadcast and cannot be pre-positioned.

Sample Manifest File

Example 2-10 shows a functional manifest file. Use this example as a model when creating or troubleshooting your own manifest files.


Example 2-10: Manifest File Containing Pre-positioned and Live Content
<?xml version="1.0"?>
<!DOCTYPE CdnManifest SYSTEM "CdnManifest.dtd">
<CdnManifest>
<options timeZone="EST" />
<server name="origin-web-server">
  <host name="http://www.cisco.com/media/"  
        proto="http" />
</server>
<item-group
      server="origin-web-server"
      type="prepos"
      ttl="300">
 <item cdn-url="wild.ram" src="wildlife.rm" /> 
  <item cdn-url="gg.mpeg" src="GoldenGate.mpeg" /> 
  <item cdn-url="jbg.mp3" src="JohnnyBeGood.mp3" /> 
  <item cdn-url="paul.avi" src="fin371k.avi" /> 
</item-group>
<item cdn-url="house.rm"
  	src="house/house.rm"/>
<item cdn-url="house.rt"
  	src="house/house.rt"/>
<item cdn-url="house.smi"
  	src="house/house.smi">
    <contains cdn-url="house.rm"/>
    <contains cdn-url="house.rt"/>
  </item>
<!--item-group server="live-streamer" type="live">
    <item cdn-url="/voices.rm" src="encoder/test.rm"/-->
<!--/item-group-->
</CdnManifest>
 

Publishing URLs That Link to CDN Content

Having reviewed the syntax and structure of the manifest file, and created a manifest file for your hosted domain, you are ready to create URLs that point end users to your CDN content.

All URLs pointing to CDN content use the following structure:

http://hosted_domain_name/cdn-playserver/cdn-url  

 

The elements of this URL are described in Table 2-2.


Table 2-2: Components of a CDN URL
URL Component Description

hosted_domain_name

Fourth-level domain name assigned to your hosted domain or the alias assigned to that hosted domain. See the "Creating a Hosted Domain for a Content Provider" section for more information on naming hosted domains.

cdn-playserver

Server that you designated to handle the content item to which you are linking.

Playservers can be specified in a number of locations, including the manifest file. Playserver designations in the URL of a content item override a content mapping in the manifest file. See Table 2-1 for a list of media formats, organized by extension.

The following playserver definitions are supported in CDN URLs:

cdn-url

Relative location of the content item on the CDN device. This value is supplied by the cdn-url or src attribute in the <item> tag in the manifest file for each piece of content.

Wildcard characters are accepted in the cdn-url attribute only when you link to live content. Actual content URLs must of course point to the actual content item.



Adding Content Providers

Content providers are your customers. Content providers deploy content on a CDN.


Note   Before you add a content provider, you need to have up-to-date customer contact information available so you can enter the correct information when you add the content provider.

To add a content provider, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click customers.

The View Content Providers page appears. (See Figure 2-1.)


Figure 2-1: View Content Providers


Step 2   Click Create Content Provider.

The Create a New Content Provider page appears. (See Figure 2-2.)


Figure 2-2: Create a New Content Provider


Step 3   Under the Content Provider heading, enter the company name for the content provider in the Name field.


Note   The company name must be distinct from that of other content provider company names.

Step 4   Enter the postal address for the content provider in these fields: Street, City, State, Zip (postal code), and Country.

Step 5   Under the Primary Contact heading, enter the name of the primary technical contact for the content provider in the Name field.


Note   The primary technical contact is usually the person responsible for the origin server that provides content to the delivery network.

Step 6   Use the fields provided to enter the phone number and e-mail address for the primary contact for this customer.

Step 7   Repeat Step 5 and Step 6 for the secondary contact person for the content provider.


Note   For a secondary contact, enter the name, telephone number, and e-mail address of a finance or accounting contact. (This step is optional.)

Step 8   Click Save to create a new content provider.


Adding Regions and Locations

A region is a geographical area. For example, Northeastern USA could be a region, or each time zone in the United States could correspond to a region. The three default regions are Eastern USA, Central USA, and Western USA.


Note   There must be a minimum of three regions. Although you can delete the default regions, you must always maintain at least three regions on the Content Distribution Manager.

A location is a physical place, for example San Jose, California, or a point of presence (POP). Each location has a region associated with it, which means that locations are grouped together in regions.

Content Routers and Content Engines have regions and locations associated with them. Content Routers use location and region information to make decisions about where to direct DNS requests.

Content Engines use regions and locations for grouping. You set up regions and locations based on the particular needs of your content providers.


Note   You can define up to 20 regions and 192 locations.

When you create a region, you must specify whether the region is desirable. A desirable region is one to which you can route any end user request (regardless of the geographic origin of the request) because of the existence of robust network connectivity. By default, a region is not desirable.

Most regions in the United States are desirable because network connectivity in the United States is generally very good. Network connectivity in other parts of the world may not be as robust, so if an end user request is received from Asia, you might not want to route the request to Africa, for example. However, routing the Asian request to anywhere in the United States would be acceptable.

Adding a Region

Since a location has a region associated with it, it is convenient to add regions before you add locations.

To add a region, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click resources.

Step 2   From the dropdown list, choose Regions. The View Regions page appears. (See Figure 2-3.)


Note   Alternatively, click networks.


Figure 2-3: View Regions


Step 3   Click Create Region.

The Create a Region page appears. (See Figure 2-4.)


Figure 2-4: Create a Region


Step 4   Under the Region heading, enter a region name in the Name field.


Note   The region name must be distinct from those of all other regions.

Step 5   Under the Comments heading, enter a description that is useful to you. (Comments do not appear to end users.) This step is optional.


Note   If you click Cancel at any time, all values return to their previous settings, and the View Regions page reappears.

Step 6   If the region is a desirable region, check the Desirable check box.

Step 7   Click Save to create the new region.


Adding a Location

To add a location, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click resources.

Step 2   From the drop-down list, choose Locations. The View Locations page appears. (See Figure 2-5.)


Figure 2-5: View Locations


Step 3   Click the Create Location button.

The Create a Location page appears. (See Figure 2-6.)


Figure 2-6: Create a Location


Step 4   Under the Location heading, enter a name for the location in the Name field.


Note   The location name must be distinct from those of all other locations.

Step 5   Next, choose a region from the Region drop-down list.

You must specify a region that is associated with the location. If you have not yet added the region you want, click Cancel and see the instructions for "Adding a Region" section before attempting to create a location.

Step 6   Under the Comments heading, enter a description that is useful to you in the field provided. (Comments do not appear for end users.) This step is optional.

Step 7   Click Save to create your new location.


Activating and Defining Content Routers and Content Engines

Using the Content Distribution Manager, you can edit the device properties of the Content Engines and Content Routers that you have configured. Properties that can be edited appear in Table 2-3.


Table 2-3: Content Engine and Content Router Properties
Device Property Description Notes

Status

Indicates whether the device has been activated

Status is online or offline. Devices cannot be deactivated after they have been activated.

Name

Provides the name of the device

Content Engine names cannot contain spaces if the named Content Engine will be a member of a cluster.

Version

Version of the Cisco Internet CDN Software currently installed on the selected device

Region

Describes the general geographic location of the physical device

Location

Describes the specific physical location of the physical device

Root Password

Password for the administrative-level root account for the selected device

Allows administrators to overwrite the root account password and gain direct, command-line access to the device.

HTTP Password

Password for the web-based graphical user interface for the selected device

Allows administrators to secure access to configuration information for selected devices from the Content Distribution Manager.

Storage Allocation

Amount of space (in gigabytes) reserved on the selected device to cache pre-positioned media

Applies only to Content Engines.

Description

Optional description of the selected device for easy recognition in the Content Distribution Manager interface



Activating and Defining a Content Router

A Content Router is a device that selects suitable Content Engines within a CDN to serve a given end user request.


Note   There can be up to eight Content Routers in a CDN.

Before you can activate and define a Content Router, it must be registered with the Content Distribution Manager. Registration happens in the last step of the Content Router setup routine, but Content Routers can be reregistered with the Content Distribution Manager at any time.

In addition, your DNS server must have entries that provide a mapping to the Content Routers before content routing can take place. For information about configuring your Content Routers and registering them with the Content Distribution Manager, or for questions regarding DNS configuration, refer to the Cisco Internet CDN Software Configuration Guide.

To activate and define a Content Router, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click resources.

Step 2   From the drop-down list, choose Content Routers.

The View Content Routers page appears. (See Figure 2-7.)


Figure 2-7: View Content Routers


Step 3   Click the icon next to the name of the Content Router that you want to activate and define.

The Modify a Content Router page appears. (See Figure 2-8.) From this page you activate, define, and manage a Content Router.


Figure 2-8: Modify a Content Router


Step 4   Under the General Configuration heading, enter a new name in the Content Router Name field if you want to change the name of the Content Router.


Note   The Content Router was named when it was configured. If you change the name, you must choose a unique name. No two Content Routers can have the same name.

Step 5   Under the General Configuration heading, check the Activate Node check box (not shown in Figure 2-8).

This activates the Content Router. The next time you display the Modify a Content Router page, the Activate Node check box will have disappeared and you will see that the Content Router is active.


Note   You cannot deactivate a Content Router once it has been activated. However, you can delete it, stop it, or shut it down. For information, see the "Deleti ng a Content Router" section 3-19.

Step 6   From the pull-down Location list, choose a location in which the selected Content Router will be grouped.

If the desired location has not already been created, see the "Adding a Location" section for instructions on how to add a location.


Note   A region is associated with a location, so the region appears automatically when the location is selected or defined. You cannot define a region here. For information on defining a region, see the "Addi ng a Region" section.

Step 7   Click Save to activate the selected Content Router.

Step 8   Change the default root and HTTP passwords for the Content Router from their default values once the device has been activated. See the "Modifying Content Router Passwords" section for instructions.


Activating and Defining a Content Engine

A Content Engine is a device that stores content from content providers and serves it to an end user.


Note   There can be up to 2000 Content Engines in a CDN.

Before you can activate and define a Content Engine, it must be registered with the Content Distribution Manager. Registration happens in the last step of the Content Engine setup routine, but Content Engines can be re-registered with the Content Distribution Manager at any time. For information about configuring a Content Engine, refer to the Cisco Internet CDN Software Configuration Guide.

If the Content Engine you are activating will be a member of a supernode, review the recommended supernode configuration procedure in the "Supernode Configuration Priorities" section before proceeding.

To activate and define a Content Engine, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click resources.

Step 2   From the drop-down list, choose Content Engines.

The View Content Engines page appears. (See Figure 2-9.)


Figure 2-9: View Content Engines


Step 3   Click the icon next to the name of the Content Engine that you want to activate and define.

The Modify a Content Engine page appears. (See Figure 2-10.) From this page, you activate, define, and manage the Content Engine. A Content Engine that has been activated is available for assignment to a CDN.


Figure 2-10: Modify a Content Engine


Step 4   Under the General Configuration heading, enter a new name in the Content Engine Name field if you want to change the name of the Content Engine.

The Content Engine was named when it was configured. If you change the name, you must choose a unique name. No two Content Engines can have the same name.


Note   Content Engine names cannot contain spaces if the named Content Engine will be a member of a cluster.

Step 5   Under the General Configuration heading, check the Activate Node check box (not shown in Figure 2-10).


Note   You cannot deactivate a Content Engine once it has been activated. However, you can delete it, stop it, or shut it down. For information, see the "Deleti ng a Content Engine" section.

Step 6   From the Location drop-down list, choose a location in which to place the selected Content Engine.

If the desired location has not already been created, see the "Adding a Location" section for instructions on how to add a location before continuing. Then choose it from the location list.


Note   A region is associated with a location, so the region appears automatically when the location is selected or defined. You cannot define a region here. For information on defining a region, see the "Addi ng a Region" section.

Step 7   Under the Storage Allocation heading, set the amount of disk space on the selected Content Engine that will be reserved for pre-positioning video-on-demand media for content providers by entering the amount of space (in gigabytes) in the Pre-position Disk Space field.

Step 8   Click Save to update the Content Engine record and activate the selected Content Engine.

Step 9   Change the default root and HTTP passwords for the Content Engine from their default values once the device has been activated. See the "Modifying Content Engine Passwords" section for instructions.


Adding Supernodes and Content Engine Clusters

Supernodes consist of two or more Content Engines grouped (or "clustered") behind a Content Services Switch. Supernodes provide data redundancy and next-click failover for CDN content, as well as load balancing between Content Engines for improved response time.

When creating a supernode on the CDN, you point the Content Distribution Manager to a Content Services Switch that has already been configured. To properly configure the supernode, you must have the following Content Services Switch configuration information at hand:

Supernode Configuration Priorities

Because supernodes are complex entities, involving the configuration of two separate hardware devices in addition to software components, it is important to configure your hardware devices and software in the proper order, so as to avoid confusion or errors caused by trying to configure a supernode before one of its components has been readied.

The following tasks must be completed when you configure a new supernode on your CDN. Tasks are listed in the order in which you should complete them. References to related sections in the Cisco Internet CDN software and hardware documentation are provided.

Creating a Supernode

Before attempting to create a supernode, review the recommended supernode configuration procedure in the "Supernode Configuration Priorities" section before proceeding.

To create a new supernode:


Step 1   From the Cisco Internet CDN Software user interface, click resources.

Step 2   From the drop-down list, choose SuperNodes. The View Supernodes page appears. (See Figure 2-11.)


Figure 2-11: View Supernodes


Step 3   Click Create SuperNode. Fields for configuring the supernode appear on the Create a Supernode page. (See Figure 2-12.)


Figure 2-12: Create a Supernode


Step 4   Under the General Configuration Heading, in the SuperNode Name field, enter the name of the new supernode.

Step 5   From the Location drop-down list, choose a location in which the supernode (and its clusters) will be grouped. Once you choose a location, the region is supplied automatically.

If you have not already created a location, see the "Adding a Location" section before continuing.

Step 6   Under the CSS Information heading, check the Redundant CSS check box if the Content Services Switch you are identifying is acting as a redundant switch.

Step 7   Under the CSS Password heading, in the Password field, enter the root account password required to log in to your Content Services Switch.

Step 8   Confirm the Content Services Switch root account password by reentering it in the Re-Type Password field.

Step 9   Under the CSS Configuration Address heading, enter the IP address of the Content Services Switch in the Configuration IP Address field. You should have recorded the IP address of the Content Services Switch during its initial configuration.

Step 10   If you wish, in the Comments field, enter a text description that will accompany the Content Services Switch. (Comments do not appear to end users.)

Step 11   Click Save to create the new supernode. The Content Distribution Manager uses the addresses you supplied to contact the Content Services Switch. You are returned to the View Supernodes page. The supernode status appears as configuring until the new supernode configuration information has been propagated.


Once the supernode status changes from configuring to up to date, you can proceed and create your Content Engine clusters. See the next section, "Creating a Cluster."

Creating a Cluster

Content Engines are designated for membership in a cluster during initial configuration, when they are associated with a Content Services Switch on the network. The actual Content Engine groupings, however, are created using the Content Distribution Manager user interface.


Note   There can be up to 1000 clusters on a CDN.

Content Engines in a cluster act cooperatively to serve the same set of content for the hosted domain. Each Content Engine must be allocated a uniform amount of disk space for pre-positioning video-on-demand content. Because of this, we recommend that you put Content Engines with the same amount of available disk space in the same cluster so that resources are not wasted on any of your Content Engines.

Before attempting to create a cluster, you must first have done the following:

  • Created the supernode to which the cluster will belong

  • Obtained the static content IP address from your DNS server that will be used to communicate with the Content Engines in the cluster

Before attempting to create a cluster, review the recommended supernode configuration procedure in the "Supernode Configuration Priorities" section before proceeding.

To create a cluster:


Step 1   From the Cisco Internet CDN Software user interface, click resources.

Step 2   From the drop-down list, choose SuperNodes.

The View Supernodes page appears. (See Figure 2-11.)

Step 3   Click the edit icon next to the supernode in which you wish to create a new cluster. Fields for modifying the supernode properties appear on the View Clusters page. (See Figure 2-13.)


Figure 2-13: View Clusters


Step 4   Click Create Cluster (not shown in Figure 2-13). Fields for configuring the new cluster appear on the Create a Cluster page. (See Figure 2-14.)


Figure 2-14: Create a Cluster


Step 5   Under the General Configuration heading, enter the name of the new cluster in the Cluster Name field.


Note   You may wish to use a name that makes it easy to distinguish this group of Content Engines from others behind the same supernode.

Step 6   In the Content IP Address field, enter the static content IP address for the cluster. This is the public IP address that end users link to when requesting content from the hosted domain. This address must be supplied by your DNS server.

Step 7   In the Virtual Hostname field, enter an optional DNS host name for the cluster. This host name can be used in place of the content IP address to represent the cluster to CDN users. If used, this address must be supplied by your DNS server.

Step 8   Under the Pre-position Disk Space heading, enter the amount of pre-positioned disk space (in gigabytes) that will be allocated on each Content Engine assigned to this cluster. Pre-positioned disk space is hard disk space on each Content Engine that is reserved for storing video-on-demand and other content for user requests.


Note   Disk space allocations for pre-positioning content on Content Engines through the cluster take precedence over and, if necessary, overwrite other pre-positioned disk space allocations for devices.

Step 9   If you wish, in the Comments field, enter a text description to accompany the cluster. This step is optional. (Comments do not appear to end users.)

Step 10   Under the Content Engines heading, choose the name of the Content Engine you wish to add to this cluster. Content Engines cannot belong to more than one cluster, and Content Engines that have already been added to a cluster are not listed.


Note   Content Engines that are members of clusters cannot have names that contain spaces.

Step 11   Click OK to create the new cluster.


The Content Distribution Manager uses the addresses you supplied to group the selected Content Engines into a new cluster.

Creating a Hosted Domain for a Content Provider

A hosted domain is a group of related content that is being hosted on a CDN and distributed on behalf of a content provider.

A given content provider can define multiple hosted domains containing different sets of content on the CDN.

Each hosted domain has the following characteristics:

  • It is associated with a content provider.

  • It stores the address of the content provider origin server from which the hosted content originates and from which the Content Engines retrieve their content for caching.

  • It is assigned a unique, fourth-level domain called the hosted domain name, which is used in URLs pointing to CDN content.

  • It is associated with one or more Content Engines that store pre-positioned video-on-demand content for the content provider.

The content provider reauthors its web page to point to content stored on the CDN, replacing URLs on its web page with the appropriate CDN URL. See the "Publishing URLs That Link to CDN Content" section.

To create a hosted domain, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click resources.

Step 2   From the drop-down list, choose Hosted Domains.

The View Hosted Domains page appears. (See Figure 2-15.)


Figure 2-15: View Hosted Domains


Step 3   Click Create Hosted Domain.

The Create a Hosted Domain page appears. (See Figure 2-16.)


Figure 2-16: Create a Hosted Domain


Step 4   Under the Hosted Domain heading, enter a valid CDN hosted domain name in the Name field, using the following guidelines:

  • The hosted domain name must be a valid, fourth-level domain name, for example:
    www.cdn.cisco.com
     
    
  • The hosted domain name does not contain underscore (_) characters.

  • The first part of the domain name (www in the example above) is open, and can be defined by you when you create the hosted domain name.

  • The remaining subdomain (the three segments after the first dot) must correspond to entries on your DNS server to provide a functional mapping for the Content Routers.

  • The CDN must be given the right to act as the authoritative DNS server for the subdomain you specify.

Step 5   In the Origin Server field, enter the name or IP address of the origin web site of the content provider's content, for example:

www.cisco.com

Your Origin Server field cannot contain a path to a subdirectory on the server. The following example is not a valid origin server address:

www.cisco.com/support 
 

Step 6   From the Content Provider drop-down list, choose the content provider whose content will be stored on this hosted domain.

If you have not added any content providers to the CDN yet, see the "Adding Content Providers" section for instructions on doing so before continuing.

Step 7   In the Alias field, enter an optional alias for the hosted domain. For example, if your hosted domain name is:

www.cdn.cisco.com

but you want to use a third-level as opposed to a fourth-level domain name on all your published links, you can use the Alias field to map a third-level domain name to your host domain name such as:

www.cisco-cdn.com

Step 8   Under the Manifest heading, identify the manifest file that will be used by this hosted domain to coordinate the delivery of live and video-on-demand content. See the "Creating a Manifest File for Importing Media" section for more information on creating manifest files.

   a. In the Url field, enter the Internet address of the manifest file for this hosted domain. For example:

    http://www.cisco.com/manifest/manifest.xml  
    
    

   b. In the Space Required field, enter the amount of disk space (in megabytes) that needs to be reserved on the Content Engines to cache the content named in the manifest file.

   c. In the Refresh Time field, enter the frequency (in minutes) with which Content Engines assigned to the hosted domain should check for updates to the manifest file. Once Content Engines detect a change in the manifest file, the file is retrieved ("fetched") and read. New content is then served in accordance with the updated manifest file instructions. Old content (media files cached, but no longer pointed to by the manifest) is purged from the Content Engines.

   d. If you wish, set up a username and password required to retrieve the manifest file. This step is optional. Enter a username in the Username field, and then enter and verify the password in the Password and ReType Password fields provided.

Step 9   If you wish, enter notes about the Hosted Domain or instructions for other users in the Comments field. This step is optional. Comments are for internal use only and are not accessible to end users.

Step 10   Click Save to create the new hosted domain.

Before you can begin serving content from the new hosted domain, you must first assign Content Engines to it. See the next section, "Assigning Content Engines to Hosted Domains."


Assigning Content Engines to Hosted Domains

Once you have created a hosted domain using the Content Distribution Manager, you need to assign it to one or more Content Engines from which its content will be served.

Content Engines may be grouped together into supernodes, or act as standalone nodes. Within a given supernode, there may be one or more groupings of Content Engines, referred to as clusters. Nodes and supernodes are in turn grouped by region and location. Alternatively, clusters and nodes can be viewed according to the virtual CDN to which they belong.

To assign Content Engines to your hosted domain:


Step 1   From the Cisco Internet CDN Software user interface, click resources.

Step 2   From the drop-down list, choose Hosted Domains. The browser refreshes, listing the hosted domains on your CDN.

Step 3   Follow the instructions for modifying an existing hosted domain in the "Modifying Hosted Domains" section to open your hosted domain for editing.

Step 4   Click the Assign Content Engines button. The browser refreshes to display the Assign Content Engines to Hosted Domains page. (See Figure 2-17.) A list of Content Engines to which the hosted domain is assigned appears.


Figure 2-17: Assign Content Engines to Hosted Domains


Step 5   Click the Assign CEs by Region or Assign CEs by Virtual CDN tab.


Note   Virtual CDNs are groupings of Content Engines that are independent of the Content Engines' geographical location. Virtual CDNs can be created to respond to the particular needs of a CDN.

Step 6   Choose the region or virtual CDN containing the Content Engines you wish to assign to the hosted domain. A list of locations in the region or clusters in the virtual CDN appears.

If you are assigning Content Engines by regions, click the name of the location in your region containing the Content Engines you wish to assign; otherwise, go to Step 7.

Step 7   Check the check box adjacent to the name of the cluster or Content Engine with which you wish to associate the hosted domain.

Step 8   Click the Add Selected CEs button. The list of clusters or Content Engines to which the hosted domain is assigned refreshes, listing the newly added Content Engine or cluster.

Step 9   From the Root Location drop-down menu, choose a root location for the hosted domain.

The root location is the location, within the CDN content distribution hierarchy, from which content is replicated. Content replication is handled by the lead Content Engine in the root location to lead Content Engines in nonroot locations. Once it is replicated to the lead Content Engine in each location, content is then distributed to all nonlead Content Engines in the location.

Step 10   Click Save.


Replicating Content from the Origin Server to a Hosted Domain

Once you have created your hosted domain, assigned Content Engines to it, and linked your hosted domain to a manifest file that identifies the content to be hosted, you are ready to copy content from your origin server to the hosted domain. This process is referred to as "fetching" content from the origin server and "replicating" or "pre-positioning" it to the Content Engines that belong to your hosted domain.


Note   By its very nature, live content is not fetched from the origin server or the live streaming server. Instead, manifest file entries prepare Content Engines to properly handle and direct live content requests.

To fetch content from your origin server and replicate it to your Content Engines:


Step 1   From the Cisco Internet CDN Software user interface, click resources.

Step 2   From the drop-down list, choose Hosted Domains. The browser refreshes, listing the hosted domains on your CDN.

Step 3   Follow the instructions for modifying an existing hosted domain in the "Modifying Hosted Domains" section to open your hosted domain for editing.

Step 4   Verify that the Url field points to the correct manifest file (with an XML extension) for the hosted domain.

Step 5   Click Fetch Manifest. You are prompted to confirm your decision to begin copying the content named by the manifest file to the Content Engines assigned to the hosted domain.

Step 6   Click OK. You are returned to the View Hosted Domains page. (See Figure 2-15.)

Step 7   You can view the status of media replication from the origin server to your Content Engines at any time. See the "Viewing the Status of Content Replication to a Hosted Domain" section for instructions.


Creating a Virtual CDN

A virtual CDN is a logical grouping of Content Engines and clusters that provides an alternative to region and location groupings when you view, manage, and assign Content Engines.

Once assigned to a hosted domain, Content Engines or clusters distribute the content from content providers.

To create a virtual CDN, follow these steps:


Step 1   From the Cisco Internet CDN Software user interface, click virtual CDN.

The View Virtual CDNs page appears. (See Figure 2-18.)


Tips Alternatively, you can access the View Virtual CDNs page by clicking resources and then choosing Virtual CDNs from the drop-down list.


Figure 2-18: View Virtual CDNs


Step 2   Click the Create Virtual CDN button.

The Create a Virtual CDN page appears. (See Figure 2-19.)


Figure 2-19: Create a Virtual CDN


Step 3   Under the Virtual CDN heading, in the Name field, enter a name for the virtual CDN.

Step 4   In the Comments field, enter a description for the virtual CDN that is useful to you. (This step is optional.) Although it is not required, you may want to assign your Content Engines and Content Engine clusters to the virtual CDN that you are creating at this time.

Step 5   Click the Assign CEs by Region tab. The page refreshes, displaying a list of defined regions.

Step 6   Click the name of the region containing the first Content Engines that you wish to assign. A table displaying the locations defined for the region appears.

Step 7   Click the name of the location containing the first Content Engines that you wish to assign. A table listing the Content Engines and Content Engine clusters in the location appears.

Step 8   Check the check box next to each Content Engine or cluster that you wish to add to the virtual CDN, or check the check box in the column header to choose all devices in the list.

Step 9   Click the Add Selected CEs button to add the Content Engines or clusters to the virtual CDN. The list of assigned Content Engines refreshes to include the newly added Content Engine.

Step 10   Repeat Step 6 through Step 9 for each Content Engine or cluster that you wish to add to the newly created virtual CDN.

Step 11   Click Save to create your new virtual CDN.

For instructions on modifying the list of assigned Content Engines and clusters after you have created your virtual CDN, see the next section, "Assigning Content Engines to Virtual Content Delivery Networks."


Assigning Content Engines to Virtual Content Delivery Networks

A Content Engine or Content Engine cluster can be assigned to one or more virtual CDNs at any time. To assign a Content Engine to a virtual CDN:


Step 1   From the Cisco Internet CDN Software user interface, click virtual CDN. The View Virtual CDNs page appears. (See Figure 2-18.)

Step 2   Click the icon next to the name of the virtual CDN to which you want to assign a Content Engine.

The Modify a Virtual CDN page appears. (See Figure 2-20.)

Step 3   Click the Assign CEs by Region tab. The page refreshes, displaying a list of defined regions.


Figure 2-20: Modify a Virtual CDN


Step 4   Choose the name of the region containing the first Content Engines that you wish to assign. A table displaying the locations defined for the region appears.

Step 5   Choose the name of the location containing the first Content Engines that you wish to assign. A table listing the Content Engines and clusters in the location appears.

Step 6   Check the check box next to each Content Engine or cluster that you wish to add to the virtual CDN, or click the check box in the column header to choose all devices in the list.

Step 7   Click the Add Selected CEs button to add the Content Engines or clusters to the virtual CDN.

Step 8   Repeat Step 4 through Step 7 for each Content Engine or cluster that you wish to add to the virtual CDN.

Step 9   Click Save to update the virtual CDN with the new Content Engines or clusters.