* 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. > 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. > 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. 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. 73, Nate -- "The optimist proclaims that we live in the best of all possible worlds. The pessimist fears this is true." Web: http://www.n0nb.us GPG key: D55A8819 GitHub: N0NB
signature.asc
Description: PGP signature
