[Nfd-dev] Ethernet unicast faces

Thu Aug 10 01:30:41 PDT 2017

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<mailto: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<mailto:nfd-dev-bounces at lists.cs.ucla.edu>> namens Susmit <susmit at cs.colostate.edu<mailto:susmit at cs.colostate.edu>>
Datum: woensdag 2 augustus 2017 18:05
Aan: Niels van Adrichem <niels.vanadrichem at tno.nl<mailto:niels.vanadrichem at tno.nl>>
CC: "nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>" <nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>>, Teng Liang <philoliang2011 at gmail.com<mailto: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<mailto: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<mailto:aa at cs.ucla.edu>]
Sent: maandag 27 maart 2017 15:47
To: D'Acunto, L. (Lucia) <lucia.dacunto at tno.nl<mailto:lucia.dacunto at tno.nl>>
Cc: Lixia Zhang <lixia at cs.ucla.edu<mailto:lixia at cs.ucla.edu>>; nfd-dev at lists.cs.ucla.edu<mailto:nfd-dev at lists.cs.ucla.edu>; Davide Pesavento <davide.pesavento at lip6.fr<mailto:davide.pesavento at lip6.fr>>; Adrichem, N.L.M. (Niels) van <niels.vanadrichem at tno.nl<mailto:niels.vanadrichem at tno.nl>>; Eric Newberry <enewberry at email.arizona.edu<mailto:enewberry at email.arizona.edu>>; Teng Liang <philoliang2011 at gmail.com<mailto: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<mailto: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]
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<mailto: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<mailto: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<mailto:nfd-dev at lists.cs.ucla.edu>; Alex Afanasyev <aa at CS.UCLA.EDU<mailto:aa at CS.UCLA.EDU>>; Davide Pesavento <davide.pesavento at lip6.fr<mailto:davide.pesavento at lip6.fr>>
Cc: Adrichem, N.L.M. (Niels) van <niels.vanadrichem at tno.nl<mailto: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<mailto: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<mailto: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<mailto: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
====================================
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/nfd-dev/attachments/20170810/a9f35793/attachment-0001.html>