Path: utzoo!attcan!uunet!peregrine!elroy!ames!ucsd!rutgers!columbia!cunixc!cck
From: cck@cunixc.columbia.edu (Charlie C. Kim)
Newsgroups: comp.protocols.appletalk
Subject: Re: EtherTalk vs. AppleTalk vs. ???
Message-ID: <927@cunixc.columbia.edu>
Date: 23 Aug 88 06:50:42 GMT
References: <1364@cayman.COM> <1367@cayman.COM>
Reply-To: cck@cunixc.cc.columbia.edu (Charlie C. Kim)
Organization: Columbia University
Lines: 60

In article <1367@cayman.COM> brad@cayman.COM (Brad Parker) writes:
>From article <Added.oX28P8y00UkT09DU8G@andrew.cmu.edu>, by
>>morgan@JESSICA.STANFORD.EDU: 
> 
>> Ah, the heart of the matter.  To allow a Ethernet-attached MacII (or 
>> MacSE) to communicate directly to a CAP-speaking Unix host, there are 
>> two ways to go.  If the MacII has an AppleTalk driver that puts out 
>> AppleTalk-in-UDP packets, then it can talk directly to an unaltered 
>> CAP.  As far as I know this doesn't yet exist.  Anybody working on 
>> one?  
>> 
> 
>The CAP code will not directly support the multiple, "ad hoc" gateways
>this solution creates. It could be changed to work with mac's
>speaking UDP encapsulated AppleTalk, but won't out of the box.
>
Actually, there's no "additional" gateways involved here.  The
situation is no different, w/r/t cap, than two unix hosts talking
directly to each other via UDP encapsulated AppleTalk.  However, in
either case (UDP encap. macs or unix), one still needs a KIP based
system to forward NBP lookups.  The way CAP handles things for kip(udp
encapsulated appletalk) is quite simple:
	send packet to bridge node for forwarding.

Actually, there's a clause that says
	send packet to bridge node for forwarding.
		UNLESS we know the ipaddress of the appletalk node
where we figure out the ipaddress of appletalk nodes by cacheing
[<ipaddress>,<ddp node/network>] tuples from receives (at present only
one tuple is cached).  Often, the cached ipaddress is of a bridge
(possibly the same as the bridge node), but it can be of an arbritrary
host too.  However, all this really does is eliminate some double hops.

One major problem is that configuration is quite painful.  One must specify:
  for ip:
	host ip address
	host broadcast address
  for kip (udp encap. appletalk) contents of atalk.local:
	appletalk network number, appletalk node number, appletalk zone
	bridge (appletalk) network number, bridge ip address
for each and every such mac.  (Actually, the appletalk number number
and appletalk zone can probably be figured out).  As we all know, this
stuff is really easy to get right and is very robust in the face of a
dynamic environment :-).  I realize that this is a problem on the unix
hosts too.

The fairly recent advent of driver based UDP/IP implementations makes
the proposal reasonable (in terms of work).  The main reference
document is "EtherTalk and Alternative ???" (something like that)
available from APDA that outlines the design of EtherTalk and
alternative LAP implementations.  I'm 99% sure the mac side is doable,
and if it is, the CAP side should be interoperable.

I don't know if anyone is working on this.  I'd be interesting in
seeing it though.

Charlie C. Kim
Systems & Networks Group
Center for Computing Activities
Columbia University