morgan@jessica.stanford.edu (02/23/90)
Here's something that I thought of today while discussing The Future of AppleTalk with someone. Those of us who are obliged to run ever-larger AppleTalk networks have been aware for quite some time that the future looks grim. Most of the protocols that make up AppleTalk (AT) simply do not scale well to work with internetworks the size of those at large research universities, much less regional, national, or international networks. The most obvious problems are with DDP, which uses a too-small 24-bit address; RTMP, which has no subnetworking capability and uses only hop-count as a metric; and NBP, which uses a flat zone-name space and uses broadcasts to find everything. Some people would complain about other protocols in the AT suite as well. Now, there are several ways to approach the problem. One is to abandon AppleTalk altogether, and use IP-based applications. This is unattractive because, after all, it's the AT applications that people like, and that have caused AT networks to spread (maybe more usable IP applications is part of the answer, though). Another is to look at putting AT upper-level protocols onto TCP/UDP/IP, much as the OSI people are doing (ISODE, specifically). Another is to keep the basic structure of AT but rework all the protocols to scale up better. Any or all of these are do-able with time and effort, but all of them depend on lots of experimentation with new protocol formats, algorithms, etc. Now, a Mac is a nice enough vehicle for such evolutionary things: you can just write some wonderful new protocol software, stuff it into your Mac and away you go. Other computers such as Unix boxes can have new protocols added to them more-or-less easily. The AT router boxes that most of us use (FastPaths and Gatorboxes and such) also are very easy to fill up with fancy new code to handle future networking schemes. OK, here's the point of all this, if you were wondering. The real stick-in-the-muds of any evolution of AT are all those LaserWriters (LWs) (and compatibles) that have AT Phase 1 built into their ROMs. It's clear that any new AT that cuts off access to LWs won't be very popular. Those LWs with Ethernet interfaces that will hit the market one of these days (no, I don't know any secrets about them) will be even more tragically crippled if all they can use is one ROM-based protocol. So here's my suggestion. Any new LW-compatible printers should be designed to be able to download new networking code into them, much as FastPaths and Gatorboxes are. A really flexible design should allow the printer to accept print jobs via multiple protocols at once. A printer control program on a Mac could do the downloading, or a printer could fetch code automatically from an AppleShare server, perhaps. Of course, retrofit ROMs for all our existing LWs would be nice, too. After all, the LW-IINTX in the next room has a 68020 and 5 MB of RAM, it should be able to run a couple of protocol stacks. (Hmm, you could even write the new network code in PostScript . .*8^)* (It occurs to me that putting old LWs behind smart print servers is another evolutionary approach.) All you printer designers who like the idea can send the royalty checks (electronically, of course) to: - RL "Bob" Morgan Networking Systems Stanford