[ax25-layer2] 7-byte address proposal

[Samuel A. Falvo II]

On 8/2/06, Pete Loveall AE5PL <pete at ae5pl.net> wrote:
> Also, I have seen comments about things like voice-over-packet.  This is
> trying to move AX.25 out of layer 2 and writing AX.25 specific
> protocols.

This is not true, and I don't see how or why you would come to this
conclusion.  Voice over IP has done absolutely nothing to change IP as
a layer-3 protocol -- most VoIP implementations utilize UDP/IP or the
new TCSP/IP protocols.

Nonetheless, the use of AX.25 to propegate digital voice cannot be
discounted on links with sufficient bandwidth.  QoS has to do
primarily with two things: timing (when to send out frames so as to
not congest the switches), and efficiency (using as large a frame as
possible to minimize header overhead, but subdividing a single frame
into multiple slots, each of which represents a different QSO in
progress -- essentially, when combined with carefully scheduled frame
transmissions, TDMA).

> If we can get a 2.3 specification which is somewhat backwards compatible
> (doesn't break currently installed equipment) with relatively generic
> support, then we can look at a 3.0 specification that may not be

I truely don't see what needs to be changed in v2.2 going forward to
v2.3.  The only thing that I would say needs to be "changed" is
verbiage telling application developers that certain antiquated modes
of use are deprecated and not guaranteed to be functional in an AX.25
v3.0 environment.

Looking forward to v3.0, the only thing I see that needs to be changed
so far is the support for different addressing formats, and maybe
support for supporting XID information as well.

Remember that AX.25 is a layer-2 protocol like Ethernet is.  How often
does Ethernet change?  :)

> character callsigns, QoS, non-HDLC layer 1s, etc.  While not necessarily

Heh, QoS at layer 2 with any kind of frame relay service on a shared
bandwidth medium, of which AX.25 over RF falls into, is going to be
nearly impossible.  The only reason VoIP works (not all that) well at
all is because of 1000-base-T and 10GigE star-topology backbones.  And
even with these rediculously fast Ethernet technologies, you get
quarter second or more of delay, massive echo, etc.

If you want true QoS, you will want Amateur ATM or DTM.  It really is
that simple.

Still, implementing things like Forward and Backward Explicit
Congestion Notification schemes (which is almost certainly a layer 3
issue) can help determine the *rate* at which a source node issues
frames so as to minimize congestion inside the frame cloud.  Note that
the use of RR and RNR frames constitutes a limited form of ECN
already, but it's restricted only between two peers, and it's "all or
nothing" in nature.

VoP also need not be real-time -- I go through a repeater scenario
where non-real-time frame transmission is used to support multiple
QSOs on a single repeater in my NgARN article.

-- 
Samuel A. Falvo II