As per Relevance of the word hardware, we have this rfc below:

---

Network Working Group G.
Request For Comments: 1029 University of
May 1988


A MORE FAULT TOLERANT APPROACH TO ADDRESS RESOLUTION
A MULTI-LAN SYSTEM OF

STATUS OF THIS

This memo discusses an extension to a Bridge Protocol to detect
disclose changes in neighbouring host address parameters in a Multi
LAN system of Ethernets. The problem is one which is appearing
and more regularly as the interconnected systems grow larger
Campuses and in Commercial Institutions. This RFC suggests
protocol enhancement for the Internet community, and
discussion and suggestions for improvements. Distribution of
memo is unlimited



Executing a protocol P, a sending host S decides, through P's
mechanism, that it wants to transmit to a target host T
somewhere on a connected piece of 10Mbit Ethernet cable
conforms to IEEE 802.3. To actually transmit the Ethernet packet,
48 bit Ethernet/hardware address must be generated. The
assigned to hosts within protocol P are not always compatible
the corresponding Ethernet address (being different address
byte orderings or values). A protocol is presented which
dynamic distribution of the information required to build tables
translate a host's address in protocol P's address space into a 48
bit Ethernet address. An extension is incorporated to allow such
protocol to be flexible enough to exist in a Transparent Bridge,
generic Host. The capability of the Bridge to detect host
conditions in a multi-LAN environment is also discussed,
particularly the effect on channel bandwidth. To illustrate
operation of the protocol mechanisms, the Internet Protocol (IP)
used as a benchmark [6], [8]. Part 1 presents an introduction
Address Resolution, whilst Part 2 discusses a reboot
process

DEFINITIONS

CATENET: a group of IP networks linked
IP : Internet






Parr [Page 1]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


PART 1



In the Ethernet, while all packets are broadcast, the
interface selects only those with either the explicit
broadcast address or the individual hardware address of
interface. Packets which do not have one of these two addresses
rejected by the interface and do not get passed to the host software
This saves a great deal of otherwise wasted effort by the
software having to examine packets and reject them. If the
hardware selected packets to pass to the host software by means
the protocol address, there would be no need for any translation
protocol to Ethernet address. Although it is very important
minimize the number of packets which each host must examine,
reducing especially needless inspections, use of the
broadcast address should be confined to those situations where it
uniquely beneficial. Perhaps if one were designing a new
network one could eliminate the need for an address translation,
in the real world of existing networks it fills a very
purpose. A rare use of the broadcast hardware address, which
putting any processing load on the other hosts of the Ethernet,
where hosts obtain the information they need to use the specific
individual hardware addresses to exchange most of their packets

REASONING BEHIND ADDRESS

The process of converting from the logical host address to
physical Ethernet address has been termed ADDRESS RESOLUTION, and
prompted research into a method which can be easily interfaced
whilst at the same time remaining portable

The Ethernet requires 48 bit addresses on the physical cable [11]
to the fact that the manufacturers of the LAN interface
assign a unique 48 bit address during production. Of course,
Managers do not want to be bothered using this address to
the destination at the higher-level. Rather, they would prefer
assign their logical names to the hosts within their supervision,
allow some lower level protocol to perform a resolving operation
Most of these logical protocol addresses are not 48 bits long, nor
they necessarily have any relationship to the 48 bit address space

For example, IP addresses have a 32 bit address space [6],
giving rise to the need to distribute dynamically the
between a PROTOCOL-ADDRESS> pair, and a 48 bit
address





Parr [Page 2]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


EXAMPLE ARP

Here is a review of the operation of ARP as defined in RFC-826 [5].
Let hosts X and Y exist on the same Ethernet cable. They
physical Ethernet addresses EA(X), and EA(Y), and DoD
addresses IPA(X), and IPA(Y). Let the Ethernet type of Internet
ET(IP). Host X begins an application, and sooner or later wishes
communicate an Internet packet to host Y. Host X has knowledge
the Internet address of Y, i.e., (IPA(Y)), and informs the
level that it wishes to talk to IPA(Y). The lower-level
consults the ARP Module (ARM) to convert into a 48
bit Ethernet address but because X has not talked to Y previously,
does not have this information in its Translation Cache (TC).
discards (or queues) the Internet packet, and creates a new
Resolution packet with

