[Ndn-interest] Multiple Ethernet faces

[Vince Lehman (vslehman)]

Hi Ray,

I can try to answer the second question. Currently, NLSR does indeed try to create a Face regardless of type; in the case of EthernetFace, this causes the error you see.

So I think it is not an error on your part, but instead a logic error in NLSR. Instead, NLSR should query for the FaceId associated with the Ethernet hardware address. If a FaceId is returned, NLSR should use the existing Face instead of attempting to create a new one.

Maybe someone more familiar with Face management in NFD can confirm.

--
Vince Lehman

On Aug 19, 2015, at 1:12 PM, Brandenburg, R. (Ray) van <ray.vanbrandenburg at tno.nl<mailto:ray.vanbrandenburg at tno.nl>> wrote:

Hi,

I've been playing around with NDN Ethernet support and bumped into two issues.

1) If I have a machine with multiple NICs, NFD will list them as separate faces (since they have different local endpoints). However, they will have the same remote endpoint, i.e the ethernet multicast address listed in nfd.conf. Is there anyway to make sure each Ethernet face has it's own distinct multicast address?

2) I'd like to run NLSR directly over Ethernet. Since the conf file only allows me to specify face-uri per neighbor (instead of face-id), and doesn't support 'dev://ethX' scheme, I thought to use the 'ether://' scheme to specify the face I'd like to use for a particular neighbor. However, when I do that, NLSR tries to create that face, which fails since NFD doesn't allow one to create Ethernet faces. The same problem occurs irrespective of whether I use the ethernet multicast address as listed in NFD or the actual hardware ethernet address. I was expecting NLSR to only try to create a face if it doesn't already exist. Is this intended behavior, or am I doing something wrong? Is there any other way of using NLSR over Ethernet?

Thanks!

Ray
This message may contain information that is not intended for you. If you are not the addressee or if this message was sent to you by mistake, you are requested to inform the sender and delete the message. TNO accepts no liability for the content of this e-mail, for the manner in which you use it and for damage of any kind resulting from the risks inherent to the electronic transmission of messages.


_______________________________________________
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/20150820/5608df28/attachment.html>