<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 TRANSITIONAL//EN">
<HTML>
<HEAD>
<META HTTP-EQUIV="Content-Type" CONTENT="text/html; CHARSET=UTF-8">
<META NAME="GENERATOR" CONTENT="GtkHTML/3.10.1">
</HEAD>
<BODY>
Hey Maiko - you have a golden idea.<BR>
I'll see your "A.IP" and raise you one "A.?"<BR>
(That's poker talk?)<BR>
<BR>
On Thu, 2006-06-22 at 11:40 -0500, maiko@pcs.mb.ca wrote:
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">A bit of history first, to give you all an idea of where I'm leading ...</FONT>
</PRE>
</BLOCKQUOTE>
A bit more brief history to put spin on where I'm coming from (open to accuracy checks):<BR>
<BR>
X.25 began with the need to transport text packages across a network.<BR>
We grabbed the idea in ham radio and made it into AX.25 to satisfy RF needs.<BR>
This has survived and expanded with IP encapsulation.<BR>
Throughout this process "overhead" remains a major issue with slow speeds in some sectors of our hobby.<BR>
<BR>
The DARPA folks found X.25 too limiting and introduced IP and Internet.<BR>
Earth shattering.<BR>
Recently, the address has grown from 32 to 64 bits and we can now address more than whole earth.<BR>
And all this happens in a world of "blinding speeds" of fiber optics and like technology.<BR>
Even the $ guys have grabbed on and US congress is struggling with "neutral Internet" concepts.
<BLOCKQUOTE TYPE=CITE>
<PRE>
</PRE>
</BLOCKQUOTE>
>SNIP<
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">That probably explains why packet radio (A.X25) grew on me.</FONT>
</PRE>
</BLOCKQUOTE>
It grew on me too - different history handled elsewhere.<BR>
Our hobby seems to work "best" in parallel with Internet, so your "switch" concept is a key component.<BR>
Like a firewall it needs Internet connectivity, content management, and ham usefulness to enable RF content transport.
<BLOCKQUOTE TYPE=CITE>
<PRE>
</PRE>
</BLOCKQUOTE>
>SNIP<
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Here's the main point I want to bring up !</FONT>
<FONT COLOR="#000000"> In the amateur radio field, A.X25 (packet radio) was created from</FONT>
<FONT COLOR="#000000"> the X25 specification. I'm surprised that no one has come up with</FONT>
<FONT COLOR="#000000"> an A.IP (ip over radio) spec to parallel the industry movement from</FONT>
<FONT COLOR="#000000"> the X25 protocol to the IP protocol. Or has someone brought it up ?</FONT>
</PRE>
</BLOCKQUOTE>
The world is too big for me to understand if A.IP has hit the streets anywhere in any form.<BR>
Here is where my view diverges from yours a bit - <BR>
A.IP enables ham radio transport of TCP/IP traffic.<BR>
A.? enables ham radio transport of (any?) traffic.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">When things settle down, and winter starts, one of my projects is</FONT>
<FONT COLOR="#000000">to perhaps implement an A.IP protocol (actually nothing more than</FONT>
<FONT COLOR="#000000">raw IP with a SOURCE CALL and maybe ONE DIGI field). The nature of</FONT>
<FONT COLOR="#000000">IP really only requires us to id ourselves I would think. That should</FONT>
<FONT COLOR="#000000">make it legal, right ?</FONT>
</PRE>
</BLOCKQUOTE>
Simple & straight forward - most certainly.<BR>
Legal - most probably.<BR>
Yet do evaluate it in overhead bytes passed per ID cycle (ten minutes?) requirements.<BR>
The gain with A.IP is to drop the AX.25 portion of overhead?<BR>
What % gain does that math demonstrate? [That's a rhetorical question - I'll do the math for myself later]
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Implementing it would be very easy. I should think we could continue</FONT>
<FONT COLOR="#000000">to use EXISTING tncs, running either KISS or SMACK firmware, to make</FONT>
<FONT COLOR="#000000">this work. KISS just delimits the data that the tnc is putting out or</FONT>
<FONT COLOR="#000000">getting in, right ?</FONT>
</PRE>
</BLOCKQUOTE>
Perhaps - but the more important concept is that KISS passes decision making from the TNC to the data processing computer.<BR>
KISS (etc) is a slick marketing tool to allow multiple application environments for one hardware.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Of course A.IP would have to be on a dedicated non A.X25 frequency,</FONT>
<FONT COLOR="#000000">unless there was agreement between the A.X25 spec and A.IP to have</FONT>
<FONT COLOR="#000000">some type of flag at the very first byte of data.</FONT>
</PRE>
</BLOCKQUOTE>
I doubt it - A.IP traffic that passes KISS would be viewed as non-qualifying-packets by AX.25. <BR>
In other words QRM.<BR>
It may be degrading, but the decision is accurate.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Anyways, just some thoughts. It would be neat and alot more usefull</FONT>
<FONT COLOR="#000000">with the modern days apps out there, to have literally raw IP going</FONT>
<FONT COLOR="#000000">out and coming in a TNC. I think so anyways ...</FONT>
<FONT COLOR="#000000">I'd like to have comments on this, what do you all think ?</FONT>
</PRE>
</BLOCKQUOTE>
I'm in accord with your desire to create an RF path in ham radio for digital content, and to that end I will place my energies behind such a project.<BR>
I'm convinced that a new protocol can preserve existing architecture like KISS while at the same time reduce overhead below existing levels.<BR>
I'm satisfied that hams are best served by one ham-only standard to carry multiple existing protocols over RF paths.<BR>
<BR>
For example - AX.25 includes ham calls into the overhead on each packet to satisfy FCC call ID needs. Yet in the US only once in ten minutes is required of any transmitting station. Consider for a moment what many operating systems do for holding "temp" file data / they invent names based on random numbers. My contention is that a random 16bit (maybe 32?) number together with an intelligent switch can satisfy all ham routing needs over RF. Further, it matters little if the originating protocol is X.25, AX.25, TCP/IP, A.IP, SCS-anything, or other, viewed from the perspective of listening to RF in any band allocated to ham use, the overhead of any protocol may be stripped before transmitting and reinserted after receipt to complete a link using the 7-layer (maybe less) model for net transport.<BR>
<BR>
Today is not the day to argue the merits of random numbers, but only to frame the environment into which a new protocol might fit. It is my request of you to consider more than TCP/IP in framing your objectives. Also - it is only a request. I do understand the utility of A.IP and the attractiveness of taking smaller steps toward a larger goal. Therefore we will all be better off no matter how you proceed.<BR>
<BR>
If there is a way I can contribute to your project, please call.
<BLOCKQUOTE TYPE=CITE>
<PRE>
<FONT COLOR="#000000">Regards,</FONT>
<FONT COLOR="#000000">Maiko Langelaar / VE4KLM</FONT>
<FONT COLOR="#000000">_______________________________________________</FONT>
<FONT COLOR="#000000">nos-bbs mailing list</FONT>
<FONT COLOR="#000000"><A HREF="mailto:nos-bbs@lists.tapr.org">nos-bbs@lists.tapr.org</A></FONT>
<FONT COLOR="#000000"><A HREF="https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs">https://lists.tapr.org/cgi-bin/mailman/listinfo/nos-bbs</A></FONT>
</PRE>
</BLOCKQUOTE>
<TABLE CELLSPACING="0" CELLPADDING="0" WIDTH="100%">
<TR>
<TD>
<BR>
73<BR>
de Skip k8rra k<BR>
<BR>
<BR>
</TD>
</TR>
</TABLE>
</BODY>
</HTML>