Project

General

Profile

Actions

Task #4282

closed

Rename LinkType constants

Added by Junxiao Shi over 7 years ago. Updated over 1 year ago.

Status:
Abandoned
Priority:
Normal
Assignee:
-
Category:
Protocol
Target version:
-
Start date:
Due date:
% Done:

0%

Estimated time:
3.00 h

Description

FaceMgmt defines three LinkType values: point-to-point, multi-access, and ad hoc.
However, the semantics of "multi-access" and "ad hoc" are ambiguous.
They should be renamed to "broadcast" and "ad hoc wireless" to be more explicit.

This task includes renaming in management protocol, implementation, nfdc face output, and NFD devguide.


Related issues 1 (0 open1 closed)

Blocked by NFD - Feature #3967: "ad hoc" property on multi-access faceClosedTeng Liang

Actions
Actions #1

Updated by Junxiao Shi over 7 years ago

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

Updated by Alex Afanasyev over 7 years ago

This deserves a discussion before doing any change

Actions #3

Updated by Teng Liang about 7 years ago

Junxiao Shi wrote:

FaceMgmt defines three LinkType values: point-to-point, multi-access, and ad hoc.
However, the semantics of "multi-access" and "ad hoc" are ambiguous.
They should be renamed to "broadcast" and "ad hoc wireless" to be more explicit.

This task includes renaming in management protocol, implementation, nfdc face output, and NFD devguide.

First, FaceMgmt is not updated for the "ad hoc" link type. The NFD developer guide is updated but not released yet.

Just to point out that in wireless networks, NFD can have a point-to-point face with point-to-point link type. Though it is shared medium, people can virtually set up links among nodes with the help of unicast MAC addresses.

In a wired shared medium such as Ethernet, a node receives a packet and this packet is also received by other nodes on the same shared medium, thus NFD will not send the packet back to the incoming face. However in a wireless shared medium, a node receives a packet receives a packet, but it is often not received by all the nodes on the same shared medium, so the node needs to send the packet out to the shared medium again (which can be the incoming face). Thus the difference is whether it is wired or wireless.

How about "wired multi-access" and "wireless multi-access"?

Actions #4

Updated by Junxiao Shi about 7 years ago

  • Blocked by Feature #3967: "ad hoc" property on multi-access face added
Actions #5

Updated by Junxiao Shi about 7 years ago

First, FaceMgmt is not updated for the "ad hoc" link type.

It should have been. I'm reopening #3967.

The NFD developer guide is updated but not released yet.

As far as I'm concerned, an NFD devguide change becomes effective as soon as it's pushed to the repository.

Just to point out that in wireless networks, NFD can have a point-to-point face with point-to-point link type. Though it is shared medium, people can virtually set up links among nodes with the help of unicast MAC addresses.

Such point-to-point faces should not be used. Instead, both broadcast and ad hoc wireless faces can have unicast capability. See #4283.

In a wired shared medium such as Ethernet, a node receives a packet and this packet is also received by other nodes on the same shared medium, thus NFD will not send the packet back to the incoming face.

This isn't a property of all wired networks. In a long distance wired network such as one formed by connecting kilometers of telephone lines together, the signal mighht be able to reach a recipient 3KM away but not a recipient 6KM away. In this case, the face would be "ad hoc wireless" despite the connection is actually wired.
The term "wireless" in "ad hoc wireless" is there because the majority of faces that may need relaying are wireless. Just "ad hoc" is too ambiguous.

However in a wireless shared medium, a node receives a packet, but it is often not received by all the nodes on the same shared medium, so the node needs to send the packet out to the shared medium again

This isn't a property of all wireless networks. In infrastructure mode WiFi, a station receiving a packet with broadcast destination address may assume it has been received by all other stations.

How about "wired multi-access" and "wireless multi-access"?

No as described above.

Actions #6

Updated by Teng Liang about 7 years ago

Just to point out that in wireless networks, NFD can have a point-to-point face with point-to-point link type. Though it is shared medium, people can virtually set up links among nodes with the help of unicast MAC addresses.

Such point-to-point faces should not be used. Instead, both broadcast and ad hoc wireless faces can have unicast capability. See #4283.

This requires discussion: whether "broadcast" faces should have unicast capability?
The alternative is to create separate point-to-point faces, which you think will bring more overhead in terms of face management (#4283-#3).

In a wired shared medium such as Ethernet, a node receives a packet and this packet is also received by other nodes on the same shared medium, thus NFD will not send the packet back to the incoming face.

This isn't a property of all wired networks. In a long distance wired network such as one formed by connecting kilometers of telephone lines together, the signal mighht be able to reach a recipient 3KM away but not a recipient 6KM away. In this case, the face would be "ad hoc wireless" despite the connection is actually wired.
The term "wireless" in "ad hoc wireless" is there because the majority of faces that may need relaying are wireless. Just "ad hoc" is too ambiguous.

However in a wireless shared medium, a node receives a packet, but it is often not received by all the nodes on the same shared medium, so the node needs to send the packet out to the shared medium again

This isn't a property of all wireless networks. In infrastructure mode WiFi, a station receiving a packet with broadcast destination address may assume it has been received by all other stations.

Can you give a defination or description of the "broadcast" face?

Actions #7

Updated by Davide Pesavento over 6 years ago

  • Assignee deleted (Yanbiao Li)
  • Target version deleted (v0.7)
Actions #8

Updated by Davide Pesavento over 4 years ago

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

Updated by Davide Pesavento over 3 years ago

  • Tags set to needs-discussion
Actions #10

Updated by Junxiao Shi over 1 year ago

  • Status changed from New to Abandoned

This was originally Beichuan's idea.
Since it is unlikely to ever have a consensus on this change, I am abandoning this issue.

Actions

Also available in: Atom PDF