gnrc/ipv6_auto_subnets: relax topology requirements

[benpicco]

Contribution description

#16536 provides a solution for networks that follow a 'skinny tree' topology, that is on each level only a single node can have children.
On such a simple topology we can automatically create subnets without coordination between routers given a sufficiently large prefix.

As it turns out we also have to deal with network topologies where this assumption does not hold and there are multiple routing nodes on a level.

Now coordination between the routers is required: Each router must announce how many subnets it wants to create to determine the total number of subnets and thereby the required prefix length to make for unique subnets.

As I could not find any standard mechanism for this functionality, I turned to simply broadcasting a UDP packet with this information. (which makes this a RIOT specific functionality which only works in homogeneous networks. I therefore kept the protocol as simple as possible and only transfer a single byte of payload).

Testing procedure

Create the topology as usual with the setup_taps.sh script in examples/gnrc_networking-subnets.
This time however we will connect two routing nodes on the same network level:

# start the root node
make PORT="tap_a0 tap_b0" term 

# start the first routing node
make PORT="tap_b1 tap_c0" term

# to test prefix removal, we can wait here for a bit until the first routing node got it's prefix
# it should be replaced after starting the second routing node

# start the second routing node
make PORT="tap_b2 tap_d0" term

# start a child node on the next level
make PORT="tap_d1 tap_e0" term

All nodes should have a global address and be able to route to each other.

Issues/PRs references

extends #16536
depends on and includes #16729, #16734

[miri64]

Does the least significant byte of the address being bold have any meaning? If so, this meaning should be apparent within the graphic somehow (a graphic should be able to stand on its own). Otherwise, it should be removed, as I think it confuses more than it helps understanding the algorithm.

[benpicco]

I thought it's a nice visual aid to see what is the difference between the l2 addresses.
I turned it down to italics

[miri64]

The problem to me was more that they are highlighted in general. Now that I know what this is about, my perspective shifted, so I'm not sure if making them italic makes any difference. I think that L2 addresses are different can be assumed for a working network, so highlighting the difference seems somewhat redundant to me, however, still. Do they have to be literal addresses? Can't they just be Node A, B, C?

[benpicco]

The idea was to visualize that the order in which the prefixes are chosen / where each router starts counting it's prefixes depends on the order of the l2 addresses.
I hoped changing only the last byte and highlighting that would make it easier to understand the concept.

[miri64]

The idea was to visualize that the order in which the prefixes are chosen / where each router starts counting it's prefixes depends on the order of the l2 addresses.
I hoped changing only the last byte and highlighting that would make it easier to understand the concept.

Mh, I think by abstracting this more to numeric or alphanumeric abstract L2 addresses would help to highlight this concept more. How about something like "L2 addr. 1", "L2 addr. 2", ...

[miri64]

If the order of their significance now would also be reflected in the order they are shown (so C in the second column, B in the third), I'd be happy :-).

[miri64]

(of course feel free to adjust the labels then as well).

[benpicco]

If the order of their significance now would also be reflected in the order they are shown

I thought mixing them up made it clearer that it's not the order of appearance that matters but the order of addresses - but alright, I can shuffle them around.

[benpicco]

[miri64]

If the order of their significance now would also be reflected in the order they are shown

I thought mixing them up made it clearer that it's not the order of appearance that matters but the order of addresses - but alright, I can shuffle them around.

No, mixing things up to make them clearer, rarely works ;-)

[benpicco]

@miri64 do you think we can still get this into the release?
We would then avoid changing the semantics of the module name (the current gnrc_ipv6_auto_subnets module behavior becomes gnrc_ipv6_auto_subnets_simple and the general implementation takes that name) from one release to the next.

[miri64]

@miri64 do you think we can still get this into the release?

Ok, let's try this.

Some function names are IMHO confusing. Yes you documented the functions, but if you just scroll through the code, see a function _insert or _compare_addr it is not immediately clear what is happening.

[miri64]

Another round of more in-depth review.

[miri64]

I'm fine with the code now and I trust your testing. Feel free to squash.

[benpicco]

Thank you for the review!