[Mini-NDN] [Nfd-dev] Doubts regarding face creation

Thu Aug 13 04:19:04 PDT 2015

Even if the parallel links exist in the interface and face list, if NLSR uses only one of them, the others will not be in the FIB and strategy won't see them (at least for now).  There may be a way for the strategy to get around this, but it is best to wait for Vince to answer the question (he is on vacation until Monday).

Lan (on phone)

On Aug 13, 2015, at 2:40 AM, Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>> wrote:

Actually I need to configure a multi interface gateway and by nfdc register I can create the face as mentioned below. The strategies like broadcast(which uses multi link) are able to transfer the interest messages over the links. But the issue I am seeing here is that the counters value are 0. Please if you can explain the significance of counters, According to my understanding they are just measuring the number of bytes going out and coming in through the interface(but what are the values i,d and B represents). Also, there is no management traffic going through the link( which might be because as you said that NLSR does not support multilinks as of now). My concern is will it have any impact on the way the traffic is sent if my strategy supports multi interface gateway?

Best Regards,
Navdeep Uniyal

From: Mini-NDN [mailto:mini-ndn-bounces at lists.cs.ucla.edu] On Behalf Of Ashlesh Gawande (agawande)
Sent: Mittwoch, 12. August 2015 21:34
To: Lan Wang (lanwang); mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Maybe he just wants a static entry. I am not sure but he mentions using nfdc register to get the desired face list.

Ashlesh
________________________________
From: Mini-NDN <mini-ndn-bounces at lists.cs.ucla.edu<mailto:mini-ndn-bounces at lists.cs.ucla.edu>> on behalf of Lan Wang (lanwang) <lanwang at memphis.edu<mailto:lanwang at memphis.edu>>
Sent: Wednesday, August 12, 2015 2:22 PM
To: mini-ndn at lists.cs.ucla.edu<mailto:mini-ndn at lists.cs.ucla.edu>
Subject: [SPAM:###68] [SPAM:###68] Re: [Mini-NDN] [Nfd-dev] Doubts regarding face creation

Ashlesh,

I don't see how nfdc register is going to help if NLSR does not support parallel links (I may have misunderstood something).  But since Navdeep has joined the mini-ndn mailing list, let's move the discussion there.

Lan

On Aug 12, 2015, at 1:09 PM, Ashlesh Gawande (agawande) <agawande at memphis.edu<mailto:agawande at memphis.edu>> wrote:

Hi

So this is happening because NLSR does not support parallel links as of now. It will simply ignore the second neighbor in the configuration file. I have filed a feature request:
http://redmine.named-data.net/issues/3097
But it will not be in the near future as it requires some design and implementation work.

Right now you will have to do that manually. If your topology is fixed you can do it within the code
so you don't have to do it manually every time the topology comes up.

Example: In bin/minindn you can do something like net.hosts['g1'].cmd("nfdc register ....")

Ashlesh
________________________________
From: Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> on behalf of Navdeep Uniyal <navdeep.uniyal at neclab.eu<mailto:navdeep.uniyal at neclab.eu>>
Sent: Wednesday, August 12, 2015 3:51 AM
To: nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>
Subject: [Nfd-dev] Doubts regarding face creation

Hello All,

I am working on minindn. While creating the topology I am using the following configuration file:
[nodes]
h1: _
h2: _
h3: _
h4: _
g1: _
[links]
h1:g1 delay=10ms bw=10
h2:g1 delay=5ms bw=1
h2:g1 delay=0ms bw=2
h3:g1 delay=0ms bw=1
h4:g1 delay=0ms bw=3

As per my understanding, between h2 and g1 there should be 2 faces created but I am finding only one face created for this, and the other connection I have to make explicitly. Please confirm if this is expected behavior,  if I am doing anything wrong  or my understanding is wrong.

For g1, faces are :
Faces:
  faceid=1 remote=internal:// local=internal:// counters={in={0i 81d 0B} out={132i 0d 0B}} local persistent point-to-point
  faceid=254 remote=contentstore:// local=contentstore:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=255 remote=null:// local=null:// counters={in={0i 0d 0B} out={0i 0d 0B}} local persistent point-to-point
  faceid=256 remote=fd://18 local=unix:///run/g1.sock counters={in={92i 27d 36942B} out={27i 43d 45212B}} local on-demand point-to-point
  faceid=257 remote=fd://20 local=unix:///run/g1.sock counters={in={1022i 223d 208468B} out={912i 288d 231943B}} local on-demand point-to-point
  faceid=258 remote=udp4://1.0.0.1:6363 local=udp4://0.0.0.0:6363 counters={in={766i 74d 106769B} out={784i 89d 115716B}} non-local persistent point-to-point
  faceid=259 remote=udp4://1.0.0.5:6363 local=udp4://0.0.0.0:6363 counters={in={767i 65d 102476B} out={779i 89d 115339B}} non-local persistent point-to-point
  faceid=260 remote=udp4://1.0.0.13:6363 local=udp4://0.0.0.0:6363 counters={in={767i 67d 103289B} out={779i 89d 115605B}} non-local persistent point-to-point
  faceid=261 remote=udp4://1.0.0.17:6363 local=udp4://0.0.0.0:6363 counters={in={768i 68d 104006B} out={782i 89d 115879B}} non-local persistent point-to-point
  faceid=265 remote=udp4://1.0.0.9:6363 local=udp4://0.0.0.0:6363 counters={in={0i 0d 0B} out={0i 0d 0B}} non-local persistent point-to-point
  faceid=266 remote=fd://25 local=unix:///run/g1.sock counters={in={3i 0d 137B} out={0i 2d 903B}} local on-demand point-to-point

Highlighted one I created explicitly using nfdc register.
Also, please explain the significance of the counters [counters={in={0i 0d 0B} out={0i 0d 0B}}]

Best Regards,
Navdeep Uniyal

_______________________________________________
Nfd-dev mailing list
Nfd-dev at lists.cs.ucla.edu<mailto:Nfd-dev at lists.cs.ucla.edu>
http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/mini-ndn/attachments/20150813/b3356579/attachment.html>