[Ndn-interest] Faces and adjacency

Junxiao Shi shijunxiao at email.arizona.edu
Mon Jun 8 19:03:47 PDT 2015

Dear folks

Excerpt from *NFD Developer Guide*:

A Face is an abstraction which implements communication primitives to
actually send and receive Interest and Data packets.
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.
For multi-access communications (Ethernet, IP multicast), a Face represents
a virtual connection between a local endpoint and zero or more remote peers.

This means:

   - A point-to-point face is an adjacency.
   - A multi-access face is a L2 interface.

In reality, most communications are still using UDP or TCP tunnels.

NFD can operate directly on Ethernet. Currently Ethernet support is limited
to multicast only.
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.

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
But if this is extended to allow multiple hops, the problem of "not
everyone receive a packet" would happen.

In my experiments of self-learning forwarding (see basic idea in NDNcomm
2014 <http://www.caida.org/workshops/ndn/1409/> "NDN in local area
networks" presentation), I find it more convenient to define a face as a L2
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.

Yours, Junxiao

On Mon, Jun 8, 2015 at 12:23 PM, <Ignacio.Solis at parc.com> wrote:

> CCNx (1.0) is designed for adjacency.
> In old CCN (0.x) (and maybe NDN too if based on the old CCN model), faces
> were used for PITs and FIBs. Faces could behave like L2 in many
> circumstances, so these were real problems.  For example, what is
> currently done for multicast faces?
> Nacho
On Mon, Jun 8, 2015 at 11:53 AM, Dave Oran (oran) <oran at cisco.com> wrote:

> Naive question:
> Are faces like L2 interfaces, or like routing adjacencies?
> If the former, all the kinds of weirdnesses regarding unsolicited data and
> non-transitivity show up.
> 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.
> My recommendation is that faces behave as adjacencies, not interfaces and
> that we adopt or design a good adjacency management protocol ASAP.
> DaveO.
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://www.lists.cs.ucla.edu/pipermail/ndn-interest/attachments/20150608/de31b9b3/attachment.html>

More information about the Ndn-interest mailing list