NFD

Use case: to communicate directly over Ethernet in an IP-free network.

Can you be a bit more specific please? How's the face supposed to be used by nfd itself? What identifies a "local NIC" (mac address, interface name, something else...)? Why only multicast?

How's the face supposed to be used by nfd itself?

NFD uses an EthernetFace like any other face: send and receive Interest and Data.

What identifies a "local NIC" (mac address, interface name, something else...)?

A local NIC is identified by its interface name, such as eth1 on linux or en1 on OS X.

Why only multicast?

To have unicast, the channel must receive the packet, and perform an exact match of the source address to find the face, and dispatch the packet to that face.

Supporting only multicast eliminates the need for this dispatching mechanism.

Imagine a NIC that understands NDN Names in the hardware: unicast is not necessary in this device.

Junxiao Shi wrote:

What identifies a "local NIC" (mac address, interface name, something else...)?

A local NIC is identified by its interface name, such as eth1 on linux or en1 on OS X.

This means that the "type" of a local endpoint (iface name) is different from the "type" of a remote endpoint (multicast address), so I'm not sure if it makes sense to define the usual ethernet::Endpoint type alias...
In either case, it would just be an alias for std::string.

Why only multicast?

To have unicast, the channel must receive the packet, and perform an exact match of the source address to find the face, and dispatch the packet to that face.

Supporting only multicast eliminates the need for this dispatching mechanism.

Imagine a NIC that understands NDN Names in the hardware: unicast is not necessary in this device.

Understood.

What's the semantics of EthernetChannel::listen() then? Should it open a promiscuous-mode pcap session on the local NIC and spawn a new EthernetFace whenever it receives an NDN packet (i.e. one with the correct ethertype) from a new (i.e. never seen before) multicast group (or in other words, when a face for that multicast group isn't already present in the ChannelFaceMap)?

the "type" of a local endpoint (iface name) is different from the "type" of a remote endpoint (multicast address)

A local NIC can be uniquely identified by an interface name or by a MAC address, so endpoint type should be uint8_t[6] or equivalent.

What's the semantics of EthernetChannel::listen() then?

Channel::listen is only applicable to unicast.

Junxiao Shi wrote:

the "type" of a local endpoint (iface name) is different from the "type" of a remote endpoint (multicast address)

A local NIC can be uniquely identified by an interface name or by a MAC address, so endpoint type should be uint8_t[6] or equivalent.

Wrong. A mac address may not be unique in the presence of virtual interfaces (e.g. think about VLAN interfaces). The name is the only way to identify it uniquely.

What's the semantics of EthernetChannel::listen() then?

Channel::listen is only applicable to unicast.

OK, makes sense. I asked only because I saw listen() in the UML diagram of EthernetChannel...

hint on how to listen on multicast Ethernet address without putting NIC into promiscuous mode

1. require multicast Ethernet address to be in the range for IPv4 multicast
2. create libpcap session without promisc
3. calculate an IPv4 multicast address whose mapped Ethernet address happens to be the multicast Ethernet address, create a UDP socket and join IP multicast using the calculated IPv4 multicast address
4. process libpcap captured packets normally; there’s no need to process packets on the UDP socket
5. close the UDP socket when libpcap session is closing

NDNFD face/ether.cc contains code that illustrates this idea.
It works on linux but seems to have problem on OS X.

Doesn't this procedure require the local network interface to have an IP address?

Junxiao, I would suggest that we move this optimization to a separate issue. For now we just need basic things to work in any way possible (either promiscuous mode or simply broadcast mode). This also for version 1 release, but after basic things are working and tested.