Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Posting-Version: version B 2.10.2 9/18/84; site uw-beaver
Path: utzoo!watmath!clyde!burl!ulysses!mhuxr!mhuxt!mhuxv!mhuxh!mhuxi!mhuxm!mhuxj!houxm!vax135!cornell!uw-beaver!info-mac
From: info-mac@uw-beaver
Newsgroups: fa.info-mac
Subject: Stanford Ethernet - AppleTalk Gateway (SEAGATE) beta release
Message-ID: <810@uw-beaver>
Date: Fri, 8-Feb-85 05:02:17 EST
Article-I.D.: uw-beave.810
Posted: Fri Feb 8 05:02:17 1985
Date-Received: Sun, 10-Feb-85 03:11:05 EST
Sender: daemon@uw-beaver
Organization: U of Washington Computer Science
Lines: 330
From: Bill Croft
The beta release of our Stanford Ethernet - AppleTalk Gateway
(SEAGATE) is ready. On the files are:
seagate.ms documentation in -ms format
seagate.hard the wirelist for the applebus interface
seagate.shar1 the main gateway sources (including the above doc's)
seagate.shar2 the ddt, dlq, testscc, and tftp subdirectories
All these files are plain ASCII and can be FTPed from SUMEX with
the 'anonymous' login. The two shar (shell archive) files are
each about 170K bytes, so we would appreciate it if you would
avoid transfers during 9 AM to 5 PM PST.
The shar files may be posted on net.sources if there is enough demand;
however I am not sure most usenet sites would appreciate this, since
the transmission time would probably be an hour or so. The complete
seagate.ms and seagate.hard documents WILL be posted to usenet.
Below are some sections of the formatted seagate.ms file.
----
Stanford Ethernet Applebus Gateway (SEAGATE)
Bill Croft
Stanford University
Medical Center
SUMEX Project *, rm TB105
Stanford, CA 94305
croft@sumex.arpa
beta release, 1/85
ABSTRACT
This note explains how to make your own gate-
way between ethernet and applebus. Such a gateway
allows UNIX (or other) systems on the ethernet to
act as servers for the Macintosh.
1. Introduction
This note describes SEAGATE, a gateway (Apple term:
bridge) that connects an ethernet using the DARPA internet
protocols (IP), to an applebus using Apple or IP protocols.
The IP protocol family was chosen because many campuses and
engineering groups are using it on their ethernets; most
such groups have access to Berkeley UNIX. With such a gate-
way in place, it becomes possible to create UNIX server dae-
mons to provide file, printing, mail, etc. services for the
Macintoshes.
In addition, it would be possible for the UNIX systems
to become integrated into a Macintosh Office such that UNIX
users could access Apple provided services such as printing
on a LaserWriter or sending mail to Macintosh users via an
Apple file server.
This distribution of SEAGATE provides all the informa-
tion and software you should need to setup your own gateway.
Please bear in mind that this distribution is not 'sup-
ported' and that we can't give extensive help about the
mechanics of putting your gateway together. I would like to
hear about bug reports or enhancements however.
2. Protocol packages / servers
UNIX provides a large number of IP based servers. With
a stripped down C based IP package, many of the UNIX user
level programs (such as TELNET and FTP) could be ported over
to the Mac straightforwardly. Alas, such a package does not
yet exist. [I could envision creating such a package by
sniping sections out of the 4.2 BSD UNIX kernel].
What does exist currently is a port of the MIT IP pack-
age (for the IBM PC) to the Macintosh. This was done by
Mark Sherman of Dartmouth in the summer of 84. Since there
were no commercial C compilers available at the time, Mark
transliterated the MIT code from C into Workshop Pascal. At
this writing, the TFTP (trivial file transfer protocol) and
TIME (fetch time-of-day from server) programs from MIT have
been ported. These programs work correctly between Macin-
toshes, or through the gateway between a Macintosh and UNIX.
Written by MIT, but as yet unported are the TCP and TELNET
packages.
While this porting was a large and admirable project, I
am not sure that it is the right base to build Mac IP ser-
vices upon. For one thing, the MIT TCP implementation (in
the original C) is incomplete and cannot handle data streams
in both directions (it's only good enough for TELNET, where
the sending stream is low volume). My hope is that someone
will take a relatively full and debugged IP package and
adapt it to the Mac, all in the C language.
Meanwhile, the gateway provides another alternative.
All Apple services on applebus are based on the applebus
datagram protocol, called DDP (datagram delivery protocol).
In addition to passing IP packets back and forth, the gate-
way will do a small amount of protocol conversion: if it
receives a DDP from the applebus destined for the ethernet,
it will 'wrap' it with an IP/UDP header, doing appropriate
address and port number conversions. This allows Apple DDP
services to be written as UDP daemons on UNIX, without
requiring any UNIX kernel changes.
Conversely, a UDP packet received by the gateway from
the ethernet will be converted to a DDP (by stripping the
IP/UDP headers) if the UDP destination port number matches a
certain 'magic number'. While these protocol conversion
functions are currently compiled into the gateway, and
easily altered, one could also imagine them being selected
dynamically based on any packet fields (such as host
address). This would allow for hosts that understand DDP
packets directly at the kernel level.
3. Addressing and routing
3.1. IP 'nets' versus 'subnets'
The gateway can be configured to treat each
(ether/applebus) cable as a separate IP 'net' number, or as
separate IP 'subnets'. Unless you are at a site which
implements subnets, such as Stanford, MIT, or CMU, you will
probably use plain 'net' numbers.
As mentioned above, the gateway can translate DDP
addresses (2 bytes of net number, 1 byte of node number) to
IP addresses (4 bytes total for both net number and node
number). When subnets are NOT used, a mapping table inside
the gateway is used to convert between network/node numbers.
The information to setup this table is in the Configuration
section below. If your site does not use subnets, you can
probably skip or skim over the next couple sections below.
3.2. Subnets
3.2.1. Subnet addressing limitations
3.3. Routing protocols
The gateway broadcasts an applebus RTMP (routing table
maintenance protocol) packet every 30 seconds. This informs
the Macintoshes of the DDP network number of their applebus
cable.
When routing a packet, if the IP (major) network number
of the destination does not match that of any interface, the
packet is forwarded to a 'default' gateway specified at con-
figuration time. In the subnet case, the gateway assumes
that there are other 'smarter' gateways or hosts that will
answer ARPs for subnets not matching its own.
...
3.4. Protocol conversion
3.5. DDP routing
At present the gateway only really knows about routing
IPs. In the future it would be desirable to participate
more in applebus RTMP protocol, and to allow the ethernet
(or even the whole DARPA internet) to be used as a long-haul
backbone between applebus segments.
4. Prerequisites
To assemble your own gateway, you will need at least
the items below:
The hardware is a 3 card multibus system: A 'SUN'
68000 CPU board, an Interlan NI3210 ethernet card, and
a homebrew applebus card (about 8 chips) which takes an
afternoon to wirewrap. More details in the hardware
section below.
A UNIX (usually VAX) running 4.2 BSD, 4.1 BSD or Eun-
ice. This is because the source distributed is written
in the PCC/MIT 68000 C compiler. [This is the same
compiler included with the SUMACC Mac C cross develop-
ment kit.] You can probably make due with any 68K C
compiler and assembler, but it will be harder.
Inside Mac, update service, and the Mac software sup-
plement.
Applebus Developer's Kit, includes: protocol manual,
applebus taps and interconnecting cable, Mac applebus
drivers on SONY disks.
Dartmouth's IP package from Mark Sherman
(mss%dartmouth@csnet-relay). The gateway distribution
includes the binary for TFTP, but if you want the whole
package (and source), you should get it from Mark.
A Lisa Workshop system is handy to have around; you
would need it to compile Mark's sources. Even if you
are doing development in C, Apple releases Applebus
updates as a combination of Mac and Lisa disks. The
Mac disks contain the 'driver' binary resources. The
Lisa disks contain source for header files.
5. Hardware used
5.1. CPU board
5.2. Ethernet board
5.3. Applebus board
5.4. Other hardware.
6. Software organization
7. Configuration
7.1. Software
7.2. CPU board
7.3. NI3210 ethernet board
7.4. Applebus board
8. Operation
8.1. Downloading
8.2. Console 'commands'
8.3. Debug printouts
8.4. TFTP usage
9. Throughput
Using Mark's TFTP and the Berkeley 4.2 BSD TFTP daemon,
we made some simple timings. On the Mac side, TFTP used a
ramdisk to avoid any delays induced by the slow SONY drive.
For a UNIX to Mac transfer, we found that the Mac took 43 ms
between data received and ack sent, while UNIX spent 25 ms
between ack received and next data sent
Since these times were from the applebus peek program,
the mac time is artificially high since it includes the 20
ms or so of packet transmission time on applebus (35 usec /
byte). So then, each side has about a 20 ms delay before
responding.
Most of the transfer occured at 512 data bytes every
70ms = 7314 bytes / sec = 58K baud.
Note however that the IP TFTP protocol is just that, a
'trivial' FTP. It is purely half-duplex in nature. When we
start using Apple's ATP, which can stream several packets
per acknowledgement, it should boost throughput signifi-
cantly. Gursharan Sidhu tells me that their process-to-
process (no disks) ATP throughput is 180K baud (out of the
230K available on the cable). This is very good, consider-
ing many TCP's running on 10 megabit ethernet are lucky to
get a few hundred kilobits of thoughput.
10. Future plans
Here are some obvious things that could be done next.
Use a DMA applebus interface. I guess right now we
really don't know how the present interface will hold
up under heavy load: it may do just fine. But cer-
tainly, if you wished the applebus gateway code to
coexist with some other gateway or ethertip (terminal
concentrator) code, DMA would be most considerate of
those other processes running on the cpu.
With DMA, you could have one gateway handling a whole
group of applebus interfaces. Alternatively, perhaps
it would be best to connect up the applebus segments as
a true 'internet' interconnected mostly thru Apple sup-
plied bridges, and have just one or two 'seagate's con-
necting that whole internet to the ethernet. Certainly
this would limit thruput more than the 1st approach.
Before you can add multiple interfaces, the 'routeip'
and 'routeddp' routines need to be beefed up a bit to
scan a group of interfaces rather than just assuming
two interfaces per gateway. [This is commented in the
code.]
Here is the most interesting thing I would try: try to
get the 'per gateway' cost way down, by building a sin-
gle board version of it. I picked the Intel 82586 eth-
ernet controller for just this reason: all you should
need is a board with the 68000, memory, the 82586 and
the Z8530. Hopefully you could get the cost down below
$1000 per gateway. Then just sprinkle them around
campus, using ethernet as your 'long-haul' and applebus
within a floor, or group of offices.
I would like to quickly finish an ATP subroutine pack-
age that runs on the UNIX side. This will allow rapid
construction of applebus servers on UNIX. A program
equivalent in functionality to FTP or TFTP should be
less than 5 pages of Mac C code. [Since the Mac MPP
applebus driver package is doing the 'dirty work' of
ATP for you].
11. Acknowledgements
Nick Veizades built and helped debug our applebus
hardware interface. Mark Sherman's Mac IP package allowed
easy access to the UNIX TFTP daemon for general debugging.
Gursharan Sidhu, the 'applebus architect', deserves much
credit for making this protocol family as simple and elegant
as it is. Arnie Lapinig of Apple was always helpful when we
needed another tap box or question answered.
In the Stanford network community, Bill Yundt supplied
us with free hardware and Ed McGuigan kept the applebus
updates flowing in our direction. Ed Pattermann (formerly
SUMEX director, now at Intellicorp) made the mistake of
turning us onto Macintoshes, when we 'should have been'
hacking on LISP machines.