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

[Tim Gorman]

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.c. IP encapsulation in AX.25 
frames.

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. The Protocol ID block is 
only a byte long if I remember right. Not much savings to be had there. 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 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?

tim ab0wr
	


On Thursday 22 June 2006 11:40, maiko at pcs.mb.ca wrote:
> A bit of history first, to give you all an idea of where I'm leading ...
>
> During the 90's, I designed, developed, and installed automated banking
> machine and point of sale networks, using a software *switch* to route
> transactions to the appropriate authorizing institutions, etc.
>
> Many of the ATMs (ABMs) used the X25 protocol to communicate to the
> switch. The whole concept of X25 was really cool (still is) and I got
> to really liking it, becoming quite experienced in setting it up, and
> writing/porting comm drivers for a variety of different Unix flavors.
>
> That probably explains why packet radio (A.X25) grew on me.
>
> At the tail end of the 90's, our company saw a new breed of ATMs (ABMs)
> coming out in the market. In particular, NCR (NDC), was starting to ship
> units that gave us the option of using TCP or UDP over IP, instead of
> the usual X25 protocol. This was a turning point, and for many of our
> customers that could afford it, X25 was on the way out, IP was the
> new way of doing it.
>
> Warranted, alot of new customers could not afford to purchase new
> ATMs (ABMs), so X25 was still in use here and there, but then again,
> alot of the used atms only had SDLC or BISYNC to offer, making X25
> less popular anyways (from my experience).
>
> Here's the main point I want to bring up !
>
>  In the amateur radio field, A.X25 (packet radio) was created from
>  the X25 specification. I'm surprised that no one has come up with
>  an A.IP (ip over radio) spec to parallel the industry movement from
>  the X25 protocol to the IP protocol. Or has someone brought it up ?
>
> When things settle down, and winter starts, one of my projects is
> to perhaps implement an A.IP protocol (actually nothing more than
> raw IP with a SOURCE CALL and maybe ONE DIGI field). The nature of
> IP really only requires us to id ourselves I would think. That should
> make it legal, right ?
>
> Implementing it would be very easy. I should think we could continue
> to use EXISTING tncs, running either KISS or SMACK firmware, to make
> this work. KISS just delimits the data that the tnc is putting out or
> getting in, right ?
>
> Of course A.IP would have to be on a dedicated non A.X25 frequency,
> unless there was agreement between the A.X25 spec and A.IP to have
> some type of flag at the very first byte of data.
>
> Anyways, just some thoughts. It would be neat and alot more usefull
> with the modern days apps out there, to have literally raw IP going
> out and coming in a TNC. I think so anyways ...
>
> I'd like to have comments on this, what do you all think ?
>
> Regards,
>
> Maiko Langelaar / VE4KLM
>
>
> _______________________________________________
> nos-bbs mailing list
> nos-bbs at lists.tapr.org
> https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs