Task #1191
closed
EthernetFace implementation
Added by Alex Afanasyev almost 11 years ago.
Updated over 10 years ago.
Description
Implement EthernetChannelFactory, EthernetChannel, and EthernetFace.
EthernetChannelFactory can
- create an EthernetChannel for communication on a local MAC address via a local NIC
If an EthernetChannel with the same local MAC address and local NIC exists, that one should be returned.
ethertype is defined as a constant.
EthernetChannel represents a local MAC address and a local NIC. It can
- create an EthernetFace for multicast communication with one multicast group
If a multicast-EthernetFace with the same multicast group exists, that one should be returned.
EthernetFace represents a broadcast tunnel (multicast).
A multicast-EthernetFace should have a libpcap session
to receive packets sent to the specific multicast group via the specific local NIC,
and to send packets to the specific multicast group via the specific local NIC.
The libpcap session SHOULD NOT be placed into promiscuous mode.
- Category set to Faces
- Target version set to v0.1
- Start date deleted (
01/31/2014)
- Assignee set to Davide Pesavento
- Description updated (diff)
- Estimated time set to 12.00 h
Ethernet is multicast-only.
On Wed, Jan 22, 2014 at 11:25 AM, Beichuan Zhang wrote:
The local multicast face doesn't run the above face registration protocol.
It is created on each physical interface at start time of the forwarder.
I'd put Ethernet under this category too, which means we don't support point-to-point Ethernet communication as for now.
What default multicast group and ethertype should we use?
NDNFD has 01:00:5E:00:17:AA and 0x8624.
- Status changed from New to In Progress
- % Done changed from 0 to 10
I'm probably missing some context here... what are the use cases for the Ethernet face/channel?
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...
- % Done changed from 10 to 60
hint on how to listen on multicast Ethernet address without putting NIC into promiscuous mode
- require multicast Ethernet address to be in the range for IPv4 multicast
- create libpcap session without promisc
- 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
- process libpcap captured packets normally; there’s no need to process packets on the UDP socket
- 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.
- Description updated (diff)
- Priority changed from Normal to High
I agree that avoiding promisc can be a separate task. It's written as #1278.
Avoiding promisc is a RECOMMENDED level requirement in this task, instead of REQUIRED.
- Status changed from In Progress to Code review
- % Done changed from 60 to 90
- % Done changed from 90 to 100
- Status changed from Code review to Closed
Also available in: Atom
PDF
Updated by 
Updated by 
Updated by