Cisco ACNS Software Caching and Streaming Configuration Guide, Release 5.1 - Chapter 1: Introduction [Cisco Application and Content Networking System (ACNS) Software]

Table Of Contents

Introduction

Overview of the ACNS 5.1 Solution

ACNS Network Overview

Sample Deployment of Centrally Managed Content Engines

Sample Deployment of Locally Managed Content Engines

Content Overview

Content Types

Content Distribution

Content Services

Content Caching Service with Filtering and Access Control

User Authentication and Content Filtering

IP Packet Filtering and Access Control

Content Engine Local Deployment Scenarios

Transparent Caching

Transparent Caching Through a WCCP-Enabled Router

Transparent Caching Through a CCS Switch

Benefits of Transparent Cache Deployments

Nontransparent Caching

Benefits of Nontransparent Caching Deployments

Reverse Proxy Caching

Benefits of Reverse Proxy Deployments

Introduction

This chapter provides an overview of the Cisco Application and Content Networking System (ACNS) solution. It also introduces the various scenarios for locally deploying Content Engines as caching engines in enterprise and service provider environments.

This chapter contains the following sections:

•Overview of the ACNS 5.1 Solution

•Content Caching Service with Filtering and Access Control

•Content Engine Local Deployment Scenarios

Note This guide is intended for administrators who want to configure, manage, and monitor locally deployed Content Engines that are running ACNS 5.x software. To initially configure a Content Engine as a locally deployed device, you turn off the autoregistration feature so that the Content Engine will not automatically register with the Content Distribution Manager, and thereby can be individually managed through the Content Engine GUI or CLI as a locally deployed device. The Content Engine GUI allows you to remotely configure, manage, and monitor locally deployed Content Engines through your browser. The Content Engine CLI allows you to configure, manage, and monitor a locally deployed Content Engine through a console connection or a terminal emulation program.

For more information about initially configuring a Content Engine as a locally deployed device, see the "Configuring Device Network Settings" section. For information about using the Content Distribution Manager to deploy and manage a Content Engine as a centrally managed ACNS network device, refer to the Cisco ACNS Software Deployment and Configuration Guide, Release 5.1.

Overview of the ACNS 5.1 Solution

With the advent of e-business applications such as e-commerce, e-learning, knowledge sharing, and corporate communications, networks can experience uncontrollable bottlenecks. The ACNS solution helps enterprises and Internet service providers (ISPs) protect their networks from these uncontrollable bottlenecks and efficiently distribute rich media files to their end users. Designed for affordability and ease of installation, the ACNS solution enables high-impact, high-bandwidth rich media such as high-quality streaming video to be quickly deployed with minimal administration.

To that end, the ACNS software supports multiple content routing methods and allows Content Engine caches to be populated with content in multiple ways. Content Engines with the ACNS software installed accelerate content delivery by caching frequently accessed content (transparently or proxy-style) and then locally fulfill content requests rather than traversing the Internet or intranet to a distant web server.

By caching content such as HTTP and FTP traffic, Content Engines minimize redundant network traffic that traverses WAN links. As a result, WAN bandwidth costs either decrease or grow less quickly. This bandwidth optimization increases network capacity for additional users or traffic and for new services such as voice.

ACNS Network Overview

The Cisco ACNS network consists of at least one Content Distribution Manager, one or more Content Engines, and one or more optional Content Routers, as described in Table 1-1.

Table 1-1 Types of ACNS Network Devices

Device

Description

Content Distribution Manager

Performs centralized content and device management. In the ACNS 5.1 network, the Content Distribution Manager manages both content acquisition and distribution and also manages policy settings and configurations on individual Content Engines that are centrally managed.

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

Serve client requests for content. Content Engines also play a major role in content request routing and in channel distribution of content.

The ACNS network deploys Content Engines in these ways:

•Inside an enterprise firewall on an internal network

•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. To locally manage a Content Engine, the ACNS software CLI or the Content Engine GUI is used instead of the Content Distribution Manager.

This guide focuses on locally configuring and managing a Content Engine. For information about centrally configuring and managing a Content Engine, refer to the Cisco ACNS Software Deployment and Configuration Guide, Release 5.1.

Content Routers

Redirect client requests for content to the closest Content Engine containing that content.

Note The ACNS software device mode determines whether the device is functioning as a Content Distribution Manager, Content Engine, or Content Router.

Sample Deployment of Centrally Managed Content Engines

