> On Jun 21, 2010, at 11:44 AM, Daniel Gavelle wrote: > > > In section 8.2.6 of 6LowPAN-ND-10, it is the responsibility of the 6LR to > retry if forwarding a special NS message to the 6LBR does not result in a > corresponding NA. > > > > I think it would be more efficient if the host were responsible for the > retry. The host will need to retry the special NS message anyway, to cover > the case where the message is lost between the host and the 6LR or the > forwarded NA is lost in the other direction. > > > > If the 6LR didn't need to retry on behalf of the host, it wouldn't need a > table of pending nodes. It could implement NS/NA forwarding in a stateless > manner, much like a REST HTTP implementation. This would not require any [SC>]
The DAD state in 6LR is needed for reliability even for successful case. If 6LRs did not keep track of the address being registered at 6LBR(s), then it'd not know if it received the NA from 6LBR for the requested IPv6 address, making the process unreliable for DAD. The first time DAD is a synchronous DAD. As described in section 8.2: "For the synchronous multihop DAD the 6LR MUST NOT add a Neighbor Cache entry for the address until it receives a successful ARO option from the 6LBRs. Otherwise a duplicate could end up being registered in the 6LRs Neighbor Cache which would cause a registration from the original host with this 6LR to fail. The system "remembers" the link-layer address of the host by carrying the host's SLLA option in the multihop DAD messages, and that is used to later deliver the NA with the ARO back to the host." However, 6LR alternately could just remove the DAD entry and respond to host with a NA with a failure status instead of retrying to 6LBR. This would eliminate the responsibility of 6LR to act as proxy for all the hosts for retrial in case the 6LBR is somehow unreachable or the path to 6LBR is broken. Implementations may choose to make the MAX_UNICAST_SOLICIT value configurable to adjust the number of retransmits. The downside of hosts being responsible for retrial is that they would have to keep trying and spending more resource which might be an issue for resource starved hosts. If we assume that hosts are equally capable as 6LRs then it would be useful for host to do the retrial - but even then 6LR would have to do an extra processing of NS for every retrial from the hosts and spend energy. Thus we chose 6LR to do the retrial as it has done half the processing already. However, multihop-dad would require some work for scalability. One thing I noticed in 8.2.6 is that it says that after the retrials, 6LR responds to the host with ARO status zero. I'd think 6LR would respond with ARO status code it received from 6LBR NA. Thanks, -Samita > other change to the specification because the state information (the SLLAO > of the host) is already carried in the messages. > > > WFM. What do others think? > > Zach > > -- > Zach Shelby, Chief Nerd, Sensinode Ltd. > http://zachshelby.org - My blog "On the Internet of Things" > http://6lowpan.net - My book "6LoWPAN: The Wireless Embedded Internet" > Mobile: +358 40 7796297 > > _______________________________________________ > 6lowpan mailing list > [email protected] > https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
