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.ARPA
Path: utzoo!watmath!clyde!burl!ulysses!ucbvax!kre
From: kre@ucbvax.ARPA (Robert Elz)
Newsgroups: net.mail
Subject: Mail Addressing [4 of 4] Routing
Message-ID: <9609@ucbvax.ARPA>
Date: Sat, 3-Aug-85 07:40:29 EDT
Article-I.D.: ucbvax.9609
Posted: Sat Aug  3 07:40:29 1985
Date-Received: Sun, 4-Aug-85 10:05:27 EDT
Organization: University of California at Berkeley
Lines: 69
Keywords: mail, addresses, routing

Now we come to the sensitive area of routing.  I would expect that most
people can simply hit the 'n' key now, as routing simply doesn't matter
at all (or shouldn't) to the average user.  Mail is given an address,
and posted.  Sometime later it arrives at the address.  Where its been
in the meantime (in ordinary circumstances) simply doesn't matter at all.

So, from here on, I'm going to assume that those of you who are left
are mail/network implementors or administrators, who do sometimes need
to know about routing and such.

The first thing to notice, is that apart from the explicit routing
semantics, the semantics (in each of the cases) simply specify the
destination host.  They provide *NO* information on how to get there.

In particular, using a!b!c syntax for Peter Honeyman's attribute style
addressing does not imply (necessarily) any routing at all.

So, if there were two "down"'s, so Peter's address became
"princeton!down!honey" this does *not* mean that mail to Peter is sent
to "princeton" which then sends it to "down" which then delivers it.
Of course, it might go that way, but that would be a coincidence.  The
"princeton" in the address is an attribute of "down", it indicates
which of the two (assumed) "down"'s is the one that the mail is to get
to.

Similarly, in a domain type address, "kre@monet.berkeley.edu" does not
mean to "send mail to edu, which sends it to berkeley, which sends it
to monet", nor does it necessarily imply any other form of routing.

We must consider two types of hosts, "dumb" ones, and "smart" ones (not
forgetting that few hosts will actually sit at the extremes, most will
be at an intermediate point somewhere).

For any addressing semantics/syntax combination we choose, a truly
"smart" host will have a complete list of every host that can be
addressed, and all of the interconnections between them, plus as much
other information as can usefully be used (delay and throughput on the
links, costs, restrictions on paths that are legal, etc).

From that it can then deduce an "optimal" route for the mail, using
whatever definition of "optimal" happens to be the current vogue.

A truly "dumb" host knows none of this, in the extreme case, all it
knows is one other host to which it sends any mail not addressed to
itself.  In slightly less limited cases, it may know a small set of
possible neighbours, and fixed routes to some hosts that can handle
particularly tricky mail (anything not addressed to the originating host
or one of its neighbours).  The decision about which host to send to in
such a case may even be made based upon what the final "domain" in the
address is, or the value of one of the "attributes" in the address.
In these cases it may appear to some people that the address is in
some way a "route", but this is really simply nonsense.  What's more,
it doesn't matter if *every* host implements routing this way, the
address is still *not* a route.  One would hope that the mail would be
continually passed to successively smarter hosts, until it reaches one
smart enough to be able to plot a route to the destination.

I don't know that much more need be said about routing, its an internal
issue.  It can be changed whenever the administrators want to change
it, and for whatever reason they desire.  All that's needed is that the
mail system provide the address of the destination, and that some
database (of whatever size is appropriate) is available to calculate
the routes from.

One thing to particularly note, is that in none of the semantic
schemes is there (necessarily) a "central host" through which
all mail passes.  There may be such a host in any of the schemes.
Everything depends on how the network is set up, and nothing stops
one scheme being transformed into another with no notice.