Relay-Version: version B 2.10 5/3/83; site utzoo.UUCP
Path: utzoo!mnetor!seismo!lll-crg!nike!ucbcad!ucbvax!COLUMBIA.EDU!cck%cunixc
From: cck%cunixc@COLUMBIA.EDU (Charlie C. Kim)
Newsgroups: mod.protocols.appletalk
Subject: InterBridge + FastPath = ?
Message-ID: <8609222119.AA16686@columbia.edu>
Date: Mon, 22-Sep-86 17:19:42 EDT
Article-I.D.: columbia.8609222119.AA16686
Posted: Mon Sep 22 17:19:42 1986
Date-Received: Mon, 22-Sep-86 22:01:53 EDT
Sender: daemon@ucbvax.BERKELEY.EDU
Organization: The ARPA Internet
Lines: 51
Approved: info-applebus@c.cs.cmu.edu

The following is based upon the June '86 version of Inside AppleTalk.

Follow are a few corrections and additions to what Dan Tappan had to
say (which was essentially correct).

(1) The reason that the Interbridge has supremecy over the Kinetics
box is because it probably does broadcast its RTMP Data Packets more
often than the Kinetics box.  The specification says that upon
receiving a RTMP request the "non-bridge" node (a RTMP stub node)
should reset the value of A_BRIDGE (which is the node number of the
appletalk bridge to use for forwarding).

Note that the currently published specifications for the various
timers are: for bridge nodes to broadcast RTMP Data Packets every 10
seconds; for Bridges nodes, with no RTMP Data Packets for a route, to
make the route suspect after 20 seconds, to mark bad after 40, and to
delete after 60 seconds; and for non-bridge nodes (RTMP stub nodes) to
timeout A_BRIDGE specifications after 90 seconds (but not THIS_NET -
the appletalk network number).

Thus, there should be a span of time no greater than 10 seconds in
which the Kinetics box is known as the valid bridge node to the Mac
(assuming the interbridge follows the RTMP specification very
tightly).  The Interbridge, in all probability, follows the
specification very closely since my understanding is that the bridge
code it runs is under license from Apple...


(2) The newest AppleTalk specifications don't even say this about
forwarding BrRq packets.  The reason is that this responsibity
actually belongs to the Zone Information Protocol (ZIP) (which wasn't
in the original documents in any form other than a slight mention).
The implication is that to properly implement RTMP you must also bring
up ZIP; I may have misread the specification here, but I don't think
so.  You could always fake it and pretend there was only one zone: the
way ZIP is suppose to handle NBP BrRq's is to send directed lookups to
the various networks in the zone.

Implementing both RTMP and ZIP properly requires careful thought
(especially since there is a high level of interaction between the
two).  For instance, it is not enough to make the Kinetics box send
"full" RTMP packets (based upon what it knows).  Minimally, even
ignoring ZIP, you must also make it understand RTMP data packets and
RTMP requests; even might not be enough since you must remember that a
setup with two kinetics boxes with interbridges behind each of them
requires RTMP traffic across the ethernet (somehow, someway...) to
support full internet operations.

Charlie C. Kim
User Services
Columbia University