On 27/10/18 22:38, Nate Bargmann wrote: > * On 2018 26 Oct 23:17 -0500, Stuart Longland wrote: >> Hi Nate, >> On 27/10/18 1:11 pm, Nate Bargmann wrote: >>> A bit of searching turned up this link: >>> >>> ftp://ftp.ucsd.edu/hamradio/packet/tcpip/docs/netrom.ps.gz >>> >>> I scanned through it and it looks to be a rather complete description of >>> the Level 3 protocol. >> >> Yes, I had seen that article, but it seemed to me more about the L4 >> protocol than about L3. > > It seemed complete recalling my days of watching the traffic through > G8BPQ running on my BBS computer "back in the day". > >> I'll have a closer look though. :-) > > I'm not sure that it was all that complex over the air as it only added > 20 bytes, err, octets, to the packet. The diagrams fit what I recall, > though I've not watched such traffic for at least 20 years. > >> I note there's mention of a "mnemonic identifier", presumably this is >> not the SSID but some other ID of the station. I'm not sure how that is >> generated, so it's still a little unclear how it all fits together. > > I worked with TheNet in the late '80s and early '90s until TheNet X1J > became available, and the mnemonic was similar to a digipeater alias > that could be set in a TNC2. It was a convenience for the user as we > generally used a local place name for it. Nodes would do an AX.25 > connection to each other using their proper callsigns, not the aliases.
Ahh okay, so if I want to know a station's AX.25 call-sign, I don't
actually need to know an alias and can ignore it. (Or run a local DNS
server so applications can use ${alias}.ax25 or some such.)
Interesting you make mention of "TheNet X1J"… I've heard people in
Brisbane WICEN make mention of "X1J" in isolation, and I came to the
(wrong) understanding that "X1J" was yet another protocol.
From your comment there, I gather it is a particular release of TheNet,
and thus, an implementation of Net/ROM.
>> It looks as though two digipeaters would be trivial, since you know if
>> station A hears station B say it can reach D via C with quality Q; that
>> it can use the route A→B→C→D in the AX.25 frame.
>>
>> Going further looks tricky though, if there were further hops between C
>> and D, there would need to be some logic at C that can consider *its*
>> routing table and forward further.
>
> I'm not sure that Net/ROM was ever that smart. Two or three hops was
> about the practical limit. But then most of the "network" around these
> parts was all on the same frequency rather than having a proper
> separation of user access frequency and backbone traffic frequency
> between nodes. Another aspect was that few understood the effect of the
> Quality parameter over several hops.
Interesting, it looked from what I had read as if the protocol itself
didn't limit the number of hops, that as it passed through each Net/ROM
node, a decision was made on where the next hop would be, much like IP does.
I guess each node will try and pick the "best" possible path, but from
what I've seen of the algorithms, if you have two possible routes:
A→C→G→Z and A→B→H→Q→Z; A will more likely pick the former even if the
link between G and Z is worse than H→Q and Q→Z.
Single-frequency networks would complicate matters a bit, all the
cross-talk between the "backbone" and access point networks.
>> AX.25 2.0 supports up to 8 digipeaters, so maybe the answer is that in
>> larger networks, you'd need this IP-enabled Net/ROM stack running so it
>> can see the incoming IP frame and consult its Net/ROM routing table to
>> move it the next few hops. I take it there's no "traceroute" like
>> functionality in Net/ROM?
>
> I don't recall any such thing. As I recall the ROSE protocol was
> supposed to be a more robust implementation with more detailed routing
> and a more coordinated network implementation as opposed to the ad hoc
> nature of Net/ROM/TheNet.
>
> TBH, I'm not such what the netrom part of the stack offers when running
> TCP/IP. If I were to do TCP/IP over packet radio again, I would forego
> using the netrom part of the stack and simply use digipeaters and adjust
> the IP parameters for best throughput. Reflecting on my experiences
> over the years, that 20 octets of overhead never really bought much.
Yeah, long term I'm thinking I'll be looking to replace Net/ROM, but I'm
thinking being backward-compatible would help in the adoption of a new
protocol.
What I'm aiming for, is someone can plug a TNC in, input their call-sign
and a SSID, click "connect", and a client on their computer will bring
up a network interface that will "appear" to look like a VPN to their
host. In reality, it's intercepting IPv6 traffic, performing header
"compression" on the packets, fragmenting frames over ~128 bytes and
encapsulating the fragments into AX.25 UI frames.
So like Net/ROM, hopefully minimal configuration. An application such
as a chat client, file transfer client or form entry program would just
open a listening socket like any other TCP/IP application.
At most, there might be some parsing logic to decode call-signs encoded
in the IPv6 address' lower 64-bits.
> War story time.
>
> Back in the early '90s I was living in Enid, OK and operating an MSYS
> packet BBS there. W0KKS in Liberal, KS wanted to forward and the only
> path was a series of netrom nodes out through western OK into the Texas
> panhandle, up through the OK panhandle into southwest Kansas. To make
> it work I set the BBS connect script to manually connect to each node
> from the previous in turn which amounted to six or seven hops in total.
>
> The Net/ROM protocol was not reliable enough but the advantage was that
> if a link between two nodes was a bit weak, handling the connection
> manually would result in AX.25 handling the retries between the
> individual nodes. If that were tried using Net/ROM, that would result
> in the entire link having to handle the retries from end-to-end as I
> recall. Again, this was on a "network" implemented on one frequency
> with user traffic. I only allowed forwarding to occur between 10 or 11
> PM and 6 AM or so when user traffic was light.
Interesting, so Net/ROM's connection handling in this case reduced the
reliability? I realise the network layout was less than ideal but I
thought the whole point of Net/ROM L4 was it did ARQ at each hop so that
the far ends didn't have to.
I've been doing some research on the topic though: my thinking is that
AX.25 isn't much different to today's wireless sensor networks. These
tend to avoid "connected-mode" type links in favour of connection-less
messaging.
So 6LoWPAN uses mostly UDP over IP, Zigbee is more data-oriented, so in
its original form uses key-value pairs, but more generically can pass
around abstract messages. I'm not sure what LoRAWAN does.
I'm thinking the same sorts of protocols that run happily over 6LoWPAN
would work here too. Most of the applications I'm thinking of are
one-to-many, and having it just go direct to the nodes instead of via
some central hub (message broker, BBS, etc) fits more with the
decentralised ethos of amateur radio.
A central hub is handy for storing messages, but it can also be a point
of failure. :-)
That said, it's interesting to hear the war stories, as I was too young
when much of this stuff is popular. If we don't learn from history,
we're bound to repeat its mistakes.
Regards,
--
Stuart Longland (aka Redhatter, VK4MSL)
I haven't lost my mind...
...it's backed up on a tape somewhere.
signature.asc
Description: OpenPGP digital signature