Figure 1-1 shows a typical enterprise deployment of centrally managed Content Engines. In this example, each branch office has a Content Engine that is centrally managed through the Content Distribution Manager in the corporate data center. The Content Distribution Manager is managed by the central Information Technology (IT) staff. Content Routers might also be deployed in the data center as well.

Branch offices at the enterprise edge connect to the enterprise data center using low-speed links (64 kbps or less) 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 Deployment of Centrally Managed Content Engines

Note For information about centrally deploying and managing a Content Engine, refer to the Cisco ACNS Software Deployment and Configuration Guide, Release 5.1.

Sample Deployment of Locally Managed Content Engines

Figure 1-2 shows a typical enterprise deployment of locally managed Content Engines that have ACNS 5.x software installed on them. In this example, three Content Engines (Content Engine A, B, and C) have been deployed as local caching engines at the central site, regional site, and the small branch office. All Content Engines are locally managed through the Content Engine GUI or CLI.

Figure 1-2 Typical Enterprise Deployment of Locally Managed Content Engines

Figure 1-3 shows an example of an ISP deployment of locally managed Content Engines. In this example, the ISP deploys the Content Engines in several network locations in a hierarchical fashion. A Content Engine (Content Engine A) is deployed at the ISP's main point of access to the Internet. All of the ISP points of presence (POPs) benefit, because requested content can be available at this main point of access without going through the Internet.

Figure 1-3 Typical ISP Deployment of Locally Managed Content Engines

Network caching offers the following benefits:

•Improved response time

•Conservation of network bandwidth

•Reduced cost

•Optimization of network resources

ACNS 5.1 software also allows administrators to control access to specific interfaces on these local Content Engines. For more information on this topic, see the "IP Packet Filtering and Access Control" section.

Content Overview

Content is the fundamental element of the ACNS network; it represents all the data that the ACNS network handles. Content can be a file or a media stream, and may be on-demand, preloaded, pre-positioned, or live.

Content Types

Content can be classified based on how the content is acquired, distributed, or served. Table 1-1 describes the different types of content that can be served in an ACNS 5.1 network.

Note The term "client" is used to refer to a device that is requesting content or information. For example, the end user who is using a browser to request information is referred to as a "web client" throughout this guide.

Table 1-2 Types of Content Served in an ACNS Network

Type of Content

Description

On-demand

