rfc887.txt

来自「RFC 的详细文档！」· 文本 代码 · 共 914 行 · 第 1/3 页

Network Working Group                                         M. Accetta
Request for Comments: 887                     Carnegie-Mellon University
                                                           December 1983

                       RESOURCE LOCATION PROTOCOL


This note describes a resource location protocol for use in the ARPA
Internet.  It is most useful on networks employing technologies which
support some method of broadcast addressing, however it may also be used
on other types of networks.  For maximum benefit, all hosts which
provide significant resources or services to other hosts on the Internet
should implement this protocol.  Hosts failing to implement the Resource
Location Protocol risk being ignored by other hosts which are attempting
to locate resources on the Internet.  This RFC specifies a draft
standard for the ARPA Internet community.

The Resource Location Protocol (RLP) utilizes the User Datagram Protocol
(UDP) [1] which in turn calls on the Internet Protocol (IP) [3] to
deliver its datagrams.  See Appendix A and [6] for the appropriate port
and protocol number assignments.

Unless otherwise indicated, all numeric quantities in this document are
decimal numbers.

1. Introduction

From time to time, Internet hosts are faced with the problem of
determining where on the Internet some particular network service or
resource is being provided.  For example, this situation will arise when
a host needs to send a packet destined for some external network to a
gateway on its directly connected network and does not know of any
gateways.  In another case, a host may need to translate a domain name
to an Internet address and not know of any name servers which it can ask
to perform the translation.  In these situations a host may use the
Resource Location Protocol to determine this information.

In almost all cases the resource location problem is simply a matter of
finding the IP address of some one (usually any) host, either on the
directly connected network or elsewhere on the Internet, which
understands a given protocol.  Most frequently, the querying host itself
understands the protocol in question.  Typically (as in the case of
locating a name server), the querying host subsequently intends to
employ that protocol to communicate with the located host once its
address is known (e.g. to request name to address translations).  Less
frequently, the querying host itself does not necessarily understand the
protocol in question.  Instead (as in the case of locating a gateway),
it is simply attempting to find some other host which does (e.g. to
determine an appropriate place to forward a packet which cannot be
delivered locally).






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

2. Resource Naming

Although the resource location problem can, in most cases, be reduced to
the problem of finding a host which implements a given Internet based
protocol, locating only a particular lowest level Internet protocol
(i.e. one assigned a protocol number for transport using IP) is not
completely sufficient.  Many significant network services and resources
are provided through higher level protocols which merely utilize the
various lower level protocols for their own transport purposes (e.g. the
FTP protocol [2] employs the TCP protocol [4] for its lower level
transport).  Conceptually, this protocol nesting may even be carried out
to arbitrary levels.

Consequently, the Resource Location Protocol names a resource by the
protocol number assigned to its lowest level Internet transport protocol
and by a variable length protocol/resource specific identifier.  For
example, the UDP based Echo Protocol can be named by its assigned
protocol number (17) and its assigned 16-bit "well-known" port number
(7).  Alternatively, the Internet Control Message Protocol [5] (lacking
any higher level client protocols) would be named simply by its assigned
protocol number (1) and an empty protocol specific identifier.  On the
other hand, some as yet undefined resource protocol (provided via say
TCP), might be named by the assigned protocol number (6), its 16-bit
"well-known" TCP port number, and then some additional fixed or variable
length identifier specific to that TCP port.

In general, the components of the protocol/resource specific identifier
are defined to be the "natural" quantities used to successively
de-multiplex the protocol at each next highest protocol level.  See
section 5 for some sample assignments.

3. Protocol Summary

The Resource Location Protocol is a simple request/reply procedure.  The
querying host constructs a list of resources which it would like to
locate and sends a request message on the network.  A request message
may be sent either to a particular IP address and host or, on networks
which provide broadcast address capability, to the IP address which
refers to all hosts on that network (see [7]).  For example, a host
attempting to locate a domain name server might construct a request
containing the resource name [17, 53] (referring to the Domain Name
Server protocol provided at "well-known" UDP port 53) and then broadcast
that request on its local network.

Each receiving host examines the list of resources named in the request
packet, determines which of the resources it provides, and returns a
reply message to the querying host in confirmation.  The receiving host
determines whether or not it provides a resource by successive
decomposition of the resource name until either the name is exhausted or
it encounters a component which is not supported.  In the previous


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

example, each host on the network receiving the broadcast request would
examine the resource name by first consulting its tables to determine if
it provided UDP service.  If this was successful, it would then examine
the UDP port component of the name and consult its UDP table to
determine if it provided service on UDP port 53.  At this point the name
would be exhausted and if both checks were successful the host would
return a reply message to the querying host indicating support for that
resource.



3.1. Request Messages

RLP provides two basic types of request messages which may be
transmitted by a querying host.  The first type requires any host
receiving the request message to return a reply message only if it
provides at least one of the resources named in the request list.  The
second type requires any host receiving the message to always return a
reply message even if it provides none of the resources named in the
request list.

These two types of request messages are:

<Who-Provides?>
    This type requires any host receiving the message to return an
    appropriate reply message which names all of the resources from the
    request list which it provides.  If the receiving host provides none
    of the named resources, no reply may be returned.

