Project

General

Profile

Actions

Feature #4283

closed

Refactor Ethernet unicast communication

Added by Junxiao Shi over 6 years ago. Updated almost 4 years ago.

Status:
Rejected
Priority:
Normal
Assignee:
-
Category:
Faces
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
12.00 h

Description

NFD currently implements Ethernet unicast communication in the same way as a UDP tunnel: each NIC has one Ethernet-multicast face configured as either broadcast or ad hoc wireless, and zero or more Ethernet-unicast face for point-to-point communication with specific neighbors.
This approach is wrong: forwarding has no way to know that an Ethernet-multicast face and some Ethernet-unicast faces are on the same NIC.
Self-learning on Ethernet (#4281) floods a discovery Interest on a NIC by sending it to the broadcast address. When a Data comes back, the strategy needs to learn the upstream's unicast address. Subsequent Interests shall be unicast to the upstream.
Since forwarding does not have access to management, which is at a higher layer, self-learning cannot generate new faces and thus it could neither learn the upstream's address nor unicast subsequent Interests.

This refactoring merges Ethernet multicast and Ethernet unicast communication over the same NIC into a single Ethernet face.
The new EthernetTransport considers EndpointId field on both directions. An outgoing packet is unicast if EndpointId represents a neighbor, or broadcast if EndpointId is empty. For an incoming packet, the EndpointId field is set to indicate the sender of this packet.


Related issues 1 (0 open1 closed)

Related to NFD - Feature #4843: EndpointId in LinkServiceAbandonedMd Ashiqur Rahman

Actions
Actions #1

Updated by Junxiao Shi over 6 years ago

Actions #2

Updated by Alex Afanasyev over 6 years ago

I don't think this refactoring is really needed (either short or long term). The self-discovery doesn't really need to know that two faces are connected. If it for some reason needs it, it can be accomplished via adding some Face API call without major refactoring.

Actions #3

Updated by Junxiao Shi over 6 years ago

The self-discovery doesn't really need to know that two faces are connected.

Self-learning doesn't need to know the relation between two existing faces. It needs to unicast toward a remote endpoint on top of a broadcast or ad hoc wireless face.

it can be accomplished via adding some Face API call without major refactoring.

If unicasting requires creation of a separate point-to-point face, the alternative solution would lead to much higher overhead: face creation triggers a notification in management. When an old face is recycled (destroyed), it triggers another notification, and triggers a cleanup action in FIB and PIT that enumerates these tables.

This refactoring simplifies Ethernet implementation. Ethernet faces no longer have to update pcap string whenever a unicast face is created or destroyed.
However, for the purpose of self-learning, it isn't required to remove the existing "unicast Ethernet tunnel". Adding unicast capability to Ethernet (multicast) faces would be sufficient.

Actions #4

Updated by Teng Liang over 6 years ago

Actions #5

Updated by Davide Pesavento over 6 years ago

  • Target version deleted (v0.7)
Actions #6

Updated by Davide Pesavento over 5 years ago

  • Assignee deleted (Yanbiao Li)
Actions #7

Updated by Md Ashiqur Rahman about 5 years ago

Please correct me if I'm wrong. Form what I understand, the following functionalities are expected:

  • Add Ethernet Unicast functionalities in the Ethernet Multicast face (need a bit more ).
  • Have a method like getEndpointId() to fetch the remoteEndpoint of a received packet over this Ethernet Multicast face. This method helps to provide the EndpointId for the FIB's NextHop entry in Self-learning when Data comes back.

Junxiao Shi wrote:

This refactoring merges Ethernet multicast and Ethernet unicast communication over the same NIC into a single Ethernet face.
The new EthernetTransport considers EndpointId field on both directions. An outgoing packet is unicast if EndpointId represents a neighbor, or broadcast if EndpointId is empty. For an incoming packet, the EndpointId field is set to indicate the sender of this packet.

Here, you said broadcast a packet when EndpointId is empty. Does this mean a null value or simply 0?

Actions #8

Updated by Junxiao Shi about 5 years ago

Add Ethernet Unicast functionalities in the Ethernet Multicast face (need a bit more ).

Yes, and rename them to just Ethernet face.

Have a method like getEndpointId() to fetch the remoteEndpoint of a received packet over this Ethernet Multicast face. This method helps to provide the EndpointId for the FIB's NextHop entry in Self-learning when Data comes back.

It's less intrusive to use a tag similar to IncomingFaceIdTag.
You may even consolidate EndpointId into IncomingFaceIdTag, since these two always go together.

An outgoing packet is unicast if EndpointId represents a neighbor, or broadcast if EndpointId is empty.

Here, you said broadcast a packet when EndpointId is empty. Does this mean a null value or simply 0?

nullptr and 0 have same semantics. An EndpointId-aware strategy should normally use 0, while a legacy strategy would not set a tag and it's nullptr. In either case, the transport broadcasts the packet.
Note that "broadcast" here means sending to NDN multicast group address, not the Ethernet broadcast address. It's called "broadcast" because semantically it's broadcasting to all NDN nodes.

esp8266ndn's EthernetTransport is an example of the expected semantics.

Actions #9

Updated by Junxiao Shi about 5 years ago

  • Blocks Feature #4281: Develop self-learning for broadcast and ad hoc wireless faces added
Actions #10

Updated by Junxiao Shi about 5 years ago

Actions #11

Updated by Davide Pesavento almost 4 years ago

  • Status changed from New to Rejected

A different design is being implemented.

Actions #12

Updated by Davide Pesavento almost 4 years ago

  • Blocks deleted (Feature #4281: Develop self-learning for broadcast and ad hoc wireless faces)
Actions

Also available in: Atom PDF