⟦e7bf19925⟧

TextFile

01/88 REVISION OF KIP

The January 1988 revision of KIP adds:
  Ethertalk support.
  Additions to atalkad to aid in configuration.
  Magic zone name 'ALL'.
  

ETHERTALK

The installation manual (doc/install) and atalkatab (etc/atalkatab) have
been modified to cover ethertalk configuration.  Please read those files.
Below is reproduced a section from 'install' that explains the modification.
See also the section 'ETHERTALK CONSIDERATIONS' in 'install'.

  APPLETALK FORMS

  Before we can discuss setting up the administrator daemon and
  database we need to explain the different forms in which appletalk
  exists.  'Appletalk' is the word used by Apple to describe the
  protocol family that they designed.  This protocol family contains
  protocols that implement various services such as name binding
  (location), file access, and laserwriter printing.

  The Appletalk protocol family can be used on a variety of
  communication media.  For each of these media, appletalk takes on a
  unique 'form' (or encapsulation) specific to that media.  Thus we can
  label three different appletalk-forms:

    'Localtalk' is Appletalk on the original Apple-designed daisy-chain
    cabling system (shielded, twisted pair).  Localtalk would also
    refer to the alternate cable scheme developed by Farallon
    (PhoneNet) that uses standard phone company cables and connectors.

    'Ethertalk' is Appletalk running on ethernet hardware.  There are
    now cards for the Mac II (from Apple/3com and Kinetics) that speak
    ethertalk.  Additionally some commercial mainframe products such as
    TOPS for UNIX and Alisatalk for VMS use ethertalk.

    'Appletalk-in-IP' is Appletalk encapsulated inside IP datagrams,
    which in turn are carried on a media such as ethernet or fiber
    optics.  The advantage of putting appletalk inside of IP is that
    preexisting campus gateways and hosts dont have to be modified (at
    low levels) to understand appletalk.  There is much more equipment
    available on the market that understands the IP protocol family
    versus the relatively new Appletalk family.  For 4.X BSD derived
    UNIX machines, the CAP (Columbia Univ. Appletalk Package) software
    provides file access and print spooling capabilities.

  The original KIP gateway software supported the localtalk and
  appletalk-in-IP forms of appletalk.  The 0188 release of KIP added
  the support of ethertalk.  Thus a single ethernet cable can support
  both the ethertalk and the appletalk-in-IP encapsulations.  This is
  done by assigning such ether cables TWO appletalk network numbers.
  Traffic directed to one of the net numbers goes out in ethertalk
  form, traffic to the other net number goes out as appletalk-in-IP.
  At a recent Apple sponsored IP conference, this mechanism was dubbed
  'doubletalk'(!)

  You might encounter this confusion in terminology:  before 1987 Apple
  Computer refered to the protocol family AND the physical cabling /
  signaling system as 'appletalk'.  Just be aware that 'appletalk' NOW
  means the protocol family and not just a particular physical
  implementation such as localtalk or ethertalk.


CONFIGURATION AIDS

Atalkad has two new configuration aids.  The major one is a "%n"
format item that can be used to refer to a "previous appletalk network
number" in the atnete, atneta, and atnetet fields.  See the install
document for further details.

The second configuration aid is a "check" command.  Now, if you run
atalkad with the "-c" flag it will check the default atalkatab by
reading it in and dumping it back in a human readable format.

A sample output from -c might look like:

	1/21 10:46 (re)reading atalkatab.test
	1/21 10:46 art build: 3 entries, 64 maximum
	Route 0.3 IP.Network,  net 0: host is client at 128.xx.16.0
	Route 66.0 ethertalk.Network,  ethertalk at 128.xx.16.144
	Route 64.9 appletalk.Network,  Kinetics box at 128.xx.16.144
		IP Broadcast: 128.xx.16.255, IP name: 192.1.2.67
		IP debug 128.xx.0.148, IP file server (unused)
		IP static address range: empty
		IP dynamic address range: 128.xx.16.145 128.xx.16.159
		Kbox interfaces:
			LocalTalk: 64.9 zone appletalk.Network
			KIP: 0.3 zone IP.Network
			ethertalk: 66.0 zone ethertalk.Network


ZONES

The zone name "ALL" allows multiple CAP hosts on a single large
ethernet to be visible in multiple zones.  This modification is from
Dan Tappan at BBN and below he explains how he uses this capability.

  The motivation is that we have one central ethernet, connected with
  LANBridges, with all the server systems on it. Different machines are
  owned by different groups, and I'd like for them to have the option
  of being in different zones.  The appletalk ZONE definition assumes
  that all machines on one network are in a single administrative
  group.  That's reasonable for localtalk when you're talking about max
  31 (and practicaly O(10)) but breaks down with CAP (and Ethertalk for
  that matter).  Before this mod I had to put a separate entry in
  atalkatab for every zone, pointing at the same network (or assign
  fake network numbers pointing to the same IP net). It seemed kludgy,
  was an administrative pain, and wasted table space.

Be careful with this option though: it is in violation of the appletalk
specification.  Note: atis, the CAP NBP nameserver, will only answer
NBP lookups in its own zone and NBP Lookups from the gateway always
include the zone (e.g. never "*").

KIP 0987 and previous releases of KIP assumed that interface networks
were in the same zone.  In KIP0188, all three appletalk-forms may all
be in different zones.


KNOWN PROBLEMS

KIP0987 added configuration flags for "conf_laserfilter" and
"conf_tildefilter".  Unfortunately, these do not work properly in all
cases.  The problem comes up when you have a NBP Response with more
than one entity in response.  This problem may occur under the
following conditions: (a) a node has more than one name in its names
information table and (b) the node receives a wildcard lookup.


OTHER CHANGES

Atalkad didn't always reread administrator database table (atalkatab)
file when the file was rewritten and modifications were made to correct
this situation.

The gateway now answers DDP echo requests.

DDP long form packets are always accepted now--even where short form
packets are asked for in the (July '86) appletalk specifications.
RTMP and non-atp ZIP responses are still sent out in DDP short form on
all interfaces.

ATP ZIP requests are always sent in long DDP form.

The zonelist is not sent in response to the ZIP Get My Zonelist
command if the zone is restricted.

Ethertalk probes are done with a retry count of 10 and a retry interval
of 1 second.  This is out of spec with the ethertalk specification.
However, the specification calls for an absurd number of probes in an
unreasonably short interval.

The 'install' document was revised with latest information.

ATP ZIP support rewritten.

Some modifications were make to the ethernet driver to speed it up
marginally.

--------
Ethertalk support was added by Dan Tappan, BB&N.

DDP Echo support, RTMP modification, and some ethertalk modifications
added Charlie C. Kim, User Services, Columbia University.
DataMuseum.dk

DKUUG/EUUG Conference tapes

⟦e7bf19925⟧ TextFile

Derivation

TextFile
