[Nfd-dev] Ethernet unicast faces

Thu Aug 10 09:02:28 PDT 2017

Hi Niels,

EthernetChannel doesn't currently enable NDNLPv2 fragmentation/reassembly
on unicast Ethernet faces. I think that should be changed to behave like
the multicast faces. I will submit an NFD patch later today.

At the moment, there is no way to toggle fragmentation/reassembly on a
per-face basis via nfdc, but we don't think this feature is necessary as we
don't have a use case for it (yet). Please let us know if you have a need
for it.

I'm not sure what you mean by "On multicast Ethernet faces the packets are
capped at the MTU". You should be seeing one or more fragments, each of
them not greater than the interface MTU, coming out of those faces. Can you
elaborate on the problem you're experiencing please?

Thanks,
Davide

On Thu, Aug 10, 2017 at 4:30 AM, Adrichem, N.L.M. (Niels) van <
niels.vanadrichem at tno.nl> wrote:

> Hello Susmit,
>
>
>
> Thank you for your answer, the unicast ethernet faces work according to
> your instructions and examples.
>
>
>
> In our scenario, there needs to occur fragmentation due to a large Data
> object size. Currently, we find that Data objects exceeding the link MTU of
> a unicast are dropped (which is expected without a link adaptation layer
> such as NDNLPv2). On multicast Ethernet faces the packets are capped at the
> MTU, which we think may be a minor bug, though it is not of influence to
> our work yet.
>
>
>
> We understood that the link adaptation layer NDNLPv2 is able to fragment
> and reassemble objects exceeding a link’s MTU and retransmit missing
> fragments on a hop-by-hop basis. However, the current Ethernet faces do not
> seem to use this encoding. Instead of the expected TLV-type 0x64 for
> NDNLPv2, we find in Wireshark that the TLV-types 0x05 and 0x06 for
> Interests and Data objects are directly encapsulated into Ethernet without
> the NDNLPv2 link adaptation layer. Do you, or any of the other readers,
> have pointers towards configuring NDNLPv2 over Ethernet faces?
>
>
>
> Best regards,
>
> Niels van Adrichem
>
>
>
> *From:* susmit.shannigrahi at gmail.com [mailto:susmit.shannigrahi at gmail.com]
> *On Behalf Of *Susmit
> *Sent:* woensdag 9 augustus 2017 17:27
> *To:* Wissingh, B.F. (Bastiaan) <bastiaan.wissingh at tno.nl>
> *Cc:* Susmit <susmit at cs.colostate.edu>; Teng Liang <
> philoliang2011 at gmail.com>; nfd-dev at lists.cs.ucla.edu; Adrichem, N.L.M.
> (Niels) van <niels.vanadrichem at tno.nl>
> *Subject:* Re: [Nfd-dev] Ethernet unicast faces
>
>
>
> Hi Bastiaan,
>
> This link has a few examples:
> https://redmine.named-data.net/issues/4012#change-19566
>
> For your example, could you try to modify your command to this?
>
> nfdc face create ether://[00:0c:29:de:37:fb] local dev://ens.38
>
> Thanks.
>
>
>
>
>
> On Wed, Aug 9, 2017 at 9:21 AM, Wissingh, B.F. (Bastiaan) <
> bastiaan.wissingh at tno.nl> wrote:
>
> Hi all,
>
>
>
> As Niels and I are both working on this topic, I’ve been playing around a
> bit with the master branch version of NFD today
> (version=0.5.1-115-g79a9208) in order to see if we could get the
> Unicast-Ethernet faces to work.
>
>
>
> Even though I found some documentation (https://named-data.net/doc/
> NFD/current/manpages/nfdc-face.html) on how to create these Unicast
> Ethernet faces, I can’t seem to get it to work… I’ve been trying all kinds
> of parameter combinations with nfdc, but without any luck.
>
>
>
> It seems that it is unable to parse the second command (so the local
> FaceURI). When I issue for example “nfdc face create
> ether://[00:0c:29:de:37:fb] dev://ens38” it returns with “cannot parse
> 'dev://ens38' as an argument name”.
>
>
>
> Do you have any hints on how to create such Ethernet Unicast face? Also,
> if a Unicast Ethernet face is created, will this ‘automatically’ enable the
> usage of NDNLPv2 on that Face?
>
>
>
> Looking forward to a response,
>
>
>
> Best regards,
>
> Bastiaan Wissingh
>
>
>
> *Van: *Nfd-dev <nfd-dev-bounces at lists.cs.ucla.edu> namens Susmit <
> susmit at cs.colostate.edu>
> *Datum: *woensdag 2 augustus 2017 18:05
> *Aan: *Niels van Adrichem <niels.vanadrichem at tno.nl>
> *CC: *"nfd-dev at lists.cs.ucla.edu" <nfd-dev at lists.cs.ucla.edu>, Teng Liang
> <philoliang2011 at gmail.com>
> *Onderwerp: *Re: [Nfd-dev] Ethernet unicast faces
>
>
>
> Hi Niels,
>
> This feature has already been merged, you might want to check-out the
> master branch to try it out.
> https://redmine.named-data.net/issues/4011
>
> Thanks.
>
>
>
> On Wed, Aug 2, 2017 at 9:37 AM, Adrichem, N.L.M. (Niels) van <
> niels.vanadrichem at tno.nl> wrote:
>
> Hello everybody,
>
>
>
> Awaiting unicast-Ethernet encapsulation, we are currently using UDP+IP
> encapsulation to achieve our functionality. However, we are facing some
> issues that with IP fragmentation the probability of packet loss increases
> greatly, while retransmission of missing fragments is absent.  We
> understand NDNLPv2 will have a retransmission-strategy for missing
> fragments of a segment larger than the MTU. Will this already be
> implemented in the unicast interface implementation you are currently
> working on?
>
>
>
> Please let us know if we can help evaluate a prototype, we are eager to
> work with NDN as the only network-layer forwarding protocol.
>
>
>
> Best regards,
>
> Niels van Adrichem
>
>
>
> *From:* Alex Afanasyev [mailto:aa at cs.ucla.edu]
> *Sent:* maandag 27 maart 2017 15:47
> *To:* D'Acunto, L. (Lucia) <lucia.dacunto at tno.nl>
> *Cc:* Lixia Zhang <lixia at cs.ucla.edu>; nfd-dev at lists.cs.ucla.edu; Davide
> Pesavento <davide.pesavento at lip6.fr>; Adrichem, N.L.M. (Niels) van <
> niels.vanadrichem at tno.nl>; Eric Newberry <enewberry at email.arizona.edu>;
> Teng Liang <philoliang2011 at gmail.com>
>
>
> *Subject:* Re: [Nfd-dev] Ethernet unicast faces
>
>
>
> Davide, Eric, Tang, Junxiao, and I are in charge of this and we will try
> to finalize the implementation quick.
>
>
>
> ---
>
> Alex
>
>
>
> On Mar 27, 2017, at 8:20 AM, D'Acunto, L. (Lucia) <lucia.dacunto at tno.nl>
> wrote:
>
>
>
> Hi Lixia,
>
> This is very good news!
>
> It would be great if you could give us the contact details of the person
> in charge of this project.
>
>
>
> Thanks, and best regards,
>
> Lucia
>
>
>
> *From:* Lixia Zhang [mailto:lixia at cs.ucla.edu <lixia at cs.ucla.edu>]
> *Sent:* maandag 27 maart 2017 13:41
> *To:* Adrichem, N.L.M. (Niels) van
> *Cc:* D'Acunto, L. (Lucia); nfd-dev at lists.cs.ucla.edu; Alex Afanasyev;
> Davide Pesavento
> *Subject:* Re: [Nfd-dev] Ethernet unicast faces
>
>
>
> unicast Ethernet was one of the hackathon projects over the weekend.
>
> my understanding is that the code should be available real soon.
>
>
>
> On Mar 27, 2017, at 1:07 AM, Adrichem, N.L.M. (Niels) van <
> niels.vanadrichem at tno.nl> wrote:
>
>
>
> Hello everybody,
>
>
>
> As a work-around we will now use IP or UDP/IP encapsulation, but
> ultimately we would like to use only L2-/Ethernet-encapsulation to show
> that these types of L3-forwarding functions can be handled using just NDN.
>
> I understand from the documentation that Ethernet multicast functionality
> is achieved through a PCAP filter on the multicast Ethernet address without
> setting the interface in promiscuous mode, suggesting a similar approach
> can be achieved through a PCAP filter on an interface’s own unicast
> Ethernet address without setting the interface in promiscuous mode.
>
>
>
> Best,
>
> Niels
>
>
>
> *From:* D'Acunto, L. (Lucia)
> *Sent:* vrijdag 24 maart 2017 17:49
> *To:* nfd-dev at lists.cs.ucla.edu; Alex Afanasyev <aa at CS.UCLA.EDU>; Davide
> Pesavento <davide.pesavento at lip6.fr>
> *Cc:* Adrichem, N.L.M. (Niels) van <niels.vanadrichem at tno.nl>
> *Subject:* Ethernet unicast faces
>
>
>
> Hi Alex, Davide, all,
>
> I have a question about Ethernet unicast faces in NDN for usage in Wifi
> ad-hoc.
>
> Do you have plans to re-implement Ethernet Unicast faces? we just
> discovered that was removed and NFD only offers Ethernet Multicast faces
> for now. For our ICN-IoT with WiFi Ad-hoc project this is a bit of a
> problem, since we want to retransmit on the same WiFi interface (which
> again is disabled in the dissemination strategy for Ethernet Multicast
> faces), and want to use the source and destination MAC address to
> respectively indicate who should be the next hop to retransmit the Data
> object and Interest.
>
>
>
> We would appreciate your help (or work arounds) with this retransmission
> problem.
>
>
>
> Thanks!
>
> Lucia
>
>
>
>
>
> Lucia D'Acunto, PhD
> Research Scientist
> Media Networking
>
> T +31 (0)88 866 71 37
> M +31 (0)64 696 60 10
> E lucia.dacunto at tno.nl
>
>
>
>
>
> <image001.gif> <http://www.tno.nl/>
>
> TNO | New Babylon | Anna van Buerenplein 1, 2595DA,  The Hague, The
> Netherlands
>
>
>
>
>
>
>
> 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.
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
>
> _______________________________________________
> Nfd-dev mailing list
> Nfd-dev at lists.cs.ucla.edu
> http://www.lists.cs.ucla.edu/mailman/listinfo/nfd-dev
>
>
>
>
>
> --
>
>
> ====================================
> http://www.cs.colostate.edu/~susmit
> ====================================
>
>
>
>
> --
>
>
> ====================================
> http://www.cs.colostate.edu/~susmit
> ====================================
>
> _______________________________________________
> Nfd-dev mailing list
> 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/nfd-dev/attachments/20170810/84d8e0fd/attachment-0001.html>