As per Relevance of the word resource, we have this rfc below:
Network Working Group M.
Request for Comments: 887 Carnegie-Mellon
December 1983
RESOURCE LOCATION
This note describes a resource location protocol for use in the
Internet. It is most useful on networks employing technologies
support some method of broadcast addressing, however it may also be
on other types of networks. For maximum benefit, all hosts
provide significant resources or services to other hosts on the
should implement this protocol. Hosts failing to implement the
Location Protocol risk being ignored by other hosts which are
to locate resources on the Internet. This RFC specifies a
standard for the ARPA Internet community
The Resource Location Protocol (RLP) utilizes the User Datagram
(UDP) [1] which in turn calls on the Internet Protocol (IP) [3]
deliver its datagrams. See Appendix A and [6] for the appropriate
and protocol number assignments
Unless otherwise indicated, all numeric quantities in this document
decimal numbers
1.
From time to time, Internet hosts are faced with the problem
determining where on the Internet some particular network service
resource is being provided. For example, this situation will arise
a host needs to send a packet destined for some external network to
gateway on its directly connected network and does not know of
gateways. In another case, a host may need to translate a domain
to an Internet address and not know of any name servers which it can
to perform the translation. In these situations a host may use
Resource Location Protocol to determine this information
In almost all cases the resource location problem is simply a matter
finding the IP address of some one (usually any) host, either on
directly connected network or elsewhere on the Internet,
understands a given protocol. Most frequently, the querying host
understands the protocol in question. Typically (as in the case
locating a name server), the querying host subsequently intends
employ that protocol to communicate with the located host once
address is known (e.g. to request name to address translations).
frequently, the querying host itself does not necessarily understand
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.
determine an appropriate place to forward a packet which cannot
delivered locally).
Accetta [Page 1]
RFC 887 December 1983
Resource Location
2. Resource
Although the resource location problem can, in most cases, be reduced
the problem of finding a host which implements a given Internet
protocol, locating only a particular lowest level Internet
(i.e. one assigned a protocol number for transport using IP) is
completely sufficient. Many significant network services and
are provided through higher level protocols which merely utilize
various lower level protocols for their own transport purposes (e.g.
FTP protocol [2] employs the TCP protocol [4] for its lower
transport). Conceptually, this protocol nesting may even be carried
to arbitrary levels
Consequently, the Resource Location Protocol names a resource by
protocol number assigned to its lowest level Internet transport
and by a variable length protocol/resource specific identifier.
example, the UDP based Echo Protocol can be named by its
protocol number (17) and its assigned 16-bit "well-known" port
(7). Alternatively, the Internet Control Message Protocol [5] (
any higher level client protocols) would be named simply by its
protocol number (1) and an empty protocol specific identifier. On
other hand, some as yet undefined resource protocol (provided via
TCP), might be named by the assigned protocol number (6), its 16-
"well-known" TCP port number, and then some additional fixed or
length identifier specific to that TCP port
In general, the components of the protocol/resource specific
are defined to be the "natural" quantities used to
de-multiplex the protocol at each next highest protocol level.
section 5 for some sample assignments
3. Protocol
The Resource Location Protocol is a simple request/reply procedure.
querying host constructs a list of resources which it would like
locate and sends a request message on the network. A request
may be sent either to a particular IP address and host or, on
which provide broadcast address capability, to the IP address
refers to all hosts on that network (see [7]). For example, a
attempting to locate a domain name server might construct a
containing the resource name [17, 53] (referring to the Domain
Server protocol provided at "well-known" UDP port 53) and then
that request on its local network
Each receiving host examines the list of resources named in the
packet, determines which of the resources it provides, and returns
reply message to the querying host in confirmation. The receiving
determines whether or not it provides a resource by
decomposition of the resource name until either the name is exhausted
it encounters a component which is not supported. In the
Accetta [Page 2]
RFC 887 December 1983
Resource Location
example, each host on the network receiving the broadcast request
examine the resource name by first consulting its tables to determine
it provided UDP service. If this was successful, it would then
the UDP port component of the name and consult its UDP table
determine if it provided service on UDP port 53. At this point the
would be exhausted and if both checks were successful the host
return a reply message to the querying host indicating support for
resource
3.1. Request
RLP provides two basic types of request messages which may
transmitted by a querying host. The first type requires any
receiving the request message to return a reply message only if
provides at least one of the resources named in the request list.
second type requires any host receiving the message to always return
reply message even if it provides none of the resources named in
request list
These two types of request messages are
Provides?>
This type requires any host receiving the message to return
appropriate reply message which names all of the resources from
request list which it provides. If the receiving host provides
of the named resources, no reply may be returned
This type is identical to the Provides?> message but with
extra requirement that a reply must always be returned. When
receiving host provides none of the requested resources, it
returns an empty reply list. This empty reply list allows
querying host to immediately detect that the confirming
provides none of the named resources without having to timeout
repeatedly retransmitting the request
The Provides?> request message is most typically used
broadcasting requests to an entire IP network. The
request message, on the other hand, is most typically used
confirming that a particular host does or does not provide one or
specific resources. It may not be broadcast (since such a request
flood the querying host with reply messages from all hosts on
network).
In addition to the two basic types of request messages, an
two variant types of request messages may also be transmitted by
querying host. These message types provide a "third-party"
location capability. They differ from the basic message types
Accetta [Page 3]
RFC 887 December 1983
Resource Location
providing space for an additional qualifier with each listed resource
identify "third-party" hosts which the confirming host believes
provide the resource. As before, the first type requires any
receiving the request message to return a reply message only if it
of some host which provides at least one of the resources named in
request list. The second type requires any host receiving the
to always return a reply message even if it knows of no hosts
provide any of the resources named in the request list
These two remaining types of request messages are
Provides?>
This message parallels the Provides?> message with
"third-party" variant described above. The confirming host
required to return at least its own IP address (if it provides
named resource) as well as the IP addresses of any other hosts
believes may provide the named resource. The confirming
though, may never return an IP address for a resource which is
same as an IP address listed with the resource name in the
message. In this case it must treat the resource as if it
unsupported at that IP address and omit it from any reply list
This message parallels the message again with
"third-party" variant described above. As before, the
host is required to return its own IP address as well as the
addresses of any other hosts it believes may provide the
resource and is prohibited from returning the same IP address in
reply resource specifier as was listed in the request
specifier. As in the case and for the
reason, this message also may not be broadcast
These variant request messages permit "smart" hosts to supply
location information for networks without broadcast capability (
that all hosts on the network always "know" the address of one or
such "smart" hosts). They also permit resource location information
services which are not provided anywhere on a directly connected
to be provided by "smart" gateways which have perhaps queried
networks to which they are attached or have somehow otherwise
the information
The restriction against returning the same IP address in a reply as
specified in the request provides a primitive mechanism for
certain known addresses from consideration in a reply (see section 5,
example 3). It may also be used to override the receiving host'
preference for its own IP address in "third-party" replies when this
required
Accetta [Page 4]
RFC 887 December 1983
Resource Location
3.2. Reply
Each of the types of request messages has an associated type of
message. The basic reply message type is returned in response to
Provides?> and request messages and
information about the resources provided by the confirming host.
other reply message type is the "third-party" variant returned
response to both Provides?> and
request messages and supplies information about resources provided
hosts known to the confirming host
These two types of reply messages are
This reply message contains a list of exactly those resources
the request list which the confirming host provides.
resources must occur in the reply list in precisely the same
as they were listed in the request message
This reply message similarly contains a list of exactly
resources from the request list (appropriately qualified with
addresses) which the confirming host provides or believes
host provides. These resources again must occur in the reply
in precisely the same order as they were listed in the
message
Neither type of reply message may be broadcast
A querying host which receives a reply message from
confirming host on behalf of a third host is not required
unquestioningly rely on the indirectly provided information.
information should usually be regarded simply as a hint. In most cases
the querying host should transmit a specific
to the third host and confirm that the resource is indeed provided
that IP address before proceeding
4. Message
RLP messages are encapsulated in UDP packets to take advantage of
multiplexing capability provided by the UDP source and destination
and the extra reliability provided by the UDP checksum.
messages are sent from a convenient source port on the querying host
the assigned RLP destination port of a receiving host. Reply
are returned from the assigned RLP source port of the confirming host
the appropriate destination port of the querying host as determined
the source port in the request message
The format of the various RLP messages is described in the
diagrams. All numeric quantities which occupy more than one octet
Accetta [Page 5]
RFC 887 December 1983
Resource Location
stored in the messages from the high order octet to the low order
as per the usual Internet protocol standard. All packet
indicate the octets of the message from left to right and then top
bottom as they occur in the data portion of the encapsulating
packet
Each RLP packet has the general
+--------+--------+--------+--------+
| | | |
| Type | Flags | Message-ID |
| | | |
+--------+--------+--------+--------+
| -
| Resource-List -
| -
+--------+--------+--------+---\\---+
- +
- Resource-List |
- |
+--------+--------+--------+---\\---+
is a single octet which identifies the message type. The
defined types are
0 Provides?>
1
2 Provides?>
3
4
5
6-255 Reserved
Accetta [Page 6]
RFC 887 December 1983
Resource Location
is a single octet specifying possible modifications to the
interpretation of . Bits in this field are numbered from
to right (from most significant to least significant) beginning
bit 1. The currently defined flag bits are
Bit 1 . Requires that any reply message generated
response to a request message with this flag bit set
only name IP addresses which are on the same IP network
the sender of the request message. This flag also
that multi-homed hosts answering broadcast Provides?>
requests use the appropriate local network IP
address in the returned reply. This bit must be zero
reply messages
Bits 2-8 Reserved. Must be zero
is a two octet (16-bit) value which identifies the request message
It is used simply to aid in matching requests with replies.
sending host should initialize this field to some convenient
when constructing a request message. The receiving host must
this same value in the field of any reply
generated in response to that request
<Resource-List
is the list of resources being queried or for which
information is being supplied. This list is a sequence of
beginning at the octet following the and
through the end of the UDP packet. The format of this field
explained more fully in the following section. The size of
list is implicitly specified by the length of the encapsulating
datagram
4.1. Resource
A <Resource-List> consists of zero or more resource specifiers.
resource specifier is simply a sequence of octets. All
specifiers have a common resource name initial
+--------+--------+--------+---\\---+
| | | |
|Protocol|IDLength| Resource-ID |
| | | |
+--------+--------+--------+---\\---+
Accetta [Page 7]
RFC 887 December 1983
Resource Location
<Protocol
is the protocol number assigned to the lowest level
protocol utilized for accessing the resource
is the length of the resource identifier associated with
<Protocol>. This length may be a fixed or variable value
on the particular resource. It is included so that specifiers
refer to resources which a host may not provide can be skipped
without needing to know the specific structure of the
resource identifier. If the <Protocol> has no associated
identifier, this length is 0.
<Resource-ID
is the qualifying identifier used to further refine the
being queried. If the field was 0, then this field
empty and occupies no space in the resource specifier
In addition, resource specifiers in all Provides?>,
and messages also contain
additional qualifier following the <Protocol-ID>. This qualifier
the
+--------+--------+--------+--------+---//---+
| | |
|IPLength| IP-Address-List |
| | |
+--------+--------+--------+--------+---//---+
Accetta [Page 8]
RFC 887 December 1983
Resource Location
is the number of IP addresses containing in the
(the field thus occupies
last 4* octets in its resource specifier). In
messages, this is the maximum number of qualifying addresses
may be included in the corresponding reply resource specifier
Although not particularly useful, it may be 0 and in that
provides no space for qualifying the resource name with IP
in the returned specifier. In reply messages, this is the number
qualifying addresses known to provide the resource. It may
exceed the number specified in the corresponding request specifier
This field may not be 0 in a reply message unless it was supplied
0 in the request message and the confirming host would have
one or more IP addresses had any space been provided
is a list of four-octet IP addresses used to qualify the
specifier with respect to those particular addresses. In
messages, these are the IP addresses of the confirming host (
appropriate) and the addresses of any other hosts known to
that resource (subject to the list length limitations). In
messages, these are the IP addresses of hosts for which
information may not be returned. In such messages, these
should normally be initialized to some "harmless" value (such as
address of the querying host) unless it is intended to
exclude the supplied addresses from consideration in any
messages
The receiving host determines if it provides any of the resources
in the request list by successively decomposing each resource name.
first level of decomposition is the Internet protocol number which
presumably be looked up in a table to determine if that protocol
supported on the host. Subsequent decompositions are based on
components until one of three events occur
1. the current component identifies some aspect of the
components which the host does not support
2. the resource name from the request list is exhausted,
3. the resource name from the request list is not exhausted
the host does not expect any further components in the
given the previous
In case 1, the receiving host has determined that it does not
the named resource. The resource specifier may not be included in
reply message returned
In case 2, the receiving host has determined that it does indeed
the named resource (note: this may occur even if the receiving
Accetta [Page 9]
RFC 887 December 1983
Resource Location
would have expected the resource name to contain more components
were actually present). The resource specifier must be included (
IP address prohibitions) in any reply message returned
In case 3, the receiving host has determined that it does not
provide the named resource since name components remain which it
not understand (this might occur with specializations of or
to a known protocol which are not universally recognized). The
specifier may not be included in any reply message returned
5. Sample
The following scenarios illustrate some typical uses of RLP. In
cases the indicated messages are encapsulated in a UDP datagram with
appropriate source and destination port numbers, message length,
checksum. This datagram is further encapsulated in an IP datagram
the appropriate source address of the sending host and
address (either broadcast or individual) for the receiving host
All numeric protocol examples are as specified in the
protocol description documents listed in the references
1. Suppose a freshly rebooted host H wishes to find some
on its directly connected network to which it can send
first external packet. It then broadcasts the
Provides?> = =12345
<Resource-List>={[GGP], [EGP]}
encoded as the 8 octet
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 128 | 12345 | 3 | 0 | 8 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
on its local network
- Gateway G1 (which understands EGP) receives the request
returns the
=none =12345
<Resource-List>={[EGP]}
encoded as the 6 octet
+-----+-----+-----+-----+-----+-----+
| 4 | 0 | 12345 | 8 | 0 |
+-----+-----+-----+-----+-----+-----+
to host H which then remembers that gateway G1 may be
Accetta [Page 10]
RFC 887 December 1983
Resource Location
to route traffic to the rest of the Internet
- At the same time, gateway G2 (which understands both
and EGP) might also receive the request and return the
=none =12345
<Resource-List>={[GGP], [EGP]}
encoded as the 8 octet
+-----+-----+-----+-----+-----+-----+-----+-----+
| 4 | 0 | 12345 | 3 | 0 | 8 | 0 |
+-----+-----+-----+-----+-----+-----+-----+-----+
to host H which might then also add gateway G2 to its
if it chooses
2. Assume instead that host H is a stand-alone system which
just encountered some fatal software error and wishes to
a crash dump server to save its state before reloading
Suppose that the crash dump protocol on the host's
network is implemented using the Trivial File Transfer
(TFTP) [8]. Furthermore, suppose that the special file
"CRASH-DUMP" is used to indicate crash dump processing (e.g
the server might locally generate a unique file name to
each dump that it receives from a host). Then host H
broadcast the
Provides?> =none =54321
<Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}
encoded as the 21 octet
+-----+-----+-----+-----+-----+-----+-----+-----+
| 0 | 0 | 54321 | 17 | 15 | 69 |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | 'C' 'R' 'A' 'S' 'H' '-' |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 'D' 'U' 'M' 'P' 0 |
+-----+-----+-----+-----+-----+
to its local network (note that the file name component
explicitly terminated by a null so as not to exclude
further specialization of the crash dump protocol).
- Host C (which supports this specialization of the
protocol) receives the request and returns the
=none =54321
<Resource-List>={[UDP, TFTP, WRQ, "CRASH-DUMP"]}
Accetta [Page 11]
RFC 887 December 1983
Resource Location
encoded as the 21 octet
+-----+-----+-----+-----+-----+-----+-----+-----+
| 4 | 0 | 54321 | 17 | 15 | 69 |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 2 | 'C' 'R' 'A' 'S' 'H' '-' |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 'D' 'U' 'M' 'P' 0 |
+-----+-----+-----+-----+-----+
to host H which may then proceed to send its crash dump
host C and reload
- Host D (which provides TFTP service but not the crash
specialization), however, might receive the request
determine that it provides no support for the
(since the resource name contains components following
UDP port number which it does not understand). It
therefore return no reply to host H.
3. Finally, suppose host M wishes to locate some domain
translation server (either UDP or TCP based) anywhere on
Internet. Furthermore, suppose that host M is on a IP
which does not provide broadcast address capabilities and
host R is a "known" resource location server for that network
First, since host M prefers to find a domain name server on
own locally connected network if possible, it sends the
=
=12321 <Resource-List>=
{[TCP, ] {M},
[UDP, ] {M}}
encoded as the 22 octet
+-----+-----+-----+-----+
| 3 | 128 | 12321 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 2 | 53 | 1 | M |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 17 | 2 | 53 | 1 | M |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
to host R.
Host R receives the request and consults its tables for
hosts known to support either variety of domain name service
It finds entries indicating that both hosts S and T provide
Accetta [Page 12]
RFC 887 December 1983
Resource Location
based domain name service but that neither host is on the
IP network as host H. It must then send the
confirmation
=none =12321
<Resource-List>={}
encoded as the 4 octet
+-----+-----+-----+-----+
| 5 | 0 | 12321 |
+-----+-----+-----+-----+
back to host M.
Host M, receiving this reply, might now abandon any hope
finding a server on its own network, reformat its request
permit any host address, and
=none =12322
<Resource-List>=
{[TCP, ] {M},
[UDP, ] {M}}
encoded as the 22 octet
+-----+-----+-----+-----+
| 3 | 0 | 12322 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 2 | 53 | 1 | M |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 17 | 2 | 53 | 1 | M |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
again to host R.
Host R receives this new request and is no longer
to return only local addresses. However, since only space
a single qualifying IP address was provided in each
resource specifier, it may not immediately return
addresses. Instead, it is forced to return only the
address and
=none =12322
<Resource-List>={[UDP, ] {S}}
encoded as the 13 octet
Accetta [Page 13]
RFC 887 December 1983
Resource Location
+-----+-----+-----+-----+-----+-----+-----+-----+
| 5 | 0 | 12322 | 17 | 2 | 53 |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | S |
+-----+-----+-----+-----+-----+
to Host M.
Host M receives the reply and (being the suspicious sort
decides to confirm it with host S. It then
=none =12323
<Resource-List>={[UDP, ]}
encoded as the 8 octet
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 0 | 12323 | 17 | 2 | 53 |
+-----+-----+-----+-----+-----+-----+-----+-----+
to host S and receives back from host S the
=none =12323
<Resource-List>={}
encoded as the 4 octet
+-----+-----+-----+-----+
| 4 | 0 | 12323 |
+-----+-----+-----+-----+
denying any support for UDP based domain name service
In desperation host M again queries host R, this time
host S from consideration, and sends the
=none =12324
<Resource-List>=
{[TCP, ] {S},
[UDP, ] {S}}
encoded as the 22 octet
+-----+-----+-----+-----+
| 3 | 0 | 12324 |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 6 | 2 | 53 | 1 | S |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
| 17 | 2 | 53 | 1 | S |
+-----+-----+-----+-----+-----+-----+-----+-----+-----+
Accetta [Page 14]
RFC 887 December 1983
Resource Location
and this time receives the
=none =12324
<Resource-List>={[UDP, ] {T}}
encoded as the 13 octet
+-----+-----+-----+-----+-----+-----+-----+-----+
| 5 | 0 | 12324 | 17 | 2 | 53 |
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | T |
+-----+-----+-----+-----+-----+
from host R which of course host M again insists on
by sending the
=none =12325
<Resource-List>=
{[UDP, ]}
encoded as the 8 octet
+-----+-----+-----+-----+-----+-----+-----+-----+
| 1 | 0 | 12325 | 17 | 2 | 53 |
+-----+-----+-----+-----+-----+-----+-----+-----+
to host T and finally receives confirmation from host T
the
=none =12325
<Resource-List>={[UDP, ]}
encoded as the 8 octet
+-----+-----+-----+-----+-----+-----+-----+-----+
| 4 | 0 | 12325 | 17 | 2 | 53 |
+-----+-----+-----+-----+-----+-----+-----+-----+
that it indeed provides domain name translation service at
port 53.
A. Assigned
The "well-known" UDP port number for the Resource Location Protocol
39 (47 octal).
Accetta [Page 15]
RFC 887 December 1983
Resource Location
[1] Postel, J
User Datagram Protocol
RFC 768, USC/Information Sciences Institute, August, 1980.
[2] Postel, J
File Transfer Protocol
RFC 765, USC/Information Sciences Institute, June, 1980.
[3] Postel, J
Internet Protocol - DARPA Internet Program Protocol Specification
RFC 791, USC/Information Sciences Institute, September, 1981.
[4] Postel, J
Transmission Control Protocol- DARPA Internet Program
Specification
RFC 793, USC/Information Sciences Institute, September, 1981.
[5] Postel, J
Internet Control Message Protocol - DARPA Internet
Protocol Specification
RFC 792, USC/Information Sciences Institute, September, 1981.
[6] Reynolds, J., and J. Postel
Assigned Numbers
RFC 870, USC/Information Sciences Institute, October, 1983.
[7] Gurwitz, R., and R. Hinden
IP - Local Area Network Addressing Issues
IEN 212, Bolt Beranek and Newman, September, 1982.
[8] Sollins, K
The TFTP Protocol (revision 2).
RFC 783, MIT/Laboratory for Computer Science, June, 1981.
Accetta [Page 16]
if you see any problems within the linking, don't worry be happy,
this is version 0.1 of the Relevance System and you gotta expect some crappy subroutines sometimes,
just be content we did not write this in Java, which would have made this "bigger and better" HAHAHHA.
RFC documents can be found at I.E.T.F.
Relevance System Copyright © 2002 Spectrum WorldResearch
other technical nosh by ServerMasters Corporation
collaboration of BobX
