Re: IP on DECNET


Charles Hedrick (hedrick@topaz.rutgers.edu)
Mon, 3 Nov 86 06:47:28 est


Thanks. I had in mind doing it as a device driver that pretended to
be point to point links. It's hard to see why this would have to know
anything about DECnet. As long as the bits get there, I find it hard
to see how DECnet could know the difference. The only question I see
is whether the interface between my device driver and the DEUNA device
driver can be made to work, particularly in the presence of the
Wollongong code. My suspicion is that it might work only when no
other IP was hapneing for that interface. (On a number of machines,
we are now using separate interfaces for IP and DECnet.) The problem,
of course, is figuring out when an IP or ARP packet gets handed to
Wollongong and when to my hack. I intentionally suggested using point
to point links because there is no structure to them. If I tried to
emulate DECnet support of Ethernet, I would have to handle multicasts
and make the system think it saw an area router. I don't know about
the X.25 support, but assume there are protocols involved to open
connection that would have to be interpreted.

I am to meet with someone from DEC this week on this issue.
Apparently at least someone is interested in looking into it. I find
that DECnet is currently my biggest networking headache. I can get
good TCP implementations for every machine other than the VAX. For
the VAX we have things that are either incomplete or the Wollongong
thing whch is too expensive for large-scale use and still doesn't
handle mail right. I know a number of people who think DEC wants it
that way. That's always hard to judge. But the only convenient way
to build a campus network that will pass DECnet is to use level 2
routers. We are very reluctant to do this because of concerns about
Ethernet meltdown being propagated around the campus. Stevens is
building a campus network with LANbridges. But the person responsible
didn't know about the problem with Ethernet meltdown. They referred
me to the DEC person who is doing their design, and he didn't seem to
care. I suggested maybe a simple filter to prevent broadcasts from
passing when the packet type is IP. He would rather die than suggest
that DEC should do anything based on packet type, since that is
non-ISO.

The problem with depending upon migration to ISO is that it looks like
the last piece of ISO to fall into place will be the network layer,
and that is precisely what I need. In fact, the only plausible
strategy for implementing ISO that I have heard is to layer it on top
of IP.



This archive was generated by hypermail 2.0b3 on Thu Mar 09 2000 - 14:36:59 GMT