9 Mar
2016
9 Mar
'16
5:41 a.m.
For a mesh this information gathering step can not be
circumvented. Even if
we change routing protocols, you still need to know your peers BEFORE being
able to set up BGP or OSPF.
And if you know your peers, you can know their subnets, too. So there is
actually no need for a routing protocol running on a limited bandwidth
network, because the information is already there, in your peering data.
Way back in the days of the previous packet radio network and NETCHL I started
to code a solution for this. I implemented multicast in NETCHL and created a
simple info protocol that multicasted information about the local system to
address 224.0.1.31 port 1535 (look them up in DNS and /etc/services!)
These announcements were sent with a TTL of 5 or so, so the neighborhood in
the then existing IP/AX.25/NETROM network learned some details about the nodes,
like the sysop call, the frequencies it was operating on, and the subnets it
was serving. The info could be displayed when connected to the NETROM.
The intention was to create an automatic IP routing protocol from there, and
then replace IP-over-NETROM and plain connects over NETROM by an automatically
routed IP network and a service to encapsulate plain user AX.25 connects
(user1-node1-node2-user2) in TCP/IP connects between the nodes. (replacing NETROM)
This never materialized, and in neighboring Germany a network was deployed
(Flexnet) that stuck to the AX.25 routing, and it became quite popular. The
author was not interested in IP at all. More and more operators wanted to switch
to that network so further development on NETCHL was mostly halted.
Of course, now this change has been made anyway (the network is IP with AX.25
running on top of it instead of under it), but quite some time has passed...
Of course we could again embark on such a project, but there is always the issue
of migration to a new method without breaking the whole network in the transition
phase.
Rob