Description

Glossary

RFCs

Publications

Obsolete RFCs

Description:

RFC 2186:

ICP is a lightweight message format used for communicating among Web caches. ICP is used to exchange hints about the existence of URLs in neighbor caches. Caches exchange ICP queries and replies to gather information to use in selecting the most appropriate location from which to retrieve an object.

ICP is a message format used for communicating between Web caches. Although Web caches use HTTP 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.

RFC 2187, page 1:

ICP queries and replies refer to the existence of URLs (or objects) in neighbor caches. Caches exchange ICP messages and use the gathered information to select the most appropriate location from which to retrieve an object.

RFC 2187, page 15:

ICP is notably different from HTTP. HTTP supports a rich and sophisticated set of features. In contrast, ICP was designed to be simple, small, and efficient. HTTP request and reply headers consist of lines of ASCII text delimited by a CRLF pair, whereas ICP uses a fixed size header and represents numbers in binary. The only thing ICP and HTTP have in common is the URL.

ICP message:

The ICP message format consists of a 20 byte header followed by a variable sized payload. All fields are represented in network byte order.

ICP messages MUST not exceed 16,384 bytes in length.

Opcode. 8 bits.

Version. 8 bits.
The ICP protocol version number.

Message Length. 16 bits.
The total length of the ICP message in bytes.

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

Options. 32 bits.
Option flags that allows extension of this version of the protocol in certain, limited ways.

Option Data. 32 bits.
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.

Sender Host Address. 32 bits.
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. Variable length.

Glossary:

RFCs:

[RFC 2186] Internet Cache Protocol (ICP), version 2.

[RFC 2187] Application of Internet Cache Protocol (ICP), version 2.

[RFC 3143] Known HTTP Proxy/Caching Problems.

• Category: Informational.

Publications:

Obsolete RFCs:

Description

Glossary

RFCs

Publications

Obsolete RFCs