Order Tray | Contact Us | Home | SIG Lists

[ax25-layer2] 7-byte address proposal

Kevin Dawson kevind at esi.com.au
Wed Aug 2 00:37:40 UTC 2006


On Tue, Aug 01, 2006 at 03:14:56PM -0700, Samuel A. Falvo II wrote:
> 
> Currently, nobody's callsign starts with 0x7F.  Hence, I propose that
> we can use this as a first-character sentinel identifying a new
> address field format.
> 
> The structure I have in mind is as follows (UNSHIFTED hex dump follows):
> 
> @00: 7F 00 d1 d2  d3 d4 d5 d6  d7 d8 s1 s2  s3 s4 s5 s6
> @10: s7 s8

I agree that having some sort of indication (the AFI here) that the
address fields are in a particular format solves a lot of guesswork by
the receiver.  The following is my thoughts a little while ago when the
topic came up on the linux-hams mailing list (which told me about this
one).  I put it forward to stimulate further discussion, as it echoes
some of Samuel's ideas.  Some people may recognise this because they're
on linux-hams; sorry for the duplication, although I've trimmed it a bit.

The context was that of VK having introduced a Foundation class of
licence with a 7-character callsign.  It's not allowed (yet) to use
packet radio but people are thinking of the addressing problems.

| Date: 	Fri, 2 Jun 2006 12:51:17 +1000
| Subject: Re: callsign limit
| 
| On various dates at various times, various people wrote: :-=)
| 
| > Date: 	Wed, 31 May 2006 16:02:03 +0300
| > From: Matti Aarnio <matti.aarnio at zmailer.org>
| > 
| > [ IPv6 ]
| > 
| > Of course it is completely incompatible with existing AX.25 ...
| 
| As will be any change to the address field.  There is no immediate need
| for a 7-character callsign on packet (even here in VK, although I
| predict it will only be a few years); there is some time to work on it.
| 
| IPv6 isn't as omnipresent as one would hope - look at the mail headers
| in this message.  All the addresses are likely IPv4.  That's not say
| the various stages along the way don't use IPv6, of course, but the
| world has been waiting a long time for the omnipresence to happen.
| 
| > Unfortunately we have _huge_ deployed base of inferior technology...
| 
| Definitely.  That will be the largest stumbling block to anything new.
| 
| One of the regulations (at least in VK) is that *every* packet must
| contain the full callsign of stations involved, so a shortened version
| won't be enjoyed by the authorities.  Visitors to VK only have VK
| callsigns (on application), so VK/xxxxx doesn't happen.
| 
| > Date: 	Thu, 1 Jun 2006 16:08:54 +0100
| > From: Ralf Baechle DL5RB <ralf at linux-mips.org>
| > 
| > On Thu, Jun 01, 2006 at 07:31:54AM -0700, Curt, WE7U wrote:
| > 
| > > "The characters of the call sign should be standard seven-bit ASCII
| > > (upper case only) placed in the leftmost seven bits of the octet to
| > > make room for the address extension bit. If the call sign contains
| > > fewer than six characters, it should be padded with ASCII spaces
| > > between the last call sign character and the SSID octet."
| > > ...
| > > There are also two reserved bits in the SSID byte.  I didn't check
| > > the later version 2.2 spec (which isn't implemented anywhere as far
| > > as I know) to see if they decided to use those two bits.  There may
| > > be some other reserved bits further down the header to use as well.
| > 
| > DAMA packs some information into the the unused bits of the SSID field.
| 
| The spec still has them as reserved in 2.2, plus:
| | c) The bits marked ?R? are reserved bits. They may be used in an
| | agreed-upon manner in individual networks. When not implemented,
| | they are set to one.
| 
| DAMA's use of them doesn't prevent other implementations.  Yes,
| there will be pain when networks interoperate.
| 
| So Curt seeded my thoughts.  At present, the address extension bit is
| used to indicate the end of the entire address field.  I propose that
| this be modified to indicate the end of an individual callsign, then
| use one of the reserved bits in the SSID octet (say bit 5) to indicate
| the end of the address field as the present address extension bit does.
| That simply changes the definition of what address is being extended,
| rather than completely rewriting the format of the field.  The padding
| of shorter callsigns with spaces is then unnecessary, although there
| may be a weak case for compatibility with the current format to retain
| it.  I'd rather not.  The SSID and control bits should perhaps be put
| into separate octets, although this is getting further away from the
| minimalist approach I'm giving.  You may as well just write a new
| format (and I'm in support of that).
| 
| So, using the example of Figure 3.8 in the spec (single repeater hop),
| the address field octets, still with space padding, would be:
| 98 94 6E A0 40 40 C1   98 6E 98 8A 9A 40 41   98 6E 9E 9E 40 40 E3
| To not have space padding, the '40' octets are removed.
| 
| Secondly, I'd suggest allowing the '/' character to be allowed for the
| case of DL/xxxxx.  Perhaps just allow the entire 7-bit ASCII set.  The
| next hurdle will then be internationalisation in callsigns, which (in
| the extreme case) could be handled as in email.  But I digress.
| 
| Advantages I see:
| - no more length restrictions
| - allowance for the XX/yyyyy format of callsign
| - allowance for other future addressing methods.  If I wanted to send a
|   signal from Germany, showing a separate receive frequency for this
|   particular link, my address might look like DL/VK2KD-2:RX=433.750
| - it's conceptually simple for programmers to implement the present
|   callsign conventions in this scheme
| - it keeps the authorities happy
| 
| Disadvantages:
| - Of course, most things now will break.  Difficult to avoid unless one
|   of the control bits is used to indicate an extended addressing scheme
|   which would sit in the I field under the current protocol.
| - more intelligence and finer control required, but this should be easy.
| - it discourages proper work in bringing the format up to date.  As I
|   understand it, Phil Karn is not entirely happy that KISS is *still*
|   being used...

The idea of an AFI octet could also be used in the same general way as
a media descriptor on a disc partition, to indicate the file system
type.  So DAMA etc could all be accommodated.

Back to Samuel:

> Maybe, to help save bandwidth, representing callsigns as integers (two
> parts: one base-10 integer for the region number, and another that is
> base-26 for the callsign letters) could be used?

As I recall, one of the original selling points of AX.25 was that the
callsigns was sent as clear text (almost - I've never liked the bit
shift) and I think that it's probably worth keeping, as the payload in
a transfer is generally going to be larger.  How much bandwidth did
you envisage this saving?  It seems only a few octets.

As long as we think of our callsigns as a sequence of letters and
digits, it makes sense to represent them that way.

Kevin




More information about the ax25-layer2 mailing list