[ax25-layer2] Possible Implementations

[pete at ae5pl.net]

A couple of good questions/statements were made that raised some
implementation issues.  Here are a couple of thoughts:

Multicast/broadcast addressing for UI.  This is in reference to packets
that might be carrying layer 3 multicast/broadcast information.  It does
not address APRS in which the destination field is not considered to be
a station address and therefore all packets are multicast/broadcast.  I
can think of a couple ways this could be implemented.  One would be to
define a "standard" multicast "callsign".  This would also give up to 16
(SSID) individual multicast groups.  The other way would be to put the
originating station's callsign-SSID in the destination field.  I tend to
lean towards this method as it doesn't require anything out of the
receiving interfaces other than to recognize that if source=destination,
it is a broadcast packet and should be looked at.  Also, I would think
that any multicast use differentiation should be done at higher layers,
not at the LAN link layer.  Note that both methods only affect how the
link endpoint devices _interpret_ packets and do not alter the spec in
any way.

Emergency digipeater support for the NSR algorithm.  This could be done
by standardizing on a callsign for those emergency digipeaters.  Again,
we are talking about replacing a down digipeater or adding a fill
digipeater _to get to a layer 3 interface_.  This keeps within the
concept of minimal single channel repeating yet would allow people to
set up emergency coverage without central digipeater reconfiguration by
the sysop.

Finally, there have been some questions regarding "Why bother?".  The
NSR algorithm was born out of recognition that in many areas such as
north Texas, APRS operation was out of control and rapidly degrading to
a relatively useless toy.  Personally, I have fought long and hard to
prevent this decline and to find worthwhile uses for APRS in our area
but I am fighting a losing battle as long as the current network
architecture is maintained.  However, I discovered that the NSR
algorithm had application outside of APRS and might also be of value to
help create a useful, layer 2 network architecture that all
_applications_ which use AX.25 could use.  While the NSR algorithm
provides a standardized repeating mechanism for UI packets, I also
recognize (as posted earlier) that much more is required to develop a
standardized layer 2 network architecture that anyone can use.

Why is this important?  Because if any application can be written with a
well defined link layer interface and hams would know that _any_ AX.25
network would support their application without modification, we could
have a generic platform for amateur RF network development just like
802..., DStar, and other well-defined link layer protocols exist for
other developers.  This is the biggest benefit that I see.  Under normal
circumstances, different LANs for different purposes.  But since those
LANs all appear to be the same to higher layers, any of the LANs could
be used for any purpose under extraordinary purposes.  In many cases,
these LANs could share purposes even during normal operation depending
on local load.

Also keep in mind that backbone links can also utilize AX.25.  The key
to this occurring, however, is that AX.25 information is not transported
through the layers unaltered.  If we truly have AX.25 being used as a
link layer protocol, then separate links (channels) can share station
identifiers (callsign-SSIDs) and each link/LAN would be able to operate
independently.  Some LANs might share RF channels so pure callsign-SSID
independence could not be assured, but most backbone links could assure
such independence.

In summary, a standardized link layer facilitates usage across many
platforms, improves usability under damaged situations since disparate
networks can be used interchangeably as needed, and simplifies
configurations (thereby increasing usability) for existing applications
as well as future applications.

This may not be enough to justify implementing such a standardized
network to some, but I believe that as people see the benefits, the
migration to a standard architecture will follow.

73,

Pete Loveall AE5PL