[nos-bbs] A.X25 then, A.IP now ??? - thinking outloud (fwd)

[Barry Siegfried]

[Tim Gorman <ab0wr at ab0wr.net> wrote]:

> Been doing a bit of thinking on this.
>
> AX.25 is a Layer1/Layer2 definition.  It is based on the concept of links
> at Layer2 between two endpoints (with two digipeaters also possible).  It
> is this concept that allows sharing of a packet channel by several
> conversations through collision avoidance routines built into the link
> layer.
>
> The move from X.25 to ip was facilitated in the wired network by other
> developments - primarily the wide introduction of ethernet and token ring.
> These provided the Layer2 data link functions for the Layer3 IP protocol
> to use.
>
> The corresponding concept in amateur radio was to carry the Layer3 IP over
> the existing Layer2 AX.25 data link setup - i.e. IP encapsulation in AX.25
> frames.

I think Tim has this down pretty well.  :)  As a matter of fact, I'll go
one step further:  The function of AX.25 ("low-level" layer 2 or the
Medium ACcess sublayer) over RF (layer 1) is equivalent to using ethernet
(Medium ACcess sublayer) over wire (layer 1).  By definition, ethernet is
a "broadcast" medium (as is RF) and the two are functionally equivalent.
AX.25 addresses (i.e. callsigns) over RF serve an identical purpose to
using ethernet addresses (i.e. MAC addresses) over wire.  The only
difference is that we have HTS (hidden transmitter or terminal syndrome)
and path noise on our RF links which we don't have on wire.

> What you are proposing is getting rid of the AX.25 frame information as
> being too much overhead.  We need to define what this discardable overhead
> is.
>
> An AX.25 frame consists off:
> 	Start Flag
> 	Address block (source, destination, 2 digipeaters)
> 	Control block (type of frame, sequence nbrs, etc)
> 	Protocol ID block (ax.25, tcp/ip, net/rom, flexnet, etc)
> 	Information block
> 	HDLC Frame Check block
> 	End Flag
>
> You could certainly shorten the Address block since source and destination
> IP addresses will exist in the IP frame.  The Control block information is
> needed, however, for controlling the ability to share the channel among
> numerous users.  Not so easy to discard parts of it.

No, and it is also needed to "bridge the gap" between AX.25 ("low-level"
layer 2 or MAC) and LAPB ("high-level" layer 2) since the AX.25 spec lacks
a proper protocol ID field (byte) between the "low-level" address (MAC)
and "high-level" (LAPB) sublayers.  A control value of "UI" indicates
that LAPB ("high-level" layer 2) is to be bypassed.

> The Protocol ID block is only a byte long if I remember right.  Not
> much savings to be had there.  No, and you absolutely need it to tell
> AX.25 what level 3 protocol it is carrying.
>
> The information block won't change.  If you have any added data outside
> the IP frame, it will be hard to get rid of the Frame Check block without
> incurring corrupted data frames.
>
> It would seem that what you are proposing would be somewhat akin to a
> proposal to get rid of the Ethernet Layer2 data on an ethernet connection
> and just transmit the IP frames natively with only an originating MAC
> address attached.

It would seem so.  How could this be accomplished this in a broadcast
medium?

> It may work on an ethernet segment with a very limited number of nodes
> but it isn't very scalable.
>
> I don't want to be a wet blanket on your idea.  Am I missing something?

I'm not sure how Maiko would accomplish what he is proposing.  The only
place I have ever seen raw IP transmitted is over point-to-point (like
serial) links where no "device" (i.e. MAC) addressing is necessary since
the "device" at the other end of the point-to-point link hears all the
frames on the link which are, by definition, "addressed" to it.

["George (Skip) VerDuin" <k8rra at ameritech.net> wrote]:

> Throughout this process "overhead" remains a major issue with slow
> speeds in some sectors of our hobby.

