1. Introduction

   ICP is a message format used for communicating between Web caches.
   Although Web caches use HTTP[1] for the transfer of object data,
   caches benefit from a simpler, lighter communication protocol.  ICP
   is primarily used in a cache mesh to locate specific Web objects in
   neighboring caches.  One cache sends an ICP query to its neighbors.
   The neighbors send back ICP replies indicating a "HIT" or a "MISS."

   In current practice, ICP is implemented on top of UDP, but there is
   no requirement that it be limited to UDP.  We feel that ICP over UDP
   offers features important to Web caching applications.  An ICP
   query/reply exchange needs to occur quickly, typically within a
   second or two.  A cache cannot wait longer than that before beginning
   to retrieve an object.  Failure to receive a reply message most
   likely means the network path is either congested or broken.  In
   either case we would not want to select that neighbor.  As an
   indication of immediate network conditions between neighbor caches,
   ICP over a lightweight protocol such as UDP is better than one with
   the overhead of TCP.

   In addition to its use as an object location protocol, ICP messages
   can be used for cache selection.  Failure to receive a reply from a
   cache may indicate a network or system failure.  The ICP reply may
   include information that could assist selection of the most
   appropriate source from which to retrieve an object.

   ICP was initially developed by Peter Danzig, et. al.  at the
   University of Southern California as a central part of hierarchical
   caching in the Harvest research project[3].

ICP Message Format

   The ICP message format consists of a 20-octet fixed header plus a
   variable sized payload (see Figure 1).

   NOTE: All fields must be represented in network byte order.

   Opcode
      One of the opcodes defined below.

   Version
      The ICP protocol version number.  At the time of this writing,
      both versions two and three are in use.  This document describes
      only version two.  The version number field allows for future
      development of this protocol.

   Message Length

     0                   1                   2                   3
    0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |     Opcode    |    Version    |         Message Length        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                         Request Number                        |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                            Options                            |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                          Option Data                          |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                       Sender Host Address                     |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
   |                                                               |
   |                            Payload                            |
   /                                                               /
   /                                                               /
   |                                                               |
   +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

                     FIGURE 1: ICP message format.

      The total length (octets) of the ICP message.  ICP messages MUST
      not exceed 16,384 octets in length.

   Request Number
      An opaque identifier.  When responding to a query, this value must
      be copied into the reply message.

   Options
      A 32-bit field of option flags that allows extension of this
      version of the protocol in certain, limited ways.  See "ICP Option
      Flags" below.

   Option Data
      A four-octet field to support optional features.  The following
      ICP features make use of this field:

      The ICP_FLAG_SRC_RTT option uses the low 16-bits of Option Data to
      return RTT measurements.  The ICP_FLAG_SRC_RTT option is further
      described below.

   Sender Host Address
      The IPv4 address of the host sending the ICP message.  This field
      should probably not be trusted over what is  provided by getpeer-
      name(), accept(), and recvfrom().  There is some ambiguity over
      the original purpose of this field.  In practice it is not used.

   Payload
      The contents of the Payload field vary depending on the Opcode,
      but most often it contains a null-terminated URL string.