[aprssig] RK3KKPK? (CONNECTED Igates?)

[Kris Kirby]

On Sun, 29 Jan 2012, Andrew P.  wrote:
> To do what you suggest, you would need full-function AX.25 digipeaters 
> that could route through an Internet backbone. The backbone would have 
> to know which digipeater was the shortest route to every RF station in 
> the world, or at least those in contact with Irouters (my name for 
> such Internet-linked full-function digipeaters)..

Indeed, if we could just cram call-signs into IP Headers and eschew the 
X.25 protocol altogether....
 
> That's a pretty big routing table to keep track of, especially since 
> it changes in real-time as mobile stations move and any RF station 
> goes on and off-line. There's no subnetting like the Internet has, 
> because callsigns are not geographically assigned (for example, I have 
> a KA2 prefix callsign but now live in 3-land). It's like the pre-DNS 
> days of the Internet, with the addition of a Single Point Of Failure 
> (SPOF): the backbone.

And, of course, two sets of routing tables, two sets of addresses, two 
sets of address resolution/mapping protocols and so on.

> Maybe it's time to bring back the TCP/IP over AX.25 network that 
> existed in the 1990's. That did have subnets that kept the routing 
> tables at a sane size and relatively slow-changing state. Such TCP/IP 
> networks could transparently tunnel through the Internet to avoid 
> having to make dozens of hops through RF links; it could route through 
> the wormholing links in the tunnels instead.

This creates the problem of needing to make The Mother Of All Proxy ARPs 
to figure out where a station has popped up at next, and where to route 
the packets out of. 

Another writer wrote:
> You don't even need connected packets, a few weeks ago I talked about 
> using ax-udp, the backbone that these wormholes use, to transport ui 
> frames from one gate or station to another gate or station, current 
> software that I used does not yet gate on destination, only on it's 
> own call tho it can gate on generic calls as wel but that would create 
> a mess. It can be rewritten to gate on MH for destination call. 
> DigiNed the software I used is afterall opensource and can transport 
> both ui-frames and connected frames. In europe there is another 
> automatic routing system active called flexnet, you select the local 
> node as the first digi, the remote node as second digi and the nodes 
> will so hop to hop acknowladge and best routing for every packet so it 
> can change from one moment to the other without the user realising it, 
> offcourse this is designed for RF use and does not flood like my 
> aprs-udp idea did. another interesting note is that flexnet does do mh 
> routing once you get to the remote node, it looks what port the user 
> is on and downlinks on that.

In the commercial satellite space, they have "protocol gateways" that do 
horrible things to packets in the name of keeping the traffic flowing 
despite the delays. TCP/IP is designed to retransmit by itself; AX.25 
connected frames are the same in that regard. There's no need to 
re-transmit a packet if another layer is handling that function. OTOH, 
the packet length of a 1200 BPS half-duplex packet radio system maxes 
out at 255, which is significantly less than the 1500 byte MTU of 
ethernet. For short frames which can be fully encapsulated, something 
like AX-UDP makes a lot of sense. It's when you cross the payload 
barrier and go into the next packet that you start buffering and 
splitting packets and reassembling them. Of course, IPv6 doesn't make 
this any easier, with even LARGER amounts of address space (and headers) 
and BIGGER packet sizes, so we need to come up with something to allow 
us to fit one protocol over another. 

I think we're at a precipice where we can build a protocol gateway of 
sorts or find a way to 

a) segment larger packets into smaller payloads for air transit or 
b) let the next layer up deal with it and keep using UI frames. 

I don't see any reason to involve the overhead of the Connected stream 
in the process at all. TCP/IP port numbers and development outran X.25 
and left it far, far behind. However, we're still stuck with devices in 
the middle which have little brainpower and less space left to handle 
and manipulate packets in a meaningful way. 

The advent of digi_ned also brings out some interesting applications. 
For instance, a remote site can be connected to the APRS network by 
bi-directionally or uni-directionally repeating either audio or data to 
a dedicated link radio for analysis or collection. Further, this link 
could be implemented using a 9600 bps FSK setup. In a place with no APRS 
coverage, a high-site could be used to fill in for pickup and the only 
active transmitter would be low power and directional away from the 
site. 

Then again, if one really wants to get nuts, we're limited by statute to 
100KHz and 19200 baud at 222MHz and up, which when using 8-PSK or 64-QAM 
can be pushed to about a half-megabit before you start throwing bits 
away for FEC.

--
Kris Kirby, KE4AHR
Disinformation Analyst
Internet Plumber
Server Sitter