Where type is either `parent', `sibling', or `multicast'.  For our
   example, it would be:

       cache_host cache.isp.com parent 8080 3130

   This configuration will cause the customer cache to resolve most
   cache misses through the parent (`cgi-bin' and non-GET requests would
   be resolved directly).  Utilizing the parent may be undesirable for
   certain servers, such as servers also in the customer.org domain.  To
   always handle such local domains directly, the customer would add
   this to his configuration file:

       local_domain customer.org

   It may also be the case that the customer wants to use the ISP cache
   only for a specific subset of DNS domains.  The need to limit
   requests this way is actually more common for higher levels of cache
   hierarchies, but it is illustrated here nonetheless.  To limit the
   ISP cache to a subset of DNS domains, the customer would use:

       cache_host_domain cache.isp.com com net org

   Then, any requests which are NOT in the .com, .net, or .org domains
   would be handled directly.

4.2.  Configuring the `cache.isp.com' cache

   To configure the query-receiving side of the cache peer
   relationship one uses access lists, similar to those used in routing
   peers.  The access lists support a large degree of customization in
   the peering relationship.  If there are no access lines present, the
   cache allows the request by default.







 
RFC 2187                          ICP                     September 1997


   Note that the cache.isp.com cache need not explicitly specify the
   customer cache as a peer, nor is the type of relationship encoded
   within the ICP query itself.  The access control entries regulate the
   relationships between this cache and its neighbors.  For our example,
   the ISP would use:

       acl src Customer  proxy.customer.org
       http_access allow Customer
       icp_access  allow Customer

   This defines an access control entry named `Customer' which specifies
   a source IP address of the customer cache machine.  The customer
   cache would then be allowed to make any request to both the HTTP and
   ICP ports (including cache misses).  This configuration implies that
   the ISP cache is a parent of the customer.

   If the ISP wanted to enforce a sibling relationship, it would need to
   deny access to cache misses.  This would be done as follows:

       miss_access deny Customer

   Of course the ISP should also communicate this to the customer, so
   that the customer will change his configuration from parent to
   sibling.  Otherwise, if the customer requests an object not in the
   ISP cache, an error message is generated.

5.  Applying the Protocol

   The following sections describe the ICP implementation in the
   Harvest[3] (research version) and Squid Web cache[5] packages.  In
   terms of version numbers, this means version 1.4pl2 for Harvest and
   version 1.1.10 for Squid.

   The basic sequence of events in an ICP transaction is as follows:

   1.   Local cache receives an HTTP[1] request from a cache client.

   2.   The local cache sends ICP queries (section 5.1).

   3.   The peer cache(s) receive the queries and send ICP replies
        (section 5.2).

   4.   The local cache receives the ICP replies and decides where to
        forward the request (section 5.3).








 
RFC 2187                          ICP                     September 1997


5.1.  Sending ICP Queries