Cache Redirection Methods
20.6 Cache Redirection Methods
We've discussed techniques to redirect traffic to general servers and specialized techniques to vector traffic to proxies and gateways. This final section will explain some of the more sophisticated redirection techniques used for caching proxy servers. These techniques are more complex than the previously discussed protocols because they try to be reliable, high-performance, and content-awaredispatching requests to locations likely to have particular pieces of content.
20.6.1 WCCP Redirection
Cisco Systems developed the Web Cache Coordination Protocol (WCCP) to enable routers to redirect web traffic to proxy caches. WCCP governs communication between routers and caches so that routers can verify caches (make sure they are up and running), load balance among caches, and send specific types of traffic to specific caches. WCCP Version 2 (WCCP2) is an open protocol. We'll discuss WCCP2 here.
20.6.1.1 How WCCP redirection works
Here's a brief overview of how WCCP redirection works for HTTP (WCCP redirects other protocols similarly):
Start with a network containing WCCP-enabled routers and caches that can communicate with one another.
A set of routers and their target caches form a WCCP service group. The configuration of the service group specifies what traffic is sent where, how traffic is sent, and how load should be balanced among the caches in the service group .
If the service group is configured to redirect HTTP traffic, routers in the service group send HTTP requests to caches in the service group.
When an HTTP request arrives at a router in the service group, the router chooses one of the caches in the service group to serve the request (based on either a hash on the request's IP address or a mask/value set pairing scheme).
The router sends the request packets to the cache, either by encapsulating the packets with the cache's IP address or by IP MAC forwarding.
If the cache cannot serve the request, the packets are returned to the router for normal forwarding.
The members of the service group exchange heartbeat messages with one another, continually verifying one another's availability.
20.6.1.2 WCCP2 messages
There are four WCCP2 messages, described in Table 20-4 .
Table 20-4. WCCP2 messages | ||
| Message name | Who sends it | Information carried |
| WCCP2_HERE_I_AM | Cache to router | These messages tell routers that caches are available to receive traffic. The messages contain all of the cache's service group information. As soon as a cache joins a service group, it sends these messages to all routers in the group. These messages negotiate with routers sending WCCP2_I_SEE_YOU messages. |
| WCCP2_I_SEE_YOU | Router to cache | These messages respond to WCCP2_HERE_I_AM messages. They are used to negotiate the packet forwarding method, assignment method (who is the designated cache), packet return method, and security. |
| WCCP2_REDIRECT_ASSIGN | Designated cache to router | These messages make assignments for load balancing; they send bucket information for hash table load balancing or mask/value set pair information for mask/value load balancing. |
| WCCP2_REMOVAL_QUERY | Router to cache that has not sent WCCP2_HERE_I_AM messages for 2.5 X HERE_I_AM_T seconds | If a router does not receive WCCP2_HERE_I_AM messages regularly, the router sends this message to see if the cache should be removed from the service group. The proper response from a cache is three identical WCCP2_HERE_I_AM messages, separated by HERE_I_AM_T/10 seconds. |
The WCCP2_HERE_I_AM message format is:
WCCP Message Header
Security Info Component
Service Info Component
Web-cache Identity Info Component
Web-cache View Info Component
Capability Info Component (optional)
Command Extension Component (optional)
The WCCP2_I_SEE_YOU message format is:
WCCP Message Header
Security Info Component
Service Info Component
Router Identity Info Component
Router View Info Component
Capability Info Component (optional)
Command Extension Component (optional)
The WCCP2_REDIRECT_ASSIGN message format is:
WCCP Message Header
Security Info Component
Service Info Component
Assignment Info Component, or Alternate Assignment Component
The WCCP2_REMOVAL_QUERY message format is:
WCCP Message Header
Security Info Component
Service Info Component
Router Query Info Component
20.6.1.3 Message components
Each WCCP2 message consists of a header and components. The WCCP header information contains the message type (Here I Am, I See You, Assignment, or Removal Query), WCCP version, and message length (not including the length of the header).
The components each begin with a four-octet header describing the component type and length. The component length does not include the length of the component header. The message components are described in Table 20-5 .
Table 20-5. WCCP2 message components | |
| Component | Description |
| Security Info | Contains the security option and security implementation. The security option can be: WCCP2_NO_SECURITY (0) WCCP2_MD5_SECURITY (1) If the option is no security, the security implementation field does not exist. If the option is MD5, the security implementation field is a 16-octet field containing the message checksum and Service Group password. The password can be no more than eight octets. |
| Service Info | Describes the service group. The service type ID can have two values: WCCP2_SERVICE_STANDARD (0) WCCP2_SERVICE_DYNAMIC (1) If the service type is standard, the service is a well-known service, defined entirely by service ID. HTTP is an example of a well-known service. If the service type is dynamic, the following settings define the service: priority, protocol, service flags (which determine hashing), and port. |
| Router Identity Info | Contains the router IP address and ID, and lists (by IP address) all of the web caches with which the router intends to communicate. |
| Web Cache Identity Info | Contains the web cache IP address and redirection hash table mapping. |
| Router View Info | Contains the router's view of the service group (identities of the routers and caches). |
| Web Cache View Info | Contains the web cache's view of the service group. |
| Assignment Info | Shows the assignment of a web cache to a particular hashing bucket. |
| Router Query Info | Contains the router's IP address, address of the web cache being queried, and ID of the last router in the service group that received a Here I Am message from the web cache. |
| Capabilities Info | Used by routers to advertise supported packet forwarding, load balancing, and packet return methods; used by web caches to let routers know what method the web cache prefers. |
| Alternate Assignment | Contains hash table assignment information for load balancing. |
| Assignment Map | Contains mask/value set elements for service group. |
| Command Extension | Used by web caches to tell routers they are shutting down; used by routers to acknowledge a cache shutdown. |
20.6.1.4 Service groups
A service group consists of a set of WCCP-enabled routers and caches that exchange WCCP messages. The routers send web traffic to the caches in the service group. The configuration of the service group determines how traffic is distributed to caches in the service group. The routers and caches exchange service group configuration information in Here I Am and I See You messages.
20.6.1.5 GRE packet encapsulation
Routers that support WCCP redirect HTTP packets to a particular server by encapsulating them with the server's IP address. The packet encapsulation also contains an IP header proto field that indicates Generic Router Encapsulation (GRE). The existence of the proto field tells the receiving proxy that it has an encapsulated packet. Because the packet is encapsulated, the client IP address is not lost. Figure 20-12 illustrates GRE packet encapsulation.
Figure 20-12. How a WCCP router changes an HTTP packet's destination IP address
20.6.1.6 WCCP load balancing
In addition to routing, WCCP routers can balance load among several receiving servers. WCCP routers and their receiving servers exchange heartbeat messages to let one another know they are up and running. If a particular receiving server stops sending heartbeat messages, the WCCP router sends request traffic directly to the Internet, instead of redirecting it to that node. When the node returns to service, the WCCP router begins receiving heartbeat messages again and resumes sending request traffic to the node.
EAN: 2147483647
Pages: 294