Path: utzoo!utgpu!jarvis.csri.toronto.edu!mailrus!tut.cis.ohio-state.edu!bloom-beacon!mit-eddie!uw-beaver!cornell!rochester!udel!princeton!njin!aramis.rutgers.edu!athos.rutgers.edu!hedrick From: hedrick@athos.rutgers.edu (Charles Hedrick) Newsgroups: comp.protocols.appletalk Subject: Re: The Coming AppleTalk Crisis Message-ID: Date: 18 Feb 89 19:53:23 GMT References: <724@aplcen.apl.jhu.edu> <28066@bu-cs.BU.EDU> <25980@apple.Apple.COM> <28088@bu-cs.BU.EDU> <25994@apple.Apple.COM> Organization: Rutgers Univ., New Brunswick, N.J. Lines: 41 To: desnoyer@Apple.COM The encapsulation he was talking about is appletalk in UDP. No TCP, and only one Ethernet. Many (most?) large university installations do their campus-wide AppleTalk that way. It is partly historical. When the practice started there was no EtherTalk. So this was the simplest way to connect LocalTalk networks that were on opposite ends of campus. Use a Kinetics box to take LocalTalk packets in one side, stick a UDP header on them, and then put them on a campus Ethernet where they would be routed to a Kinetics box on the destination Ethernet. Now that there is an EtherTalk, one could consider having the packets travel through the campus network as EtherTalk. This would still require the same hardware, since you'd still have to get the packets from the LocalTalk to the Ethernet. But you would be saving yourself is the extra UDP and IP headers. While we're always happy to save a few bytes in packets, there are two problems with this: - many people consider EtherTalk inappropriate for a large network. The excessive broadcasting is only one problem. There are also questions about the quality of the routing algorithms. - some university networks consist of a complex combination of Ethernets, serial lines, broadband, fiber, etc. It's hard enough to route IP reliably through this. We don't want to have to manage a separate routing structure for every vendor's protocol. So we'd rather stick an IP header on the packets for transit through the network than have to maintain Appletalk routing over the whole network. (And this assumes that our routers even support Appletalk. Many do not.) OSI is still not widely enough available to be a real alternative for most campuses. But I assume if networks move from IP to OSI, similar encapsulation will be done using the OSI equivalent of UDP. (Of course one could hope that by then Appletalk would have direct support of OSI.) IP may or may not be the be-all and end-all of network development. (Many of us suspect that, like Algol 60, it is a great improvement over all its successors.) But at the moment there are good reasons why it is the basis for most campus networks. Any company interested in selling to us needs to realize that our campus network is based on IP, and there's probably not much they can do to change that.