[aprssig] APRS routing strategies (was: New n-N success in North Carolina)

[Robert Bruninga]

>>> mckeehan at mckeehan.homeip.net 2/14/05 3:53:44 PM >>>
>I'm thinking about having some paths like this:
CITY
COUNTY
REGION
STATE
IGATE

Its a reasonable concept but is equivalent to this:

WIDE2-2 = CITY
WIDE3-3 = COUNTY   <== saturates channel in dense areas
WIDE4-4 = REGION    <== saturates channel in dense areas
SS5-5      = STATE
WIDE2-2 = WORLD

Problem is it would take all new hardware at over 1000
digipeaters and would not make sense until the majority
had switched over.  APRS for travelers needs consistency.

Bob



CITY would be equivilant to a single hop path, like a WIDE.
COUNTY would restrict the packet travel to the COUNTY
REGION would restrict the packet travel to the REGION (depending on
where you
are in the world, this could have different meanings)
STATE would restrict it to the STATE
IGATE would only be digi'd if the DIGI has recently heard an IGATE

This would let the user define how far out his beacon should propogate
- yeah,
it would require some more smarts on the part of the digi's and it may
not be
something that can easily be accomplished.

I think this would work well for position beacons, but not very well
for
sending messages. For messages, I see source routing as a pain and
would like
to simply address messages like an e-mail and have the digi's know how
to get
the message to the destination; this could be pretty easy with the
APRS-IS,
but I do not see how to do it with RF only without source routing.

Just some ideas - rip it apart :-)


On Mon, February 14, 2005 3:01 pm, Jason Winningham said:
>
> On Feb 12, 2005, at 4:20 PM, Wes Johnston wrote:
>
>> I love a good discussion....
>
> yep. (:
>
>> Well, yes, we are kinda saying the same thing.... what you are
doing
>> is putting
>> a cap on the number of hops a packet can take beyond you.... what
I'm
>> suggesting is that we pass it along as-is it hasn't hopped too many
>> times
>> already....
>
> OK, I see the difference now, and I see some merits for both
> approaches.  I need to draw myself some pictures.  There may be a
way
> to use a combined approach, or have it user-configurable for the
> digi/router operator.
>
> I haven't brought it up yet to keep examples simple, but when the
> router is calculating the requested number of hops (or the number of
> hops already taken) it should examine the _entire_ path, not just
the
> first unflagged call.  some example pseudo-code:
>
> total_hops_requested=0
> for each call in path
> 	total_hops_requested = total_hops_requested + hops requested by
this
> call
>
> ... and the hop count limit code from before:
>
> hop_count=total_hops_requested
>
> if total_hops_requested > max_allowed_hops
> 	hop_count = max_allowed_hops
> hop_count--
> if hop_count > 0
> 	transmit packet
>
> This would allow only a sane number of hops for a path like
> WIDE2-2,WIDE2-2,WIDE2-2,WIDE2-2,WIDE2-2,WIDE2-2.  We'd need to
decide
> on a mechanism for rewriting such a path; probably a total rewrite
is
> in order.
>
>
>
> While we're talking about hypothetical new hardware, we can designate
a
> new path specification: Hn, the letter H followed by a single digit
> indicating the number of hops requested.  H3 would be equivalent to
> R,W,W, or R,W2-2, R,R,R, etc.  Or, we could stick with WIDEn-n,
provide
> for an abbreviation of Wn-n and drop RELAY.
>
> I'm not sure of the consensus on the value of a path trace, but it
> would be simple to make adding the call of the router to the path,
> e.g., H3 is path received by router KG4WSV-7, "KG4WSV-7*,H2" is the
> path as transmitted.  I haven't examined the possibility of adding
> flags, but maybe something like inserting a call of "FLxyz*"
(flagged
> as digipeated) as the first call in the path would work.  We could
use
> flags for things like
>
> - "add a trace to this packet"
> - "digipeat only until I get to an Igate"
> - "this packet should stay within the area/state/region/etc"
> - "this is a serious situation and I _need_ for this packet to go 7
> hops" (to override hopcount reduction)
>
>
> There should probably be a "first hop only" router, analogous to the
> current RELAY only digi.  This device would transmit a packet only
if
> it had not been transmitted by another digi/router.
>
>
> There is also the issue of the APRS router acting as a standard
AX.25
> digipeater.  We are making assumptions on the path and modifying it
to
> suite an ARPS network, and the operations may not be compatible with
> standard AX.25 operation.  Once choice is to designate this device
as
> ARPS-only - no other AX.25 operations would be allowed.  Another
method
> would be to try and figure out if we're handling an APRS packet or
not
> and act accordingly.  This may be possible by examining the
destination
> address, and see if it matches one of the generic APRS addresses or
an
> ALTNET designated by the digi/router operator.
>
> It seems to me that the APRS network is busy enough without non-APRS
> traffic on the frequency, so it wouldn't necessarily be a bad thing
to
> "break" non-APRS packet operation.
>
> -Jason
> kg4wsv
>
>
> _______________________________________________
> aprssig mailing list
> aprssig at lists.tapr.org 
> https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig 
>
>


-- 
William McKeehan
KI4HDU
Internet: mckeehan at mckeehan.homeip.net 
http://mckeehan.homeip.net 

_______________________________________________
aprssig mailing list
aprssig at lists.tapr.org 
https://lists.tapr.org/cgi-bin/mailman/listinfo/aprssig