<Do-You-Provide?>
    This type is identical to the <Who-Provides?> message but with the
    extra requirement that a reply must always be returned.  When a
    receiving host provides none of the requested resources, it simply
    returns an empty reply list.  This empty reply list allows the
    querying host to immediately detect that the confirming host
    provides none of the named resources without having to timeout after
    repeatedly retransmitting the request.

The <Who-Provides?> request message is most typically used when
broadcasting requests to an entire IP network.  The <Do-You-Provide?>
request message, on the other hand, is most typically used when
confirming that a particular host does or does not provide one or more
specific resources.  It may not be broadcast (since such a request would
flood the querying host with reply messages from all hosts on the
network).

In addition to the two basic types of request messages, an additional
two variant types of request messages may also be transmitted by a
querying host.  These message types provide a "third-party" resource
location capability.  They differ from the basic message types by


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

providing space for an additional qualifier with each listed resource to
identify "third-party" hosts which the confirming host believes may
provide the resource.  As before, the first type requires any host
receiving the request message to return a reply message only if it knows
of some host which provides at least one of the resources named in the
request list.  The second type requires any host receiving the message
to always return a reply message even if it knows of no hosts which
provide any of the resources named in the request list.

These two remaining types of request messages are:

<Who-Anywhere-Provides?>
    This message parallels the <Who-Provides?> message with the
    "third-party" variant described above.  The confirming host is
    required to return at least its own IP address (if it provides the
    named resource) as well as the IP addresses of any other hosts it
    believes may provide the named resource.  The confirming host
    though, may never return an IP address for a resource which is the
    same as an IP address listed with the resource name in the request
    message.  In this case it must treat the resource as if it was
    unsupported at that IP address and omit it from any reply list.

<Does-Anyone-Provide?>
    This message parallels the <Do-You-Provide?> message again with the
    "third-party" variant described above.  As before, the confirming
    host is required to return its own IP address as well as the IP
    addresses of any other hosts it believes may provide the named
    resource and is prohibited from returning the same IP address in the
    reply resource specifier as was listed in the request resource
    specifier.  As in the <Do-You-Provide?> case and for the same
    reason, this message also may not be broadcast.

These variant request messages permit "smart" hosts to supply resource
location information for networks without broadcast capability (provided
that all hosts on the network always "know" the address of one or more
such "smart" hosts).  They also permit resource location information for
services which are not provided anywhere on a directly connected network
to be provided by "smart" gateways which have perhaps queried other
networks to which they are attached or have somehow otherwise acquired
the information.

The restriction against returning the same IP address in a reply as was
specified in the request provides a primitive mechanism for excluding
certain known addresses from consideration in a reply (see section 5,
example 3).  It may also be used to override the receiving host's
preference for its own IP address in "third-party" replies when this is
required.





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

3.2. Reply Messages

Each of the types of request messages has an associated type of reply
message.  The basic reply message type is returned in response to both
<Who-Provides?> and <Do-You-Provide?> request messages and supplies
information about the resources provided by the confirming host.  The
other reply message type is the "third-party" variant returned in
response to both <Who-Anywhere-Provides?> and <Does-Anyone-Provide?>
request messages and supplies information about resources provided by
hosts known to the confirming host.

These two types of reply messages are:

<I-Provide>
    This reply message contains a list of exactly those resources from
    the request list which the confirming host provides.  These
    resources must occur in the reply list in precisely the same order
    as they were listed in the request message.

<They-Provide>
    This reply message similarly contains a list of exactly those
    resources from the request list (appropriately qualified with IP
    addresses) which the confirming host provides or believes another
    host provides.  These resources again must occur in the reply list
    in precisely the same order as they were listed in the request
    message.

Neither type of reply message may be broadcast.

A querying host which receives a <They-Provide> reply message from a
confirming host on behalf of a third host is not required to
unquestioningly rely on the indirectly provided information.  This
information should usually be regarded simply as a hint.  In most cases,
the querying host should transmit a specific <Do-You-Provide?> request
to the third host and confirm that the resource is indeed provided at
that IP address before proceeding.

4. Message Formats

RLP messages are encapsulated in UDP packets to take advantage of the
multiplexing capability provided by the UDP source and destination ports
and the extra reliability provided by the UDP checksum.  Request
messages are sent from a convenient source port on the querying host to
the assigned RLP destination port of a receiving host.  Reply messages
are returned from the assigned RLP source port of the confirming host to
the appropriate destination port of the querying host as determined by
the source port in the request message.

The format of the various RLP messages is described in the following
diagrams.  All numeric quantities which occupy more than one octet are


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

stored in the messages from the high order octet to the low order octet
as per the usual Internet protocol standard.  All packet diagrams
indicate the octets of the message from left to right and then top to
bottom as they occur in the data portion of the encapsulating UDP
packet.

Each RLP packet has the general format

                 +--------+--------+--------+--------+
                 |        |        |                 |
                 |  Type  | Flags  |   Message-ID    |
                 |        |        |                 |
                 +--------+--------+--------+--------+
                 |                                   -
                 |           Resource-List           -
                 |                                   -