Networking with IP
- To: firstname.lastname@example.org
- Subject: Networking with IP
- From: email@example.com (Steve Sampson)
- Date: Mon, 2 Jan 1995 16:34:08 -0600 (CST)
This is HAM TCP/IP SMTP email from OKC to the nearest Internet (in Texas):
text (local Ham)
IP (local Ham) (encapsulate text with IP) (NOS)
AX.25 (local Ham) (encapsulate IP with AX.25) (NOS to Rose)
X-25 (Rose) (OKC to ROSE) (encapsulate AX.25 with X.25) (Rose to Rose)
AX.25 (ROSE to NOS) (un-capsulate X.25 to AX.25) (Radio to NOS)
IP (NOS ROUTER) (un-capsulate AX.25 to IP and route) (NOS)
AX.25 (local Ham) (encapsulate IP with AX.25) (NOS to Radio)
AX.25 (local Ham) (un-capsulate AX.25 to IP) (Radio to NOS)
Ethernet (local Ham) (encapsulate IP in Ethernet) (NOS to Router)
IP (local Ham) (un-capsulate Ethernet to IP) (Router)
Seems like a lot of hoopla to carry the text, but in fact it works fairly well,
with response times from 2 to 5 minutes (tcp rtt). This is due to Larry/WB5CQU
9600 Rose path from Double Oak (TX) to Pauls Valley (OK). There is further
linking to OKC, but it uses 145.01. Which is just as well, as there's not
that many hams on packet here.
My theory is that the AX.25 and Rose are obsolete and not needed. The Internet
uses pure IP (well, who really knows anymore what the routers do - X.25, ATM,
etc), the Ham Internet could also. We use AX.25 because it allows third-party
freedom. We could use pure IP. It is authorized as an unspecified code.
Since PACTOR uses 8 bits, and is therefore an unspecified code, and the FCC
has allowed it to pass third-party data, then IP with 8 bits would not be any
more of a violation.
Here's the proposal. This is a point-to-point network. There is one source,
and one target at each radio node. For speeds of 9.6k or 19.2k max:
1. Modify NOS to emit IP datagrams over the radio port. The radio port
is assumed to be on a network frequency, not an user frequency. I say
this because combining VC and DG on an user frequency is certain death.
2. Modify NOS to emit an AX.25 beacon every 9 Minutes when network is
3. Modify the TAPR TNC-2 to process IP datagrams and route the packets
to either the asynchronous SLIP port, or the radio port. This would
allow the TNC to be stand-alone, paired with another, or tied to a NOS.
(Linux, KA9Q, Cisco, etc).
This would result in:
text (pc-elm, bm, telnet, ftp, nfs, etc)
IP (NOS) (encapsulate text with IP)
IP (NOS to 1.2k) (NOS to Radio)
IP (1.2k to 9.6k) (Route Datagrams to TX)
IP (9.6k to 1.2k) (Route Datagrams to OK)
IP (1.2k to 1.2k) (Route Datagrams to another Freq) (delete this)
IP (1.2k to 10M) (Route Datagrams to Ethernet) (upgrade to 9.6k)
Ethernet (10M to 10M) (encapsulate IP in Ethernet) (NOS to Router)
IP (10M to 1.5M) (un-capsulate Ethernet to IP) (T1 Router)
I didn't create this to point fingers. I really think we may be
stuck with developers pulling too many G's, resulting in
tunnel-vision on this AX.25 deal. When I see AX.25 being ported
to Linux, I know some are approaching GLOC. I think a port of
YAPP, or KA-GOLD to Linux would be more appropriate if the
result is for non-networking. Most of us have already
experienced Net/Rom, and it was pretty neat on a user/network
frequency plan. We've tried Rose, and it has a neat telephone
number routing scheme. But if you throw out the AX.25 carrier?
What then? I think it would be akin to removing blinders, or
releasing the G's. The tunnel-vision opens onto a green field
of virgin grass - oops, too dramatic - and the Net-Masters can
start thinking about alternate possibilities.
No. I don't think we should ask if it's legal, or petition.
Model it after the PACTOR guys and: "Just Do It!"