Table Of Contents
Understanding the ACNS 5.0 Software Content Delivery Network
Content Delivery Network Overview
Content Distribution Managers
Content Engines
Content Routers
Deployment Scenarios
Key Features
Content Overview
Creating and Managing Content in a CDN
Content Request Interception and Router Redirection
WCCP Routing
Proxy Configuration
Simplified Hybrid Routing
Content Services Overview
Content Pre-Positioning
Content Caching and Access Control
User Authentication and Content Filtering
About Device Groups
Content Distribution Architecture
Content Providers, Websites, Channels, and Manifests
Channel Distribution
Multicast Replication of Content
Content Delivery Network Topology Considerations
Understanding the ACNS 5.0 Software Content Delivery Network
The basic objective of a Content Delivery Network (CDN) is to deliver content to the user in the most efficient manner possible. To that end, Cisco Application and Content Networking System (ACNS) software supports multiple content routing methods, and allows Content Engine caches to be populated with content in multiple ways.
This chapter describes the basic concepts of the Cisco ACNS 5.0 CDN. It describes the function and relationships of the different devices that make up the CDN and explains how content is acquired, distributed, stored, and delivered to the end user.
This chapter contains the following sections:
•
Content Delivery Network Overview
•
Key Features
•
Content Overview
•
Content Request Interception and Router Redirection
•
Content Services Overview
•
Multicast Replication of Content
•
Content Delivery Network Topology Considerations
Content Delivery Network Overview
Cisco ACNS software, Release 5.0 is the basis for the Cisco CDN described in this publication. The Cisco CDN consists of at least one Content Delivery Manager, one or more Content Engines, and one or more optional Content Routers. Cisco ACNS software allows content services to be configured, reconfigured, and monitored centrally from the Content Distribution Manager graphical user interface (GUI), Cisco's web-based application management tool.
Content Distribution Managers
The primary role of a Content Distribution Manager is to perform centralized content and device management. In the ACNS 5.0 CDN, the Content Distribution Manager manages both content acquisition and distribution and also manages policy settings and configurations on individual Content Engines. Through the Content Distribution Manager GUI, the network administrator can specify what content is to be distributed and to whom. The Content Distribution Manager also allows the administrator to monitor network nodes and apply changes, such as software upgrades, to groupings of nodes from a central location.
Content Engines
The primary role of a Content Engine in the CDN is to serve client requests for content. Content Engines also play a major role in content request routing and in channel distribution of content. The CDN works by deploying Content Engines either inside an enterprise firewall on an internal network, or at the edge of the enterprise network.
Content Engines can be managed centrally through the Content Distribution Manager or locally as separate standalone content caches.
Content Routers
The primary role of a Content Router in the CDN is to redirect client requests for content to the closest Content Engine containing that content. In the ACNS 5.0 CDN, Content Routers use simplified hybrid routing for request redirection. Simplified hybrid routing uses the Domain Name System (DNS) to ensure that the Content Router receives all requests for content. Once the Content Router receives these requests, it can redirect the end user to the content. (See the "Understanding Simplified Hybrid Routing and Coverage Zones" section for more details.)
An alternative to simplified hybrid routing is to use an enterprise router that supports and is configured with Web Cache Communication Protocol (WCCP) to intercept and route requests for content. WCCP detects client requests and routes the request to a Content Engine within the same network. WCCP does not require the presence of a Content Router. (See the "Understanding WCCP-Enabled Router Interception" section.)
Deployment Scenarios
All three types of devices do not need to be present in the CDN in order for Cisco ACNS software to function. For example, your ACNS 5.0 software might be deployed in any one of the following scenarios:
•
One Content Engine only
•
Many standalone Content Engines
•
One Content Distribution Manager and many managed Content Engines
•
One Content Distribution Manager and many managed Content Engines and Content Routers
Cisco ACNS 5.0 software is especially beneficial for deployment in an enterprise or Internet service provider (ISP) network where there is a requirement to both pre-position and cache content. Typically, such a network uses topologies that contain both high-speed and low-speed links. Cisco ACNS 5.0 software allows companies to use off-peak hours to move moderate or high-bandwidth content to the edge of their networks over low-speed links.
Figure 1-1 shows a typical enterprise intranet. Branch offices at the enterprise edge connect to the enterprise data center using low-speed links (56-kilobit [Kb], 128-Kb or 512-Kb) links. In addition, branch offices in the same region may connect to a regional headquarter data center, which then connects to corporate headquarters using limited-bandwidth links.
Figure 1-1 Typical Enterprise CDN Topology
In this example, each branch office has a Content Engine. The corporate data center has a Content Distribution Manager that is managed by the central Information Technology (IT) staff. Content Routers might also be deployed in the data center as well.
Key Features
Cisco ACNS 5.0 software combines the features and functionality of Cisco Cache Software, Cisco E-CDN software, and Cisco ACNS 4.x software, as well as certain aspects of Cisco ICDN software and Cisco streaming engine functionality. Cisco ACNS 5.0 software incudes the following key features:
•
Request interception and routing through these methods:
–
WCCP.
–
Nontransparent proxy.
–
Simplified (DNS) hybrid routing.
•
Content delivery that supports both pre-positioned content and on-demand cached content through these methods:
–
HTTP delivery.
–
Microsoft Windows Media Technologies (WMT) protocols over TCP, User Datagram Protocol (UDP), and multicast.
–
RealNetworks streaming protocols.
–
Standard Real-Time Transport Protocol/Real-Time Streaming Protocol (RTP/RTSP) streaming.
–
Analog TV-out.
•
Content distribution that supports these capabilities:
–
Pre-positioning of content.
–
On-demand content and caching of content.
–
Time of day, quality of service (QoS), and bandwidth limits.
–
Use of multicast for bulk data where available (otherwise using unicast).
–
Live WMT and RealMedia streaming over fault-tolerant distribution trees.
•
Content model in which:
–
Content is not imported or stored in the Content Distribution Manager.
–
Request URLs do not require special tags or modifications from the existing origin server URLs (except host name changes).
•
Management features:
–
Cisco-style command-line interface (CLI) over SSH and Telnet for configuring and monitoring, including configuring devices and content services.
–
Content Engine local GUI for configuring and monitoring.
–
Centralized CDN management through the Content Distribution Manager GUI for configuring and monitoring content distribution and content services.
–
Local and centralized license management.
–
Log files for request and log file exporting.
–
System monitoring using Simple Network Management Protocol (SNMP) and syslog.
–
Support for CiscoWorks2000 management system.
•
Security features:
–
All devices are mutually authenticated.
–
All interdevice communications are cryptographically signed and optionally encrypted.
–
All passwords are encrypted in transit between devices.
–
Compromise of one device does not necessarily compromise all devices (different passwords or certificates are on each device).
–
Secure access to the management GUI is provided over HTTPS.
–
Secure access to the management CLI is provided over SSH.
–
Unused network ports are closed.
Content Overview
Content is the fundamental element of the CDN; it represents all the data that the CDN handles. Content can be classified based on how the content is acquired, distributed, or served. The ACNS 5.0 CDN serves three classes of content: on-demand content, pre-positioned content, and live content.
This section explains some of the terminology that is used to discuss content in this publication.
On-Demand Content
On-demand content is acquired, cached, and delivered by client-triggered demand. When the first client request is made for the content, the content is retrieved from the origin web server and is served to the client by way of the best-suited Content Engine, which also stores or caches the content.
Pre-Positioned Content
Pre-positioned content is a means of distributing content to populate Content Engines in a centrally managed CDN environment. Bandwidth-intensive content objects, such as Java applets, Flash animations, Shockwave programs, and other file formats can be managed and scheduled for distribution to Content Engines during off-peak hours.
The CDN administrator configures, through the Content Distribution Manager GUI, a number of channels to specify the destination Content Engines for content delivery and assigns a Content Engine (called a root Content Engine) that is generally (but not necessarily) located in close proximity to an origin web server, to fetch the content according to attributes that are set out in an XML file called a manifest file. The manifest file (see "Creating Manifest Files") is used to specify the location from which the pre-positioned content objects should be fetched and how often the content should be checked for updates. The root Content Engine distributes the content to other Content Engines that serve as content caches and distribution gateways along the enterprise edge.
Pre-Positioned Versus Preloaded Content
Whereas pre-positioning content is associated with a centrally managed CDN environment, cache preloading is configured on a Content Engine-by-Content Engine basis and is not generally associated with a centrally managed CDN.
Content Engines can be configured to preload specific content items using HTTP or FTP. Websites are scanned several link levels down for content. Preloaded content can be configured with specified bandwidth limits for better control of network usage.
Content preloading is done by configuring the Content Engine to create a cache request for all the content located at the origin web server that stores the primary content. At a time specified by the pre-load schedule command, the Content Engine verifies that its content is still current and updates any content that has changed.
Live Content
Live content is acquired as a live streaming broadcast from either a satellite or terrestrial broadcasting source. The CDN administrator configures the policies associated with obtaining the live multimedia stream, such as the program listing URL (playlist), the maximum bit rate, and so forth, as well as the distribution policies, such as priority, schedule, and maximum bandwidth.
Creating and Managing Content in a CDN
Responsibilities for creating and managing content in a CDN are divided between webmasters and network administrators. This publication addresses both areas of responsibility.
Creating websites and adding content to the CDN are the responsibilities of the webmaster, whereas managing the content and the network is the responsibility of the CDN administrator. Webmasters are generally not involved with network topologies, configurations, WAN bandwidths, or Content Engine locations.
Enterprise companies can have multiple webmasters who are responsible for content by business unit, geography, content type, and so forth. The webmaster is authorized to add content to the CDN by creating one or more manifest files for channels associated with their website. The webmaster defines and schedules the acquisition jobs through the manifest file. Content is fetched according to the time defined in the webmaster's manifest file. (See "Creating Manifest Files.")
To associate one or more manifest files with the same logical content, the website and all of its associated channels must be registered and predefined in the Content Distribution Manager GUI. A network administrator is the person responsible for registering and defining content providers, websites, and channels through the Content Distribution Manager GUI. The administrator points the channel to a manifest file, assigns Content Engines to the channel, and designates a root Content Engine. (See "Configuring the CDN.")
Furthermore, the CDN administrator assigns channels and allocates disk space. The administrator allocates both the total amount and the per-channel amount of disk space for the website and assigns each channel to a set of device groups. The administrator also schedules bandwidth allocation for each root Content Engine. (See "Working with CDN Devices," and "Cisco ACNS Software Disk Space-Allocation Guidelines.")
Content Request Interception and Router Redirection
Cisco ACNS 5.0 software supports three methods of request handling to deliver content to the end user:
•
WCCP transparent interception
•
Proxy configuration
•
Simplified hybrid routing (SHR)
An ACNS 5.0 CDN can combine both WCCP and SHR.
WCCP Routing
The Content Engine supports WCCP Version 2 redirected requests. When configured for WCCP routing, the Content Engine receives requests from its assigned router and compares the content request against the content currently stored in its cache. If the Content Engine has the requested content (cache hit), the request is served from this cached storage. If the Content Engine does not have the content (cache miss), the content is requested from the origin web server and served to the requesting client through the Content Engine. No proxy configuration is required at the end user's browser. (See the "Understanding WCCP-Enabled Router Interception" section.)
Proxy Configuration
In this mode, end user web browsers need to be explicitly configured to use the IP address or host name of the Cisco Content Engine, and there is no need for additional hardware, such as Layer 4 switches, Content Routers, or WCCP-enabled routers to intercept user requests.
If the Content Engine has the requested content, the request is serviced from this cached storage. If the content is not in the Content Engine's storage, the content is requested from the origin web server and served to the requesting client by way of the Content Engine. (See the "Understanding Content Routing Using a Proxy" section for more information.)
Simplified Hybrid Routing
Simplified hybrid routing (SHR) uses HTTP or RTSP redirection through a Content Router. The Content Router determines which Content Engine is best suited to deliver the desired content to the client by comparing the source IP address of the client end system against a table of address ranges assigned to Content Engines, known as the coverage zone. The coverage zone provides information on the proximity of client end systems to Content Engines based on each client's IP address. The Content Router can then choose the closest, best-suited Content Engine to serve the website request to the client. (See the "Understanding Simplified Hybrid Routing and Coverage Zones" section for more information.)
If several Cisco Content Engines are located behind a Network Address Translation (NAT) device or firewall, the Content Router can issue the redirect response to a routing-enabled Content Engine behind the NAT device. The routing Content Engine has the ability to issue a redirect to another Content Engine that is also located behind the NAT device or firewall. This Content Engine looks at its coverage zone file and issues a subsequent redirect response to the appropriate Content Engine that is configured to serve the client's request. (To enable routing on a Content Engine, see the "Configuring a Content Engine as a Routing Content Engine" section.)
Content Services Overview
The ACNS 5.0 CDN combines two types of content services using a single software base: content pre-positioning and content caching with filtering and access control. This section explains the objectives of these services and provides examples that are based on some typical needs and requirements of an enterprise network.
For more information on configuring content services, see "Configuring Services on CDN Devices."
Content Pre-Positioning
When pre-positioning content, the administrator can specify a group of content objects to be "pushed" to the remote branch offices in off-peak times, such as at night. This is advantageous because after the content is pre-positioned at a nearby Content Engine in the branch office, for example, it can be accessed using a higher-bandwidth connection than the typical low-bandwidth link between branch offices and remote corporate headquarters. Pre-positioning can be particularly advantageous for streaming objects.
For example, the training department at www.bigcorp.com might prepare an online training course that includes multiple videos and slides. The course might be posted at an internal website. If there is no CDN network, an employee from a remote office taking the course online must wait a long time for the video and slides to load. If, however, the administrator uses the CDN to pre-position the videos and slides to a Content Engine at the local branch office, then the employee can take the course as if the website were on the local LAN.
Content Caching and Access Control
Content caching, filtering, and access control services address the need to accomplish the following objectives:
•
Reduce bandwidth usage by caching frequently accessed Internet content.
•
Authenticate, monitor, log, and control web access from end users to implement corporate policies regarding work environment and system security.
Both objectives are made possible because of the Content Engine's special position as an "in-line" device between the end users and the Internet.
For example, BigCorp Enterprise wants to make sure that the following policy, security, and budgetary objectives are met:
•
Only full-time employees can access the web.
•
No employee can access objectionable content through the corporate network.
•
Viruses such as "Code Red" are prevented from being propagated inside the corporate network.
•
Monthly payments to the company's ISP are reduced.
BigCorp Enterprise can achieve all of these objectives by placing Content Engines at the network edge, where the corporate network interfaces with the Internet, and by placing Content Engines at remote branch offices. The Content Engines can then intercept content requests made by end users and enforce the above policies.
A Content Router might also be placed at the BigCorp Enterprise data center to aid in redirecting requests to Content Engines in the CDN.
User Authentication and Content Filtering
Content Engines can be configured to perform a number of authentication and content filtering services. Once the Content Engine receives a request, it does a number of things, including the following tasks:
•
Authenticates the client, asks the client to provide a username and password so that it can consult an authentication, authorization, and accounting (AAA) server, and checks whether the client is allowed to access the web.
•
Passes the request through a "filter," such as Websense or SmartFilter, to make sure that the requested object is not objectionable content.
ACNS 5.0 software relies on third-party software to implement content filtering. Supported filtering software includes Websense, N2H2, and SmartFilter.
•
Passes the request through the "rules," which might rewrite certain headers, redirect the request, or otherwise manipulate the request.
•
Checks to see whether the requested content is already in the Content Engine cache. If so, then the Content Engine serves the object directly, rather than from the origin server, thus saving bandwidth to the Internet.
•
If the requested content is not already in the cache, then the Content Engine fetches the content from the Internet on the client's behalf, and caches the content for future use if appropriate.
This functionality is typically called "proxy" functionality. Cisco ACNS 5.0 software supports Content Engine proxy functionality by supporting all web access protocols (including HTTP) and all streaming protocols.
About Device Groups
To facilitate configuring content services for large numbers of Content Engines, ACNS 5.0 software supports device groups.
A device group is a set of similar devices (such as Content Engines) that share common qualities and capabilities. Some common qualities might include disk capacity, distribution minimum bandwidth, or routing properties.
By grouping devices into device groups, you can configure settings and channel assignments for the entire group of devices at one time. Settings that can be configured through device groups include Content Engine properties, bandwidth settings, and content services.
Note
Content services that require a license key must be enabled on the Content Engine before you can configure service settings for a device group. You cannot enable software licenses on a device group. Licenses must be enabled on an individual Content Engine basis. (See the "Configuring Licensing and Enabling Streaming Servers" section.)
Content Engines can be assigned to multiple device groups when the device group overlap feature is enabled in the Content Distribution Manager GUI. (See the "Enabling Device Group Overlap" section.)
The Content Distribution Manager GUI allows you to change settings on individual devices to override the device group settings, and gives you the option of reverting back to the device group settings, if you wish.
To create and modify device groups, see the "Working with Device Groups" section.
Content Distribution Architecture
This section discusses the CDN content distribution architecture. It describes how content arrives at a Content Engine and discusses the role of content providers, websites, channels, and manifests in fetching and distributing content to the various Content Engines in the CDN.
Content Providers, Websites, Channels, and Manifests
Content is made available for distribution by content providers. A content provider is a person, group of persons, or organization that is responsible for providing content for an enterprise organization.
In the Content Distribution Manager GUI for ACNS 5.0 software, the network administrator can enter administrative information about the content provider, including who authored the content, contact information, and the purpose for the content. (See the "Working with Content Providers" section.)
The placement of the content from the content provider becomes the responsibility of a webmaster, who uses the content to build a website or multiple websites.
Websites can be classified as either routable or nonroutable. Routable websites are controlled and operated by the enterprise corporation where the content is owned. Routable website domain names are fully qualified domain names (FQDNs) that are recognizable to Content Routers. Routable websites support all ACNS software routing and edge intercept mechanisms: WCCP intercept, proxy intercept, and simplified hybrid routing. (See the "Content Request Interception and Router Redirection" section.)
Nonroutable websites are not controlled or operated by the enterprise corporation, and the content is not owned by the enterprise. For example, www.cnn.com or www.yahoo.com are nonroutable websites. Nonroutable websites support WCCP and proxy intercept only.
In the Content Distribution Manager GUI for ACNS 5.0 software, the network administrator enters information about the website, such as the origin server and the FQDN of the website, so that this content can be acquired by the CDN for distribution to designated Content Engines. (See the "Working with Websites" section.)
A Content Engine can be subscribed to a given website by being assigned to a channel that belongs to the website. A Content Engine that is subscribed to a website can perform simplified hybrid routing: that is, it can handle content requests for this website through a Content Router and cache the content from this website. (Routing through a Content Router is based on the subscribed relationship between Content Engines and websites.)
A channel is the mapping of a set of content objects from a single website to a set of devices or device groups. Content objects associated with a specific channel have a common domain (host) name; in other words, the content in a specified channel resides in a single location at an origin web server. Each channel is restricted to a single website and maps domain names to devices one-to-one for simplified hybrid routing DNS interception. (See Figure 1-2.)
Figure 1-2 One-to-One Channel Mapping to Devices
When a Content Engine is assigned to a channel, it is also, by definition, subscribed to the channel's website. A Content Engine must be assigned to a channel in order to accept the pre-positioned content (that has been itemized in a manifest file) for that channel. Channel assignment is also required for the Content Router to be able to serve content from the website of that channel. The network administrator creates and defines channels in the Content Distribution Manager GUI. (See the "Working with Channels" section.)
A manifest file specifies the content for a single channel. It is an XML file consisting of explicit item descriptions and crawler items with prefix constraints or match rules. The manifest file is defined by the webmaster or the CDN administrator acting as an agent for the webmaster, and controls both content acquisition and content distribution. The manifest file is assigned to one or more root Content Engines (a primary and a list of backups) through the Content Distribution Manager GUI.
The root Content Engine is the one Content Engine that is authorized to go directly to the origin web server for content. The root Content Engine then publishes the content to other Content Engines in the channel. The root Content Engine is designated as such in the Content Distribution Manager GUI. In general, the root Content Engine should be in the same general location as the origin web server.
Channel Distribution
Channel distribution describes the manner in which pre-positioned content is distributed from the origin web server to all the Content Engines that are subscribed to the content, or more specifically, assigned to the channel that represents that group of content objects.
Channel distribution is based on network topology, as follows:
•
Physical locations of devices
•
Configured relationships between locations
•
Logical content routes created by channels
Commonly encountered terms in channel distribution are defined in Table 1-1.
Table 1-1 Channel Distribution Terminology
Term
|
Definition
|
Locations
|
Groupings of well-connected (often physically connected) or interchangeable Content Engines, having IP address adjacency and usually found in the same proximate geographic location.
Locations organize and group Content Engines into virtual networks for distribution of content through channels. Locations are configured in the Content Distribution Manager GUI; each location can have zero to many Content Engines assigned to it. (See the "Working with Locations" section.)
|
Level
|
Hierarchical arrangement of locations defined by the child-to-parent relationships between locations.
• Each location can have zero to one location as its parent. Each location can have zero to many locations as its children.
• Locations with no parents are placed at level 1. A location whose parent is at level 1 is placed at level 2, and so on. An ACNS 5.0 network can have up to 4 levels and support up to 200 Content Engines per location and up to 200 child locations per parent location.
To configure location levels, see the "Creating and Modifying Locations" section.)
|
Location tree
|
A set of locations organized in the form of a tree structure. The structure is defined by the location levels.
A CDN can consist of one or many location trees. (See the "Viewing the Location Tree" section.)
|
Channels
|
Groups of content to which Content Engines can be assigned. Content Engines in the same location can be assigned to different channels.
• When configuring a channel in the Content Distribution Manager GUI, the administrator specifies a list of Content Engines which belong to the channel and which replicate the content of the channel, and a root Content Engine to acquire the content from the origin web server and publish it.
• For any given channel, there is only one publisher of content (the root Content Engine) and multiple receivers of that content (the Content Engines that are assigned to that channel). The location that contains the root Content Engine for a given channel is called the root location. A channel can have only one configured root Content Engine. Other Content Engines in the root location can act as backup publishers, if the configured root Content Engine fails.
To configure channels in the Content Distribution Manager GUI, see the "Working with Channels" section.
|
Root Content Engine
|
Content Engine designated to download the content from the origin web server and forward it to the Content Engines that are assigned to the content channel.
You designate a Content Engine to be the root Content Engine for a channel through the Channels tab of the Content Distribution Manager GUI. (See the "Adding and Removing Content Engines from Channels" section.)
|
Channels form logical routes for content to travel from an origin web server through the root Content Engine to all the other Content Engines in the channel. The distribution route follows the general tree structure of the manually constructed CDN location tree, where content is distributed from the root of the tree towards the branches; however, only the Content Engines assigned to a particular channel can be a part of that channel distribution tree. The channel distribution tree is constructed specifically for each channel.
Content is forwarded from Content Engine to Content Engine through the channel distribution tree until all Content Engines in the channel have received their subscribed content. The content is forwarded (or replicated) either by unicast pull or, if enabled, by multicast push. Unicast content forwarding involves communication between a single sender and single receiver; whereas, multicast replication involves communication between a single sender and a selected group of receivers (see the "Multicast Replication of Content" section).
Multicast Replication of Content
Multicasting allows efficient distribution of content to multiple Content Engines and is useful when many end users are interested in the same content. In ACNS 5.0 software, the administrator configures the CDN for multicasting by configuring a "multicast cloud" in the Content Distribution Manager GUI. Content Engines that are assigned to the multicast cloud must be enabled for multicasting.
The administrator enables the multicasting feature in the Content Distribution Manager GUI by entering a license key (purchased from Cisco Systems) for each Content Engine that is to be multicast-enabled (see the "Enabling Content Engines for Multicasting" section).
The multicast-enabled Content Engines must then be assigned to a multicast-enabled channel for multicast transmissions to take place (see the "Adding and Removing Content Engines from Channels" section and the "Assigning and Removing Multicast Clouds from Channels" section).
You can enable a channel for multicasting when you first create the channel, or you can modify the channel properties for multicasting (see the "Creating and Modifying Channels" section).
For more information on IP multicasting, including assigning IP multicast addresses, see "IP Multicasting."
Content Delivery Network Topology Considerations
The CDN administrator creates the CDN by defining the network topology location and relationship parameters in the Content Distribution Manager GUI. In the GUI, the administrator names the device locations, assigns the parent-child relationship to the locations, creates channels, and assigns Content Engines to channels. Procedures for using the Content Distribution Manager GUI to set up device locations and relationships are covered in "Configuring the CDN."
Before creating the CDN, the administrator should be prepared to answer the following questions:
•
What does my network look like?
•
Where is my origin web server located?
•
Where do I want the content to go?
•
How many Content Engines do I need at each location to support fan-out of child locations and end-users?
•
How many Content Engines do I need for failover and redundancy?