The "overhead" to which you refer is the "high-level" part the AX.25
layer 2 implementation or LAPB.  LAPB requires an acknowledgement at
layer 2 over the link and it is this that causes the large overhead.
Normally, the payload "acknowledgement" function is reserved to
transport layer 4 which is where is properly provided but the
assumption is that you have a very reliable transmission medium
(physical layer 1).  Unfortunately, our RF links provide a very
UNreliable layer 1.  :(

> Recently, the address has grown from 32 to 64 bits and we can now
> address more than whole earth.

We can practically address more than the whole earth with 32 bits too.
Oh well.  Don't get me started on IPv4.  :)

> the more important concept is that KISS passes decision making
> from the TNC to the data processing computer.  KISS (etc) is a
> slick marketing tool to allow multiple application environments
> for one hardware.

Perhaps, but it was not originally created to provide a marketing
tool and it was never really meant to be "slick".  KISS (as implemented
in TNCs and invented by K3MC in the late 1980s) was provided as a way
to move the AX.25 (or MAC, "low-level") address part of layer 2 into
the computer so that it could be configured on demand by users with
changing callsigns/SSIDs etc.  This left only the physical interface
between the medium (RF layer 1) and the computer to be handled by the
TNC (or PAD).  PAD stands for "packet assembler/disassembler" and
some of may remember when TNCs were called PADs.  :)  The simplicity
of KISS for its day was awesome and to the best of my knowledge, the
original KISS spec has not been changed although I may be quite behind
the times on that one.  No doubt it has been expanded in some way
since then.

["Duvall [US], Mike J." <michael.duvall at sperry.ngc.com> wrote]:

> I had a similar thought years ago. It always seemed like a waste to
> wrap x25 around and IP packet.  Legally all you need is the call sign
> to identify the transmitting station.  A simple way to implement it
> would be to prefix the IP packet with the transmitting station, SSID
> and a check sum.

Yes, and that is called "AX.25".  :)

> You just strip these off on receive and pass the remaining data that
> is IP packet on for processing.  In a more abstract sense, prefix any
> network packet with the transmitting station, SID and a check sum.

Both of the above are exactly what AX.25 does now.  :)

Ok, here's my take.  AX.25 in an of itself does not necessarily
create more overhead (unless you are trying to use lots of digipeaters).
In fact with no digipeaters and counting the SSID the AX.25 "address"
is only one more byte (7) than is an ethernet MAC "address" (6).  And
as Tim said above, the only added baggage is the control field (one byte)
to bridge the gap between "low- and high-level" layer 2 because you STILL
need a protocol ID field to tell AX.25 what it is carrying (even if it
is plaintext and there are no higher layers).  Re-displaying Tim's model
above, we see:

Implemented by the PAD (KISS):

	Start Flag

Implemented by AX.25:

	Address block (source, destination, 2 digipeaters)
	("low-level" MAC data link layer 2)

 	Control block (type of frame, sequence nbrs, etc.)
	(bridge to "high-level" LAPB data link layer 2)

	Protocol ID block (tcp/ip, net/rom, flexnet, etc.)
	(bridge to network layer 3 or above)

Implemented by network layer 3 and above:

	Information block
	(payload)

Implemented by the PAD (KISS)

	HDLC Frame Check block
	End Flag

So what then CAN be "corrected" with AX.25?  In my opinion, there is
really only one item and that is, the need to make our RF circuits
more reliable so that the requirement for using "high-level" layer 2,
or LAPB will be eliminated.  If we did not need to use LAPB under most
circumstances, this would do more to help our IP throughput problems
over RF much more than eliminating AX.25 entirely would do.

Just my 2 cents on this discussion.  :)

73, de Barry, K2MF >>
           o
          <|>      Barry Siegfried
+---------/-\---------------------------+
| Internet | bgs at mfnos.net              |
| HomePage | http://www.mfnos.net/~bgs  |
+----------+----------------------------+
| Amprnet  | k2mf at nnj.k2mf.ampr.org     |
| PBBS     | k2mf at k2ge.#cnj.nj.usa.noam |
+----------+----------------------------+