[ndnSIM] interest=/localhost/nfd/faces/events/%FE%05 ?

Tue Apr 26 15:26:55 PDT 2016

If you have a producer application or any invocation of FibHelper::AddRoute, it will create a command interests with /localhost/nfd/fib/add-nexthop prefix.

Why do you want to disable that?  The simulation will not be meaningful much if you don't have FIB configured...

---
Alex

> On Apr 26, 2016, at 1:58 AM, Carl <carlzu8 at gmail.com> wrote:
> 
> Hi Alex,
> 
> I have disabled RIB manager, but still I see control data messages with prefix _data=/localhost/nfd/fib/add-nexthop_. This means that even if I have disabled RIB manager, still FIBs are populated ? Why ?... And how I can completely disable this ?
> 
> After, I also disabled Face Manager to see what happens, but received the same output. Actually I have done this because always fib/add-nexthop messages appear right after face events.
> 
> Looking forward to your response.
> 
> Thanks.
> Regards,
> C
> 
> On 24.02.2016 07:31, Alex Afanasyev wrote:
>> Hi Carl,
>> 
>> In the beginning of simulation (time moment 0s), there are a few initial tasks that NFD performs internally.  One of them is setting up internal RIB manager.  RIB manager is separated from main forwarding and uses interest-data exchange to receive notifications that new face is created, face is destroyed, and few others.  The LocalControl refer to LocalControlHeader protocol http://redmine.named-data.net/projects/nfd/wiki/LocalControlHeader, which allows additional meta information to be communicated alongside interest and data packets.  You also may want to check http://named-data.net/wp-content/uploads/2015/10/ndn-0021-5-nfd-developer-guide.pdf for further explanation how RIB manager module works.
>> 
>> Regarding your question.  Most likely, you would want to populate RIB, not FIB:  FIB is calculated from RIB, taking into account inheritance and capture flags.  Though, if you like, you can still work directly with FIB and completely disable RIB manager module (http://ndnsim.net/2.1/doxygen/classns3_1_1ndn_1_1StackHelper.html#a1820acb048f802a6686dc92518a4a826).
>> 
>> Either way, you have two options.  One option is to use NFD management protocol and send register/unregister (for RIB management) and add-nexthop/remove-nexthop (for FIB management).  For the latter, you can use FibHelper, for the former, you will need a little bit of code similar to FibHelper (we are overdue in adding RibHelper).
>> 
>> Second option is a little bit hacky (it can be "faster", but I would recommend it) and will work only in the simulation: you can get direct access to Fib instance on the node and add entries directly:
>> 
>> auto fib = node->GetObject<ndn::L3Protocol>()->getForwarder()->getFib();
>> ...
>> 
>> (few comments inline)
>> 
>>> On Feb 23, 2016, at 9:54 PM, Carl Zu <carlzu8 at gmail.com> wrote:
>>> 
>>> Hi Alex,
>>> 
>>> Thanks for your reply. These notification streams are not only for new faces. They are for strategy choice, and in particular for FIB population (add-nexthop). The important question is that what shall I do if I like to implement my own FIB population method ?
>>> 
>>> Minor questions (logs are for ndn-simple.cpp):
>>> 1. Why these notification streams start from node "-1" (I believe it should not be a node), and then they continue for real nodes. See here:
>>> 
>>> 0s -1 nfd.Forwarder:onDataUnsolicited(): [DEBUG] onDataUnsolicited face=1 data=/localhost/nfd/fib/add-nexthop/h%0C%......
>> -1 means that this event was scheduled outside context of the simulation node.  Most likely, it happened during scenario initialization.  I wouldn't worry about this.
>> 
>>> 2. Notification streams not only contain interests and data, but they contain "matching" as well (for add-nexthop and enable-local-control). What is that ?. See here:
>>> 
>>> 0s 1 nfd.Forwarder:onIncomingData(): [DEBUG] onIncomingData matching=/localhost/nfd/fib/add-nexthop/h%1A
>>> 
>>> OR
>>> 
>>> 0s 1 nfd.Forwarder:onIncomingData(): [DEBUG] onIncomingData matching=/localhost/nfd/faces/enable-local-control/h%03........
>> You may get a better idea after reading the link I gave you above.  Essentially, you see that RIB manager module requested "control-header" support on its face and was granted it by NFD.
>> 
>> --
>> Alex
>> 
>> 
>>> 3. even if googled and read, have not understood well "enable-local-control". Small explanation would be appreciated.
>>> 
>>> Thanks very much,
>>> C
>>> 
>>> 
>>> 
>>> 
>>> 
>>> On Tue, Feb 23, 2016 at 7:25 PM, Alex Afanasyev <aa at cs.ucla.edu> wrote:
>>> 
>>>> On Feb 23, 2016, at 6:29 AM, Carl Zu <carlzu8 at gmail.com> wrote:
>>>> 
>>>> Hi !
>>>> 
>>>> there are some interests that come in between ordinary interests. For example, look at the two types of interest messages in the following logs. Type 1 is clearly an interest sent for retrieving a content object with a certain prefix. What is interest type 2 ?
>>>> 
>>>> Type1:
>>>> 2s 0 nfd.Forwarder:onOutgoingInterest(): [DEBUG] onOutgoingInterest face=256 interest=/prefix/%FE%00
>>>> 
>>>> Type2:
>>>> 2s 0 nfd.Forwarder:onIncomingInterest(): [DEBUG] onIncomingInterest face=257 interest=/localhost/nfd/faces/events/%FE%05
>>> Hi Carl,
>>> 
>>> When NFD detects there is a new face (e.g., new application), it notifies its internal module and any other interested applications about the fact.  You can learn more about this here: http://redmine.named-data.net/projects/nfd/wiki/Notification
>>> 
>>> Does this mechanism affect your simulations?
>>> 
>>> ---
>>> Alex
> 

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 841 bytes
Desc: Message signed with OpenPGP using GPGMail
URL: <http://www.lists.cs.ucla.edu/pipermail/ndnsim/attachments/20160426/b904bd72/attachment.bin>