[aprssig] AX.25 RR bit test - Holy Grail?

[Andrew P.]

Robert:

Just as a reminder, these bits are in AX.25 headers. _not_ in messages sent through APRS-IS, and not available in any clients speaking to command-mode TNC's. Only KISS-mode TNC's would be able to pass such non-standard packets.

Would that cause a problem with any plans you have for this?

Andrew Pavlin, KA2DDO

> From: bruninga at usna.edu
> Date: Fri, 30 Nov 2012 13:30:24 -0500
> To: aprssig at tapr.org
> Subject: [aprssig] AX.25 RR bit test - Holy Grail?
> 
> Byon, Scott, everyone...
> 
> Have I been asleep for 30 years? Or are these RR bits in every AX.25
> packet the available extra bits I have been looking for all these years?
> 
> Who can generate raw AX.25 packets with these bits set to something other
> than "11" so we can see what existing APRS hardware does with them???
> 
> If so, and if all existing TNC's ignore these bits then we have tremendous
> potential for expanding APRS capability without obsolescing anything! ...
> Every APRS packet has at least 4 of these bits we can play with...  Every
> digipeated packet has 2 more
> 
> Or is this just another "senior moment"?
> 
> The bits I have always wanted are for setting PRIORITY levels and OPERATOR
> PRESENT for starters...  Now the HAS-BEEN-PREEMPTED is another...
> 
> Bob, WB4aPR
> 
> -----Original Message-----
> From: Robert Bruninga [mailto:bruninga at usna.edu]
> Sent: Friday, November 30, 2012 12:36 PM
> To: TAPR APRS Mailing List
> Cc: Robert Bruninga
> Subject: RE: Premptive Digipeating (b) PATH MARKING
> 
> Taking comments to date, I added the sentence about keeping the remainder
> of the path open, and attempted to address Steve Dimse's very valid points
> about traceability.  I'm suggesting we can use the RR bits in the SSID
> field. CAN WE DO THIS?
> 
> PREMPTIVE DIGIPEATING DEFINITION (rev b):  When ON, the digi will search,
> starting at the first unused field and then to the end for a match to any
> of its potential matching aliases (MYCALL, MYALIAS, UIDIGI).  If a match,
> it will mark that and all prior fields as HAS-BEEN-USED, it will REPLACE
> its ALIAS with its MYCALL and will digipeat it once.  All remaining fields
> are still active.
> 
> INDICATORS:  When the packet is preemptively digipeated, the preempted
> path can either be DROPPED, or MARKED.  If dropped, then the packet
> arrives with only the preemptive digipeater's MYCALL and remaing path as
> normally done.  All prior path data is lost.  Or if MARKED is SET, then
> the entire path is retained but the LSB of the two RR bits is set to 1
> indicating the field was prempted.
> 
> In the GATEWAY scenario, one would probably use the DROP setting.  In the
> normal network scenario, then the MARK setting might be the best setting.
> 
> PRIORITY BIT:  Now why not use the other RR bit in the SSID field for a
> PRIORITY bit.  The existing default value of the RR bit is 1 and will
> indicate a PRIORITY  packet but if "0", then this packet is of less
> priority and can be dropped in future networks that recognize it..
> 
> QUESTION:  Does playing with the RR bits break any existing processing?
> To see the definition of these bits, see figure 2.2.13.1.1 in:
> http://www.tapr.org/pub_ax25.html
> 
> So the PREMPT TNC command now has 3 settings:  OFF, DROP, MARK to indicate
> how to indicate the action.
> 
> The rest of the below remains as originally
> proposed:-----------------------
> 
> PACKETS TO HOME SCENARIO:  In this scenario your goal is to get your
> packets targeted to a particular digi or area.  The path WIDE2-2,HOMEX
> With the HOMEX digipeater recognizing pre-emptive digipeating would make
> sure that all your packets got to HOMEX in from 1 to 3 hops.  To get them
> say 4 hops from City A to City B without flooding everywhere, the path
> WIDE1-1,CITYA,WIDE2-1,CITYB would get to CITYB no matter where you are in
> A or B or inbetween, but not involve ANY OTHER DIGI's than the shortest
> path between them.  ETC...
> 
> Or CITYD,CITYC,CITYB,CITYA would let you go on a trip to CItyD, but your
> packets would get back home to A no matter where you were inbetween.  When
> close, then they would only go 1 hop.  Or if you wanted those at CityD to
> anticipate your arrival, you might use the path CITYA,CITYB,CITYC,CITYD
> and then your packets would all preceed you to CITYD until you got there,
> but with fewer and fewer hops as you got close.
> 
> GATEWAY SCENARIO:  IN this scenario there is a special event on FREQB with
> lots of FREQB digis that desires to get at least one (and only 1) copy of
> each packet into the 144.39 system via a cross-channel gateway with the
> callsign GATE.  The path of FREQB7-7,GATE,WIDE2-1 would make sure that a
> packet got everywhere in the special event network but only one copy
> always gets through the gateway at least one hop into the APRS network.
> (such as the linear appalachan trail event or an underground multihop cave
> event...
> 
> NO PREMPTIVE DIGIPEATING ON UIFLOOD and UITRACE.  The reason is, that it
> would preclude any use of any kind of WIDEn-N AFTER going through a gate,
> and that is one of the main reasons for doing it.
> 
> Remember, these 4 hop Premptive SPECIFIC paths are MUCH less load on the
> network than a WIDE4-4 which can potentially cause 34 DUPES, compared to
> only a maximum of 4 hops with the explicit preemptive hop approach.
> 
> Have I missed anything?
> 
> Bob, WB4APR
> 
> _______________________________________________
> aprssig mailing list
> aprssig at tapr.org
> https://www.tapr.org/cgi-bin/mailman/listinfo/aprssig
 		 	   		  
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.tapr.org/pipermail/aprssig/attachments/20121130/7e7f4d3b/attachment.htm>