[Nfd-dev] Possibility to create unicast face inside forwarding strategy

Mahyuddin Husairi mahyuddin at gmail.com
Mon Nov 27 05:56:03 PST 2017


If the suggested feature on issue #4283
<https://redmine.named-data.net/issues/4283> is not accepted, what is the
way that self learning strategy switch the forwarding mode from multicast
to unicast after discovery?
We just assume the relevant unicast face exist? and if not exist how?

On Mon, Nov 27, 2017 at 9:11 PM, Junxiao Shi <shijunxiao at email.arizona.edu>
wrote:

> Hi Mahyuddin
>
> I need your opinion about enabling forwarding strategy to create face. At
>> least unicast face (raw ethernet or udp) for dynamic unicast face features
>> in my NDN based MANET solution.
>>
>
>> 1. What is the possible dirty hack way to enable it?
>>
> Do not look for or use "dirty hack way". The harm of doing so is described
> on https://yoursunny.com/t/2017/academic-papers/ "program quality"
> section.
>
> AFAIK, to create face, it is part of NFD management protocol API. Is that
>> possible to access that API just like face-module.cpp in NFD tools?
>>
> No, because forwarding plane is not an application. It cannot send packets
> to itself.
>
> 2. Or is there any better way to implement it?
>>
> The better way is to avoid the program in the first place.
> A face is a generalization of an interface. Therefore, an Ethernet face
> shall support both multicast and unicast on the same physical interface.
> NFD currently implements Ethernet unicast like tunnel, which is wrong.
> You may achieve unicasting by implementing https://redmine.
> named-data.net/issues/4283 . I heard from last NFD call that NFD team is
> planning to reject this issue, but I believe this is the right way to go.
>
> Yours, Junxiao
>



-- 
Human knowledge Belongs to The World
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20171127/0987b1d8/attachment.html>


More information about the Nfd-dev mailing list