rfc887.txt

著名的RFC文档,其中有一些文档是已经翻译成中文的的.

                 +--------+--------+--------+---\\---+
                 -                                   +
                 -           Resource-List           |
                 -                                   |
                 +--------+--------+--------+---\\---+

where

<Type>
    is a single octet which identifies the message type.  The currently
    defined types are:

    0     <Who-Provides?>
    1     <Do-You-Provide?>
    2     <Who-Anywhere-Provides?>
    3     <Does-Anyone-Provide?>
    4     <I-Provide>
    5     <They-Provide>
    6-255 Reserved.

















Accetta                                                         [Page 6]

RFC 887                                                    December 1983
Resource Location Protocol

<Flags>
    is a single octet specifying possible modifications to the standard
    interpretation of <Type>.  Bits in this field are numbered from left
    to right (from most significant to least significant) beginning with
    bit 1.  The currently defined flag bits are:

    Bit 1    <Local-Only>.  Requires that any reply message generated in
             response to a request message with this flag bit set may
             only name IP addresses which are on the same IP network as
             the sender of the request message.  This flag also requires
             that multi-homed hosts answering broadcast <Who-Provides?>
             requests use the appropriate local network IP source
             address in the returned reply.  This bit must be zero in
             reply messages.
    Bits 2-8 Reserved.  Must be zero.

<Message-ID>
    is a two octet (16-bit) value which identifies the request message.
    It is used simply to aid in matching requests with replies.  The
    sending host should initialize this field to some convenient value
    when constructing a request message.  The receiving host must return
    this same value in the <Message-ID> field of any reply message
    generated in response to that request.

<Resource-List>
    is the list of resources being queried or for which location
    information is being supplied.  This list is a sequence of octets
    beginning at the octet following the <Message-ID> and extending
    through the end of the UDP packet.  The format of this field is
    explained more fully in the following section.  The size of this
    list is implicitly specified by the length of the encapsulating UDP
    datagram.



4.1. Resource Lists

A <Resource-List> consists of zero or more resource specifiers.  Each
resource specifier is simply a sequence of octets.  All resource
specifiers have a common resource name initial format

                 +--------+--------+--------+---\\---+
                 |        |        |                 |
                 |Protocol|IDLength|   Resource-ID   |
                 |        |        |                 |
                 +--------+--------+--------+---\\---+

where




Accetta                                                         [Page 7]

RFC 887                                                    December 1983
Resource Location Protocol

<Protocol>
    is the protocol number assigned to the lowest level Internet
    protocol utilized for accessing the resource.

<IDLength>
    is the length of the resource identifier associated with this
    <Protocol>.  This length may be a fixed or variable value depending
    on the particular resource.  It is included so that specifiers which
    refer to resources which a host may not provide can be skipped over
    without needing to know the specific structure of the particular
    resource identifier.  If the <Protocol> has no associated natural
    identifier, this length is 0.

<Resource-ID>
    is the qualifying identifier used to further refine the resource
    being queried.  If the <IDLength> field was 0, then this field is
    empty and occupies no space in the resource specifier.

In addition, resource specifiers in all <Who-Anywhere-Provides?>,
<Does-Anyone-Provide?> and <They-Provide> messages also contain an
additional qualifier following the <Protocol-ID>.  This qualifier has
the format

             +--------+--------+--------+--------+---//---+
             |        |                                   |
             |IPLength|          IP-Address-List          |
             |        |                                   |
             +--------+--------+--------+--------+---//---+

where






















Accetta                                                         [Page 8]

RFC 887                                                    December 1983
Resource Location Protocol

<IPLength>
    is the number of IP addresses containing in the following
    <IP-Address-List> (the <IP-Address-List> field thus occupies the
    last 4*<IPLength> octets in its resource specifier).  In request
    messages, this is the maximum number of qualifying addresses which
    may be included in the corresponding reply resource specifier.
    Although not particularly useful, it may be 0 and in that case
    provides no space for qualifying the resource name with IP addresses
    in the returned specifier.  In reply messages, this is the number of
    qualifying addresses known to provide the resource.  It may not
    exceed the number specified in the corresponding request specifier.
    This field may not be 0 in a reply message unless it was supplied as
    0 in the request message and the confirming host would have returned
    one or more IP addresses had any space been provided.

