Path: utzoo!attcan!uunet!husc6!bloom-beacon!tut.cis.ohio-state.edu!mailrus!ames!pasteur!ucbvax!oliver.CRAY.COM!dab
From: dab@oliver.CRAY.COM (Dave Borman)
Newsgroups: comp.protocols.tcp-ip
Subject: Re:  HYROUTE(TCP/IP gateway between HYPERchannel and ethernet)
Message-ID: <8805231553.AA21150@oliver.cray.com>
Date: 23 May 88 15:53:38 GMT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The Internet
Lines: 54


I can proababaly answer quite a few questions about HYROUTE.
First, it depends on what version of HYROUTE you are using.
There have been two main versions of the HYPERchannel driver,
the one written years ago at Tektronix (and distributed with
4.2BSD and 4.3BSD), and the one developed by CRAY research.
The two drivers are incompattable with each other, because
the Tektronix driver uses a variable size Message Proper,
and the CRAY driver insists on a 64 byte Message Proper.
From my experience, a lot of vendors that have HYPERchannel
drivers are using the CRAY version (since there is now an
RFC, #1044, that is compatable with the CRAY version)

HYPERchannel does NOT have a broadcast mechanism.  Therefore,
if you are going to use TCP/IP over HYPERchannel, you can't use
ARP, and you have to have some other method for translating IP
address to HYPERchannel address.

For those that do not use a HYROUTE command, the usual method
is to put the 16 bit HYPERchannel address in the bottom 16 bits
of the IP address.  With that scheme, you can not use subnetted
Class B addresses.  Also, several implementations also use bits
in the 3rd byte for loopback control information, hence meaning
that this scheme only works with Class A addresses.  I personally
find this method as less than acceptable.

The HYROUTE program provides the kernel with mappings between
internet address and HYPERchannel addresses.  Typically, it uses
a hash table to speed up lookups.  HYROUTE should work with
Class A, B and C addresses.  If you machine/driver doesn't work
with all of them, complain to the vendor because the implementation
is broken.

For most implementations of HYROUTE, it does it's hashing, on just
the host part of the address.  I've been thinking long and hard on
this.  It can cause problems with subnets if the HYROUTE program and
the kernel are not in sync with each on whether or not a network is
subnetted.  The HYROUTE builds the hash table and writes it into
the kernel, so the kernel had better be hashing things the same
way as HYROUTE or things won't work right.  I'll probably be
changing the CRAY UNICOS implementation of HYROUTE to hash  on the
entire 32 bit IP address, and then it won't matter any more
whether an address is subnetted or not.

The bottom line is that any implementation of HYROUTE that limits
you to a subset of the IP addresses that the vendor supports is
broken.  (That is, if the vendor doesn't support subnets, then
his HYROUTE program isn't broken because it doesn't work with
subnets.  But if the vendor does support subnets, as the vendor
should, and HYROUTE does not work with subnets, then the vendor's
implementation is broken)

			-Dave Borman
			CRAY Research, INC.