Implementation of optimized neighbor discovery based on RFC 6775

[MohamedSeliem]

the commit of this pull is to update the neighbor discovery files to implement the new optimized version of neighbor discovery which suggested by IETF in RFC 6775.
IPv6 Neighbor Discovery (ND) based on RFC4861 was developed primarily for wired traffic on the shared medium. Its heavily use the multicast transmission in periodic router-advertisement multicast addresses with router solicitation, neighbor solicitation, address resolution, and duplicate-address detection. While periodic multicast signaling and solicited-node multicast signaling are useful for network stability in the standard Ethernet-based shared network, the limited-lifetime, battery-operated devices in the IEEE 802.15.4 network conserve energy with less signaling and by sending broadcast messages only once in a while. that makes makes it inefficient and sometimes impractical for IPv6 over Low power Wireless Personal Area Networks (6LoWPAN).
(https://tools.ietf.org/html/rfc6775) optimizes multicast messages to uni-cast messages. It eliminates the need for relatively expensive address resolution by sending a neighbor registration option along with a neighbor solicitation; it supports sleepy nodes in the networks; and it optimizes the protocol constants while eliminating periodic router-advertisement messages.
you could find all details in the following paper http://eece.cu.edu.eg/~akhattab/files/ND.pdf.

[vsaw]

I really appreciate the work implementing RFC 6775. This is a very useful feature for many nodes and networks.

However it seems the pull-request was based on an outdated version of ContikiOS. E.g. you have included an outdated version of tcpip.c. Contiki's current version of tcpip.c was moved to a different folder and received some fixes/refactoring in the mean time.

As far as I can see, the bulk of your work should be portable to the current contiki codebase. Would you mind trying a rebase, and if this fails, a manual port?

[MohamedSeliem]

I am trying manual port now. i will try rebase after Travis build ends. any feed will be gladly appreciated.

[nvt]

Please refrain from pushing until you have completed your work; many e-mails get sent about commits to this PR otherwise.

[MohamedSeliem]

i need to delete all old commits except the last one (fixing issues). when i do rebase, it did not work.
any help will be greatly appreciated. thanks in advance and sorry for disturbance.

[darkopetrovic]

The ND optimization should definitively be part of the contiki codebase.

I've noticed that you have implemented the code from https://github.com/lcmaqueda/6lowpan-nd. I did the same and found that it can work well. But I switched then to the ND optimisation implemented in the 6lbr project.

In the first implementation, the registrations are stored in a list and handled by dedicated functions (add, remove, lookup, ...). The new states introduced by RFC6775 for the Neighbor Cache Management (Garbage-collectible, Registered and Tentative) are then assigned to these registrations. However, these new types of Neighbor Cache Entries must instead remplace those in RFC4861 (Incomplete, Reachable, Stale, ...) which is not really the case with this implementation.

In the 6lbr project, the new types are assigned to the neighbor cache entries and the implementation is much easier to understand I think.

[MohamedSeliem]

First, i would like to thank you for your interest in implementing ND optimizations and our work.
second, i confirm that My implementation is based on https://github.com/lcmaqueda/6lowpan-nd. however i would like to mention that this implementation is obsolete considering that it implements a draft from the RFC 6775 not the RFC it self.
Moreover, The code lake the implementation of mean points in the optimization such as:
a. No implementation for the processing procedure for Address registration process header. Also when creating NA in response no ARO included. This will lead to obvious failure in the address registration mechanism.
b. the implementation of scheduled RA message does not contain destination which is must be set to the source of solicitation message.
c. implementing event timers to control the transmission of ND protocol messages, which is essential to construct the ND tables(neighbours, prefix list, registration list, and default router list)
d. RFC 6775 omit the use of periodic RA messages, and only depend on transmission solicited RA message.
e. The implementation of Ra transmissions message Only depend on receiving Rs message.

Also, when i skimmed through the 6lbr project. i did not see the above points are covered.
Finally, i would like to excerpt from the RFC 6775 some parts which clears things about Neighbor cache entries and the most prominent feature of the optimizations:

1- "The most important part of the optimizations is the evolved host-to-
router interaction that allows for sleeping nodes and avoids using
multicast Neighbor Discovery messages except for the case of a host
finding an initial set of default routers, and redoing such
determination when that set of routers have become unreachable"
2- " Note that the type of the NCE is orthogonal to the states specified
in [RFC4861]."
orthogonal by means that entry will keep the state (Incomplete, Reachable, Stale, ...) and orthogonal choose state from (Garbage-collectible, Registered and Tentative). then as you mentioned the replacement won't be correct.

[darkopetrovic]

It seems to me that the points you mentionned are covered by the implementation from the 6lbr project, at least as I tested them so far.

For me with this optimized standard there is no more host-to-host interaction when using sleeping devices, therefore the use of the precedent states (Incomplete, Reachable, ...) are no more required for a sleeping host to perform Address Resolution. The host send NS only for registration and to perform NUD with the routers. Howerver, on the router side, I guess this later use the new types with the sleeping device when the ARO option is present, and the others when not. Meaning that orthogonal means that the new types doesn't affect the old ones. But this means that both protocol cohabits on the router.

This is what I understand, maybe I'm wrong :)

[MohamedSeliem]

i closed this pull request, and will start all over again as i made major changes in the code to be compatible with contiki v 3.0.

[MohamedSeliem]

#1765 updates this pull request.

[simonduq]

Cannot you push -f to this branch again, so as to update this rather than open a new one?
So much better to keep track of the discussion.

[MohamedSeliem]

sorry, i can not as i deleted this branch when i created the new one.
if you can guide me, i will be glad to do it.
thanks

[simonduq]

I would simply push to the branch again and then look for the "reopen" button on the web

[MohamedSeliem]

when i try doing what you mentioned i get this message.
remote: Permission to contiki-os/contiki.git denied to MohamedSeliem.
fatal: unable to access 'https://github.com/contiki-os/contiki.git/': The requested URL returned error: 403

as i mentioned, i deleted the branch from my repository.

[simonduq]

do not attempt to push on contiki-is/contiki, target your own repo instead

[MohamedSeliem]

excuse me, but i can not push to my own repo, as i do not have a branch that will commit the changes to this PR.
pushing to my repo will update the new PR #1765 , it is already opened for 2 months.
i will refer to this PR to keep track of the discussion.

[simonduq]

ah ok I see you were using your master, then well, not sure if we can re-open this one indeed