tappan@MIKEY.BBN.COM (08/12/87)
I had alot of requests for whatever information I found out: Basicly 1) There currently exists TCP/IP for Kinetics EtherSC card. 2) Apple has just (today) announced their "Ethertalk" product which is appletalk over ethernet. This will be available in October. Some good points which answer most of my questions: Along with the implimentation they've added a 'Lap Manager' which allows you to splice in any transport medium you like to carry appletalk packets. The ethernet card driver supports multiple protocols, multiplexed by the type field, so supporting TCP/IP is possible. This interface will presumably become standard among Mac network interfaces - in fact Kinetics has apparently just announced a card for the SE that complies. Hopefully the EtherSC will soon. Some less good points about EtherTalk: o They did it using encapsulation under raw ethernet packets. This limits them to 254 appletalk hosts on an ethernet cable. It also means that it can't work on a large subneted network with routers (until you add the bridge protocols to the routers). On a network segmented with MAC level bridges you're restricted to 254 appletalk hosts on the whole campus. o Because they are using the standard appletalk drivers, with only a hook to select a different transport protocol, they will require the same frequency of RTMP packets to keep things going - on the order of every 5 seconds. This means that there is yet another constant source of broadcast garbage on a large ethernet. o To impliment appletalk broadcasts they used the physical broadcast address (-1) - meaning that every host on the segment will have to process and throw away those packets. Presumably it was easier than implimenting multicast.. o To do address resolution (8 bit appletalk -> 48 bit ether) they use "Appletalk Address Resolution Protocol". This looks suspiciously like standard ARP - in fact it's identical except they added one opcode (PROBE) and used a different ethernet type field for the ARP packets ($80F3). The claim is that it had to be different to support dynamic address assignment. [When a host comes up it sends PROBES until it finds an address that doesn't respond] Actually they could have noticed that a PROBE is basicly identical to a REQUEST. It only causes problems if someone is updating the ARP cache on requests (which they do) which they could have gotten around by reserving a value for the "source protocol address" on those packets. They could also have noticed that a new opcode shouldn't matter since hosts should be checking the "Protocol" field of the packet (= $809B for atalk vs $8006 for IP) before checking the opcode. I'm not sure why this bothers me... Anyway, since they have implimented the "add your own transport layer" hooks it would be straightforward to switch to the KIP encapsulation should that be better for an environment.