Order Tray | Contact Us | Home | SIG Lists

[ax25-layer2] 7-byte address proposal

Samuel A. Falvo II sam.falvo at gmail.com
Thu Aug 3 17:34:07 UTC 2006

On 8/3/06, Pete Loveall AE5PL <pete at ae5pl.net> wrote:
> Summary: Any 7 character callsign accommodation within the current six 7
> bit characters + one 4 bit SSID addressing scheme is a kluge but a
> necessary interim step that should be developed as a de fact standard
> instead of part of the specification.  Before adopting a de facto

I disagree with this position.  The acts of maintaining current
addressing flexibility plus having 7 character callsigns are mutually
exclusive -- no matter what, something somewhere is going to break,
and software will need to be rewritten to accomodate 2.3.

I say instead of prolonging the pain and suffering, we should just go
ahead and design the AX.25 3.0 framing format and release it, and let
system implementers adjust their software accordingly.  Sometimes, you
just have to start over from scratch.

> standard, we should look at (as I did previously) the plus and _minuses_
> of any such scheme.  The 7 character callsigns might best be handled
> long term by a variable length header denoted by a unique PID in future
> versions of the specification which would not exclude using the
> thousands of currently deployed devices and applications.

The problem with this is that you must seek somewhere inside the frame
to determine the length of the previous part.  That means that the
0x30 must appear at a fixed location, even if the callsigns have to
wrap around it.  From a software development (and likely a hardware
development) perspective, that's gotta be one of the most bug-prone
areas you are likely to see -- not only is the Information field
mobile, but now so too are the control fields.

Moreover, the PID field only exists in information-bearing frames.
Control frames don't have a PID field.  Therefore, I propose instead
to use a specially designated U-frame.  Let's arbitrarily call it a

Leave the 6 character address field 100% intact.  Leave the PID and
control fields right where they are.  It's bad enough that the
information field is variable due to the variable-length of the
control field.  :)

If the frame is a UX frame, then a header extension structure exists
immediately following the control fields, but immediately preceding
the information fields.  It consists of a fixed-part and a
variable-length part:

Fixed Part:

@00:  HEL (Header Extension Length), in octets
@01:  AEL (Address Extension Lengths)
@02:  SSID Extensions
@03:  FTI (Frame Type Indicator)

Present ONLY for I- and S-frames.  NOT present for U-frames:

@04:  SNF (Sequence Number Field; modulo 8 and modulo 128)
@05:  SNF (Sequence Number Field; modulo 128 ONLY)

Variable Length Part:

@04|05|06-mm:  Destination address octets 7 through 7+mm
@mm+1 - nn:  Source address octets 7 through 7+nn
@nn+1:  First octet of real information frame.


* HEL (Header Extension Length) is used to compute the offset to the
first octet of the actual I- or UI-frame information field.

* AEL (Address Extension Length) bytes are formatted thusly:

dddd----  destination address length extension, in octets
----ssss  source address length extension, in octets

So callsigns can be any arbitrary length from 1 character to 21.

* SSID Extensions are formatted similarly to the address length extension:

dddd----  bits 7-4 of the destination address SSID
----ssss  bits 7-4 of the source address SSID

* Frame Type Identifier field, used to identify the real frame type.
It's ALWAYS formatted:

fff-ff--  frame type field.
---0--11  fixed bits for easier software and hardware changes.

where fffff *cannot* be the code for UX frame (that is reserved for
future definition when used in this field).

* Sequence Number Fields are present ONLY for S- and I-frames.  They
take the following encodings:


rrr----- N(R)
---p---- Poll/Final bit
----sss- N(S)
--------0 must be zero for future expansion

Modulo 128:

rrrrrrr--------- N(R)
-------p-------- Poll/Final bit
--------sssssss- N(S)
---------------0 must be zero for future expansion

* Addresses -- contain exactly as many bytes as are necessary to
contain the tail portion of the addresses.  That is, no space padding.
 Bytes are stored *unshifted*.

I can't think of any real negatives to this.  Legacy AX.25
implementations will drop the frame because of an unrecognized
U-frame, or maybe issue a FRMR frame in response.  Can anyone see any
problems with this approach?

Samuel A. Falvo II

More information about the ax25-layer2 mailing list