home *** CD-ROM | disk | FTP | other *** search
/ Internet Info 1997 December / Internet_Info_CD-ROM_Walnut_Creek_December_1997.iso / drafts / draft_s_z / draft-wessels-icp-v2-01.txt < prev    next >
Text File  |  1997-03-25  |  19KB  |  505 lines
  1.  
  2.  
  3. Network Working Group                                         D. Wessels
  4. Internet-Draft                           National Laboratory for Applied
  5. Obsoletes <draft-wessels-icp-v2-00.txt>            Network Research/UCSD
  6. Expires: September 25, 1997                                25 March 1997
  7.  
  8.  
  9.  
  10.                 Internet Cache Protocol (ICP), version 2
  11.                      <draft-wessels-icp-v2-01.txt>
  12.  
  13.  
  14. Status of this Memo
  15.  
  16.  
  17.    This document is an Internet-Draft. Internet-Drafts are working
  18.    documents of the Internet Engineering Task Force (IETF), its areas,
  19.    and its working groups. Note that other groups may also distribute
  20.    working documents as Internet-Drafts.
  21.  
  22.    Internet-Drafts are draft documents valid for a maximum of six months
  23.    and may be updated, replaced, or obsoleted by other documents at any
  24.    time. It is inappropriate to use Internet-Drafts as reference
  25.    material or to cite them other than as ``work in progress.''
  26.  
  27.    To learn the current status of any Internet-Draft, please check the
  28.    ``1id-abstracts.txt'' listing contained in the Internet-Drafts Shadow
  29.    Directories on ftp.is.co.za (Africa), nic.nordu.net (Europe),
  30.    munnari.oz.au (Pacific Rim), ds.internic.net (US East Coast), or
  31.    ftp.isi.edu (US West Coast).
  32.  
  33.  
  34.  
  35. Abstract
  36.  
  37.  
  38.    This draft document describes the Internet Cache Protocol (ICP) as
  39.    currently implemented in a couple of World-Wide Web proxy cache
  40.    packages.  ICP was initially developed by Peter Danzig, et. al. at
  41.    the University of Southern California.  It evolved as an important
  42.    part of hierarchical caching on the Harvest research project.
  43.  
  44.  
  45.  
  46. 1.  Introduction
  47.  
  48.  
  49.    ICP is a message format used for communicating between Web caches.
  50.    Although Web caches use HTTP[1] for the transfer of object data,
  51.  
  52.  
  53.  
  54. Wessels                                                         [Page 1]
  55.  
  56. Internet-Draft                                             25 March 1997
  57.  
  58.  
  59.    caches benefit from a simpler, lighter communication protocol.  ICP
  60.    is primarily used in a cache mesh to locate specific Web objects in
  61.    neighbor caches.  One cache will send an ICP query to its neighbors.
  62.    The neighbors will send back ICP replies indicating a ``HIT'' or a
  63.    ``MISS.''
  64.  
  65.    In current practice, ICP is implemented on top of UDP, but there is
  66.    no requirement that it be limited to UDP.  We feel that ICP over UDP
  67.    offers features important to Web caching applications.  An ICP
  68.    query/reply exchange needs to occur quickly, typically within a sec-
  69.    ond or two.  A cache cannot wait longer than that before beginning to
  70.    retrieve an object.  Failure to receive a reply message most likely
  71.    means the network path is either congested or broken.  In either case
  72.    we would not want to select that neighbor.  As an indication of imme-
  73.    diate network conditions between neighbor caches, ICP over a
  74.    lightweight protocol such as UDP is better than one with the overhead
  75.    of TCP.
  76.  
  77.    In addition to its use as an object location protocol, ICP messages
  78.    can be used for cache selection.  Failure to receive a reply from a
  79.    cache may indicate a network or system failure.  The ICP reply may
  80.    include information that could assist selection of the most appropri-
  81.    ate source from which to retrieve an object.
  82.  
  83.  
  84.  
  85.  
  86. ICP Message Format
  87.  
  88.  
  89.    The ICP message format consists of a 20-octet fixed header plus a
  90.    variable sized payload:
  91.  
  92.      0                   1                   2                   3
  93.     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
  94.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  95.    |     Opcode    |    Version    |         Message Length        |
  96.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  97.    |                         Request Number                        |
  98.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  99.    |                            Options                            |
  100.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  101.    |                          Option Data                          |
  102.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  103.    |                       Sender Host Address                     |
  104.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  105.    |                                                               |
  106.    |                            Payload                            |
  107.  
  108.  
  109.  
  110. Wessels                                                         [Page 2]
  111.  
  112. Internet-Draft                                             25 March 1997
  113.  
  114.  
  115.    /                                                               /
  116.    /                                                               /
  117.    |                                                               |
  118.    +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  119.  
  120.    NOTE: All fields must be represented in network byte order.
  121.  
  122.    Opcode
  123.       One of the opcodes defined below.
  124.  
  125.    Version
  126.       The ICP protocol version number.  At the time of this writing,
  127.       both versions two and three are in use.  This document describes
  128.       only version two.  The version number field allows for future
  129.       development of this protocol.
  130.  
  131.    Message Length
  132.       The total length (octets) of the ICP message.  ICP messages MUST
  133.       not exceed 16,384 octets in length.
  134.  
  135.    Request Number
  136.       An opaque identifier.  When responding to a query, this value must
  137.       be copied into the reply message.
  138.  
  139.    Options
  140.       A 32-bit field of option flags that allows extension of this ver-
  141.       sion of the protocol in certain, limited ways.  See ``ICP Option
  142.       Flags'' below.
  143.  
  144.    Option Data
  145.       A four-octet field to support optional features.  The following
  146.       ICP features make use of this field:
  147.  
  148.       The ICP_FLAG_SRC_RTT option uses the low 16-bits of Option Data to
  149.       return RTT measurements.  The ICP_FLAG_SRC_RTT option is further
  150.       described below.
  151.  
  152.    Sender Host Address
  153.       The IPv4 address of the host sending the ICP message.  This field
  154.       should probably not be trusted over what is  provided by getpeer-
  155.       name(), accept(), and recvfrom().  There is some ambiguity over
  156.       the original purpose of this field.  In practice it is not used.
  157.  
  158.    Payload
  159.       The contents of the Payload field vary depending on the Opcode,
  160.       but most often it contains a null-terminated URL string.
  161.  
  162.  
  163.  
  164.  
  165.  
  166. Wessels                                                         [Page 3]
  167.  
  168. Internet-Draft                                             25 March 1997
  169.  
  170.  
  171. 2.  ICP Opcodes
  172.  
  173.  
  174. The following table shows currently defined ICP opcodes:
  175.  
  176.    Value    Name
  177.    -----    -----------------
  178.        0    ICP_OP_INVALID
  179.        1    ICP_OP_QUERY
  180.        2    ICP_OP_HIT
  181.        3    ICP_OP_MISS
  182.        4    ICP_OP_ERR
  183.      5-9    UNUSED
  184.       10    ICP_OP_SECHO
  185.       11    ICP_OP_DECHO
  186.    12-20    UNUSED
  187.       21    ICP_OP_MISS_NOFETCH
  188.       22    ICP_OP_DENIED
  189.       23    ICP_OP_HIT_OBJ
  190.  
  191.    ICP_OP_INVALID
  192.       A place holder to detect zero-filled or malformed messages.  A
  193.       cache must never intentionally send an ICP_OP_INVALID message.
  194.       ICP_OP_ERR should be used instead.
  195.  
  196.    ICP_OP_QUERY
  197.       A query message.  NOTE this opcode has a different payload format
  198.       than most of the others.  First is the requester's IPv4 address,
  199.       followed by a URL.  The Requester Host Address is not that of the
  200.       cache generating the ICP message, but rather the address of the
  201.       caches's client that originated the request.  The Requester Host
  202.       Address is often zero filled.  An ICP message with an all-zero
  203.       Requester Host Address address should be taken as one where the
  204.       requester address is not specified; it does not indicate a valid
  205.       IPv4 address.
  206.  
  207.       ICP_OP_QUERY payload format:
  208.  
  209.         0                   1                   2                   3
  210.        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
  211.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  212.       |                     Requester Host Address                    |
  213.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  214.       |                                                               |
  215.       /                       Null-Terminated URL                     /
  216.       /                                                               /
  217.       |                                                               |
  218.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  219.  
  220.  
  221.  
  222. Wessels                                                         [Page 4]
  223.  
  224. Internet-Draft                                             25 March 1997
  225.  
  226.  
  227.       In response to an ICP_OP_QUERY, the recipient must return one of:
  228.       ICP_OP_HIT, ICP_OP_MISS, ICP_OP_ERR, ICP_OP_MISS_NOFETCH,
  229.       ICP_OP_DENIED, or ICP_OP_HIT_OBJ.
  230.  
  231.    ICP_OP_SECHO
  232.       Similar to ICP_OP_QUERY, but for use in simulating a query to an
  233.       origin server.  When ICP is used to select the closest neighbor,
  234.       the origin server can be included in the algorithm by bouncing an
  235.       ICP_OP_SECHO message off it's echo port.  The payload is simply
  236.       the null-terminated URL.
  237.  
  238.       NOTE: the echo server will not interpret the data (i.e. we could
  239.       send it anything).  This opcode is used to tell the difference
  240.       between a legitimate query or response, random garbage, and an
  241.       echo response.
  242.  
  243.    ICP_OP_DECHO
  244.       Similar to ICP_OP_QUERY, but for use in simulating a query to a
  245.       cache which does not use ICP.  When ICP is used to choose the
  246.       closest neighbor, a non-ICP cache can be included in the algorithm
  247.       by bouncing an ICP_OP_DECHO message off it's echo port.  The pay-
  248.       load is simply the null-terminated URL.
  249.  
  250.       NOTE: one problem with this approach is that while a system's echo
  251.       port may be functioning perfectly, the cache software may not be
  252.       running at all.
  253.  
  254.  
  255.    One of the following six ICP opcodes are sent in response to an
  256.    ICP_OP_QUERY message.  Unless otherwise noted, the payload must be
  257.    the null-terminated URL string.  Both the URL string and the Request
  258.    Number field must be exactly the same as from the ICP_OP_QUERY mes-
  259.    sage.
  260.  
  261.    ICP_OP_HIT
  262.       An ICP_OP_HIT response indicates that the requested URL exists in
  263.       this cache and that the requester is allowed to retrieve it.
  264.  
  265.    ICP_OP_MISS
  266.       An ICP_OP_MISS response indicates that the requested URL does not
  267.       exist in this cache.  The querying cache may still choose to fetch
  268.       the URL from the replying cache.
  269.  
  270.    ICP_OP_ERR
  271.       An ICP_OP_ERR response indicates some kind of error in parsing or
  272.       handling the query message (e.g. invalid URL).
  273.  
  274.    ICP_OP_MISS_NOFETCH
  275.  
  276.  
  277.  
  278. Wessels                                                         [Page 5]
  279.  
  280. Internet-Draft                                             25 March 1997
  281.  
  282.  
  283.       An ICP_OP_MISS_NOFETCH response indicates that this cache is up,
  284.       but is in a state where it does not want to handle cache misses.
  285.       An example of such a state is during a startup phase where a cache
  286.       might be rebuilding its object store.  A cache in such a mode may
  287.       wish to return ICP_OP_HIT for cache hits, but not ICP_OP_MISS for
  288.       misses.  ICP_OP_MISS_NOFETCH essentially means ``I am up and run-
  289.       ning, but please don't fetch this URL from me now.''
  290.  
  291.       Note, ICP_OP_MISS_NOFETCH has a different meaning than
  292.       ICP_OP_MISS.  The ICP_OP_MISS reply is an invitation to fetch the
  293.       URL from the replying cache (if their relationship allows it), but
  294.       ICP_OP_MISS_NOFETCH is a request to NOT fetch the URL from the
  295.       replying cache.
  296.  
  297.    ICP_OP_DENIED
  298.       An ICP_OP_DENIED response indicates that the querying site is not
  299.       allowed to retrieve the named object from this cache.  Caches and
  300.       proxies may implement complex access controls.  This reply must be
  301.       be interpreted to mean ``you are not allowed to request this par-
  302.       ticular URL from me at this particular time.''
  303.  
  304.       Caches receiving a high percentage of ICP_OP_DENIED replies are
  305.       probably misconfigured.  Caches should track percentage of all
  306.       replies which are ICP_OP_DENIED and disable a neighbor which
  307.       exceeds a certain threshold (e.g. 95% of 100 or more queries).
  308.  
  309.       Similarly, a cache should track the percent of ICP_OP_DENIED mes-
  310.       sages that are sent to a given address.  If the percent of denied
  311.       messages exceeds a certain threshold (e.g. 95% of 100 or more),
  312.       the cache may choose to ignore all subsequent ICP_OP_QUERY mes-
  313.       sages from that address until some sort of administrative inter-
  314.       vention occurs.
  315.  
  316.    ICP_OP_HIT_OBJ
  317.       Just like an ICP_OP_HIT response, but the actual object data has
  318.       been included in this reply message.   Many requested objects are
  319.       small enough that it is possible to include them in the query
  320.       response and avoid the need to make a subsequent HTTP request for
  321.       the object.
  322.  
  323.       CAVEAT: ICP_OP_HIT_OBJ has some negative side effects which make
  324.       its use undesirable.  It transfers object data without HTTP and
  325.       therefore bypasses the standard HTTP processing, including autho-
  326.       rization and age validation.  Another negative side effect is that
  327.       ICP_OP_HIT_OBJ messages will often be much larger than the path
  328.       MTU, thereby causing fragmentation to occur on the UDP packet.
  329.       For these reasons, use of ICP_OP_HIT_OBJ is NOT recommended.
  330.  
  331.  
  332.  
  333.  
  334. Wessels                                                         [Page 6]
  335.  
  336. Internet-Draft                                             25 March 1997
  337.  
  338.  
  339.       A cache must not send an ICP_OP_HIT_OBJ unless the
  340.       ICP_FLAG_HIT_OBJ flag is set in the query message Options field.
  341.  
  342.       ICP_OP_HIT_OBJ payload format:
  343.  
  344.         0                   1                   2                   3
  345.        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
  346.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  347.       |                                                               |
  348.       /                       Null-Terminated URL                     /
  349.       /                                                               /
  350.       |                                                               |
  351.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  352.       |         Object Size           |                               |
  353.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+                               |
  354.       |                                                               |
  355.       /                           Object Data                         /
  356.       /                                                               /
  357.       |                                                               |
  358.       +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
  359.  
  360.       The receiving application must check to make sure it actually
  361.       receives Object Size octets of data.  If it does not, then it
  362.       should treat the ICP_OP_HIT_OBJ reply as though it were a normal
  363.       ICP_OP_HIT.
  364.  
  365.       NOTE: the Object Size field does not necessarily begin on a 32-bit
  366.       boundary as shown in the diagram above.  It begins immediately
  367.       following the NULL byte of the URL string.
  368.  
  369.  
  370.    UNRECOGNIZED OPCODES
  371.       ICP messages with unrecognized or unused opcodes should be
  372.       ignored, i.e. no reply generated.  The application may choose to
  373.       note the anomalous behaviour in a log file.
  374.  
  375.  
  376.  
  377.  
  378.  
  379. 3.  ICP Option Flags
  380.  
  381.  
  382.    0x80000000  ICP_FLAG_HIT_OBJ
  383.       This flag is set in an ICP_OP_QUERY message indicating that it is
  384.       okay to respond with an ICP_OP_HIT_OBJ message if the object data
  385.       will fit in the reply.
  386.  
  387.  
  388.  
  389.  
  390. Wessels                                                         [Page 7]
  391.  
  392. Internet-Draft                                             25 March 1997
  393.  
  394.  
  395.    0x40000000  ICP_FLAG_SRC_RTT
  396.       This flag is set in an ICP_OP_QUERY message indicating that the
  397.       requester would like the ICP reply to include the responder's mea-
  398.       sured RTT to the origin server.
  399.  
  400.       Upon receipt of an ICP_OP_QUERY with ICP_FLAG_SRC_RTT bit set, a
  401.       cache should check an internal database of RTT measurements.  If
  402.       available, the RTT value MUST be expressed as a 16-bit integer, in
  403.       units of milliseconds.  If unavailable, the responder may either
  404.       set the RTT value to zero, or clear the ICP_FLAG_SRC_RTT bit in
  405.       the ICP reply.  The ICP reply MUST not be delayed while waiting
  406.       for the RTT measurement to occur.
  407.  
  408.       This flag is set in an ICP reply message (ICP_OP_HIT, ICP_OP_MISS,
  409.       ICP_OP_MISS_NOFETCH, or ICP_OP_HIT_OBJ) to indicate that the low
  410.       16-bits of the Option Data field contain the measured RTT to the
  411.       host given in the requested URL.  If ICP_FLAG_SRC_RTT is clear in
  412.       the query then it MUST also be clear in the reply.  If
  413.       ICP_FLAG_SRC_RTT is set in the query, then it may or may not be
  414.       set in the reply.
  415.  
  416.  
  417.  
  418.  
  419. 4.  Security Considerations
  420.  
  421.    Security is an issue with ICP over UDP because of its connectionless
  422.    nature.  A proxy/cache must only process ICP messages received from
  423.    its known neighbors.  A cache must discard messages from unknown
  424.    addresses.
  425.  
  426.    The ICP_OP_HIT_OBJ message is especially sensitive to security issues
  427.    since it contains actual object data in the response.  In combination
  428.    with IP spoofing it is most likely possible to pollute the cache with
  429.    invalid objects.
  430.  
  431.    Multicasting ICP queries provides a very simple method for others to
  432.    "snoop" on ICP messages.  Cache administrators should configure the
  433.    application to use the minimum required multicast TTL.
  434.  
  435.  
  436.  
  437.  
  438. 5.  References
  439.  
  440.  
  441.    [1] Fielding, R., et. al, "Hypertext Transfer Protocol -- HTTP/1.1",
  442.    RFC 2068, UC Irvine, January 1997.
  443.  
  444.  
  445.  
  446. Wessels                                                         [Page 8]
  447.  
  448. Internet-Draft                                             25 March 1997
  449.  
  450.  
  451.    [2] Berners-Lee, T., Masinter, L., and M. McCahill, "Uniform Resource
  452.    Locators (URL)", RFC 1738, CERN, Xerox PARC, University of Minnesota,
  453.    December 1994.
  454.  
  455.    [3] Bowman M., Danzig P., Hardy D., Manber U., Schwartz M., and Wes-
  456.    sels D., "The Harvest Information Discovery and Access System",
  457.    Internet Research Task Force - Resource Discovery, http://har-
  458.    vest.transarc.com/.
  459.  
  460.    [4] Wessels D., Claffy K., "ICP and the Squid Web Cache", National
  461.    Laboratory for Applied Network Research, http://www.nlanr.net/~wes-
  462.    sels/Papers/icp-squid.ps.gz
  463.  
  464.  
  465.  
  466.  
  467. 6.  Acknowledgments
  468.  
  469.    Paul A Vixie <paul@vix.com>
  470.  
  471.  
  472.  
  473. 7.  Author's  Address:
  474.  
  475.    Duane Wessels
  476.    National Laboratory for Applied Network Research
  477.    wessels@nlanr.net
  478.  
  479.    K Claffy
  480.    National Laboratory for Applied Network Research
  481.    kc@nlanr.net
  482.  
  483.  
  484.  
  485.  
  486.  
  487.  
  488.  
  489.  
  490.  
  491.  
  492.  
  493.  
  494.  
  495.  
  496.  
  497.  
  498.  
  499.  
  500.  
  501.  
  502. Wessels                                                         [Page 9]
  503.  
  504.  
  505.