[Ndn-interest] LSDB in NLSR

[Lan Wang (lanwang)]

Tanusree,

On Jun 25, 2016, at 6:36 AM, Tanusree Chatterjee <tnsr.chatterjee at gmail.com<mailto:tnsr.chatterjee at gmail.com>> wrote:

Hi all,

Previously, in NLSR we can see that Sync computes a hash tree over all the data in a slice (of LSDB) that exchange the root hash between neighbors to detect inconsistencies. If the hash value do not agree, then two neighboring nodes exchange the hash value of nodes on the next tree level until they detect the specific leaf nodes (data) causing the problems.
While NLSR using chronosync every party keeps an outstanding sync interest with the current state digest.As soon as some party generates new data, the state digest changes, and the outstanding interest gets satisfied. ChronoSync module on her machine immediately noticesits state digest is newer and hence proceeds to satisfy the sync interest with sync data that contains the name of LSA. Whoever receives the sync data updates the digest tree to reflect the new change to the dataset state, and sends out a new sync interest with the updated state digest, reverting the system to a stable state.

This is a good summary of how ChronoSync works.  If I understand correctly, ChronoSync doesn’t have a deep digest tree: just the leaves and a root.

So, using chronosync, it reduces too much message exchanges than the previous sync protocol?

Which previous sync protocol are you referring to?  CCNSync?  I’m not aware of comparisons in terms of message overhead between chronosync and CCNSync.  They are not implemented on the same platform.   The paper “Synchronizing Namespaces with Invertible Bloom Filters” by Fu, Abraham and Crowley https://named-data.net/wp-content/uploads/2015/08/synchronizing_namespaces_invertible_bloom_filters.pdf has comparison between iSync and CCNSync.

While there is a change in the digest, the outstanding interest is satisfied by the LSA name itself which causes the change? It is in form of a ndn data packet thus preserving the integrity as well? What changes it has now in security while disseminating LSAs?

NLSR uses ChronoSync.  The Sync data packet carries the same name as the Sync interest (not the LSA name).  The LSA name is carried inside the Sync data packet as content.  Since the Sync data packet is a regular ndn data packet, it has a signature from the node that originates the Sync data.  The trust model for the sync protocol protects the authenticity of the sync data (I think the trust model is still an open research issue for ChronoSync), but I may be wrong.  Alex Afanasyev at UCLA can give you more accurate and up-to-date information about ChronoSync.

Lan


-- Regards,
Tanusree Chatterjee

_______________________________________________
Ndn-interest mailing list
Ndn-interest at lists.cs.ucla.edu<mailto:Ndn-interest at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/ndn-interest

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20160707/717c1c97/attachment.html>