Populating neighbor cache without ND

Development archive
1

(Continuing from a thread on Github: https://github.com/RIOT-OS/RIOT/issues/5025)

tldr; It should be possible to use RPL standalone without 6lowpan-ND.

Currently the only way to add neighbor cache entries is through neighbor solicitations+neighbor advertisements (ND) or through the shell. My initial opinion was that RPL should add neighbor cache entries for all DAOs it receives ​.

​@cgundogan argued that the lowpan network may be asymmetrical in what packets get through between nodes, so a DAO reception may not guarantee​ reliable​ bidirectional communication between two link-local addresses​:​

​RPL states in the RFC that it requires bidirectional links to function properly. (6Lo-)ND is one way to get those bidirectional links, so that the ncache itself only contains entries that are bidirectional. Receiving a DAO is not a strong indication whether the link is bidirectional or not. DIO traffic is (mostly) multicast (and sparse) in the downwards direction, while DAO traffic is (mostly) unicast in the upwards direction. Due to the known problems of wireless technology (interference, etc.) and “enhancements” of link layers (e.g. to apply QoS for certain traffic patterns, multicast, unicast, etc.) the link can be highly asymmetric. Receiving a DAO does not mean that my DIO, which I send out e.g. 1 minute ago, has reached that same child.​

So, a summary of the scenario, written by Cenk:

To summarize again so that I understand you correctly: You have 2 nodes (A and B) A is the RPL root and has a neighbor cache (+ (6Lo-)ND is running) B is a normal rpl router who joins the DODAG of A and has no neighbor cache and no ND running. A will always expect an entry in its neighbor cache before it can send out traffic to B, but since B is not participating in the RS/RA-NS/NA exchange with A, A will never get an entry for B in its ncache.

​Emmanuel further suggested:

Maybe we should consider creating a STALE entry in the neighbor cache for neighbors heard of, but without bidirectional check at ND level yet?

It was suggested that we would continue the discussion on the devel mailing list.

Does anyone have more ideas or suggestions on how to populate the neighbor cache without ND?

This is especially interesting for interoperability with ​other systems which may not even have a 6lowpan ND implementation, and can only do RPL.

Best regards, Joakim

2

Hi all,

@Emmanuel: Maybe we should consider creating a STALE entry in the neighbor cache for neighbors heard of, but without bidirectional check at ND level yet? I think this will not help in a situation where a neighbor node does not use ND. The entry will be pruned after some timeout when no update has been done, and the update-interval is then highly dependent on the routing-protocol(-settings).

But generally I think its a good idea to have a STALE state for neighbor-cache entries in lossy networks.

I propose that the FIB updates the neighbor-cache with LL-addresses of added FIB-entries. They are supposed to be used in forwarding and considered as a reachable next-hop by a routing-protocol. I think there’s no need to extend RPL to fill the neighbor-cache.

Best regards, Martin

3

I think that updating the ncache when a FIB entry is added is a reasonable proposal.

Another option regarding the specific case of RPL is to use DAO-ACK messages as a confirmation of bidirectional reachability, but that only works in child nodes for adding the RPL parent to the ncache. On the parent side, a unicast DAO (as opposed to multicast DAO) should be enough to confirm bidirectional reachability.

If a unicast DAO is received without a prior DIO having reached the child, how would the child node otherwise have known the link local address of the parent to send the unicast DAO to?

I checked the Contiki implementation of RPL to see how they do it without ND. The Contiki implementation uses DAO reception as the neighbor cache entry trigger. Though I don't consider Contiki an authority on network best practises, it is still interesting to see what choices were made in that particular implementation.

Regards, Joakim