[comp.protocols.appletalk] CAP and AppleTalk PhaseII

eljazzar@utkux1.utk.edu (Mohamad El Jazzar) (11/09/90)

The subject line says it all..  Does/will CAP support AppleTalk Phase
II?

--------------------------------------
Mohamad El Jazzar
UT Computing Center
Internet: eljazzar.utkux1.utk.edu
Bitnet  : eljazzar@utkvx
 

hedrick@athos.rutgers.edu (Charles Hedrick) (11/13/90)

When I get time, I'll make our CAP code support phase II.  However
this is likely to be months.  The process would be considerably
speeded if somebody would get me a list of differences between phase I
and II.  I have a version of Inside Appletalk based on phase II, so I
can find out what phase II is, but diff-ing books is not too
practical.  The initial version is likely to support only non-extended
networks.  Is this likely to cause trouble?

urlichs@smurf.sub.org (Matthias Urlichs) (11/15/90)

In comp.protocols.appletalk, article <Nov.13.01.39.51.1990.29468@athos.rutgers.edu>,
  hedrick@athos.rutgers.edu (Charles Hedrick) writes:
< When I get time, I'll make our CAP code support phase II.  However
< this is likely to be months.  The process would be considerably
< speeded if somebody would get me a list of differences between phase I
< and II.  I have a version of Inside Appletalk based on phase II, so I
< can find out what phase II is, but diff-ing books is not too
< practical.  The initial version is likely to support only non-extended
< networks.  Is this likely to cause trouble?

Let's see...

Oh yes, for each zone on an EtherTalk II network, you'll have to have a
multicast address. That might cause problems, with your machine being
essentially invisible.

I have here some pieces of paper called "Appletalk 2.0 protocol specification
proposal, draft 3/10/89", which essentially lists the changes for 2.0:

Getting a node address has become more complicated because no router may
be online and it's not a very good idea to hard-configure the net number into
every machine's atalk.data file anyway. You'll have to reimplement that part
using the current specs.
What to do is to:
- Get a preliminary node number. If you remembered one from last time, it's
  24 bits ($nnnnyy) and you send AARP probes for it and (if the number is in
  use) all other values for xyy except for $00, $FF, and $FE.
- Get network information by broadcasting (cable.wide broadcast) a ZIP
  GetNetInfo. 
- If no router responds, get a nuber in the startup range.
- Make sure the information from above is valid for this cable. This implies
  ATIS picking a valid zone name from the list which the gateway responds
  with.
- Each zone name on that cable has a specific multicast address, which you
  must support -- use ZIP GetNetInfo calls.
In general, the stuff on the network is more dynamic and you should try not
to depend on any information which someone has to manually change to get
things working again after reconfiguring the router(s).

Forward to the "best router", if at all possible.

NBP must also match zones because "*" doesn't make sense on networks with more
than one zone.
Similarly, lookups must contain a zone name on extended networks.

NBP now knows about another wildcard, the double-tilde (the "approximately
equal" sign), which will match zero or more characters in a name. (There may
not be more than one of these in any string.)

ATP XO uses three unused bits as a validity timer indication.

Some of these seem to require some sort of central management.
It's not easy, and you may run into the need for several ugly hacks unless
you resort to kernel support or a scaled-down version of UAB.

-- 
Matthias Urlichs -- urlichs@smurf.sub.org -- urlichs@smurf.ira.uka.de     /(o\
Humboldtstrasse 7 - 7500 Karlsruhe 1 - FRG -- +49+721+621127(0700-2330)   \o)/

mmccann@eng.clemson.edu (Mike McCann) (02/07/91)

Does CAP support AppleTalk Phase II over EtherNet (I didn't see it in the docs
anywhere) or will it ever?

Thanks for your help in advance,
Mike McCann
mmccann@eng.clemson.edu