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
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:	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 and seagate.hard documents WILL be posted to usenet.

Below are some sections of the formatted file.


        Stanford Ethernet Applebus Gateway (SEAGATE)

                         Bill Croft

                    Stanford University
                       Medical Center
                 SUMEX Project *, rm TB105
                    Stanford, CA  94305

                     beta release, 1/85


          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

     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

     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

     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-

     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

     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

     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.