<IP-Address-List>
    is a list of four-octet IP addresses used to qualify the resource
    specifier with respect to those particular addresses.  In reply
    messages, these are the IP addresses of the confirming host (when
    appropriate) and the addresses of any other hosts known to provide
    that resource (subject to the list length limitations).  In request
    messages, these are the IP addresses of hosts for which resource
    information may not be returned.  In such messages, these addresses
    should normally be initialized to some "harmless" value (such as the
    address of the querying host) unless it is intended to specifically
    exclude the supplied addresses from consideration in any reply
    messages.

The receiving host determines if it provides any of the resources named
in the request list by successively decomposing each resource name.  The
first level of decomposition is the Internet protocol number which can
presumably be looked up in a table to determine if that protocol is
supported on the host.  Subsequent decompositions are based on previous
components until one of three events occur:

   1. the current component identifies some aspect of the previous
      components which the host does not support,

   2. the resource name from the request list is exhausted, or

   3. the resource name from the request list is not exhausted but
      the host does not expect any further components in the name
      given the previous components

In case 1, the receiving host has determined that it does not provide
the named resource.  The resource specifier may not be included in any
reply message returned.

In case 2, the receiving host has determined that it does indeed provide
the named resource (note: this may occur even if the receiving host


Accetta                                                         [Page 9]

RFC 887                                                    December 1983
Resource Location Protocol

would have expected the resource name to contain more components than
were actually present).  The resource specifier must be included (modulo
IP address prohibitions) in any reply message returned.

In case 3, the receiving host has determined that it does not completely
provide the named resource since name components remain which it does
not understand (this might occur with specializations of or extensions
to a known protocol which are not universally recognized).  The resource
specifier may not be included in any reply message returned.

5. Sample Usage

The following scenarios illustrate some typical uses of RLP.  In all
cases the indicated messages are encapsulated in a UDP datagram with the
appropriate source and destination port numbers, message length, and
checksum.  This datagram is further encapsulated in an IP datagram with
the appropriate source address of the sending host and destination
address (either broadcast or individual) for the receiving host.

All numeric protocol examples are as specified in the appropriate
protocol description documents listed in the references.

 1. Suppose a freshly rebooted host H wishes to find some gateway
    on its directly connected network to which it can send its
    first external packet.  It then broadcasts the request

        <Who-Provides?> <Flags>=<Local-Only> <Message-ID>=12345
                    <Resource-List>={[GGP], [EGP]}

    encoded as the 8 octet message

           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  0  | 128 |   12345   |  3  |  0  |  8  |  0  |
           +-----+-----+-----+-----+-----+-----+-----+-----+

    on its local network.

     - Gateway G1 (which understands EGP) receives the request and
       returns the reply

               <I-Provide> <Flags>=none <Message-ID>=12345
                         <Resource-List>={[EGP]}

       encoded as the 6 octet message

                  +-----+-----+-----+-----+-----+-----+
                  |  4  |  0  |   12345   |  8  |  0  |
                  +-----+-----+-----+-----+-----+-----+

       to host H which then remembers that gateway G1 may be used


Accetta                                                        [Page 10]

RFC 887                                                    December 1983
Resource Location Protocol

       to route traffic to the rest of the Internet.

     -  At the same time, gateway G2 (which understands both GGP
       and EGP) might also receive the request and return the reply

               <I-Provide> <Flags>=none <Message-ID>=12345
                      <Resource-List>={[GGP], [EGP]}

       encoded as the 8 octet message

            +-----+-----+-----+-----+-----+-----+-----+-----+
            |  4  |  0  |   12345   |  3  |  0  |  8  |  0  |
            +-----+-----+-----+-----+-----+-----+-----+-----+

       to host H which might then also add gateway G2 to its list
       if it chooses.

 2. Assume instead that host H is a stand-alone system which has
    just encountered some fatal software error and wishes to locate
    a crash dump server to save its state before reloading.
    Suppose that the crash dump protocol on the host's local
    network is implemented using the Trivial File Transfer Protocol
    (TFTP) [8].  Furthermore, suppose that the special file name
    "CRASH-DUMP" is used to indicate crash dump processing (e.g.
    the server might locally generate a unique file name to hold
    each dump that it receives from a host).  Then host H might
    broadcast the request

            <Who-Provides?> <Flags>=none <Message-ID>=54321
           <Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}

    encoded as the 21 octet message

           +-----+-----+-----+-----+-----+-----+-----+-----+
           |  0  |  0  |   54321   |  17 |  15 |     69    |
           +-----+-----+-----+-----+-----+-----+-----+-----+