Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.3 4.3bsd-beta 6/6/85; site ucbvax.BERKELEY.EDU
Path: utzoo!decvax!ittatc!dcdwest!sdcsvax!ucbvax!RED.RUTGERS.EDU!HEDRICK
From: HEDRICK@RED.RUTGERS.EDU (Charles Hedrick)
Newsgroups: mod.protocols.tcp-ip
Subject: Re: more interesting features of 4.2
Message-ID: <12212068498.49.HEDRICK@RED.RUTGERS.EDU>
Date: Wed, 4-Jun-86 04:15:48 EDT
Article-I.D.: RED.12212068498.49.HEDRICK
Posted: Wed Jun  4 04:15:48 1986
Date-Received: Wed, 4-Jun-86 19:49:07 EDT
References: <12212027261.22.JNC@XX.LCS.MIT.EDU>
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 42
Approved: tcp-ip@sri-nic.arpa

I'd rather use a socket wrench as a hammer than my bare hands.  I'm
eagerly awaiting the gateway group's proposals, and their implementation
by all of the vendors supplying systems that we use. Until then,
ARP-based routing is something that I can do that will work, and that
does not abuse any standards too badly.  I don't intend it to be for
routing information interchange in the general sense.  The gateways will
use other protocols among themselves. What I need is a way to get
information from the gateways to the hosts.

I just reread the relevant section of 917, and in fact Mogul says that
ARP-based subnetting is a reasonable strategy.  His only criticism,
other than the fact that it can only be implemented if you have
broadcasts (which of course we do), is that there may be trouble
recovering if a gateway goes down.  In fact it is no more difficult to
recover from gateway failure using ARP-based routing than using any
other scheme.  When a connection is about to time out, the system should
attempt to recompute the route.  It is just as easy to purge the ARP
entry and issue another ARP as to purge the routing entry and do
whatever you would normally do to find another routing at that level. In
fact 4.2 does neither.  But it does time out ARP entries, so eventually
it will correct routings when ARP are being used to discover routes.
Most alternative methods don't do even this well.

I am assuming that our gateways will talk to each other, and arrange it
so that the right gateway responds.  That is, if one gateway goes down,
and there is another route, the backup gateway will begin responding to
ARP requests.  In fact that gateway technology we are using (Stanford's)
has this ability.

Note that I have gone one step beyond the ARP-based subnetting described
in RFC 917, in that I also use ARP's to identify routes to hosts outside
our class B network.  We currently have 3 different gateways to 
the outside world.  One handles a single class C network.  One handles
a class B network and a class C network.  The third is our Arpanet
gateway, to which we send all other traffic.  As the supercomputer
network and other NSF-sponsored networking develop, we are likely to
start moving traffic for certain other Universities from the Arpanet
to one of the other networks.  We do not want to have to change routing
tables in every host when we make such a change.

What is TOS routing?
-------