Content that is acquired, cached, and delivered because of a user request (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.

Preloaded

Content that is retrieved and stored on an individual Content Engine because the administrator of that Content Engine scheduled a retrieval of specific content in anticipation of user requests for that content. Content Engines can be configured to preload specific content items using HTTP or FTP. Web sites are scanned several link levels down for content. Preloaded content can be configured with specified bandwidth limits for better control of network usage. For more information about preloading content on a locally deployed Content Engine, see the "Configuring Content Preloading" section.

Pre-positioned

Content that is retrieved and distributed through a network of centrally managed Content Engines because the ACNS network administrator has configured acquisition and distribution of content in anticipation of user requests. Used as a means of distributing content to populate Content Engines in a centrally managed ACNS network environment. Bandwidth-intensive content objects, such as Java applets, Macromedia Flash animations, Shockwave programs, and other file formats can be managed and scheduled for distribution to Content Engines during off-peak hours. For information about managing pre-positioned content, refer to the Cisco ACNS Software Deployment and Configuration Guide, Release 5.1.

Live

Content stream (typically streaming media) that is being broadcast from an origin server. (This content is acquired as a live streaming broadcast from either a satellite or a terrestrial broadcasting source.) The ACNS network 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.

Tip Pre-positioned content is associated with a centrally managed ACNS network environment, whereas cache preloading is configured on a Content Engine-by-Content Engine basis and is not generally associated with a centrally managed ACNS network.

Content Distribution

Table 1-3 describes the different types of distribution that can be used to serve content in an ACNS 5.1 network.

Table 1-3 Types of Content Distribution in an ACNS Network

Type of Content Distribution

Description

Pull

The Content Engine retrieves (pulls) the requested content from the remote origin server because it does not have the requested content stored in its local cache.

This pull distribution method is used when the Content Engine is operating in transparent, proxy, or reverse-proxy mode and the requested content is not in its local cache (a cache miss). The Content Engine retrieves the requested content from the origin web server, stores it in its local cache, and then serves it to the end user (web client) who requested the content. When future user requests are made for this content, the Content Engine serves the content to end users (web clients) from its local cache rather than retrieving it again from the origin web server.

Preloaded

Content is preloaded on an individual Content Engine because the administrator of that Content Engine scheduled a retrieval in anticipation of user requests for that content.

Pre-positioned

Content is retrieved and distributed through a network of centrally managed Content Engines because the ACNS network administrator has configured acquisition and distribution of content in anticipation of user requests.

Content Services

The ACNS 5.1 network combines two types of content services into a single software base. Table 1-4 describes these two types of content services.

Table 1-4 Types of Content Services in an ACNS Network

Type of Content Service

Description

Content pre-positioning

The administrator can specify that a group of content objects should be "pushed" to Content Engines at a specific time in anticipation of user requests. For example, the administrator can specify that a group of streaming objects is to be pushed to the Content Engines at the remote branch offices in off-peak times (night time). For information about pre-positioning content in a centrally managed ACNS network, refer to the Cisco ACNS Software Deployment and Configuration Guide, Release 5.1.

Content caching with filtering and access control

Content caching is the saving and storing of information locally. Copies of recently requested content are stored temporarily on a Content Engine in locations topologically closer to the web client (the end user who is requesting the content). The content is readily available to be reused for subsequent client requests for the same content. Content Engines that have ACNS 5.x software installed also support content caching with filtering and access control.

For more information on this topic, see the "Content Caching Service with Filtering and Access Control" section.

Cisco ACNS software allows content services to be managed through the following interfaces:

•The Content Distribution Manager GUI for centrally managed ACNS networks, as described in the Cisco ACNS Software Deployment and Configuration Guide, Release 5.1

•The Content Engine GUI or CLI for locally deployed Content Engines, as described in this guide.

Note For complete syntax and usage information for the CLI commands used in this guide, refer to the Cisco ACNS Software Command Reference, Release 5.1.

Content Caching Service with Filtering and Access Control

Nothing is more frustrating to Internet users than waiting for a web page to load in their browser. A number of factors contribute to slow delivery of web content, including Internet congestion, web server overload, and slow-speed WAN access lines. One cost-effective solution to reduce slow web access and latency is to "push" content out to the edges of the Internet and closer to the end users.

The combination of Cisco's Content Engines and WCCP-enabled routers delivers a powerful solution for accelerating content delivery and optimizing WAN bandwidth usage by pushing content to the edges of a network. The mechanism used to accomplish is called content caching. Content caching is also referred to as "network caching".

Because of its special position as an "in-line" device between the end user (web clients) and the Internet, Content Engines can be easily configured for network caching. Bandwidth usage and web latency is significantly reduced because frequently accessed Internet content is being locally cached and served by the Content Engine at each location. See Figure 1-4.

Figure 1-4 Benefits of Network Caching

Network caching offers the following benefits to enterprises and service providers:

•Improved response time

•Reduced Internet congestion

•Conservation of network bandwidth

•Optimization of network resources

Tip Objects are cached, not pages. For more information on this topic, see the "Cacheable Content" section.

Content Engines can be configured to provide network caching with filtering and access control.

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 performs the following tasks:

•Authenticates the web 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.

Note ACNS 5.1 software relies on third-party software to implement content filtering. Supported filtering software includes Websense, N2H2, and SmartFilter.

•Compares content against configured rules, which might rewrite certain headers, redirect the request, or otherwise manipulate the request.

•Checks to see whether the requested content is already in its cache. If so, then the Content Engine serves the object directly, rather than from the origin web server, thus saving bandwidth to the Internet.

•If the requested content is not already in its 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.1 software supports Content Engine proxy functionality by supporting all web access protocols (including HTTP) and all streaming protocols.

As Figure 1-5 shows, both login and configuration privileges can be obtained from the Content Engine local database, or from either of the remote third-party databases (the TACACS+ database or the RADIUS database).

Figure 1-5 Authentication Databases and a Locally Deployed ACNS Content Engine

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.

Note For more information about configuring user authorization and authentication, see "Configuring Login Authentication and Authorization." For more information about the Rules Template and content filtering, see "Configuring the Rules Template," and "Configuring URL Filtering."

IP Packet Filtering and Access Control

Content Engines with ACNS 5.1 software installed also support IP packet filtering, which controls access to specific interfaces (services) on the Content Engine. Like routers and switches, the administrator wants to limit Telnet, SSH, and Content Engine GUI access to the IT source subnets. The administrator can configure IP access control lists (ACLs) that determine whether or not IP packets are allowed to cross specific interfaces on a Content Engine.

For example, an administrator can use IP ACLs to control access to content serving and management services on the Content Engine. As Figure 1-6 shows, the administrator has defined the following two distinct interfaces on the Content Engine to implement this access control feature:

•A public interface for content serving that all of the enterprise employees can access.

•Another interface (private interface) for management services (for example, Telnet, Secure Shell [SSH], Simple Network Management Protocol [SNMP], Hypertext Transfer Protocol Secure (HTTPS), and Trivial File Transfer Protocol [TFTP]) that only the enterprise IT staff can access.

Figure 1-6 IP Packet Filtering Access to Specific Interfaces on a Content Engine

Note IP ACLs are defined for individual devices only. ACLs cannot be managed globally across the ACNS network or through device groups.

For more information about configuring IP ACLs on a locally deployed Content Engine, see "Creating and Managing IP Access Control Lists."

Content Engine Local Deployment Scenarios

The Content Engine can be deployed as a locally managed ACNS network device in three basic configurations:

•Transparent Caching

•Nontransparent (Proxy) Caching

•Reverse Proxy Caching

Note For information about deploying a Content Engine as a centrally managed ACNS network device, refer to the Cisco ACNS Software Deployment and Configuration Guide, Release 5.1.

To integrate with existing proxy infrastructures, the Cisco ACNS software supports a number of proxy protocols, including FTP, HTTPS, HTTP 1.0, and HTTP 1.1. With the Rules Template feature, ACNS system administrators can establish proxy policies, providing control over how traffic is proxied.

The Cisco Content Engines can be deployed in front of a web site (reverse proxy) to transparently cache inbound requests for content, significantly reducing the traffic and TCP connection maintenance performed by origin web servers.

Transparent Caching

In transparent caching, the user is not aware of the presence of the Content Engine. The user (web client) requests content (web objects) directly from the source (origin web server) by entering the URL of the origin server in a browser. This request is intercepted by a WCCP-enabled router or a Layer 4 CCS switch.

By supporting WCCP Version 2 or by interoperating with Cisco Content Services Switch (CSS) 11000 series switches, a Content Engine can achieve a basic level of transparency that includes:

•Transparent receipt of content traffic

•Fault tolerance

•Scalable clustering

Note The Cisco CSS 11000 series switches are hereafter called the CSS switch.

For more information about these advanced transparent caching services, see the "Advanced Transparent Caching Features" section.

Transparent Caching Through a WCCP-Enabled Router

Figure 1-7 shows how transparent caching through a WCCP-enabled router and Content Engine works.

1. A user (web client) requests a web page from a browser.

2. The WCCP-enabled router analyzes the request, and based on the TCP destination port number, determines whether it should transparently redirect the request to the Content Engine.

3. If the request is transparently redirected to the Content Engine, the following occur:

a. If the Content Engine does not have the requested content, it sets up a separate TCP connection to the origin web server to retrieve the content.

b. The content returns to, and is stored on, the Content Engine.

4. The Content Engine sends the requested content to the web client. Upon subsequent requests for the same content, the Content Engine transparently fulfills the request from its local storage (cache).

Figure 1-7 Transparent Caching Through WCCP-Enabled Router

Tip WCCP can also handle asymmetric packet flows and always maintains a consistent mapping of web servers to caches regardless of the number of switches or routers used in a WCCP service group (up to 32 routers or switches communicating with up to 32 caches in a cluster).

Transparent Caching Through a CCS Switch

In transparent caching through a Layer 4 CSS switch, the user is unaware that the request made to an origin web server is redirected to the Content Engine by the CSS switch. The CSS switch can be configured to dynamically analyze the request and determine if the requested content is cacheable or not. If it is not cacheable, the CSS switch sends the request directly to the origin web server. If the requested content is cacheable, the CSS switch directs the request to the Content Engine. The Content Engine either returns the requested content if it has a local copy or sends a new request to the origin web server for the content.

The Content Engines are stocked with static data (that is, HTML, Audio Video Interleaved [AVI], Joint Photographic Experts Group [JPEG], or Graphics Interchange Format [GIF] files). Requests for cacheable content can be load-balanced over multiple Content Engines based on the URL. In a real-world scenario, they could also be balanced based on the domain name.

Figure 1-8 shows how transparent caching works through a CCS switch and Content Engine.

1. A user (web client) requests a web page from a browser.

2. The CCS switch analyzes the request, and determines whether the requested content is cacheable or not. If the requested content is cacheable, the CCS switch transparently redirects the request to a Content Engine.

Note If all the Content Engines are unavailable in a transparent cache configuration, the CSS switch allows all client requests to progress to the origin web servers.

3. If the Content Engine does not have the requested content, the following occur:

a. It sets up a separate TCP connection to the origin web server to retrieve the content.

b. The content returns to, and is stored on, the Content Engine.

4. The Content Engine sends the requested content to the web client. Upon subsequent requests for the same content, the Content Engine transparently fulfills the request from its local storage (cache).

Figure 1-8 Transparent Caching Network with the CSS 11000 Series Switch

Benefits of Transparent Cache Deployments

There are some significant advantages to deploying caches in transparent mode:

•No end user configuration—The end user does not have to point to the Content Engine.

•Fail-safe operation—Caches are automatically fault-tolerant and fail-safe. Any cache failure does not cause denial of service to the end user.

•Scalability—Cache service can be scaled by deploying multiple caches.

•Automatic bypass—Sites which depend on end user authentication or which fail to conform to HTTP standards will automatically bypass a transparent cache.

Note For more information about transparent caching, see "Transparent Caching."

Nontransparent Caching

In nontransparent (proxy-style) caching, the user (web client) specifically sends all requests to the Content Engine, which acts as a proxy for the web client.

Figure 1-9 shows how the Content Engine caches content in proxy mode.

1. A user (web client) requests a web page from a browser.

2. If the Content Engine does not have the requested content (cache miss) the following occur:

a. It sets up a connection to the origin web server to retrieve the content.

b. The content returns to, and is stored on, the Content Engine.

3. The Content Engine sends the content to the user.

4. Upon subsequent requests for the same content by the same user or a different user, the Content Engine transparently fulfills the request from its local storage (cache hit).

Figure 1-9 Web Caching with the Content Engine in Proxy Mode

Tip In nontransparent caching, the web client must be explicitly configured to point to the Content Engine. When you have multiple Content Engines that support many clients, you can use a .pac file to configure all of your browser clients. For more information about how to use a single .pac file to configure all browsers in any organization, see the "Configuring Browser Autoconfiguration" section.

For more information on nontransparent (proxy-style) caching, see the "Proxy Mode Operation" section.

Benefits of Nontransparent Caching Deployments

In nontransparent (explicit proxy) deployments, the Content Engine acts as a proxy cache that proxies requests on behalf of the user population. In these types of deployments, the Content Engine functions as a network gateway device that has been optimized to retrieve and store web pages on behalf of a user (client) population.

Because the Content Engine is the destination of all browser-initiated requests for content, all user Internet connection requests must meet the policy guidelines before users can retrieve the content from the Internet.

There are some significant advantages to deploying the Content Engine in nontransparent (explicit proxy) mode:

•Internet access can be regulated because the proxy is a gateway device.

•Internet requests all appear to be sourced from the proxy cache (Content Engine), thereby hiding internal network addressing.

•Frequently requested cacheable content is cached.

Note For more information about deploying the Content Engine as a proxy caching engine, see "Proxy-Style Caching."

Reverse Proxy Caching

In reverse-proxy caching mode, the Content Engine acts as a proxy for the origin web server.

Figure 1-10 shows how the Content Engine caches content in reverse proxy mode.

1. A user (web client) requests a web page from a browser.

2. A WCCP-enabled router intercepts the request and forwards it to a Content Engine.

3. If the Content Engine does not have the requested content (cache miss), it sets up a connection to the origin web server to retrieve the content.

4. A Content Engine at the content provider site, acting as reverse proxy for the origin web server, tries to deliver the requested content.

5. If the Content Engine in reverse proxy mode does not have the content, it sets up a connection to the origin web server to retrieve the original content requested.

6. The content returns to, and is stored on, the Content Engine at the enterprise.

7. The Content Engine at the enterprise sends the content to the web client.

Upon subsequent requests for the same content by the same user or a different user, the Content Engine transparently fulfills the request from its local storage (cache hit).

Figure 1-10 Content Engine in Reverse Proxy Mode

Note For more information about reverse proxy caching, see the "Reverse Proxy Caching Overview" section.

Benefits of Reverse Proxy Deployments

In reverse proxy deployments, the Content Engine accelerates web server performance by offloading common or static pages from the origin web server. Users requesting objects from the origin web server receive the static pages from the Content Engine acting in reverse proxy mode rather than from the origin web server.

There are some significant advantages to deploying the Content Engine in reverse proxy mode:

•It provides an alternative to web server expansion.

•It provides a possible way of replicating content to geographically dispersed areas by deploying Content Engines in these areas.

Note For more information about deploying the Content Engine as a reverse proxy caching engine, see "Reverse Proxy Caching."