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