<div dir="ltr">Dear folks<div><br></div><div>Excerpt from <b>NFD Developer Guide</b>:</div><blockquote style="margin:0px 0px 0px 40px;border:none;padding:0px">A Face is an abstraction which implements communication primitives to actually send and receive Interest and Data packets.<br>Depending on nature of communication, a Face can represent slightly  different elements. For "unicast" communications (TCP, unicast UDP, UNIX sockets, WebSocket), a Face represents a connection between local and remote endpoints for the specific protocol, i.e, a connection between NFDs on different network nodes or local NFD and local application.<br>For multi-access communications (Ethernet, IP multicast), a Face represents a virtual connection between a local endpoint and zero or more remote peers.</blockquote><div><br></div><div>This means:</div><div><ul><li>A point-to-point face is an adjacency.</li><li>A multi-access face is a L2 interface.</li></ul></div><div><br></div><div>In reality, most communications are still using UDP or TCP tunnels.</div><div><br></div><div>NFD can operate directly on Ethernet. Currently Ethernet support is limited to multicast only.<br></div><div>When we integrate NDNLPv1 fragmentation and reassembly, it appears necessary to maintain some kind of adjacency, because the receive must reassemble frames from each individual sender address separately. But there's no explicit adjacency concept in Ethernet face.</div><div><br></div><div>The only other multi-access face implemented in NFD is IPv4 UDP multicast. It's limited to one hop only so it isn't much different from Ethernet multicast.</div><div>But if this is extended to allow multiple hops, the problem of "not everyone receive a packet" would happen.</div><div><br></div><div><br></div><div>In my experiments of self-learning forwarding (see basic idea in <a href="http://www.caida.org/workshops/ndn/1409/" target="_blank">NDNcomm 2014</a> "NDN in local area networks" presentation), I find it more convenient to define a face as a L2 interface.</div><div>This would allow a node to send an Interest to a well-known multicast address during flooding in order to reach all NDN nodes on a L2 segment, but the reply Data could be delivered over unicast toward the requester only so that other nodes won't be bothered.</div><div><br></div><div>Yours, Junxiao<br><div class="gmail_extra"><br><div class="gmail_quote">On Mon, Jun 8, 2015 at 12:23 PM,  <span dir="ltr"><<a href="mailto:Ignacio.Solis@parc.com" target="_blank">Ignacio.Solis@parc.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">CCNx (1.0) is designed for adjacency.<br>
<br>
In old CCN (0.x) (and maybe NDN too if based on the old CCN model), faces<br>
were used for PITs and FIBs. Faces could behave like L2 in many<br>
circumstances, so these were real problems.  For example, what is<br>
currently done for multicast faces?<br>
<br>
Nacho<br></blockquote><div class="gmail_quote">On Mon, Jun 8, 2015 at 11:53 AM, Dave Oran (oran) <span dir="ltr"><<a href="mailto:oran@cisco.com" target="_blank">oran@cisco.com</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0px 0px 0px 0.8ex;border-left-width:1px;border-left-color:rgb(204,204,204);border-left-style:solid;padding-left:1ex">Naive question:<br><br>Are faces like L2 interfaces, or like routing adjacencies?<br>If the former, all the kinds of weirdnesses regarding unsolicited data and non-transitivity show up.<br>If the latter, you need an adjacency initialization and maintenance protocol (which all routing protocols running on multi-access links have), but you avoid all the messiness pointed out in this thread.<br><br>My recommendation is that faces behave as adjacencies, not interfaces and that we adopt or design a good adjacency management protocol ASAP.<br><br>DaveO. </blockquote></div></div></div></div></div>