The following sections describe the basics of provisioning a Cisco ECDS network and how metadata and content flow through the Cisco ECDS:
•Provisioning the Cisco ECDS
•Cisco ECDS Topology
•HTTP and HTTPS Support
•Where to Go Next
Note To achieve the best throughput, we recommend you configure a port channel for the two gigabit Ethernet interfaces on the SE.
Provisioning the Cisco ECDS
Provisioning the Cisco ECDS consists of two main tasks.
Register the devices to the Cisco Enterprise Content Delivery System Manager (Cisco CDSM) and define the network topology and device groups.
Configure the delivery services that deliver content to the clients.
Cisco ECDS Topology
In the Cisco ECDS Service Engines are grouped together into locations, and a set of locations is then organized into the form of a tree, called a "Location Tree." The Location Tree represents the network topology configuration that is based on parent-child relationships. Locations are well connected and have similar connectivity properties to the outside world. A location generally implies topological proximity. Each location can have a parent relationship and multiple child relationships, such that each location can have zero to one parent locations and zero to many child locations. These relationships guide how content flows among locations but does not restrict content flow in any direction.
Locations are also classified into tiers. Each tier consists of locations belonging to the same tier. All locations with no parents belong to Tier 1. All locations that are children of Tier 1 locations belong to Tier 2.
The Cisco ECDS can consist of one or more topological Location Trees. A Cisco ECDS network is limited by the maximum depth of four tiers.
Figure 2-1 illustrates two location trees, with the parent-child relationship of each location indicated by a solid line and each tier indicated by a dotted line.
Figure 2-1 Location Trees Example
The Location Trees define preferred distribution routes. The Tier 1 locations are located closest to the WAN backbone. Tier 1 locations can communicate with all other Tier 1 locations.
Note The ECDS does not support network address translation (NAT) configuration, where one or more SEs are behind the NAT device or firewall. The workaround for this, if your ECDS network is behind a firewall, is to configure each internal and external IP address pair with the same IP address.
The ECDS does support clients that are behind a NAT device or firewall that have shared external IP addresses. In other words, there could be a firewall between the ECDS network and the client device. However, the NAT device or firewall must support RTP/RTSP.
Device groups offer a way to group similar devices and configure all the devices in a group at one time. Service Engines can be assigned to multiple device groups when the Device Group Overlap feature is enabled.
A device in a device group can have individual settings different from other devices in the group, and its settings can revert back to the group settings. The last configuration submitted for the device, whether group or individual, is the configuration the device uses.
In addition to group configuration and assignment, the CDSM allows the following:
•Hiding configuration pages of a device group
•Adding all newly activated devices to a device group
•Forcing device group settings onto all devices assigned to a group
A device can be assigned to a device group in one of two ways:
•From the Device Assignment page
•From the Device Group Assignment page
A baseline group denotes a group of devices for a particular service. There are three baseline groups:
•Web Baseline Group—Used for web-based content
•Video Baseline Group—Used for video content
•Platform Baseline Group—Used for platform-specific configurations
A device group can be configured as a baseline group. A device can be assigned to a baseline group in the following three ways:
•From the Devices home page
•From the Device Assignment page
•From the Device Group Assignment page
A delivery service is a configuration that defines how content is acquired, distributed, and stored in advance of a client request (prefetch), and after a client request (cached). Content from a single origin server is mapped to a set of Service Engines by a delivery service. Content objects associated with a specific delivery service have a common domain name; in other words, the content in a specified delivery service resides in a single location on an origin server. Each delivery service maps service routing domain names to origin servers one-to-one for Service Router DNS interception.
The CDSM is used to create the topology and configure the delivery services. All Service Engines and Service Routers that register with the CDSM are populated with the topology and the information about the configured delivery services.
The designated Content Acquirer is the only role which is administratively defined in the CDSM, all other roles, based on the topology and delivery service subscription, are assumed by the Service Engines automatically.
Both prefetched content and on-demand (dynamic and hybrid) content caching is supported. Different algorithms are used to elect the Service Engines for the various roles based on the type of content being distributed.
See the following sections for more information:
•Forwarder and Receiver Service Engines
•Persistent HTTP Connections
•Delivery Service Distribution Tree
•Types of Delivery Services
•Methods for Ingesting Content
For each delivery service, there is only one Content Acquirer but multiple Service Engines. The location that has the Content Acquirer for a delivery service is called the root location. Other Service Engines in the root location that are assigned to the same delivery service can act as backup Content Acquirers if the configured Content Acquirer fails.
Note The locations can be virtual. For example, a location can consist of the enterprise data center and the backup data center. The SEs in both the data center and the backup data center can be backup Content Acquirers for each other.
For Content Acquirer redundancy, a delivery service must have at least two SEs located in the root location. If the primary Content Acquirer fails or becomes overloaded, the SEs in the delivery service use the selected backup Content Acquirer (there could be several SEs assigned to the delivery service that are colocated at the root location).
See the following sections for more information:
•Content Acquirer Selection for Prefetched Content
•Content Acquirer Selection for Dynamic or Hybrid Ingest
Content Acquirer Selection for Prefetched Content
For prefetched content, the designated Content Acquirer always performs the content acquisition. Only in an event of a failure does another Service Engine in the same location assume the Content Acquirer role.
The selection algorithm runs in every Service Engine in the root location (also known as the Content Acquirer location). The algorithm always runs in context of a delivery service; that is, only the Service Engines subscribed to the same delivery service are considered in the selection.
Each Service Engine creates an ordered list of Service Engines belonging to the same location and subscribed to the same delivery service. In the root location, the designated Content Acquirer is always added as the first entry in the list.
At steady state when there are no failures, the designated Content Acquirer performs the content acquisition. Each Service Engine in the delivery service gets the content and metadata from the Content Acquirer by way of forwarder Service Engines and receiver Service Engines. Every Service Engine polls its forwarder Service Engine periodically for content and metadata. For more information, see the "Forwarder and Receiver Service Engines" section.
In the event that the Content Acquirer fails, the periodic polls for metadata fail causing the Service Engines to run the Content Acquirer election algorithm.
Each Service Engine creates the ordered list again. The list looks the same as the previous list, except that the Content Acquire which just failed is not considered in the election process. The Service Engine that appears second in the ordered list now assumes the role of the Content Acquirer.
Content Acquirer Selection for Dynamic or Hybrid Ingest
For on-demand content, which is dynamic or hybrid ingest, the designated Content Acquirer is only used to determine the location of where to acquire the content from the origin server directly. All of the Service Engines in the root location are eligible to acquire the content. The Service Engine selected to acquire the content is based on a URL hash. Content acquisition and storage is spread across multiple Service Engines.
The selection algorithm runs on every Service Engine in the root location (also known as the Content Acquirer location). The algorithm always runs in context of a delivery service; that is, only Service Engines subscribed to the same delivery service are considered in the selection.
Each Service Engine creates an ordered list of Service Engines belonging to the same location and subscribed to the same delivery service. This ordering is based on a index created by a URL hashing function. At steady state when there are no failures, the Service Engine that appears first in the list performs the content acquisition.
In addition to the URL-based list ordering, the health and the load of the Service Engines are also considered in the selection. Service Engines that do not have the applicable protocol engine enabled, failed Service Engines, and Service Engines with load thresholds exceeded are eliminated from the selection process. If a Service Engine is eliminated from the list, the next Service Engine in the ordered list is used to acquire the content.
See the "Specifying Hybrid Ingest Content" section for more information.
All other locations (that is, non-root locations) in the delivery service have an SE designated as the location leader. The location leader is determined automatically by the CDSM. The other SEs act as backup location leaders in case the location leader fails. In the same location, different delivery services may have different SEs as their location leaders. The location leader gets the delivery service content from outside the location, while the other SEs in the location get the content from the location leader. This reduces the distribution traffic on low-bandwidth links, because the SEs in the same location are likely to be on the same LAN.
Use the show distribution forwarder-list and show distribution location location-leader-preference commands to see the location leader for a delivery service.
See the following sections for more information:
•Location Leader Selection for Prefetched Content
•Location Leader Selection for Live Streaming
•Location Leader Selection for Dynamic or Hybrid Content
Location Leader Selection for Prefetched Content
The location leader selection for prefetched content is based on the same algorithm that is used for the Content Acquirer backup selection for prefetched content, except that the Service Engines are ordered based on an internal ID assigned at the time of registering to the CDSM. The first Service Engine in the list is selected. In the root location, the designated Content Acquirer is always the location leader.
Location Leader Selection for Live Streaming
For live streaming, the location leader selection is based on the program URL hash and the service availability. Each program within a delivery service could have different location leaders. Depending on the URL hash and the number of SEs in the location, some SEs could be acting as the location leader for more than one program.
Location Leader Selection for Dynamic or Hybrid Content
For on-demand content, which is dynamic ingest or hybrid ingest, the location leader selection is based on the same algorithm that is used for the Content Acquirer selection for on-demand content, with the algorithm repeated for each location. This mechanism helps distribute the load, improve cache hits, and reduces redundant content (which contributes to storage scalability). The location leader selection is very similar to how a location leader is selected for live streaming content.
Forwarder and Receiver Service Engines
Content distribution flows from the Content Acquirer to the receiver Service Engine (SE) by way of store and forward. A receiver SE does not just go directly to the Content Acquirer for content. Rather, it finds out who its upstream SE (the forwarder SE) is and pulls the content from that forwarder. The forwarder SE in turn pulls the content from its own forwarder, which may be the Content Acquirer. All receiver SEs store the content on disk after they get the content. Each receiver SE selects a forwarder SE.
The store-and-forward process causes content to flow through a distribution tree constructed specifically for this delivery service and with all receiver SEs in the delivery service as nodes on the tree. If an SE does not belong to the delivery service, it does not appear on the tree.
Both the metadata about the content and content itself flow through the distribution tree. This tree is constructed by using the dynamic routing of the delivery service and is often a subtree of the overall ECDS topology.
Although the tree is global, the delivery service routing process is actually a per-SE local function that answers the question "who is my forwarder for this delivery service?"
The following criteria is used to select a forwarder:
•An SE is a forwarder for other SEs in its own location if it subscribes to the delivery service and it is the location leader for the delivery service.
•An SE in location A can be a forwarder for SEs from location B if it subscribes to the delivery service, location A is "closer" to the root location of the delivery service than location B, and there is no other location between location A and location B that has a receiver SE of the delivery service. When selecting a forwarder from other locations, a receiver SE uses a hash algorithm seeded with its own unique SE ID (assigned by the CDSM), to spread the load of multiple receivers equally to all eligible forwarders.
Note A "location leader" is always a per-delivery service and per-location concept, while a "forwarder" is always a per-delivery service and per-SE concept.
A receiver SE finds its forwarder by examining the series of locations on the topology "toward" the root location, following the parent-child relationship as described in the "Cisco ECDS Topology" section.
1. First, find a forwarder within the SE's own location. The location leader should be the forwarder. If the location leader is down, use the backup location leader as the forwarder.
2. If none is found or if the SE thinks it is the location leader, look for a forwarder in the next location "toward" the root location. If still none are found (for example., there is no SE at that location assigned to the delivery service or the potential ones are unreachable), then look further "toward" the root location, and so on. The recursion ends if a forwarder is found or the Content Acquirer's location is reached.
3. Multicast Forwarder: If the delivery service is marked "multicast enabled," the delivery service searches for a multicast forwarder. If it fails to find any reachable multicast forwarder, it searches again, this time, looking for unicast forwarders.
4. Content Acquirer failover: If the SE is unable to find a live forwarder (for example, there is a network or machine outage), the SE has to retry later, unless it is in the root location for the delivery service and is allowed to failover to the origin server directly and act as a backup Content Acquirer.
Note This process follows the search path provided by the overall topology that was configured for the ECDS. Using the combination of the overall topology configuration and the assignment of SEs to delivery services, the ECDS gives the administrator a lot of control over the form of the distribution tree, and yet still automates most of the selection and failover process.
Persistent HTTP Connections
HTTP connections are maintained among the SEs in a delivery service and the origin server as long as the connection idle period does not exceed the keepalive timeout period of 30 seconds or the idle period does not exceed the timeout period set on the origin server, whichever is the shorter period.
Persistent HTTP connections in a delivery service work in the following way:
1. Open new HTTP connection. The first time a request for cache-miss content is sent to an upstream device (SE or origin server), which is identified by the IP address of the device, a new HTTP connection is formed.
The Web Engine has 8 working threads, which are computing units. Each thread can have as many connections to as many upstream devices as required.
There are a maximum of 10 connections per upstream device (SE or origin server) that are persisted in the idle queue for reuse for each of the 8 working threads, which gives a total of 80 persistent connections.
2. Connection moved to idle queue. Once the content download is complete, the connection is moved to the idle queue.
3. Closing connections in idle queue. A 30-second keepalive timeout period is applied to each connection moved to the idle queue and if the idle time of a connection reaches the keepalive timeout period, it is closed. If a new request needs to be sent and there is a connection for the same server (IP address) in the idle queue, the connection is moved to the main connection list and used for that request.
A working thread uses an existing connection if the connection is idle; otherwise, a new connection is opened.
4. Open and close non-persistent connection. If a request for cache-miss content needs to be sent and there are no idle connections for that upstream device, a new connection is created. If, after the request is served, there already exists 10 connections for the upstream device in the idle queue, the connection is terminated.
5. Close 50 percent of connections in idle queue. If the origin server has a timeout period for HTTP connections, that is taken into consideration. The 30-second keepalive timeout is used for closing old HTTP connections. If the upstream SE or origin server has a shorter keepalive timeout period, that takes precedence over the downstream SEs 30-second keepalive timeout. If there are no keepalive timeout values set on the upstream devices (SEs or origin server), then every 30 seconds 50 percent of the persistent connections (maximum of 80 per origin server) are closed.
In the case of network partitions, there can be multiple Content Acquirers for a single delivery service, or multiple location leaders. There can be as many Content Acquirers as there are network partitions (that have backup Content Acquirers) in the root location. Once the partition incident is over in the root location, the system recovers and there is only one Content Acquirer again. There can be as many location leaders as there are partitions (that have subscriber SEs) in any location. Once the partition incident is over, the system recovers from it and there is one location leader again.
Delivery Service Distribution Tree
Delivery services form logical routes for content to travel from an origin server through the Content Acquirer to all the Service Engines in the delivery service. Logical routes for content distribution are based on the device location hierarchy or Location Tree.
The content distribution route follows the general tree structure of the Location Tree, where content is distributed from the root of the tree (Content Acquirer) to the branches (Service Engines associated with the delivery service). A delivery service distribution tree is constructed for each delivery service.
By excluding it from the Coverage Zone file, a Service Engine in a delivery service can be configured only to forward content and metadata, and not deliver the content to client devices.
Figure 2-2 shows an example of a delivery service distribution tree. The Service Engines participating in the delivery service are marked in red. Possible content and metadata routes are indicated by red lines. The actual route may differ among the participating Service Engines as determined by the Service Router routing method.
Figure 2-2 Delivery Service Distribution Tree Example
Types of Delivery Services
The Cisco ECDS supports two types of delivery services:
•Prefetch/Caching Delivery Services
•Live Delivery Service
Prefetch/Caching Delivery Services
For prefetch delivery services, called content delivery services in the CDSM, content is forwarded from Service Engine to Service Engine through the delivery service distribution tree until all Service Engines in the delivery service have received it. The delivery service distribution architecture provides unicast content replication using a hop-by-hop, store-and-forward methodology with the forwarder Service Engines systematically selected on the basis of the manually configured location hierarchy. For caching delivery services, the content need not be fully stored before forwarding.
Live Delivery Service
The live delivery services are only used for managed live stream splitting. The prefetch/caching delivery services are used for prefetch ingest, dynamic ingest, and hybrid ingest.
Methods for Ingesting Content
There are two methods that can be used to configure a delivery service:
•Specifying the content by using an externally hosted Manifest file.
•Specifying the content by using the Enterprise CDSM.
The Enterprise CDSM provides a user-friendly interface for adding content and configuring crawl tasks. All entries are validated and a Manifest file is generated. The Enterprise CDSM offers the most frequently used parameters, a subset of the Manifest parameters. For a complete set of parameters, use a Manifest file.
The following sections describe the main building blocks of a delivery service:
Content is stored on origin servers. Each delivery service is configured with one content origin. The same origin server can be used by multiple live delivery services. However, only one prefetch/caching delivery service is allowed per content origin. Each Content Origin is defined in the Enterprise CDSM by the following:
•Service routing domain name
The origin server is defined by the domain name that points to the actual origin server. The origin server domain name is used to fetch content that resides outside the delivery service, and to request redirection in case of a failure. The origin server must support at least one of the following protocols in order for the ECDS to be able to ingest content:
Content can also originate from a local file on the ECDS.
The service routing domain name is an FQDN and is used for content redirection. Each content that is ingested by the Manifest file is published using the service routing domain name. The service routing domain name configured for the Content Origin must also be configured in the DNS servers, so client requests can be redirected to a Service Router for request mediation and redirection.
When the Content Acquirer cannot directly access the origin server because the origin server is set up to allow access only by a specified proxy server, a proxy server can be configured. The proxy server is configured through the Enterprise CDSM for fetching the Manifest file, and through the Manifest file for fetching the content. Proxy configurations made in the Manifest file take precedence over proxy configurations in the CLI.
The Manifest file contains XML tags, subtags, and attributes used to define how content is ingested and delivered. Each delivery service has one Manifest file. The Manifest file can specify attributes for content playback and control. Attributes for specifying metadata only, without fetching the content, are supported. If special attributes are set, only the metadata and control information are propagated to the Service Engines. The control data is used to control the playback of the content when it gets cached by dynamic ingest. The Manifest file format and details are described in "Creating Manifest Files."
For HTTP, HTTPS, SMB, or CIFS, a single item can be fetched by specifying a single URL in the CDSM or Manifest file, or content can be fetched by using the crawler feature. The crawler feature methodically and automatically searches acceptable websites and makes a copy of the visited pages for later processing. The crawler starts with a list of URLs to visit, identifies every web link in the page, and adds every link to the list of URLs to visit. The process ends after one or more of the following conditions are met:
•Links have been followed to a specified depth.
•Maximum number of objects has been acquired.
•Maximum content size has been acquired.
The crawler works as follows:
1. The Content Acquirer requests the starting URL that was configured for the delivery service.
2. The crawler parses the HTML at that URL for links to other files.
3. If links to other files are found, the files are requested.
4. If those files are HTML files, they are also parsed for links to additional files.
In this manner, the Content Acquirer "crawls" through the origin server.
A website that has indexing enabled and the default document feature disabled generates HTML that contains a directory listing whenever a directory URL is given. That HTML contains links to the files in that directory. This indexing feature makes it very easy for the crawler to get a full listing of all the content in that directory. The crawler searches the folders rather than parsing the HTML file; therefore, directory indexing must be enabled and the directory cannot contain index.html, default.html, or home.html files.
Content ingest from an SMB server for crawl jobs crawls the folder hierarchy rather than parsing the HTML file.
The Content Acquirer parses the Manifest file configured for the delivery service and generates the metadata. If the hybrid ingest attributes are not specified, the Content Acquirer ingests the content after generating the metadata. The Content Acquirer can be shared among many delivery services; in other words, the same Service Engine can perform the Content Acquirer role for another delivery service.
The ECDS supports file acquisition from Windows file servers with shared folders and UNIX servers running the SMB protocol. The Content Acquirer first mounts the share folder. This mount point then acts as the origin server from which the content is fetched. The Content Acquirer fetches the content and stores it locally.
Note With SMB, files greater than two gigabytes cannot be ingested.
The no-cache directive in an HTTP(S) server response header tells the client that the content requested is not cacheable. When an HTTP(S) server responds with a no-cache directive, the Content Acquirer behaves as follows:
•If the content to be ingested is specified in an <item> tag in the Manifest file, the Content Acquirer ignores the no-cache directive and fetches the content anyway.
•If the content to be acquired is specified in a <crawler> tag in the Manifest file, the Content Acquirer honors the directive and does not fetch the content.
The Media Streamer application on the Service Engine participates in the delivery service by distributing content within the ECDS and delivering content to the clients. The Service Engines can be shared among other delivery services.
In some instances, for example when there are contractual obligations to prevent clients from downloading content, it may be necessary to disable HTTP(S) downloads on a delivery service. When HTTP(S) download is disabled, the Web Engine returns a 403 forbidden message. For configuration information, see the "Creating Delivery Service" section.
The following diagrams describe ECDS content workflows:
•Content Request Using the Service Router
•Content Request Using WCCP
Content Request Using the Service Router
Figure 2-3 shows the delivery service workflow.
Figure 2-3 Delivery Service Workflow Acquisition and Playback Diagram
Service Workflow Example Details
1. The topology is propagated to all the devices registered and activated in the Enterprise CDSM. The delivery service configuration is propagated to all the Service Engines subscribed to the delivery service. The Manifest file information is sent to the Content Acquirer for the delivery service.
2. The Content Acquirer parses the Manifest file and generates the metadata. All content listed in the Manifest file, except for non-cache content types, is fetched.
3. The Content Acquirer propagates the metadata to all other Service Engines.
4. The Service Engines receive the metadata and associated prefetched content. The Service Engines do not prefetch content that is "wmt-live" or "cache" types. The "wmt-live" type corresponds to the Windows Media live streaming and the "cache" type corresponds to the hybrid ingest content.
5. The client request for a URL first performs a DNS resolution. The Service Router is configured as the authoritative DNS server for the hosted, or service routing, domain. The URLs that are published to the users have the service routing domain names as the prefix.
6. The Service Router resolves the service routing domain name to its own IP address.
7. The client sends the request to the Service Router and the Service Router uses its routing method to determine the best Service Engine to stream the requested content.
8. The Service Router redirects the client to the best Service Engine.
9. The client sends the request to the Service Engine.
The following are the possible scenarios after the request reaches the Service Engine:
Flow 10, "Pre-ingested response."
The content is prefetched using the URL: http://www.ivs-example.com/video/wmv-152
The actual user request is: http://cr-video.example.com/video/wmv-152
The Service Engine processes the user request, and based on the metadata, determines the content was prefetched and pinned in its local storage. The Service Engine looks up the policies for the content and streams the content to the user.
•Dynamic Ingest/Cached Content
Flows 10, 11, 12, "Non-ingested contents—Hierarchical cache resolution," "Native Protocol Response," and "Dynamic ingest response."
If the request for content is not specified in the Manifest file, dynamic ingest is used.
The user request is: http://cr-video.example.com/video/wmv-cached.wmv
The Service Engines in the delivery service form a hierarchy, pull the content into the ECDS, and cache it. The Service Engine streams the content to the user.
•Hybrid Ingest/Metadata Only Content
(no content flow)
The request for content is specified in the Manifest file as "cache."
The user request is: http://cr-video.example.com/video/wmv-59
The Service Engine fetches the content, similar to the dynamic ingest method, but the metadata attributes (for example, serveStartTime, serveStopTime) are honored by the Service Engines and the content is served only if the request falls within the defined time interval.
Table 2-1 shows sample values for the delivery service workflow described in Figure 2-3.
Table 2-1 Delivery Service Parameters Example
Service Routing Domain Name
Delivery Service Contents
http://www.ivs-example.com/video/wmv-59 type= "cache"
http://www.ivs.example.com/video/wmv-6 type= "cache"
Content Request Using WCCP
Figure 2-4 describes the typical WCCP content workflow.
Figure 2-4 WCCP Workflow
WCCP configuration settings for the Service Engine are managed with the CDSM graphical user interface (GUI) beginning in ECDS Release 2.5.5. Access SE request routing administration by choosing:
Devices > Request Routing > WCCP
See the following sections for information about WCCP services:
•WCCP Service Negotiation
•WCCP Service Groups
•Dynamic WCCP Redirection Services
•WCCP Custom Web Cache Service
WCCP Service Negotiation
The Administrator creates a WCCP service on the cache engine (Streaming Engine, or SE) and assigns a router to the created service. The SE sends a "HERE_I_AM" message to the router. The router replies with the "I_SEE_YOU" message. Each of the messages contain enough information for the routers and the service engines to be aware of the router list, service engine list, service IDs, and so on.
Note These messages are also a form of KeepALive message. If the continuous message stream is lost for an amount of time longer than the preset threshold, the service is automatically removed from the service group.
WCCP Service Groups
WCCP uses the concept of a service group to define caching related services for a WCCP-enabled router and WCCP-enabled Service Engines in a cluster. Service groups are identified by a service group number. Each WCCP service group number specifies a router list, single port list (containing up to eight ports), application type, hash parameters, password, and weight (for load balancing).
Table 2-2 lists the service group numbers and describes the services supported by a WCCP-enabled router. For more information, see the "Configuring WCCP General Settings" section.
Table 2-2 WCCP Service Groups
Dynamic Service (user-configurable)
A WCCP-enabled Service Engine supports various Internet protocols depending on the style of the request URL. If the WCCP-enabled Service Engine receives a server-style URL, only HTTP(S) and RTSP protocols are supported (if the RTSP user agent criteria is met). If the WCCP-enabled Service Engine receives a proxy-style URL, the HTTP(S) and RTSP protocols are supported, as long as the respective proxy services are configured on the Service Engine. Proxy-style request URLs include the protocol and host name, whereas server-style request URLs do not. The RTSP protocol is supported for both server-style and proxy-style requests.
For proxy-style requests, the Service Engine supports up to eight incoming ports each for HTTP, MMS, and RTSP proxy modes. The incoming proxy ports can be the same ports that are used by transparent mode services. The incoming proxy ports can be changed without stopping any WCCP services running on the Service Engine or on other Service Engines in the Service Engine farm.
The Service Engine WCCP implementation currently allows global settings that apply to all WCCP services, such as healing parameters, slow start, and others. The multiple service model does not change that, and the settings in question remain global for the whole WCCP system. (See the "Configuring WCCP General Settings" section.)
Dynamic WCCP Redirection Services
You can configure the Service Engines to handle up to eight user-configurable or dynamic WCCP redirection services (service group numbers 90 to 97) on a Service Engine, provided that the services are also configured on the router.
With 8 dynamic services using a maximum number of 8 ports each, the maximum number of ports that can be specified for transparent redirection is 64.
WCCP Custom Web Cache Service
Custom web cache service (service number 98) causes the Service Engine to establish WCCP Version 2 redirection services automatically with a Cisco router on a user-specified port number. The Service Engine then performs transparent web caching for all HTTP requests over that port while port 80 transparent web caching continues without interruption. For custom web caching, service 98 must be enabled on the routers.
Transparent caching on ports other than port 80 can be performed by the Service Engine when WCCP is not enabled or when client browsers have previously been configured to use a legacy proxy server. The following features combine to support WCCP transparent caching:
•WCCP Load Balancing- Source and Destination IP Hash
•WCCP Availability Monitoring
•Multiple Router/Multiple Service Engine Support
•Additional WCCP Support
The service group servers monitor interfaces based on interception configuration criteria to identify traffic to be redirected to a service group client:
•Ingress redirection (inbound): When applied to an interface, the router monitors traffic entering an interface to see if it matches criteria for any of the running service groups.
•Egress redirection (outbound): When applied to an interface, the router monitors traffic leaving an interface to see if it matches criteria for any of the running service groups.
WCCP Version 2 tells the network which packets to redirect to the SE. Service group servers (routers) can use one of two methods to redirect traffic to an SE:
•GRE—This is the most commonly use method. The entire packet is encapsulated into a new IP packet that is destined for the SE.
•Layer 2 redirect—Less frequently used, but common with LAN switches. The original frame header is rewritten with the SE MAC address as destination and then forwarded to the SE.
WCCP Load Balancing- Source and Destination IP Hash
Routers and cache engines become aware of each other and form a service group using the WCCP management protocol. Once the service group has been established, one of the cache engines is designated to determine load assignments among the cache engines.
If there is a group of cache engines, the one seen by all routers and that has the lowest IP address becomes the lead cache engine. The role of this cache engine is to determine how traffic should be split across cache engines. The assignment information is passed to the entire service group from the designated cache engine so that the routers of the group can redirect the packets properly and the cache engines of the group can manage their load better.
WCCP Version 2 allows for load balancing based on a number of parameters, including source information (IP address, subnet, port) or destination information (IP address, subnet, port).
With the hash assignment method, the hash parameters specify how traffic should be load balanced among the different service groups. Specifically, hashing maps items from one item set to another, such as mapping destination IP addresses or destination ports to different Service Engines in a service group from the WCCP-enabled router for load-balancing purposes. Only one load-balancing method can be used per Service Engine farm.
See the following sections for more information about load balancing:
For more information, see the "Load Balancing Command Examples" section.
The default assignment method, hash assignment, uses a 256-bucket redirection hash table to distribute traffic across the WCCP clients in a service group. As a WCCP server intercepts traffic, the source/destination IP address or source/destination port (depending on the service group configuration) is run through a hash function to produce an index value. The index value maps into one of the 256 buckets in the hash table. Each bucket in the hash table is assigned to a WCCP client in the service group.
Note Web-cache service does not get a hash assignment.
For more information, see the "Hash Assignment Command Example" section.
Mask assignment uses masks and a table of values to distribute traffic across the WCCP clients in a service group. Mask assignment was developed specifically for the Cisco Catalyst series switches, and is one of the key characteristics that enables WCCP interception to be performed completely in hardware on these platforms. As the WCCP server intercepts traffic, a bitwise AND operation is performed between each mask value and the contents of the packet (specifically the source/destination IP addresses and ports). The result is then compared to a list of values for each mask. Each value is assigned to a specific WCCP client in the service group. The following figure shows the masking and value assignment concept.
Weight assignment is used when one SE is determined to have better hardware performance than another and you would like to shed more buckets to the better performing SE. Once the buckets have been shed to the better performing SE, the router redirects the traffic as usual using the appropriate assignment method.
For more information, see the "Weight Assignment Command Example" section.
WCCP Availability Monitoring
WCCP Version 2 keepalive (heartbeat) information is exchanged every 10 seconds between SEs and the router. If an SE is unresponsive for three consecutive heartbeats, it is removed from the service group.
WCCP Version 2 heartbeat uses UDP port 2048.
If a SE within a service group fails, the portion of the load that it was handling is automatically distributed to other SE within the service group. If no additional SEs are available, the service group is taken offline and packets are not redirected.
Multiple Router/Multiple Service Engine Support
With WCCP Version 2, multiple routers can service a cluster, creating contention between available routers to obtain status as the device that redirects packets for data coming from each of the cache engines in the cluster. A maximum of 32 routers together with 32 Service Engines are supported in any one WCCP Service Group, which increases the service capability and adds greater bandwidth. For configuration information, see the "Managing WCCP Router Lists" section.
WCCP single Service Engine deployment is also supported; one SE and one router can be deployed in the WCCP network.
Additional WCCP Support
The following features introduced for the Cisco ECDS with WCCP are listed alphabetically:
•TCP Flow Protection
•WCCP Service Negotiation
•Dynamic Service and Port List
•WCCP Transparent Routing Bypass Options
TCP Flow Protection
TCP flows are protected when a Service Engine is added to or removed from a service group. Because all buckets are re-allocated, there is a chance that some buckets might be assigned to the new Service Engine when a new service engine is added to the service group. In that case, TCP traffic belonging to that bucket will be broken. Flow protection is a mechanism on the new service engine to forward that broken TCP flow back to its original service engine, keeping TCP flow intact.
WCCP TCP flow protection is managed by the wccp flow-redirect enable command. See the "Load Balancing Command Examples" section for configuration information.
The following sections describe how TCP flow is managed:
•Graceful (Clean) Shutdown
Graceful (Clean) Shutdown
To prevent broken TCP connections after a reload, version change or enabling or disabling WCCP, the Service Engine performs a clean shutdown before you begin the reload. The Service Engine does not reboot until all connections have been serviced or the configured maximum wait interval has elapsed.
During a clean shutdown, the Service Engine continues to service the flows it is handling but starts to bypass new flows. When the number of flows goes down to zero, the Service Engine takes itself out of the cluster by having its buckets reassigned to other Service Engines by the lead Service Engine. TCP connections can still be broken if the Service Engine crashes or is rebooted without WCCP being cleanly shut down. The clean shutdown can be aborted while in progress.
Tip You must first configure WCCP General Settings before you can use this feature. See the "Configuring WCCP General Settings" section.
Graceful shutdown is managed by the no wccp version 2 command. For more information, see the "Load Balancing Command Examples" section.
In some cases you may want to bring an SE online or remove it from a service group to ensures that no existing flows are broken. This action:
•Allows preexisting TCP flows to continue.
•Allows existing flows serviced by preexisting SEs in the cluster continue to receive flows when an SE is added to the group.
Flow redirection is managed by the wccp flow-redirect command. See the "Load Balancing Command Examples" section for configuration information.
Within a cluster of Service Engines, TCP connections are redirected to other Service Engines as units are added or removed. A Service Engine can be overloaded if it is reassigned new traffic too quickly or if it is introduced abruptly into a fat pipe. To prevent a Service Engine from being overwhelmed when it comes online or is reassigned new traffic, enable the slow start provides the following:
•TCP flow protection when WCCP Version 2 is enabled and a Service Engine is introduced into the cluster.
•TCP flow protection when WCCP Version 2 is disabled and a Service Engine is leaving the cluster.
•Load assignment to the Service Engine in slow increments rather than a full load at boot up.
Slow start is applicable only in the following situations:
•During initial boot up when there is no Service Engine present in the server farm.
•When a new Service Engine is added to a cluster that is not handling the full load; for example, when there are some buckets that are being shed by the cluster.
In all other cases slow start is not necessary and all the Service Engines can be assigned their share of traffic right away. Slow start is managed by the wccp slow-start command. See the "Configuring WCCP General Settings" section.
Dynamic Service and Port List
Dynamic service in WCCP provides wider port choices for more applications. The typical setup involves the non-standard port of applications running on the origin server, but you can use any port. The setup works as follows:
1. The administrator uses the dynamic service number provided on the WCCP configuration to associate with a port-list number.
2. The service engine uses the configured dynamic service number to allow WCCP service.
3. The WCCP router treats the dynamic service as usual and redirects the packet.
WCCP Transparent Routing Bypass Options
One of the fundamental principles of transparent network request redirection is that the Service Engine must remain transparent to the end user at all times. A transparent caching solution in a network environment must not introduce any possible failure conditions or side effects in the network.
The Cisco ECDS transparent caching solution uses a WCCP-enabled router and various advanced techniques to ensure that the Service Engine remains transparent, even if web browsers are nonoperational or web servers are not HTTP-compliant.
If a Service Engine becomes overwhelmed with traffic, it can use the overload bypass feature to reroute the overload traffic. When the Service Engine is overloaded and the bypass load command is enabled, the Service Engine refuses additional requests and forwards them to the origin servers. If the load remains too high, more traffic is bypassed to the servers, and so on until the Service Engine can handle the load. The time interval between one bucket being bypassed and the next is set by the out-interval option. The default is 4 seconds. See
Figure 2-5 Overload Bypass
When the first bucket bypass occurs, a set interval must elapse before the Service Engine begins to resume service to the bypassed buckets. When the Service Engine begins to serve bypassed traffic again, it means that the overload timer has timed out. Once bypass load is enabled, whenever the system CPU and memory usage has exceeded its threshold, bypass is triggered. The Service Engine stops the bypass process and begins service again when the configured time interval has been reached. Time interval default is 5 minutes.
Bypass and time interval are managed by the following commands:
bypass load time-interval 5 (minutes)
See the "Configuring WCCP Transparent Routing Bypass Settings" section for more information.
HTTP and HTTPS Support
See the following sections for HTTP and HTTPS support with ECDS:
•Web Engine HTTP Connections
•IP Spoofing for HTTP
Web Engine HTTP Connections
To access HTTP Connections in the ECDS GUI, choose Devices > Application Control > Web > HTTP > HTTP Connections. For more information, see the "Configuring Web Engine HTTP Connections" section.
The Outgoing HTTP Proxy Bypass Domains option in the ECDS GUI allows a Service Engine to skip some connections based on source and destination IP addresses. The SE will not forward packets being sent to these domains to the Outgoing Proxy. This feature is activated when you select the Enable Outgoing Proxy check box. You can create an outgoing proxy bypass list with up to 32 space-separated entries.
For more information, see "Configuring the Outgoing Proxy Bypass List" section.
IP Spoofing for HTTP
IP Spoofing enabled on a WCCP v2 router allows the Service Engine to send and receive packets with the client IP (which is different from the Service Engine IP address), and then sends the packets to the waiting application. The router intercepts the packets from both the client and the server transparently, and forwards these redirected packets to the same Service Engine so that the TCP connection is not broken.
With typical transparent caching, an end user issues an HTTP request from a web browser. This request is transparently intercepted and sent to the Service Engine (acting as a transparent proxy server) by a WCCP router (Figure 2-6).
Figure 2-6 IP Spoofing Intercept and Redirect
The Service Engine accepts the incoming TCP connection from the WCCP router, determines that the request is for an object not in storage (cache miss), and issues a request to the origin server for the requested object. When the Service Engine contacts the origin server, it uses its own IP address instead of the client IP address for which it is making the request.
If IP spoofing is configured on the WCCP Version 2-enabled routers and the Service Engines, the Service Engine (acting as a transparent proxy server) can send out the client's IP address to the origin server for authentication purposes instead of sending out the request with its own IP address. The WCCP router intercepts packets from the server that are destined for the client's IP address, and redirect these packets to the Service Engine to maintain TCP flow integrity.
By spoofing a client's IP address, the following capabilities are supported:
•The Service Engine can send out packets with the client IP (which is different from the Service Engine's own IP address).
•The Service Engine can receive packets with the client IP (which is again different from the Service Engine's own IP address), and send the packet to the correct application that is waiting for the packet.
•The WCCP Version 2-enabled router can intercept the packets from both the client and the server transparently, and forward these redirected packets to the same Service Engine so that the TCP connection is not broken.
When configured for IP spoofing, the Service Engine connects to the origin server using the client IP address instead of its own IP address. At this point, the router cannot identify requests coming from the Service Engine because the source IP address of the request is not that of Service Engine.
IP Spoofing is available only when WCCP is enabled.
1. See the "Configuring WCCP General Settings" section to enable WCCP in the ECDS GUI.
2. See the "Configuring HTTP IP Spoofing with WCCP" section to enable IP Spoofing in the ECDS GUI
WCCP Version 2 supports transparent HTTPS redirection for ECDS deployments. Access Service Engine HTTPS administration by choosing:
Devices > Application Control > Web > HTTPS
The following are general features that support HTTPS caching:
•Transparent HTTPS Caching Using SSL
•HTTPS Service Rules
•HTTPS Requests on Ports
•HTTPS Connection Statistics
•HTTPS Protocol Protection
Transparent HTTPS Caching Using SSL
Transparent HTTPS caching using SSL works as follows:
1. The Service Engine, configured as an HTTPS server, receives an HTTPS request redirected through a WCCP-enabled router.
2. The Service Engine sends back an SSL certificate (obtained from the origin server) to the requesting client to negotiate an SSL connection.
3. The client sends HTTPS requests inside the negotiated SSL connection.
4. The Service Engine examines the request, looks in its cache, and performs normal HTTP request processing.
5. If the Service Engine can fulfill the request from its local storage (cache hit), it sends the requested content back using the SSL connection.
6. If the Service Engine cannot fulfill the request from its local storage (cache miss), it initiates a connection to the origin server to retrieve the requested content through the SSL connection.
7. The Service Engine caches the requested content (if possible) and also sends a copy to the requesting client through the negotiated SSL connection.
For the SSL-termination feature to work properly, you must install the SSL certificate and private key of the origin HTTPS servers on the Service Engine. The SSL-termination feature works in transparent mode if the Service Engine has the correct certificates and private keys installed. For specific requested content to be cached, you must import the proper certificates and keys for these origin HTTPS servers into the Service Engine and configure the Service Engine to cache content from these origin HTTPS servers. See the "Configuring HTTPS Certificates" section for more information.
HTTPS prepositioned caching and HTTPS dynamically cached content is supported through self-signed certificates with keys that are generated outside the Service Engine and imported to the SE.
A digital certificate is a credential that allows the Service Engine to be presented to an HTTPS client as the origin HTTPS server, enabling encrypted communication and secure identification of a network webserver.
The Service Engine accepts certificates in Privacy-Enhanced Mail (PEM) format, which is used by Apache servers. The Service Engine uses PEM format internally, and automatically converts certificates in PKCS #12 format to PEM format. If you need to use a certificate in a different format, first convert it to one of these supported formats.
See the "Configuring HTTPS" section.
HTTPS Service Rules
You can specify a set of rules using the Rules Template licensed feature for HTTPS; Service Rule functions that apply to HTTP also apply to HTTPS. See the "Configuring Service Rules" section.
HTTPS Requests on Ports
The Service Engine provides configurable options to receive HTTPS requests on ports other than 443, which is the default. See the "Configuring HTTPS" section.
HTTPS Connection Statistics
New CLI commands and CDSM statistics tools are available to monitor connections per domain.
•WCCP status show command:
•Updated logging retrieval—Access logs by entering the following on the SE:
HTTPS Protocol Protection
The Service Engine provides an option to reject access to file objects if requesting protocol is anything other than HTTPS
Transparent Proxy Support for HTTPS (Live and VoD)
The Service Engine provides an option to receive HTTPS requests as a proxy and send requests to the HTTPS origin via separate outgoing proxy for dynamic caching. See "Configuring Primary and Backup Proxy Servers."
A Cisco ECDS program is a scheduled live or rebroadcast event that streams content to client devices. The ECDS streams live or rebroadcast content by using the Movie Streamer, Windows Media Streaming, or Flash Media Streaming Engine.
Movie Streamer live and rebroadcast programs can have multiple tracks (1-3 tracks).
See the following sections for supported programs:
•API Program File
Live events are streamed from third-party encoders (such as Windows Media Encoder Version 9 or the QuickTime encoder) or from streaming servers (such as Windows Media Server). The live stream is ingested by the Content Acquirer and transmitted to all Service Engines using either unicast or multicast. The live stream is transmitted to end users by using either multicast or multicast/unicast live splitting. The live stream is only available to end users during its scheduled times.
With live stream splitting, administrators do not have to create scheduled multicast events, because the Service Engines automatically split the stream.
Unicast to multicast streaming is a solution similar to live stream splitting, except that in the final delivery segment the stream is converted to multicast to minimize the bandwidth demand on the ECDS network and to minimize the load on the Service Engines.
Each live program can have up to ten different playtimes scheduled. The program is broadcast from all Service Engines simultaneously.
In a scheduled rebroadcast, prefetched content is scheduled to be streamed from the Service Engines using multicast. Content can only be selected from one delivery service. The Service Engines and device groups assigned to the delivery service are automatically selected when the content files are chosen for the program.
API Program File
Programs can be defined through the Enterprise CDSM or through an API. Programs created through APIs are based on a program file. A program file is an XML file that resides on an external server and contains the elements that define the schedule, content, and presentation parameters. The Enterprise CDSM gets the program file, parses it, and saves the program file to the database. The program is automatically updated at intervals by refetching the program file and reparsing it. RTSP is the only protocol supported in the program file.
Programs created using an API can be viewed in the Enterprise CDSM as read-only, and modifications to the API programs can be accomplished through the API. The API program can also be edited using the Enterprise CDSM; however, the information about the API program file is deleted and the program can no longer be modified through the API. A third option is to copy the API program using the Copy Program feature.
Where to Go Next
Proceed to Chapter 3 "Getting Started" to learn about initial device configuration, logging into and navigating the Cisco ECDS, and to see n examples of a typical ECDS configuration workflow.