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 ________________________________ Von: devel [devel-boun...@riot-os.org]" im Auftrag von "Joakim Nohlgård [joakim.nohlg...@eistec.se] Gesendet: Donnerstag, 10. März 2016 16:30 An: RIOT OS kernel developers Betreff: [riot-devel] Populating neighbor cache without ND (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
_______________________________________________ devel mailing list devel@riot-os.org https://lists.riot-os.org/mailman/listinfo/devel
