Resource Location Protocol
RFC 887

Document Type RFC - Experimental (December 1983; No errata)
Last updated 2013-03-02
Stream Legacy
Formats plain text pdf html bibtex
Stream Legacy state (None)
Consensus Boilerplate Unknown
RFC Editor Note (None)
IESG IESG state RFC 887 (Experimental)
Telechat date
Responsible AD (None)
Send notices to (None)
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
Show full document text