As per Relevance of the word terminal, we have this rfc below:
Network Working Group J.
Request for Comments: 1735 Telecom
Category: Experimental R.
December 1994
NBMA Address Resolution Protocol (NARP
Status of this
This memo defines an Experimental Protocol for the
community. This memo does not specify an Internet standard of
kind. Discussion and suggestions for improvement are requested
Distribution of this memo is unlimited
IESG Note
Note that the work contained in this memo does not describe
Internet standard. This work represents an early stage in
ongoing efforts to resolve direct communication over NBMA subnets
It is a suitable experimental protocol for early deployment. It
expect that it will be superceded by other work being
within the IETF
This document describes the NBMA Address Resolution Protocol (NARP).
NARP can be used by a source terminal (host or router) connected to
Non-Broadcast, Multi-Access link layer (NBMA) network to find out
NBMA addresses of the a destination terminal provided that
destination terminal is connected to the same NBMA network.
this document focuses on NARP in the context of IP, the technique
applicable to other network layer protocols as well. This RFC is
product of the Routing over Large Clouds Working Group of the IETF
1.
The NBMA Address Resolution Protocol (NARP) allows a source
(a host or router), wishing to communicate over a Non-Broadcast
Multi-Access link layer (NBMA) network, to find out the
addresses of a destination terminal if the destination terminal
connected to the same NBMA network as the source
Heinanen & Govindan [Page 1]
RFC 1735 NBMA ARP (NARP) December 1994
A conventional address resolution protocol, such as ARP [1, 2]
IP, may not be sufficient to resolve the NBMA address of
destination terminal, since it only applies to terminals belonging
the same IP subnetwork, whereas an NBMA network can consist
multiple logically independent IP subnets (LISs, [3]).
Once the NBMA address of the destination terminal is resolved,
source may either start sending IP packets to the destination (in
connectionless NBMA network such as SMDS) or may first establish
connection to the destination with the desired bandwidth and
characteristics (in a connection oriented NBMA network such as ATM).
An NBMA network can be non-broadcast either because it
doesn't support broadcasting (e.g., an X.25 network) or
broadcasting is not feasible for one reason or another (e.g., an
broadcast group or an extended Ethernet would be too large).
2. Protocol
In this section, we briefly describe how a source S uses NARP
determine the NBMA address of a destination D or to find out
such an address doesn't exist. S first checks if the
terminal belongs to the same IP subnetwork as S itself. If so,
resolves the NBMA address of D using conventional means, such as
[1, 2] or preconfigured tables. If D resides in another subnetwork
S formulates a NARP request containing the source and destination
addresses. S then forwards the request to an entity called the "
ARP Server" (NAS).
For administrative and policy reasons, a physical NBMA network may
partitioned into several disjoint logical NBMA networks.
cooperatively resolve the NBMA next hop within their logical
network. In the following we'll always use the term "NBMA network
to mean a logical NBMA network. If S is connected to several
networks, it should have at least one NAS in each of them. In
to know which NAS(s) to query for which destination addresses,
multi-homed S should also be configured to receive
information from its NASs
Each NAS "serves" a pre-configured set of terminals and peers with
pre-configured set of NASs, which all belong to the same
network. A NAS may also peer with routers outside the served NBMA
A NAS exchanges reachability information with its peers (and
with the terminals it serves) using regular routing protocols.
exchange is used to construct a forwarding table in every NAS.
forwarding table determines the next hop NAS towards the
request's destination or a next hop router outside the NBMA
Heinanen & Govindan [Page 2]
RFC 1735 NBMA ARP (NARP) December 1994
After receiving a NARP request, the NAS checks if it "serves" D.
so, the NAS resolves D's NBMA address, using mechanisms beyond
scope of this document (examples of such mechanisms include ARP [1,
2] and pre-configured tables). The NAS then either forwards the
request to D or generates a positive NARP reply on its behalf.
reply contains D's IP and NBMA address and is sent back to S.
replies usually traverse the same sequence of NASs as the
request (in reverse order, of course).
If the NAS does not serve D, it extracts from its forwarding
the next hop towards D. If the next hop is a peer NAS, it
the NARP request to the next hop. If the next hop is a peer
outside the served NBMA or if no such next hop entry is found,
NAS generates a negative NARP reply
A NAS receiving a NARP reply may cache the NBMA address
contained therein. If a subsequent NARP request for the same
address does not desire an authorative reply, a caching NAS can
respond with the cached non-authoritative NBMA address or with
negative information. A well behaving terminal should always
accept a non-authoritative reply. Only if communication
based on the non-authoritative information fails, the terminal
choose to issue another request this time asking for an
reply
NARP requests and replies never cross the borders of an NBMA network
Thus, IP traffic out off and into an NBMA network always traverses
IP router at its border. Network layer filtering can then
implemented at these border routers
3.
To participate in NARP, a terminal connected to an NBMA
should to be configured with the IP address(es) of its NAS(s).
the terminal is attached to several NBMA networks, it should
be configured to receive reachability information from its NAS(s
so that it can determine, which IP destinations are
through which NBMA networks
NBMA ARP
A NAS is configured with a set of IP address prefixes
correspond to the IP addresses of the terminals it is serving
Moreover, the NAS must be configured to exchange
information with its peer NASs (if any). In addition, the NAS
be configured to exchange reachability information with
Heinanen & Govindan [Page 3]
RFC 1735 NBMA ARP (NARP) December 1994
outside the served NBMA. And finally, if a served terminal
attached to several NBMA networks, the NAS may need to
configured to send reachability information to such a terminal
4. Packet
NARP requests and replies are carried in IP packets as protocol
54. This section describes the packet formats of NARP requests
replies
NARP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hop Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA length | NBMA address |
+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NARP version number. Currently this value is 1.
Hop
The Hop count indicates the maximum number of NASs that a
or reply is allowed to traverse before being discarded
The standard IP checksum over the entire NARP packet (starting
the fixed header).
The NARP packet type. The NARP Request has a Type code 1.
A response to an NARP request may contain cached information. If
authoritative answer is desired, then code 2 (NARP Request
Authoritative Information) should be used. Otherwise, a code
of 1 (NARP Request) should be used
Heinanen & Govindan [Page 4]
RFC 1735 NBMA ARP (NARP) December 1994
Source and Destination IP
Respectively, these are the IP addresses of the NARP requestor
the target terminal for which the NBMA address is desired
NBMA Length and NBMA
The NBMA length field is the length of the NBMA address of
source terminal in bits. The NBMA address itself is zero-filled
the nearest 32-bit boundary
NARP
0 1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Version | Hop Count | Checksum |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Type | Code | Unused |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Destination IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| Source IP address |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| NBMA length | NBMA address |
+-+-+-+-+-+-+-+-+ |
| (variable length) |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
The NARP version number. Currently this value is 1.
Hop
The Hop count indicates the maximum number of NASs that a
or reply is allowed to traverse before being discarded
The standard IP checksum over the entire NARP packet (starting
the fixed header).
The NARP packet type. The NARP Reply has a Type code 2.
NARP replies may be positive or negative. A Positive, Non
authoritative Reply carries a code of 1, while a Positive
Authoritative Reply carries a code of 2. A Negative, Non
authoritative Reply carries a code of 3 and a Negative
Authoritative reply carries a code of 4.
Heinanen & Govindan [Page 5]
RFC 1735 NBMA ARP (NARP) December 1994
The general rule is that a NAS should not reply to an NARP
for authoritative information with cached information, but may
so for an NARP request. A NAS implementation is allowed to
this rule and return non-authoritative information even in
authorative was desired if the NAS becomes heavily loaded and
cached information is very recently updated
Source and Destination IP
Respectively, these are the IP addresses of the NARP requestor
the target terminal for which the NBMA address is desired
NBMA Length and NBMA
The NBMA length field is the length of the NBMA address of
destination terminal in bits. The NBMA address itself is zero
filled to the nearest 32-bit boundary. Negative replies do
carry the NBMA length or the NBMA address field
A NAS may cache NBMA replies
5. Protocol
The external behavior of a NAS may be described in terms of
procedures (processRequest and processReply) operating on two
(forwardingTable and cacheTable). In an actual implementation,
code and data structures may be realized differently
Each NAS has a forwardingTable consisting of entries with the fields
The networkLayerAddrPrefix field identifies a set of IP
known to the NAS. It consists of two subfields .
The type field indicates the type of the networkLayerAddrPrefix.
possible values are
- locallyServed: The NAS is itself serving
networkLayerAddrPrefix. The outIf field denotes the NBMA
via which the served terminals can be reached and the
field has no meaning. Such a forwardingTable entry has
created by manual configuration
- nasLearned: The NAS has learned about the
from another NAS. The outIf and outIfAddr fields, respectively
denote the NBMA interface and IP address of this next hop NAS
Such a forwardingTable entry is a result of network layer
prefix information exchange with one of the NAS' peer NASs
Heinanen & Govindan [Page 6]
RFC 1735 NBMA ARP (NARP) December 1994
- externallyLearned: The NAS has learned about
networkLayerAddrPrefix from a peer router outside the served NBMA
The outIf and outIfAddr fields, respectively, denote the
interface and IP address of this next hop NAS. Such
forwardingTable entry is a result of network layer address
information exchange with one of the NAS' peer routers
The protocol used to exchange networkLayerAddrPrefix
among the NASs can be any regular IP intra-domain or inter-
routing protocol
In addition to the forwardingTable, each NAS has an NARP
consisting of entries with the fields
timeStamp
The entries in the cacheTable are learned from NARP
traversing the NAS. In case of a negative cache entry the
is empty. The timeStamp field records the time when the
entry has been created or updated. It is used to determine if
entry is a very recent one and to age old entries after a
hold period
The following pseudocode defines how NBMA NARP requests and
are processed by an NAS
procedure processRequest(request);
let bestMatch == matchForwardingTable(request.dIPa)
if bestMatch
if bestMatch.type == locallyServed
let nbmaAddr == arp(request.dIPa)
if nbmaAddr
genPosAuthReply(request.sIPa, request.dIPa, nbmaAddr
genNegAuthReply(request.sIPa, request.dIPa
elseif bestMatch.type == nasLearned
if not requestForAuthInfo?(request)
realBusyRightNow?()
let cacheMatch == matchCacheTable(request.dIPa)
if cacheMatch
(not requestForAuthInfo?(request)
realRecentCacheEntry?(cacheMatch))
if cacheMatch.nbmaAddr == EMPTY
genNegNonAuthReply(request.sIPa, request.dIPa
genPosNonAuthReply(request.sIPa, request.dIPa
Heinanen & Govindan [Page 7]
RFC 1735 NBMA ARP (NARP) December 1994
cacheMatch.nbmaAddr
else /* no cache match */
forwardRequest(request, bestMatch.OutIf
bestMatch.OutIfAddr
else /* request for authoritative information */
forwardRequest(request, bestMatch.OutIf
bestMatch.OutIfAddr
else /* bestMatch.type == externallyLearned */
genNegAuthReply(request.sIPa, request.dIPa
else /* no match in forwardingTable */
genNegAuthReply(request.sIPa, request.dIPa
procedure processReply(reply);
addCacheTableEntry(reply.dIPa, reply.nbmaAddr, currentTime);
if reply.sIPa == selfIpAddr
/* reply is to the NAS itself */
let bestMatch == matchForwardingTable(reply.sIPa)
if bestMatch
forwardReply(reply, bestMatch.outIf, bestMatch.outIfAddr
The semantics of the procedures used in the pseudocode are
below
matchForwardingTable(ipAddress) returns the forwardingTable
whose networkLayerAddrPrefix field is the longest match for
or FALSE if no match is found
arp(ipAddress) resolves the NBMA address corresponding to ipAddress
It returns FALSE if the resolution fails
genPosAuthReply(sourceIpAddr, destIpAddr, destNbmaAddr)
genPosNonAuthReply(sourceIpAddr, destIpAddr, destNbmaAddr) generate
positive, authoritative and non-authoritative reply
sourceIpAddr, destIpAddr, and destNbmaAddr in Source IP address
Destination IP address, and NBMA Address fields, respectively
Heinanen & Govindan [Page 8]
RFC 1735 NBMA ARP (NARP) December 1994
genNegAuthReply(sourceIpAddr, destIpAddr)
genNegNonAuthReply(sourceIpAddr, destIpAddr) respectively generate
negative, authoritative and non-authoritative reply with
and destIpAddr in Source IP address and Destination IP
fields, respectively
requestForAuthInfo?(request) tests if request is a Request
authoritative information
realBusyRightNow?() returns TRUE if the NAS is heavily loaded
FALSE otherwise
realRecentCacheEntry?(cacheTableEntry) returns TRUE if
cacheTableEntry is very recently updated and FALSE otherwise
matchCacheTable(ipAddr) returns a cacheTable entry
networkLayerAddr field is equal to ipAddr or FALSE if no match
found
forwardRequest(request, interface, ipAddr) decrements the Hop
field of request, recomputes the NARP Checksum field, and
request to ipAddr of interface provided that the value of the
count field remains positive
addCacheTableEntry(ipAddr, nbmaAddr, time) adds a new entry to
cacheTable or overwrites an existing entry whose
field is equal to ipAddr
forwardReply(reply, interface, ipAddr) decrements the Hop count
of request, recomputes the NARP Checksum field, and forwards reply
ipAddr of interface provided that the value of the Hop count
remains positive
Like NASs, each NBMA terminal has a forwardingTable and a cacheTable
The forwardingTable is either manually configured or filled
reachability information exchange with the terminal's NASs or
routers
When the terminal wishes to find out the NBMA address of a
destination terminal, it first checks if a matching entry is found
the forwardingTable. If not, the destination is unreachable and
terminal gives up. If a forwardingTable entry is found, and if
next hop belongs to one of the terminal's NASs, the terminal
consults its cacheTable to obtain the NBMA address. If no
match is found, the terminal generates a NARP request to the next
NAS. If the reply to the NARP request is positive, the
learns the NBMA address and updates its cacheTable with the
information
Heinanen & Govindan [Page 9]
RFC 1735 NBMA ARP (NARP) December 1994
6.
The NARP semantics resembles closely the ATMARP semantics
in [2]. The only actual differences are
- NARP requests and replies include a hop count to prevent them
looping forever in case of misconfigured NAS routing
- NARP request and replies distinguish between authoritative
non-authoritative information
In order to keep the NBMA terminals as simple as possible, it
be desirable to extend the the ATMARP protocol a little further
that it could be also used as the terminal-NAS protocol. This
be easily accomplished just by adding three new operation codes
ATMARP to cover the different kinds of queries and responses.
would then become the NAS-NAS protocol. Finally, if the NASs
co-located with the "classical" ATM ARP servers, the terminals
not need to make any distinction between between local and foreign
subnetworks
The NASs can also act as "connectionless servers" for the terminal
advertizing to it all destinations no matter if they are inside
outside the served NBMA. Then, the terminal could choose either
try to resolve the NBMA address of the destination or just to
the IP packets to the NAS. The latter option may be desirable
communication with the destination is short-lived and/or doesn'
require much network resources
NARP supports portability of NBMA terminals. A terminal can be
anywhere within the NBMA network and still keep its original
address as long as its NAS(s) remain the same. Requests
authoritative information will always return the correct
address
[1] Plummer, D., "An Ethernet Address Resolution Protocol - or -
Converting Network Protocol Addresses to 48.bit Ethernet
for Transmission on Ethernet Hardware", STD 37, RFC 826, MIT
November 1982.
[2] Laubach, M., "Classical IP and ARP over ATM", RFC 1577, Hewlett
Packard Laboratories, January 1994.
[3] Piscitello, D., and J. Lawrence, "Transmission of IP
over the SMDS Service, RFC 1209, Bell Communications Research
March 1991.
Heinanen & Govindan [Page 10]
RFC 1735 NBMA ARP (NARP) December 1994
We would like to thank John Burnett of Adaptive, Dennis Ferguson
ANS, Joel Halpern of Network Systems, and Paul Francis of
for their valuable insight and comments to earlier versions of
draft
Security
Security issues are not discussed in this memo
Authors'
Juha
Telecom
PO Box 228
SF-33101
Phone: +358 49 500 958
EMail: Juha.Heinanen@datanet.tele.
Ramesh
USC/Information Sciences
4676 Admiralty
Marina del Rey, CA 90292
Phone: +1 310-822-1511
EMail: govindan@isi.
Heinanen & Govindan [Page 11]
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