PACKET FIELD VALUE

HRDTYP

PROTYP ET(IP

HRDLEN length (EA(X))

PROTLEN length (IPA(X))

ARPOPC

SOURCE HWR EA(X

SOURCE PROT IPA(X

TARGET HWR don't

TARGET PROT IPA(Y

It then broadcasts this packet to all hosts on the connecting cable
Host Y picks up this packet and determines that it understands
hardware type (Ethernet), that it speaks the indicated
(Internet), and that the packet is for it, that is, TARGET
ADDRESS = IPA(Y). Replacing any previous entry, it enters
information that that this is an ARREQ packet, so it swaps fields, placing EA(Y)
the new sender Ethernet address field SOURCE HARDWARE ADDRESS, EA(X
as TARGET HARDWARE ADDRESS, IPA(X) as TARGET PROTOCOL ADDRESS, IPA(Y
as SOURCE PROTOCOL ADDRESS, and sets the opcode to REPLY. The
is then sent with direct routing address information to EA(X). Thus
Y now knows how to send to X, but X still doesn't know EA(Y).



Parr [Page 3]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


When X receives the ARREP packet from Y, it gets the
information into its translation cache ET(IP),IPA(Y)>-->EA(Y),
notices that it is a REPLY, and discards the packet (i.e.,
of the dynamic packet buffer). However, if the original
Module packet had been queued, it could have been accessed and
the full addressing information from the translation cache
Alternatively, had it been discarded, the higher level would
succeeded on a subsequent attempt, and the Internet packet would
transmitted immediately

OBTAINING GREATER NETWORKING

There are many benefits to be gained in dividing a large
network into smaller, more manageable networks. These include :
Security; Overall Network Reliability; Performance Enhancement;
to mention the most obvious: Greater Networking Range. In
network technologies, cable length may be stipulated not to exceed
certain range due to electrical limitations. By installing a Bridge
this restriction is effectively eliminated. An
consideration is the effect the induced Bridge delays will have
the protocol timeouts in operation on each LAN/Subnet.
analysis of upper bounds on timeouts would have to be made in
to gain full benefit from the increased range. In the case
Ethernet the following system parameters exist [11], [12]:

- the bus bandwidth is 10Mbit/

- the maximum node-to-node cable length is 1500

- the maximum point-to-point link cable length is 1000

- the maximum number of repeaters between two nodes is

- the worst case end-to-end bus propagation delay is 22.5

- the jam time after collision is 32

- the minimum interframe time is 9.6

- the slot size is 512 bit = 51.2

Once a decision has being taken to subnet, the resulting subLANs
be connected by including a Bridge to link them together
providing a protocol which makes the collection of subnets appear
a single network. The basic idea of the Bridge providing 'repeater
facilities would not suffice in this application. Moreover,
Bridge would have to have further 'intelligence' to enable it
select those packets which are destined for remote networks based



Parr [Page 4]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


the protocol address of the target host. Thereby preventing it
forwarding packets needlessly that will not be accepted. If
procedure was not adhered to, the channel bandwidth on the
networks would be inundated with packets, causing local valid
to backoff and the efficiency of the respective networks to
decrease

One problem fundamental to the operation of the Bridge is how
discovers on which LAN a particular host is interfaced. If there
only two LANs in the system, each will have a dedicated cache at
Bridge, and when a packet is received at the particular interface
the source host's address parameters are entered in the
LAN cache. However, when we consider a Multi-LAN environment,
procedure becomes more complicated

___
|
|-----h
| E
|-----hq |-----------------------|
| _ | |
|-----hx | | B1 | |
|---------------| | | |
|-----h1 |_| | |
| | h19 | | ______
| | | | | -----|______| B
| | | | | B3 |
|-----he |-------------------| E2 |_| |
| | | |
|-----h5 | | |
| | | |
| --- --- | |
--- | | |------- |
E1 | | B2 | |
| |-----------------| |
--- | |
| |---------------------
--- |
E3 |
|
FIGURE 1. A MULTI-LAN


In the normal set-up, whenever B3 or B4 would receive a packet on E4,
they would both update the caches on their E4 interface.
addition, a method must be provided to permit B4 to
between packets arriving on E4 from E1, E2, E3, and those
actually originated on E4.



Parr [Page 5]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


This is so that packets can be categorized as being of remote
local source and processed accordingly. The most obvious solution
for each Bridge to act as an AGENT and plug in its address as
source of any packets it cascades to a remote network, instead of
packet being cascaded with its original source address. At
boot, it may issue a broadcast request for all locally
hosts/devices to return their local network protocol addresses.
subsequent receipt of this information, the Bridge could then
the cache for each of its interfaces so that it would now have a
from which to perform future operations

The alternative to this automatic procedure is to permit
intervention in the Bridge software which could be activated by
network manager in order to key in the addresses of the
connected to each LAN interface

Thus, having provided a means for the Bridge to obtain the
state of the LAN addresses when it boots, how then does the
distinguish the arrival of a new host on the locally connected
from transmissions which were sent from a remote source and
by an adjacent Bridge? Two approaches are currently
consideration to solve this problem, namely Explicit Subnets,
Transparent Subnets [4], [7], [9], [14].

In the Explicit Subnet approach, the location of the host in
system is important. The address of the host in the protocol
will reflect which subnet the host is interfaced to.
the protocol address space is divided into a three level hierarchy
. Within the Internet there are five
divisions in operation [10], classes A, B, C, D, and E. Classes
and E relate to an addressing technique that will be used
management of multi-casting groups and will not be discussed here
With such a structure, it is possible to provide an address mask
each interface so that received packets may have their source
fields examined and compared with the address mask of this LAN.
so doing, the component which is being verified is actually
subnet address. If the masking operation is successful the
must exist on this LAN, otherwise it must be remote

With the Transparent scheme, the first time a newly booted
'speaks' it will be looking for addressing information (
using BOOTSTRAP [1], RARP [2] or ARP [5]). Accordingly, the
will detect these respective requests and be in a position to
operations on the address parameters. The current approach
Transparent Subnetting is that before any such requests can
cascaded by the Bridge to an adjacent LAN, that Bridge will place
interface address parameters into the source address fields,
acting as the AGENT. Therefore, this Bridge will 'see'



Parr [Page 6]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


packets arriving from the remote Bridge address, or local packets
By virtue of the RARP/ARP operation, which hosts perform when
first come up, any hi-level packets received on to the network
having the bridge address, and not having a mapping in the cache
that LAN, can be considered as being remote

Currently, there is a move toward the Transparent subnet
originally described by Postel [7]. This has been due mainly
practical problems of incompatible implementations from
vendors, and the restrictions that the Explicit address space
on the adaptability of the system to change (class C addresses
not flexible enough for the Explicit scheme). It is also the
of the Author of this paper that the Agent technique adopted by
Bridges could have shortcomings in a dynamic environment which
be detrimental to its operation; for example, where the
themselves relocate or crash, or in the management of the "Agent
Who" cache at the bridge. Insofar as Loop Resolution
SelfStabilization after failure are Bridge problems that need to
addressed, it is strongly felt their satisfactory solution will
supported by elimination of the Agent technique [13].

BRIDGE

Referring to figure 1, assume that at some stage during
processing [E1H3] wishes to communicate with [E2H19]. [E1H3]
knowledge of the Internet address of [E2H19] from its
cache, but will not require the knowledge that [E2H19] exists on
completely different subnet. [E1H3] calls its Internet Module
transmit the packet. As detailed, the usual procedure of
control to its ARM is performed in an attempt to obtain
translation. If we assume that [E1H3], and [E2H19] have not
before, the ARM in [E1H3] will not be able to resolve the
on the first attempt

In such a case, an ARREQ packet is assembled and broadcast to
hosts on the network [E1]. The packet traverses the cable and
eventually picked up by the (B1) Bridge Address Resolution
(BARM), whereupon it determines whether or not it should intervene
the request. If the target is determined as remote (i.e., having
match in the local cache), the BARM examines its Global
Cache (GTC) to determine if it has an entry for <protocol,[E2H19]>.
Should a mapping be obtained at the Bridge, there is no need for
broadcast REQUEST packet to be cascaded on to the remote
[E2]. It is therefore assumed that the entries in the GTC
the most current addressing information. A match thus obtained,
original ARREQ packet buffer is adapted as required and
directly to [E1H3] via the Bridges hardware interface IFE1.




Parr [Page 7]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


On the other hand, should the Bridges' GTC have no information
[E2H19], the BARM would have to perform the following steps

1. drop the current ARREQ from [E1H3],

2. create its own ARREQ using the Bridge source
and copy the target_internet_addr from the
[E1H3] ARREQ packet

3. broadcast the ARREQ on network E2 via network
IFE2, and go into a timeout awaiting a REPLY

Should this timeout period expire, a number of retries will
permitted under control of the BARM. Alternatively, if a REPLY
received within the timeout interval, then the BARM will update
GTC. The ARM of [E1H3] next will attempt to transmit another ARREQ
but this time a mapping will be obtained at the BARM'S GTC, and
appropriate REPLY will be returned

Part 1 has described the state of the art of the behaviour of
Resolution. Part 2 now extends the study to the more serious
of rebooting hosts in a multi-LAN system of Ethernets, and
effects such changes have on the integrity of state information
in ARP caches and routing tables

PART 2

THE CAPTURE OF

Because Address Resolution packets are broadcast, all hosts on
connecting cable including the Transparent Bridge will pick them
and determine what they are. Referring to figure 1, it may well
the case that a host on E1 wishes to communicate with a fellow
on the same physical ether. Hence, if Hx wishes to talk to Hw on
same ether, but has not done so previously, it will broadcast
Address Resolution packet in the normal fashion. The Bridge
also 'see' the packet as it passes by, and will act as
above, unless that is, there is some method of preventing it
so; there is no point in the Bridge invoking its ARM, and
processing time if the problem is going to be resolved locally

It may occur however, that H1 wants to communicate with H5.
however, H5 has not talked with anyone before (i.e., it has
"dormant"), H1 will issue an ARREQ. The Bridge will not know that H
is local because it won't have been entered in the local
cache from previous conversations. To avoid broadcasting an ARREQ
all networks/subnets, one way around this problem is to set up
contents of the local cache at Bridge startup time. Therefore,



Parr [Page 8]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


Bridge will already know not to intervene. Thus, if the Bridge (
2 nets) finds that a particular IP destination address is not in
local cache of interface 1, it would have to examine its GTC and
it for a mapping. Should no mapping be obtained at interface 2,
of two possibilities exist

1. the target host doesn't exist

2. the caches are corrupt (the eventuality of this
be negligible!)

If it is assumed that each of the translation caches contains
the most recent addressing information regarding its own domain
the network then, in this example, if the Bridge does not get
mapping at the GTC it would appear that the host must exist
from E1, and E2.

Such a conclusion would ignore cases in which a host unplugs from
particular hardware interface and plugs into another
interface, or where logical names are reassigned to
interfaces due to host user change. Either of these events
happen had the host being accessed on E2, which would mean that
REBOOT has taken place

Anticipating these possiblities local caches are essential.
normal operation, the Bridge will process and forward IP
received from one network, and destined for another. If the
picks up an ARREQ, it will first look for a mapping in its GTC
discarding the original ARREQ, and transmitting its own to the
network. In any case, the Bridge will always examine the local
entries at the receiving interface, so that it may determine if
target address is local or remote. When the Bridge first scans
local cache, it does so with the source IP address as the key. If
mapping is retrieved, it then scans the GTC with the same key
Should a mapping now be obtained, it remains for the Bridge to
the source IP into the local cache, where it has either
previously deleted or corrupted

However, if the source IP exists in the respective local cache,
validity of the source Ethernet address should also be verified
examining the respective entry in the GTC. A scan of the GTC is
performed with <protocol,source_prot_addr> as the key. If a
is retrieved, the respective should be checked against
source Ethernet address in the packet header. If the addresses
not match, then we have uncovered a Hardware Reboot condition (i.e.,
a change in Ethernet ID). On the other hand, should the scan of
GTC with <protocol,source_prot_addr> fail to obtain a mapping,
the Bridge would scan the GTC with the current Ethernet address



Parr [Page 9]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


the packet header. If this obtains a mapping, then a Protocol
condition (i.e., change in logical ID) has been detected

In the next section, the implications of these forms of 'Reboot'
discussed

REBOOT

In normal operation, packets will uneventfully traverse each
either as complete Internet packets, broadcast ARREQ's, or
ARREP's. The Bridge attached to each subnet will 'hear', and 'see
all packets as they travel past its connected interfaces. Because
the existence of the local caches at each interface, the Bridge
decide whether or not to intervene. In general circumstances,
host on the Catenet will have a translation cache
<protocol,source_prot_addr,source_et_addr> entries for all packets
has observed. Most of these entries will have been due to
ARREQ packets, which were broadcast, and by receiving REPLY packets
In accordance with the foregoing , the Bridge will have a
attached to each subnet interface containing entries for
addresses

Within the Bridge's Global Translation Cache (GTC) will be entries
all <protocol,source_prot_addr,source_hrd_addr> triplets relating
valid hosts which have been recognised. If we assume that we
just connected up a Catenet such as that illustrated in figure 1,
then at power-up no stations will have knowledge about
neighbours. If the Bridges are to remain transparent,
translation caches at each host will be totally empty. The
addressing details that will be in existence will be the
addresses stored in the local caches of the Bridges

The hosts subsequently begin to run applications and will want
communicate with one another. The first ARREQ is broadcast on
respective subnet and all hosts, including the Bridge's interface
the subnet, will pick it up and store the details. If, for example
Hx issues an ARREQ for Hq, the Bridge will not intervene since
is no need (providing no reboot has occurred at Hq). However, if
wishes to talk with Hz, B1 will determine that the target IP in
respective ARREQ does not exist in the local cache of IFE1, so
will examine the GTC, with the <protocol,target_prot_addr> of Hw
the key

It is assumed that there will be a timeout mechanism in operation
the source of any packet. In addition, the Bridge may also place
target address in a 'search list' of currently sought hosts, so as
prevent ARREQs from different sources being cascaded for the
target. Under these conditions, Hx may re-issue its original ARREQ



Parr [Page 10]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


but will be ignored until the host Hw has replied to the
transmitted by the Bridge

NORMAL RUNNING

Assuming that a few ARP's have been issued, IP packets will
traversing the Catenet with full addressing information. Again,
Bridges will 'see' all the packets. If we extend the situation
step further, and assume that several conversations have taken
across the Catenet, there will be entries in the translation
of the hosts concerned, regarding
<protocol,target_prot_addr,target_hrd_addr> triplets of those
with which the conversations took place. The Bridges also, will
details in their GTC's for packets which they cascaded

If a host is relocated, any connections initiated by that host
still work, provided that its own translation cache is cleared
it does physically move. However, any connections
initiated to it by other hosts on the Catenet will have no
reason to know to discard their old translation for that host
Ideally, 48 bit Ethernet addresses will be unique and fixed for
time

RECOGNITION OF THESE REBOOT

With reference to figure 1, assume that for some reason a
occurs on the hardware interface of . The result of this
that a new interface is installed with a newly acquired
address. When is powered up, the previous contents of
translation cache are cleared and it has no recollection of local,
remote host addresses. Accordingly, begins to issue ARREQ'
to hosts it requires. Whenever transmits its first ARREQ,
could be termed a 'HELLO PACKET', since everyone on the subnet
pick up the packet, and store the relevant information in
translation caches. Within hosts, a mapping will be found on the
<protocol,source_prot_addr> pair, and the current of
packet header will replace whatever is entered in the
cache

At this point it would be easy for each host with an entry
recognise the Hardware Reboot situation and inform the subnet with
respective broadcast reboot packet. But allowing such a
would be extremly inefficient on the broadcast medium, and
drastically outweigh any improvements in performance which might
obtained in the long term. In any case, given the fact that
ARREQ is broadcast, all stations on the subnet will recognise
reboot. The important point to consider is the effect such a
will have on subsequent conversations which are initiated remotely



Parr [Page 11]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


Can redundant transmissions be thwarted before they tie up
time on hosts en-route to the rebooted target? How
difficulties are resolved is critical to the level of
obtained in a Catenet configuration. Since it is not optimal
hosts to inform the system of a reboot, it is left to the Bridge
Whenever the Bridge receives a packet, be it IP, or ARP, it
the source address parameters in the packet header, in the hope
detecting any incompatibilities between them and the entries in
caches. There are three distinct possibilities, namely, a
in the 48 bit hardware address only, a difference in the
address, and two completely new addresses. If an incompatibility
discovered, a "REBOOT" packet is constructed and issued on all
interfaces containing the appropiate information, allowing Bridges
update their GTC's and generic hosts their ARP caches

The structure of the Reboot packet is as depicted in figure 2.

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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P A C K E T O P C O D E |REB OPC| S O U R C E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| H A R D W A R E A D D R E S S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| S O U R C E P R O T O C O L A D D R E S S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| M U L T I C A S T T A R G E T H A R D W A R E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A D D R E S S | M U L T I C A S T T A R G E T |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| P R O T O C O L |
+-+-+-+-+-+-+-+-+-+-+-+-+

---------> NEXT FOLLOWS A VARIANT FIELD ON REBOOT

+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O L D S O U R C E H A R D W A R E |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| A D D R E S S |
+-+-+-+-+-+-+-+-+-+-+-+-+



+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| O L D S O U R C E P R O T O C O L A D D R E S S |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

FIGURE 2. REBOOT



Parr [Page 12]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


The following definitions apply

PACKET FIELD

OPCODE

REBOOT OPCODE

REBOOT OPCODE

The format is then as follows

48 bit broadcast Ethernet address for the destination

48 bit Ethernet address of source Bridge

16 bit Protocol type = PACKET OPCODE - REBOOT


For completeness and error checking it may be an advantage to have
field which specifies the length of addresses in the Ethernet
protocol address spaces. Thus, the Reboot packet structure
the following

FIELD FIELD SIZE

HRDLEN 4 bit byte length of Ethernet

PROTLEN 4 bit byte length of Protocol




ADDRESS 32 bit current protocol address of



ADDRESS 32 bit broadcast target protocol


OPCODE 4 bit will be either PROTOCOL or


if PROTOCOL 32 bit old protocol

else HARDWARE 48 bit old hardware





Parr [Page 13]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


As shown, depending on the REBOOT-OPCODE, the structure will
with either the 48 bit old hardware address or the 32 bit
protocol address. The choice of a variant packet structure is
reasons of curtailing the size of the packet to the fields that
truely necessary in each situation. From this Reboot
structure, the process of generating such a packet can be considered
When the Bridge algorithm detects a reboot, it should create a
packet structure containing the relevant addressing information
subsequently multicast it on the interface(s) which access(es)
remote subnet(s). The decision as to which interface(s) is/
local, and which is/are remote, can be resolved
whenever a packet is received. With respect to this packet
the receive interface at the Bridge becomes local, and all others
tagged as remote

Thus, hosts on the subnet remote from the reboot are informed of
situation immediately as it is detected by the Bridge. In
Catenet configuration illustrated in fig 1, this will have the
of updating the Translation Cache within each host, whenever
receives the packet. If for example, reboots under hardware
B3 will detect this occurance. There is no reason for the
E1, E2, E3 to be aware of this episode. In normal operation, B3
recognise the reboot from the first ARREQ issued from .
this reboot detection facility, B3 will be in a position to
the hosts on E1, E2, and E3. B3 can then create and issue the
packet via its interface with E3. When B3 picks it up, it
update its own caches and subsequently cascade the packet onto E2,
where it will be passed on to E1 via B1.

ARGUMENTS FOR REBOOT

It is envisaged that introducing Reboot packets, will serve
enhance the bandwidth achievable within a Catenet system.
of addressing 'dead' hosts will no longer exist in a
functioning configuration. Translation Caches will have on hand
most recent addressing information available, which should also
to enhance the performance of the routing strategy in operation
Multiple, redundant processing of packets destined for 'dead'
will be avoided. Weighing this against the processing involved
a single multicast of Reboot packets, it is expected that the
will be is the most economically viable in relation to the long-
traffic presented to the system



It appears that reboots are becoming increasingly common on
networks. Many sites use Personal Computers (PC) as terminals
the typical way to finish a session is to switch them off! With



Parr [Page 14]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


increasing popularity of multitasking Operating Systems on
types of machines, problems are more likely to occur,
when the PCs are diskless, or participating in a distributed
system of some kind. Given the importance of correct addressing
communications networks running Ethernet, it is anticipated
reboot mechanism described will serve to improve the correctness
validity of the protocol/network address mappings which may be
in the translation caches. To this degree, simulation is expected
show that the volume of invalid traffic will decrease, to the
of hosts, Bridges and servers alike. Likewise, ratification of
routing policy is anticipated and since redundant/obsolete
will be thwarted, the efficient utilization of available
bandwidth across the catenet is also expected to improve. Thus
effectively increasing Catenet throughput for 'valid' packets,
therefore enhancing the level of service provided to the end users

It is obvious that the proposed scheme implies the alteration of
packet processing code in Bridges/Gateways. The point to remember
the increased favour with which larger, more complex Multi-
systems of Ethernets are being received. The recent adaption
extra telephone cables to serve as the transmission media for
Ethernet can only result in installation costs being reduced,
making the Ethernet more attractive within large corporate buildings
etc. It is sensible to suggest that the probability of host
re-assignment shall increase in proportion to the number of
systems attached, component failure rate (for whatever reason),
relocation of resources, and the size and turnover of the
(i.e., people moving from one room to another).
experiments are currently being developed to analyse the
traffic patterns under this scheme, and it is hoped to
thresholds where adoption of the scheme becomes a necessity

In addition, the Author is currently extending the boundaries of
problem to encompass the reboot, or relocation of Bridges themselves
Involved with this are the phenomena of loop resolution, load
and duplicate packet suppression. It is envisaged that a Self
Stabilizationg Bridge Protocol will result that will be more "light
weight" than those adhering to the Spanning Tree Algorithm

The Author would appreciate feedback/comments on this RFC.
network address is: CBAD13%UCVAX.ULSTER.AC.UK@CUNYVM.CUNY.EDU



The Author acknowledges with gratitute the help and
contributed by Mr. Piotr Bielkowitz (Supervisor) of the
Science Department, and the time devoted my Mr. Raymond Robinson
painstakingly preparing the first draft of this paper on 'Pagemaker'.



Parr [Page 15]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


Thanks are due also to Dr. M. W. A. Smith of Information Systems
his assistance. Finally, this work was supported under a grant
the Department of Education for Northern Ireland of which the
is extremely grateful



[1] Croft, Bill, and John Gilmore, "Bootstrap Protocol", RFC-951,
Stanford University, September 1985.

[2] Finlayson, Mann, Mogul, and Theimer, "A Reverse
Resolution Protocol", RFC-903, Computer Science Dept,
University, June 1984.

[3] Lorimer, Alan, and Jim Reid, "ARP Information Communique",
Computer Science Dept, Strathclyde University, 1987.

[4] Mogul, Jeffrey, "Internet Subnets", RFC-917, Computer
Dept, Stanford University, October 1984.

[5] Plummer, David, "An Ethernet Address Resolution Protocol", RFC
826, MIT, November 1982.

[6] Postel, Jon, "DARPA Internet Program Protocol Specification",
RFC-791, USC/Information Sciences Institute, September 1981.

[7] Postel, Jon, "Multi-LAN Address Resolution", RFC-925,
USC/Information Sciences Institute, October 1984.

[8] Postel, Jon, Carl Sunshine, and Danny Cohen, "The ARPA
Protocol", Computer Networks, no. 5, pp. 261-271, 1981.

[9] Postel, Jon, and Jeff Mogul, "Internet Standard
Procedure", RFC-950, USC/Information Sciences Institute
Stanford University, August 1985.

[10] Reynolds, Joyce, and Jon Postel, "Assigned Numbers", RFC-1010,
USC/Information Sciences Institute, May 1987.

[11] "The Ethernet: a local area network, data link layer
physical layer specification", Version 1.0 DEC, Intel and
Corporations, USA 30 September 1980).

[12] Hughes, H.D., and L. Li, "Simulation model of an Ethernet",
Computer Performance, Vol 3, no. 4, December 1982.

[13] Parr, Gerald P., "Address Resolution For An
Filtering Bridge Running On A Subnetted Ethernet System",



Parr [Page 16]

RFC 1029 Fault Tolerant ARP for Multi-LANs May 1988


SIGCOMM Computer Communication Review, (July/August 1987), vol
17, no. 3.

[14] Smoot, Carl-Mitchell, and John S. Quarterman, "Using ARP
Implement Transparent Subnet Gateways", RFC-1027, Texas
Consulting, October 1987.













































Parr [Page 17]

---

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

---