brad@gcc-milo.UUCP (Brad Parker) (09/22/86)
Has anyone used the CAP 2.01 gateway code with a Hayes interbridge?
Everything works fine until I turn on the interbridge:
+---> mac
|
VAX <---> Kinetics box <---+
|
+---> InterBridge <----> many mac's
I looked at the NBP requests coming from the VAX (running the
samples/look program). Everything comes across fine, but the mac's
all seem to send their NBP lookup responses back to the *wrong*
bridge (the InterBridge) in this case. Turning off the Interbridge
allows the vax to see the mac on the middle bridge again.
Shouldn't the RTMP stub in each mac handle this case?
Brad Parker
harvard!gcc-milo!brad
--
J Bradford Parker
General Computer (HyperDrive Beach, 3rd Cabana)
harvard!gcc-milo!brad
Good Sex is easier than a good slow roll. ("Left Stick! Right Rudder!...")Tappan@G.BBN.COM (Dan Tappan) (09/22/86)
Date: Sun, 21 Sep 86 20:25:13 edt
From: brad%gcc-milo.UUCP@harvard.HARVARD.EDU (Brad Parker)
Newsgroups: mod.protocols.appletalk
Subject: InterBridge + FastPath = ?
Has anyone used the CAP 2.01 gateway code with a Hayes interbridge?
Everything works fine until I turn on the interbridge:
.....
I don't have an interbridge to play with, but I can make some guesses:
1) The RTMP doc. in inside mac "suggests" sending RTMP updates every
5 seconds (with a "gateway down" timeout of 10 seconds). The Seagate/Kinetics
UDP gateway code sends an RTMP packet every 30 seconds. 30 seconds seems
like a much better number as far as not wasting appletalk bandwidth, but
likely the Interbridge close 5 seconds. This means two things
i) It probably is declaring the Kinetics down.
ii) Since it sends so many more packets than the Kinetics the Mac always
choses it as "a_bridge".
2) Even assuming the RTMP stuff was in sync, the UDP gateway code does
not do a full RTMP. It wouldn't be hard to make it forward to the Interbridge
properly, but there are a few things that might be alittle painful:
o The spec says gateways "cooperate in forwarding BrRq nbp packets to
all nets" It doesn't say how. Specificly it's not clear whether
the InterBridge will forward the BrRq packet to the Kinetics box, and
in what form.
o The appletalk routing protocol is fairly simplistic, more or less like
the old Arpanet GGP which broke down under alot of networks. The CAP
code uses a routing server. The interface to the routing server needs
to be extended alittle so the Kinetics box can generate a RTMP packet
that will tell the InterBridge all the nets that it (the Kinetics box)
can reach.
I suppose someone needs to sit down with an Interbridge and resolve
these issues. Probably the biggest one is the "send-RTNP" interval,
I don't think I would want several bridges broadcasting every 5 seconds
on my appletalk net.
-------cck%cunixc@COLUMBIA.EDU (Charlie C. Kim) (09/23/86)
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
Tappan@G.BBN.COM (Dan Tappan) (09/23/86)
You probably don't need to do RTMP across the ethernet, it would be sufficent to let the masterbridge know about the indirect routes to both (all) interbridged nets. Note that you want to be real careful in setting up linked appletalk nets. The way the MAC RTMP stub is implimented you can have two linked nets [mac] [mac] ------[bridge]----- or a star with no mac's on the center cable [mac] -------[bridge]| | [mac] -----[bridge]------[bridge]------- | etc but anything more complicated than that then the packets start getting sent to a non-optimum bridge ((N-1)/N of the time) and travelling over the appletalk cable twice. Cuts the usable appletalk bandwidth in half. Basicly you need to think of the appletalk internet as a tree, and mac's can go only on the leaves. Has anyone seen a specification for ZIP yet? For that matter, my 'Inside Appletalk' is from Spring '85: are there enough changes that it would be worthwhile my updating it? It would be nice if Apple publicized it when they changed the specifications. -------
croft@SAFE.STANFORD.EDU (Bill Croft) (09/26/86)
Here at Stanford we are currently debugging new gateway code that will allow such use of the Hayes bridge, provided that the net numbers used by the Hayes boxes are pre-registered in the masterbridge database. The major new functionality of the gateway however is in the manner in which it manages IP addressing for Mac's running MacIP. We expect to release the new gateway code and C based MacIP in mid October. Kinetics has also indicated that they are eager to cooperate with putting full ZIP/RTMP functionality into the IP/UDP version of the gateway. They have already implemented this for their DDP version and may be able to merge this code with the public domain UDP gateway by perhaps adding new PROM entry points.