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 firstname.lastname@example.org 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.