RFC 887 (rfc887) - Page 1 of 16
Resource Location Protocol
Alternative Format: Original Text Document
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
