[ax25-layer2] IP Routing

[pete at ae5pl.net]

> -----Original Message-----
> From: Timothy J. Salo
> Sent: Tuesday, September 20, 2005 12:35 AM
> To: ax25-layer2 at lists.tapr.org
> Subject: RE: [ax25-layer2] IP Routing
> 
> Backward compatibility is, like the say, a bit like 
> pregnancy: either you are or you aren't -- there is no half way.
> 
> Your proposed or desired changes will create a version of 
> AX.25 that is incompatible with the existing standard and usage.

It will not be incompatible with the existing standard.  It will enforce
the existing standard.  Therefore, it will be "backward" compatible.  It
will not, however, support non-layer 2 usage of the digipeater fields
although people may still be able to implement some level of layer 3
routing within the AX.25 protocol if they so desire to break local
networks.

> My simple answer is: this simply isn't going to happen.  

That is your view and if you are correct, then AX.25 and all those
existing devices you talk about will go the way of all the other AX.25
applications: into history rarely to be heard from again.

We have a lot of new amateurs coming on the scene whose entire
experience with data is in networks where they don't fuss with layer 2
and make use of layer 2 protocols instead of trying to hack them.
Hamdom has spent the last 20+ years trying to hack AX.25 with _nothing_
to show for it.

TNC2 ROMs can still be made and coded.  Kantronics still supports their
TNCs.  Specialty TNCs such as trackers are compatible with what is being
proposed.  So can it happen?  I say "Yes!" and if it doesn't, I believe
that all that "neat" equipment will go the way of the AM radio on HF:
nice to use but used by very few.

Here is a proposal which can be done in any TNC out there if someone
(and/or the manufactures) write the code:

1) AX.25 v2.2.  This includes the restriction to 2 digipeaters.

2) NSR UI algorithm with the addition of the destination SSID to dupe
checking.  This provides the basis for higher layers to "discover"
associated higher layer devices on the RF LAN.  This also supports the
current APRS application sans long distance routing on a single channel.

3) No layer 3 routing via digipeater fields (in other words, TNCs do not
directly support aliases or any of the other AX.25 "node"
implementations).

4) KISS with out-of-band (RTS/CTS) flow control.  One of the biggest
problems to KISS has been buffer overruns.  Digipeating can occur even
when in KISS mode.

5) For serial or USB TNCs, command mode is just that: the mode to set
TNC parameters.  No direct keyboard transmissions can be accomplished
and no "monitor" mode.  All transmissions and reception must be done
using #4.


Now, can someone write a driver to still make use of AX.25 as a layer 3
protocol?  Yes because they have direct access to the
transmission/reception via KISS.  Will these devices _directly_ support
non-layer 2 usage of AX.25?  No because those mechanisms have been
removed (long range digipeating, aliases, text mode, "node" operations,
etc.).

The proposal above is significantly less code than exists today within
TNCs.  It is compatible with today's KISS drivers yet provides known
network extensions which those driver authors can make use of for
interfaces to higher layers.  It provides an extra layer of stability to
those drivers by allowing flow control at the KISS layer.

The reason for this SIG is to try and come up with ideas like above,
discuss the ramifications, and create "standard" implementation
specifications which authors can then code to.  There is no reason why
manufacturers would not want to code to standards that would improve
their sales (since usage would increase), simplify their support
(simpler implementations mean fewer demands upon their support), and
improve the usability of their devices.  The easier and more
"plug-and-play" the network is and the more reliable the network is, the
more usage we will see.

Also, there are many new TNCs coming on the market and if they focus on
layer 2 implementations, our networks can and will change.

73,

Pete Loveall AE5PL