Copy Link
Add to Bookmark
Report
TCP-IP Digest Vol. 2 No. 08
TCP/IP Digest Tuesday, 7 June 1983 Volume 2 : Issue 8
Today's Topics:
Digest Numbering Mixup on V2#06
Comments on Host-Table RFC
InterNet -vs- SubNet Routing
More on SubNet Routing
Network Humor: C/30 Power Wiring
----------------------------------------------------------------------
TCP/IP Digest --- The InterNet Digest
LIMITED DISTRIBUTION
For Research Use Only --- Not for Public Distribution
----------------------------------------------------------------------
Date: 7 Jun 83 6:11:27 EDT (Tue)
From: Mike Muuss (TCP-IP Digest) <tcp-ip@BRL-VGR>
To: tcp-ip@brl
Subject: TCP-IP Digest Numbering Error
The 24-May issue was incorrectly marked as being V2#05
when it was in fact V2#06.
V2#05 was published on 26-Apr
V2#06 was published on 24-May
and V2#07 was published on 25-May.
My thanks to the many people who pointed out this error.
Best,
-Mike
------------------------------
Date: 6 Jun 83 5:20:18 EDT (Mon)
From: Ron Natalie <ron@brl-bmd>
To: tcp-ip@brl-bmd
Subject: Host table RFC
Since M. Crispin put out a real request for comments, I'm commenting.
He has many good points, but I don't feel that his preferred solution is
optimal. He points out that the NIC is not always careful of notifying
users of host table updates. He suggests that the NIC send out the
individual updates to the hosts as the database is modified. My
observation is that the NIC is very reliably mailing me letters about
the tables being modified, but they batch up the submissions before
entering them in the database. Every day I load up the host list using
the provided server. It generally is identical every time except for
the biweekly (or whatever) event when they put in the new entries. If
this mode of operation is to be continued, I suggest that Mark's
suggestion #2 is better. This allows a host to query version number of
the hosts database as many times per day as he feels necessary and only
transfer the entire file when it has been changed. This can easily be
done without altering any of the existing or creating any new protocols
by adding a "VERSION" keyword to the RFC811 hostnames server. This will
return some string that is guaranteed to be different for each revision
of the database. In this way a majority of the inquiries are very short
TCP connections rather than the time it takes to retrieve an entire copy
of the table.
VERSION --> To nic host server
VERSION : 1234 <-- Back to host.
-Ron
------------------------------
Date: Thu, 26 May 83 17:38 PDT
From: Taft.PA@PARC-MAXC.ARPA
Subject: Internet vs. subnet routing
To: TCP-IP@Brl.ARPA
This has been a most interesting and constructive discussion. I would
like to compliment the participants for their careful, well thought-out
presentations, and to offer a somewhat different approach to the
problem.
There are good arguments on both sides of the issue of Internet vs.
subnet routing:
-- Assigning each local network its own IP network number has the
virtues of simplicity and of taking maximum advantage of the Internet
routing algorithm, but the disadvantage of propagating excessively large
amounts of detailed routing information to all parts of the Internet.
-- Adopting a hierarchical structure, with each cluster of local
networks treated as a single IP network, reduces the spread of
irrelevant routing information, but has the disadvantages of requiring
duplication of routing mechanisms and of making poor routing decisions
when clusters are interconnected in more than one way.
In the design of the Pup Internet protocols, we used the first approach
(which I believe is still used in the Xerox NS protocols). We regularly
have over 100 networks up at a time, and the distribution of routing
information is still manageable. However, if we had an opportunity to
do the design over again, we would likely try to combine the best
features of both approaches.
The main problem with simple "area routing" strategies is that, in the
absence of knowledge about the internal structure of an area, they can't
know how to select the correct gateway into it. If the area in fact has
a rich internal structure and has many gateways into it, the routing
algorithm will make bad choices and the resulting performance will be
very poor.
Suppose, for example, we carried DOD IP traffic in the Xerox Internet
(we don't, but there's no reason in principal that we couldn't). And
suppose the DOD and Xerox internets were interconnected not just in Palo
Alto, California but also in Webster, New York. It would clearly matter
a great deal which of the two gateways you chose to route packets to
when sending to a destination within Xerox. This means that some
aspects of the internal structure of the Xerox Internet would have to be
distinguishable from the rest of the DOD Internet, which in turn means
that it would have to be assigned more than one IP network number.
Well, how many? Two? Ten? A number that varies as the topology
changes? You see the problem.
An alternative way of approaching this is not to adopt a hierarchical
structure for network addressing as a whole, but only for the
propagation of routing information. That is, routing information flows
only along the branches of the hierarchy, but the routes computed for
transport of IP packets are not so constrained.
Each network in a "cluster" gets its own unique network number,
addressable from anywhere within the Internet. The normal IP routing
algorithms are used for communication within the cluster.
However, detailed routing information about individual networks in this
cluster is NOT automatically propagated throughout the Internet. What
is instead propagated everywhere is a route to some gateway (or more
precisely, some routing information server) that has enough local
knowledge to compute a good route to the precise desired network. This
information is cached by the gateways along the route, maintained until
it falls into disuse or stops working, and then forgotten.
In this way we decouple the structure of the routing information
hierarchy from the actual structure of the Internet as embodied in IP
addresses. This is just as well, since "clusters" may often represent
administrative entities that bear little relation to the overall
Internet topology.
Of course, there are many details I haven't discussed here (indeed, I
haven't worked them out), and much careful design work would have to be
done to make such a scheme work smoothly. However, it does seem
promising as a way of combining most of the good features of the two
approaches previously discussed. Additionally, it is entirely
transparent to host software and requires new routing update algorithms
to be implemented only in gateways.
By the way, as someone pointed out, the parallels between this and the
domain naming issue are striking. Much confusion may be avoided if we
maintain a clean separation between names, addresses, and routes. I
highly recommend John Shoch's paper, "Internetwork naming, addressing,
and routing", which appeared in the 1978 IEEE CompCon proceedings. It
was also distributed as IEN-019; I haven't been able to find it on-line
anywhere, but I expect Jon can.
Ed Taft
------------------------------
Date: 27 May 1983 0857-EDT (Friday)
From: Thomas Rodeheffer@cmu-cs-a
To: TCP-IP@brl
Subject: subnet routing
Well, I'm real glad to see subnet routing get some air time, because
there are a lot of tricky issues involved and I'd like to see some of
them sorted out before we at CMU have to plunge into building our own
implementation (which is imminent).
In TCP-IP 2(7) Larry Allen and Mike O'Dell described what is happenning
at MIT and LBL, respectively. I'll call these the MIT and LBL schemes.
Since I like to rehash the issues, I'll summarize both of these schemes
and state what I see as their advantages and disadvantages.
The MIT scheme can be summarized as postulating a function
ExtractNetworkNumber: IPaddress -> IPaddress
that is used in the internet module everywhere that network numbers are
contemplated: principally, during IP routing. The MIT scheme requires
that this function be changed so that, when in the context of MIT,
addresses that refer to MIT's particular network are treated specially,
in that some of the "rest" bits, which everywhere else in the world
would be ignored as not relevant, are treated as part of the network
number. Although gateways between MIT and the rest of the world have to
be moderately schizoid (because "the context of MIT" changes from one
side to the other), everybody completely inside or outside of MIT can
just swim right along, and everything will work perfectly.
This is essentially the same scheme as propounded by Chris Kent of
Purdue. It has the advantage that within MIT all of the routing
mechanisms of IP are applied to the problem of moving a datagram from
one place to another. You don't need to implement any local routing
mechanisms. Indeed, assuming that the gateway-to-gateway protocol sent
around routing updates without attempting to compress the data based on
"knowing" what class A, B, and C network numbers looked like, internal
gateways at MIT could be identical to their brethern everywhere else in
the world.
The disadvantage is that because the special treatment of MIT addresses
is not part of the IP standard, all code that is imported to MIT has to
be "upgraded" before it will work at MIT. Because the necessary change
may require rooting around all through the internet module to find the
places where network numbers are used (not necessarily so nicely
modularized as an ExtractNetworkNumber function), even when source code
is available it may be quite difficult to carry out.
The LBL scheme can be summarized as postulating an external mechanism
for translating IP addresses to local network addresses (the address
resolution protocol) and a local system of gateways that
"transparently" route packets around between various subnets so as to
give the impression to the internet module that it's looking at a flat,
completely connected network. The gateways respond to address
resolution requests on behalf of hosts on other subnets, giving the
local network address of the best first-hop gateway. Thus packets
destined for other subnets get sent right to the appropriate gateway
without the host even having to know what is going on.
Because some sort of address resolution protocol is needed anyway in
order to do anything intelligent with IP packets on the popular 10mb
Ethernet, there is a good chance that the LBL scheme will not require
modifying the software of any host that is to be plugged into it. This
is a major advantage.
The major disadvantage is that you have to your own local gateway code
and routing update algorithms. This may not be so hard if you have
friends at other sites who have already done exactly the same thing.
A second disadvantage is the presence of a very subtle violation of the
Internet Protocol specification. The problem arises in connection with
the separation between the internet layer and the local network layer.
The way I read RFC 791, the internet module has the responsibility of
deciding for each datagram what address inside the network it should be
sent to and the local network interface has the responsibility of
getting it there. This is not quite what happens in the LBL scheme.
An example should help illustrate the situation. Suppose that A1, C1,
and D1 are stations on network 1, and D2 and Z2 stations on network 2.
D1 and D2 are two halves of an internet gateway. Network 1 is actually
divided into two subnets, connected by B1a and B1b. I will denote the
physical network's address corresponding to an internet address X as
@X.
====+======+========+=== ==+==========+=====
| | | | |
A1 C1 B1a~~~~~~~~B1b D1
* *
C3 D2 Z2
| | |
==+== ====+=========+==
Suppose that A1 wants to send a datagram to Z2. Noticing the different
network number, A1 consults its routing tables and decides that D1 is
an appropriate gateway. A1's internet module calls up its local network
interface, and says:
Send "SRC=A1,DEST=Z2,DATA=xxx" to D1
A1's local network interface does address resolution on D1 and gets
@B1a. So off goes the packet:
To: @B1a, From: @A1, Type: DoDIP, Data: "SRC=A1,DEST=Z2,DATA=xxx"
Observe that at this point all knowledge of D1 has been lost. What B1a
has to do is peek inside the datagram and recompute the IP routing for
Z2. With any luck, it will come up with the same answer that A1 did. Of
course, it might come up with C1 instead. That would be unfortunate,
especially if C1 were an ordinary internet gateway that didn't
understand about the fancy subnet routing that was going on. You might
see a whole slew of ICMP redirect messages come piling into A1 as C1
valiantly tried to push the datagram through B1a. At the IP level the
problem would be characterized as a persistent delivery error in the
local network.
The problem is that the local network interface isn't acting as a
transparent delivery mechanism for the internet layer. It is usurping
some of the routing responsibility that according to the specification
ought to be performed by the internet module. The IP specification
assumes that if a datagram is wandering off course inside the same
network as the datagram's source, then it's the fault of the source,
who was supposed to route the datagram properly in the first place.
This is the position taken by the ICMP redirect message, whose purpose
is to correct such misroutings. As my example shows, it wouldn't be
safe to use ordinary internet gateways with the LBL scheme because the
responsibility for routing errors is not always vested where the
gateway would expect.
I should note that if you only have one external gateway the misrouting
problem never comes up (at the IP level).
As a side issue, if subnet routers are going to have to perform IP
routing anyway in order to second guess where packets are supposed to
go, why not go the whole hog and punt IP routing from hosts entirely.
Let the address resolution take any random IP address and return an
appropriate physical network address. Of course, the host software
wouldn't be complete IP implementations any more. I'm not saying this
is bad, but it is not an implementation of IP according to the full
specification.
There are two ways one could modify the LBL scheme in order to make the
local network delivery transparent to the internet layer. Neither of
these are very attractive. The first way is to change the encapsulation
of IP packets by adding a field to the physical packet to carry the
local network destination address through the subnets. In my example,
this would mean arranging for A1's local network interface to transmit
the packet:
To: @B1a, From: @A1, Type: DoDIPx, DeliverTo: D1,
Data: "SRC=A1,DEST=Z2,DATA=xxx"
This of course means changing all local network interfaces everywhere
on the local network, which erases the major advantage of the LBL
scheme of not requiring any host software modifications. Back when I
gave my example, I sneaked the issue of packet encapsulation past you,
assuming an encapsulation that was similar to those used by all
implementations I am familiar with, one which is indeed the obvious
encapsulation to use under the assumption that the local area network
implements an entire IP network. I am not aware of any formal
specifications of IP packet encapsulations, although of course such
specifications are necessary if IP implementations are ever really
going to be compatible.
The second way is to require that the address resolution function be
one-to-one instead of many-to-one. In other words, address resolution
must produce a physical local network address that uniquely identifies
the desired IP address, at least when considered within the subnet in
which the address resolution was performed. In this situation, the
subnet gateways could rederive the local network destination address by
inverting the address resolution on the physical destination address of
the packet. The physical address space of the 10mb Ethernet is so large
that imbedding an entire IP network within it is no problem, but this
could be impossible on other kinds of local area networks. Of course,
subnet gateways would have to attend to some potentially very large set
of addresses to which packets could be sent.
The question remains whether the original LBL scheme is suitable, even
though it violates the separation between the internet and local
network layers. It might be that the benefit from being able to attach
hosts with software written according to the existing IP specification
and common-law packet encapsulations overweighs the disadvantage of
having slightly illegal routing behaviour.
-Tom Rodeheffer
------------------------------
[ While this message does indeed detail an error in the C/30 documentation,
it is published here because of the humorous nature of the mixup. -Mike ]
Date: 6 Jun 83 5:34:02 EDT (Mon)
From: Ron Natalie <ron@brl-bmd>
To: tcp-ip@brl-bmd
cc: romash@bbn-unix, brescia@bbn-unix, taccers@bbn-unix
Subject: C-30 Site Preparation
BRL has taken delivery of eight C-30 processors to act as IMPs and TACs
on our CAN [Campus Area Network -Mike]. While reading the site
preparation guide provided by BBN, I came across some unusal problems
that I had not planned for. The first line in section 2.2 (page 2-3)
states that "The receptacle MUST be wired as shown in figure 2.2."
Figure 2.2 (same page, labeled "Wiring of Power Receptacle) indicates
some interesting power considerations to which I was unacustomed. I had
no problem figuring out what to do with contact number 1 labled "frame
ground", and I assume that I can jumper "request to send" to "clear to
send", since I always want power flowing, but contacts 2 and 3 for
"received data" and "transmitted data" really have me confused.
Figure 2.2, although labeled "Wiring of Power Receptacle", depicts how to
turn two DB-25's into an RS-232 null modem. Interesting, since the only
other place that this figure appears is on page 3-9 where it is identified
as Figure 3.6 and again as "Wiring of Power Receptacle", this time for
the C-60 and C-70 processors.
I suggest that BBN would be better off if they adopted the more standard
three wire (hot, neutral, and ground) system of power.
-Ron
------------------------------
END OF TCP-IP DIGEST
********************
