Feature #3626
open
Use IncomingFaceId tag to direct LSA Interests
0%
Description
Currently, when NLSR synchronizes changes to LSDBs, it attempts to fetch the routing updates using multicasted Interests. Thus, neighbors that may not even have the data will receive and further multicast these Interests resulting in unnecessary messages.
Instead, NLSR can use the information of which incoming interface the Sync update was received to send directed Interests. The neighboring router that triggered the Sync update will eventually receive, or already has, the updated Data; the router can send an Interest to this neighboring router using the incoming FaceId.
This change will require:
- Enable IncomingFaceId and NextHopFaceId Control Header features on application Face
- Change strategy on LSA prefix to ClientControl strategy
- Pass received Sync Data's IncomingFaceId tag from NSync to NLSR
- Use the IncomingFaceId tag to set NextHopFaceId for LSA Interest
But, this change would need the ClientControl strategy to use the multicast strategy as a backup instead of the BestRoute strategy.
Updated by Junxiao Shi about 8 years ago
need the ClientControl strategy to use the multicast strategy as a backup instead of the BestRoute strategy
I disagree with changing ClientControl strategy.
Instead, ClientControl strategy should be eliminated.
Current NDNLPv2 spec says:
NextHopFaceId indicates the nexthop FaceId to which an Interest should be forwarded. A local consumer application MAY add this field to an LpPacket carrying an Interest. The local forwarder SHOULD follow this instruction and forward the Interest to the specified nexthop. ContentStore lookup SHOULD be bypassed unless NextHopFaceId equals a special FaceId that represent the ContentStore.
This means:
NextHopFaceId should be recognized universally.
When NextHopFaceId is given, forwarding always forwards the Interest toward the specified next hop, and CS lookup and strategy choice are bypassed.
However, in NLSR's use case, it's undesirable to bypass CS lookup.
There are other use cases that wants to bypass CS lookup.
Thus, this definition may need an amendment on choosing whether CS lookup should be bypassed.
Updated by Junxiao Shi about 8 years ago
- Tracker changed from Task to Feature
20160913 NFD call approves note-1 idea, and decides CS lookup should not be bypassed under any circumstance because there's no valid use case.
I'll create an issue under NFD for this change.
Updated by Junxiao Shi about 8 years ago
- Blocked by Feature #3783: Honor NextHopFaceId universally added
Updated by Muktadir Chowdhury almost 7 years ago
The description of this task is outdated.
LocalControlHeader has been removed in NFD v0.4.
It's replaced with NDNLPv2 NextHopFaceId, CachePolicy, IncomingFaceId fields.
Moreover, Nlsr uses Chronosync to sync-up the lsdb dataset, and Nlsr uses it as a library now. It's been used in SyncLogicHandler to get sync update.
So the change require to do the following:
- Enable IncomingFaceIdIndication (already enabled in this issue here).
- Make change in the Chronosync to get the FaceId of the incoming update.
- Pass the FaceId to Nlsr.
- Nlsr uses that FaceId to fetch the lsa.
Updated by Ashlesh Gawande over 5 years ago
- Blocks Task #4920: Set best-route strategy for LSAs added
Updated by Ashlesh Gawande over 5 years ago
- Blocks Feature #4921: Change LSA prefix to /localhop/⟨network⟩/⟨site⟩/⟨router⟩/NLSR/LSA/⟨lsa-type⟩/ added
Updated by Ashlesh Gawande over 5 years ago
- Target version set to v0.6.0
- Start date deleted (
05/25/2016)
Updated by Saurab Dulal almost 4 years ago
- Target version changed from v0.6.0 to 0.7.0