[ax25-layer2] The lights.

[pete at ae5pl.net]

See below... 

> -----Original Message-----
> From: Robert Bruninga [mailto:bruninga at usna.edu] 
> Sent: Sunday, September 25, 2005 6:01 PM
> To: Pete Loveall AE5PL; ax25-layer2 at lists.tapr.org
> Subject: RE: [ax25-layer2] The lights.
> 
> I don't think there is anything in the AX.25 protocol that 
> prevents it from being used as a simple Layer 2.  Just 
> because present use of some TNCs add some layer 3 stuff that 
> you do not find satisfactory, does not prevent you from using 
> these same TNC's at a pure level 2  and writing whatever 
> layer 3 code you want on top of that.

You are correct.  There is nothing in the spec that prevents AX.25 from
being used as a layer 2 protocol.  However, a necessary component
required for AX.25 to be used as a layer 2 protocol is the ability for
other layers to navigate the small (link) layer 2 networks without
knowledge of the underlying topology.  This is normally achieved by
providing a transparent discovery mechanism which then can be used for
all broadcast messages or to automatically discern best path for link
layer connections.  This mechanism does not exist in today's AX.25
network implementations.  Also, in most of today's APRS digipeater
implementations for instance, the digipeaters only digipeat UI packets
and only using predefined paths.  This is contrary to a transparent,
generic local area topology.  In non-APRS networks, other mechanisms
exists but none provide this generic discovery capability.  So it all
gets back to how we implement AX.25 since the spec (as it should)
defines the protocol, not how we implement it.

> Maybe all you need to do is to simply re-write the KISS 
> inteface, to get the universality you want.

The KISS interface is actually a layer 1/2 interface since it doesn't
enforce any AX.25 constructs and therefore is fine just the way it is
since any of the AX.25 layer 2 operations being discussed can be done
with a TNC in KISS mode today if the underlying network topology also
supports it.  To accomplish this last part, the digipeater code needs to
change, not the AX.25 spec and not the layer 1/2 interface.  The
digipeater code needs to change to implement a _generic_ broadcast mode
to support higher layer discovery operations and then those digipeaters
must also support connected mode digipeating to provide higher layers
with "best path" connectivity through each link layer LAN.

> Nothing in the AX.25 spec needs changing to do that?

Again, while some may determine that minor tweaks to the spec are
required as Bill mentioned in his post, in general the 2.2 spec appears
to be pretty much on track.  It recognizes the inherent problems
experienced by multiple repeats on a single half-duplex channel by
limiting digipeaters while providing extended support for layer 3
protocols being _transported_ over AX.25 (as opposed to AX.25 being the
layer 3 protocol).

73,

Pete Loveall AE5PL