Path: utzoo!attcan!utgpu!jarvis.csri.toronto.edu!mailrus!csd4.csd.uwm.edu!gem.mps.ohio-state.edu!ginosko!uunet!murtoa.cs.mu.oz.au!djh From: djh@cs.mu.oz.au (David Hornsby) Newsgroups: comp.protocols.appletalk Subject: Re: UDPTalk as a backbone Message-ID: <2831@murtoa.cs.mu.oz.au> Date: 7 Sep 89 11:58:44 GMT References: <1989Sep6.165747.23972@caen.engin.umich.edu> Reply-To: djh@murtoa.UUCP (David Hornsby) Organization: Comp Sci, Melbourne Uni, Australia Lines: 45 In article ("Steven L. Waldbusser") writes: > >> Excerpts from internet.info-appletalk: 6-Sep-89 Re: UDPTalk as a >> backbone billkatt@ucsd.edu (3104) > >> I've tried it, have you? Look a little closer. The packets which >> FastPaths use to supply original routes aren't RTMP packets. It happens >> that with 64 routes, the packet used to supply routes to FastPaths is >> full. > > At CMU we have achieved 100 routes from one atalkad host (we currently >use 93). There are two mechanisms behind this. There is another method, currently in use around here and working well. There is an otherwise unused (and zeroed by default) flags field (1 byte) in these AA packets. A simple protocol allows a gateway to obtain (theoretically) 256 routing packets or 256 * 64 = 16384 route tuples The protocol is trivial but requires modifications to both atalkad and the gateway code. I list it here with the packet types we use for your interest. Initially atalkad receives an aaROUTEI (2) request. If the number of routes is bigger than one packet, atalkad returns the first packet with the flags field set to the number of packets that are required to transmit the data. The gateway then continues by sending aaROUTER (33) requests with the flags field being set to the desired packet. atalkad returns a type aaROUTEM (32) packet with the desired data and the flag set to the packet number. This continues until all the data is transferred. There is a similar mechanism for aaPROXY packets. >This is no substitute for a cleanly engineered solution which is >needed in the long term. I feel that such a solution should come from >your favorite gateway vendor. It also needs the cooperation of all the other gateway vendors :-) Cheers, David Hornsby ...!uunet!munnari!djh Professional Officer djh@munnari.OZ.AU Department of Computer Science "The home of Multigate" +61 3 344 4044 The University of Melbourne, Parkville, 3052, Victoria, Australia.