[aprssig] Modification to AE5PL's routing idea

[Gerry Creager N5JXS]

Wes,

I've succeeded in staying out of this on the sig, and I'm gonna try for 
a couple of more rounds.  I'm swamped at work so I can't give this a lot 
of cycles, but feel free to use or abuse my comments.

OK, first comment:  SOURCE ROUTING IS EVIL.  There are places for it, 
but overall, it's just plain wrong to expect every user to define every 
aspect of their route.

If we retain the capability to allow 'RELAY,COUNTY' we're encouraging 
source routing.

I can accept a route delimiter of LOCAL, COUNTY, NWSxxx (as recognized 
by the local network), STATE, etc.  These aren't source routing, but, 
instead, indentify intent.

We're back to the fact that we need to be engineering (requirements, 
specifications, design, implementation) a new version of the APRS RF 
*AND* IS network interfaces.  That's going to mean more hardware design, 
and more software design.  It will require input, but not necessarily 
coding help, from the client authors and folks like Pete and Steve, 
who've a rather deep and focused concept of the current workings of 
these areas.

We're not talking about disenfranchising anyone, and we're not talking 
about a revolution overnight.  We're talking about a mechanism where a 
broadcast protocol for tactical position reporting, with some adjuncts 
attached and accepted as useful, can be better handled as the number of 
users, and the network complexity grows.

Another problem I have resides with continuing to use digipeaters.  The 
technology has bypassed them.  We can, and should, begin looking at a 
more network-centric mechanism than a layer 2 hub being the core of our 
networks.  The I-Gate concept effectively incorporates routers and 
intelligent broadcast filtering, but the core of the RF systems, that 
getting RF data to the IS, is dumb hubs.  There's a major efficiency 
failure.

Most of Bob's efforts in network "enhancement" over the last 5 years... 
longer?... have focused on taking a broken paradigm and slapping 
bandaids on it to make it better.  Of these, the original RELAY,WIDE and 
WIDEN-n concepts were refocusing events.  The rest have tended to be 
distractors supported by questionable math and an attempt to make an 
archaic system do things it's incapable of achieving.

I suggest we're on the right track.  It's time to look at some real work 
in network design, and hardware implementation going.  I suspect we 
could take a day at DCC, with this group of addressees and perhaps a 
half-dozen more, and wrap up a reasonable requirements document, and 
have a decent start on a specification.

I'm gonna talk to a colleague with some students in telecommunications 
for their Masters.  (I don't ever see him really getting a serious PhD 
student...) I think we could possibly leverage one or more of these for 
the theoretical evaluations of what we're talking about, and some 
simulations.  Anyone game to help write an NSF proposal to the CISE or 
Networks areas?

73, gerry

Wes Johnston wrote:
> In a nutshell, in the winter 2005 PSR ftp://ftp.tapr.org/psr/Winter_94_2005.pdf
> , Pete Loveall ae4pl suggests that digipeaters hearing any packet would remove
> the path from the packet and substitute it's own callsign and mark that
> callsign as having been digipeated.  Other surrounding digi's would be
> programmed to recongize that original digipeater's callsign as "local" and
> digipeat any packet marked with that digi's callsign.  Each digi in the system
> would keep a checksum of the last 30 packets' data portion for dupe supression.
> 
> The thing I didn't like about this idea was that the users could not specify a
> smaller area than the area of digipeaters who were programmed for a given area
> - not that any of us ego-maniacs would want smaller coverage, right?? lol. 
> Seriously though, what about the need for different coverage for different
> services like NWS (which often one office serves two states).  Another drawback
> to Pete's idea is that if someone adds a new digi, none of the other digipeaters
> would recognize it until all the other digiowners programmed their digi to be
> familiar with it - or maybe this isn't a drawback ... some digiowners put up
> digi's for the sake of having thier call's attached to a digi.... we'll deal
> with that later.
> 
> Anyway, the suggestion that came up (again) yesterday was to use a generic call
> such as LOCAL, CITY, COUNTY, STATE.  If we combine Pete's excellent idea with
> the suggestion from yesterday, we can make it fit in the AX.25 v2.2 spec which
> limits us to 2 digipeaters instead of 7.
> 
> Here's how we do it...
> A user transmits a packet with a path of COUNTY.
> kd4rdb>aprs v COUNTY:my data here   (yes, I do mean the generic term COUNTY for
> the sake of travellers who may not know what county they are in)
> 
> A given digipeater (kc4pl in this case) in the area hears this packet direct and
> rewrites the path to include the specific county and as Pete suggests, puts in
> the digi's callsign with the has been digi'ed flag set.
> kd4rdb>aprs v SUMTER*,kc4pl*:my data here
> 
> Now, all other neighboring digi's that have been programmed to respond to SUMTER
> alias will digipeat the packet and maintain a checksum of the packet's data
> portion in memory for dupe supression.  They will simply digipeat the packet
> per Pete's idea and not alter it in any way - the first digi did all the mod's
> to the packet we'd need.
> 
> The same can work for NWS areas... all digi's in NWSCHS (nation weather
> Charleston) would respond to NWSCHS... it works on a state level with all
> digi's in a group set to respond to two letter state abbreviations, it works
> for CITY too!!  If each digipeater were to have the ability to know to respond
> to 6 or 10 such aliases, we'd have a winner!  The individual digiowners would
> simply get together and determine the local convention for the spelling of the
> various areas they wish to support.  The users don't need to know the
> spelling/abbreviations because they just use words like CITY,STATE, LOCAL and
> IGATE.
> 
> Now for the gotchas and details....
> 1)users could transmit a packet to RELAY,COUNTY instead of just COUNTY.
> 2)users could still specify a path which names specific digipeaters so they can
> go further in one direction if needed.
> 3)digipeaters could analize paths such as WIDE2-2 and realize that is equivalent
> to COUNTY and convert the WIDE path to Pete's path system on the fly.
> 
> This is souped-up subnetting.
> 
> Comments?  Jason?? Gerry? Eric? Pete?
> 
> Wes
> --
> 
> 
> 
> 
> 
> 
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig

-- 
Gerry Creager -- gerry.creager at tamu.edu
Texas Mesonet -- AATLT, Texas A&M University	
Cell: 979.229.5301 Office: 979.458.4020 FAX: 979.847.8578
Page: 979.228.0173
Office: 903A Eller Bldg, TAMU, College Station, TX 77843