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
  
  
• Supported Content Types
  
  
• CDN Users
  
  
• 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.

If live, video-on-demand, or pre-positioned content will be distributed from the hosted domain, an XML-format file, referred to as a manifest file, is also required. The manifest file 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.

Alternatively, fourth-level hosted domain names can be mapped to valid third-level domain names using the hosted domain aliasing feature.

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.

Security

The Cisco Internet CDN Software uses Secure Socket Layer (SSL) for Java to encrypt all interdevice 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.

About Cisco Internet CDN Software Version 2.1

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

• Support for Microsoft Windows Media Technologies (WMT) including support for ASF and ASX file formats
  
  
• Multiple login accounts with three separate login levels: administrator, operations, and guest
  
  
• Static- as well as dynamic routing of CDN content, providing administrators with fine control of request routing
  
  
• Secure transfer of log files to remote logging server
  
  
• Content-based security using Symmetric Key Content Authorization on a hosted domain-by-hosted domain basis
  
  

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 ICDN-K9
  
  
• Cisco Content Engine 590 ICDN-K9 or 7320 ICDN-K9 Series
  
  
• Cisco Content Router 4450 ICDN-K9
  
  
• 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, 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.

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 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 can contain up to 2000 Content Engines 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, 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.

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 (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 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.

When this assumption is not appropriate, the CDN administrator has the option of enabling static routing. See the "Static Routing" section.

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.

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 used by its supernode in the form of an address (A) 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 DNS software to fine-tune the response to the client, recording which servers respond most quickly and directing future requests to those servers. 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 24 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, approximately 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.

Standalone Content Engines and supernode leaders also communicate with the Content Routers during each routing period. This communication provides a list of the hosted domains that a Content Engine or supernode is authorized to serve. 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.

Static Routing

The preceding discussion of CDN routing explains the way that the Cisco Internet CDN software takes advantage of DNS in routing end user requests to Content Engines through Content Routers, which choose from among the Content Engines or supernodes hosting the content being requested, selecting those that are close to the requesting client. In conventional CDN routing, sometimes called dynamic routing, the IP address of the DNS proxy making the request is used to make an approximation of the location of the actual requesting client.

Given a configuration in which the DNS proxy is not in close proximity to the requesting client, however, dynamic routing may assign the task of serving a user request to a Content Engine that is not close to the source of the request—even when a better positioned Content Engine hosting that content exists on the CDN. Particularly when serving live or video-on-demand content, this discrepancy could affect the quality of the served content.

Cisco Internet CDN Software provides a way for content providers to adjust for such irregularities in their network topography through static routing. Using static routing:

• Each location in a CDN is assigned to a coverage zone, a set of address ranges that it is well positioned to serve.
  
• DNS proxies from which requests should be specially handled are identified.
  
  
• End user (client) machines are mapped to the CDN Content Engines (based on location) that are well positioned to serve them
  
  

Coverage zone information is provided in a special text file, maintained on a machine controlled by the content provider. This file is fetched and periodically updated on each Content Router and Content Engine on the CDN.

With coverage zones deployed, the CDN software can use a combination of both dynamic and static routing, referred to as hybrid routing. Using hybrid routing, DNS proxy requests are compared by the Content Router against the list of DNS proxies in the coverage zone file.

• If the DNS proxy is not listed in the coverage zone file, the request is processed using standard CDN routing.
  
• If the DNS proxy is listed in the coverage zone file, the Content Router chooses, at random, one or two supernodes which host the requested content and which are in locations listed in the coverage zone file. The Content Router then returns these addresses to the DNS proxy in the form of NS records. The DNS proxy then communicates with the supernodes and chooses which supernode to use, passing its address back to the requesting client's browser.
  
  

When the selected Content Engine receives the request from the client, it determines whether it is best situated to serve the request, consulting the coverage zone information to determine if it is identified as a well-situated Content Engine for this client.

• If the Content Engine is well situated, it serves the request.
  
  
• If the Content Engine finds that it is not well situated to the end user, it generates a redirection response to the Content Router. The host name in this response encodes the address of the client.
  
  

The Content Router then makes a selection from the supernodes hosting the requested content that are in the locations identified in the coverage zone file, starting with those locations identified as "best" and "second-best" locations for the client's IP address, and continuing on to all locations identified in the coverage zone file for that IP address, if necessary.

For information on specifying a coverage zone file for your CDN and setting other dynamic and static routing parameters, see the "Modifying Routing Properties" section.

Importing and Pre-Positioning Content

In order to be able to serve pre-positioned content and live, streamed media, Cisco Internet CDN Software Version 2.1 uses an 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 is in contrast to earlier versions of the software, in which content was cached on Content Engines based on hosted domain records received from the Content Distribution Manager.

The manifest file serves as a roadmap 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.

Supported Content Types

Cisco Internet CDN Software supports any standard static content type. In addition, the CDN supports live streaming and video-on-demand delivery 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 Windows Media Player (ASF and ASX)
  
• Microsoft Windows Media Audio (WMA)
  
• Microsoft Windows Media Video (WMV)
  
• Microsoft Word (DOC)
  
• Motion Picture Experts Group (MPEG, MPG)
  
• MPEG Audio Layer 3 (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)
  

CDN Users

Cisco Internet CDN Software has three types of users:

• CDN administrators
  
  
• CDN operations-level users
  
  
• CDN guests
  
  

Table 1-2 describes user access privileges for the various Cisco Internet CDN Software features.

CDN Administrators

CDN administrators use Cisco Internet CDN Software to create CDNs. For example, administrators add new hosted domains, oversee content import, and remove Content Engines from the network.

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:

• Access—By adding, removing, and modifying user login accounts
  
  
• 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.

See Table 1-2 for an overview of administrator account access privileges for each feature on the Cisco Internet CDN Software graphical user interface.

CDN Operations-Level Users

CDN operations-level users can create, modify, and delete hosted domains, virtual CDNs, and content providers, but cannot modify other system components, update CDN software, modify system configuration, or change device passwords.

Operations-level users interact with CDN devices using the web browser-based graphical user interface to the Content Distribution Manager. The Content Distribution Manager provides write-level access to only those web pages that contain features for creating and modifying hosted domains, virtual CDNs, and content providers. In addition, operations-level users have access to the Login Password Administration page, from which they can change their own login password. See the "Changing the Login Account Password" section for information on using the login password administration feature.

Other information available to administrator-level accounts can be viewed but not edited. Certain administrative features are hidden from operations-level users.

See Table 1-2 for an overview of operations account access privileges for each feature on the Cisco Internet CDN Software graphical user interface.

CDN Guests

CDN guest-level users can view CDN device configuration, including configuration settings for hosted domains, virtual CDNs, and so on, but they cannot modify the CDN or any of its components in any way.

Guest-level users interact with CDN devices using the web browser-based graphical user interface to the Content Distribution Manager. The Content Distribution Manager provides read-only access to those web pages that contain information on hosted domains, virtual CDNs, and content providers. In addition, guest-level users have access to the Login Password Administration page from which they can change their own login password. See the "Changing the Login Account Password" section for information on using the login password administration feature. Other features available to administrator-level accounts are hidden from guest-level users.

See Table 1-2 for an overview of guest account access privileges for each feature on the Cisco Internet CDN Software graphical user interface.

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-3 describes the five primary groups of features associated with the Content Distribution Manager user interface:

Content Distribution Manager Icons

The Content Distribution Manager uses status icons for required fields, password field validation, and access to device configuration features. The icons you may see on the Content Distribution Manager user interface are shown in Table 1-4.

When problems arise with data entered into the Content Distribution Manager user interface, error messages are displayed for each problem field, on popup windows and in the footer area of the Content Distribution Manager user interface. These error messages help identify the source of problems and speed problem resolution.

To resolve the errors, hold the mouse cursor over each field-level error indicator. Error text will appear in a "tool tip" above the mouse cursor. Make any necessary adjustments to the format of the data you are entering and click the Save button. See the "User Interface Errors" section for more information on resolving errors on the CDN software graphical user interface.

Logging On to 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.

Logging On Following Session Timeout

The Content Distribution Manager web interface is equipped with a timeout feature that terminates idle sessions after a set amount of time. See the "Modifying the System Timeout Value" section for instructions on changing the length of time that must pass before your session times out.

When a session has timed out, you immediately lose access to the Content Distribution Manager web interface, which is replaced with a message informing you that "this session has expired.

To log back on to the Content Distribution Manager:

---

Note   Often when you log on to the Content Distribution Manager, the web interface is loaded into a separate instance of the web browser from the one used to point to the Content Distribution Manager URL. Make sure that both instances of the browser are terminated before attempting to log back on to the Content Distribution Manager.

---

Step 2   Open a new instance of your preferred web browser and point it to the URL of your Content Distribution Manager. You are prompted to log on to the Content Distribution Manager web interface.

Changing the Login Account Password

Regardless of your level of access (administrator, operations, or guest), you can update the login password of the account you are currently using. You should periodically change your login password to reduce the likelihood that unauthorized users will be able to use your login and password to access CDN data.

To change your login account password:

The View Content Engine Statistics page appears.

Step 2   From the drop-down list, choose the Login Password Administration option.

The Login Password Administration page appears, listing the name of the current login account.

Step 3   In the Old Password field, enter your current login password. You must be able to provide the current password before updating the login password.

Step 4   In the New Password field, enter your new password. Passwords should be eight characters long.

Step 5   In the Re-type New Password field, reenter your new password to verify the value that you entered. The value entered here must match the value that you entered in the New Password field, or you will not be allowed to update the login password.

Step 6   Click Save. The account's login password is updated and you are returned to the Login Password Administration page.

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.