I’ve been doing more pondering on the routing side of things. The initial thought was to use Net/ROM L3 to figure out the source route of who can hear whom. Getting access to that via BPQ’s interfaces may not be easy unless we happen to eavesdrop on the broadcasts, and of course, there’s no service discovery in BPQ.
The thought came to me, what does ICMPv6 offer me in terms of routing? If I can ask “who has a route to node X?” or announce “I know how to reach X”… I could just skip Net/ROM L3 altogether, since there’s a good chance both will co-exist quite happily on the same AX.25 network, we just take a ship-pass-in-the-night approach.
ICMPv6 Router Advertisements basically just say “I’m a router and this is my local prefix”, similarly, ICMPv6 Router Discovery messages just ask “Who’s a router?” … not greatly helpful.
RFC-4191 gets close, specifically the Route Information Option, but this is again, targeted at reaching a node on a differing subnet to the local one, and only applies to RAs.
This is a service that 802.15.4 actually provides to 6LoWPAN (RFC-4944), so from the point of view of IPv6, a 802.15.4 network translated through 6LoWPAN “looks” like one L2 network, it just needs to know a node’s extended address which is what made me think about Net/ROM L3 in the first place.
RFC-6775 looks to enhance things a little bit, by considering the fact that it’s not just one big happy family however, not everyone can talk to each-other, and links come and go.
One thing is clear, not everybody will be a router. Specifically, a node should definitely not advertise itself as a router unless it can hear at least two other nodes, or knows routes to nodes learned either through static configuration or via Net/ROM node advertisements.
Two nodes can just exclusively use link-layer communications, so there’s no need for either to be “routers”. Soon as a third joins in, potentially all three could be routers if they can all hear each-other, but if you have a linear topology where only the central node can hear the other two, it is logical that that node becomes a router, and not the others.
The question is then, if one of those peripheral nodes disappears, what should the router do? I’m thinking it should remain a router for a limited period of time (configurable, but maybe measured in hours), just in case that node returns or other nodes appear. After some time, it may “demote” itself to non-routing node status and relinquish control of the on-mesh prefix.
Where a node promotes itself to router, if an existing on-mesh prefix is in use, it should continue to use that, otherwise it should derive a suitable ULA prefix for use.
It may also follow that a ULA is configured for certain nodes, and they are configured to remain in the router role, regardless of the number of neighbours. Repeater sites would be prime candidates for this. They’re in a position where they should have good coverage, and thus should be prime candidates to be routers.
Since we can do multi-hop source routing with AX.25, there’s scope to perhaps exploit this in a higher level protocol which we might build on UDP messaging, as it doesn’t look like the existing standards provide for this sort of route path all that well. TCP/IP is after all destination routed whilst AX.25 is source routed.
I think maybe tomorrow (which is predicted to be wet), it’ll be a good day to sit down and prototype something that maybe takes care of the IP messaging side of things and at least gets two AX.25 stations exchanging messages, then we can start to build something atop that.
Recent Comments