Task #4282
closedRename LinkType constants
Added by Junxiao Shi about 7 years ago. Updated over 1 year ago.
0%
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.
Updated by Junxiao Shi about 7 years ago
- Blocks Feature #4281: Develop self-learning for broadcast and ad hoc wireless faces added
Updated by Alex Afanasyev about 7 years ago
This deserves a discussion before doing any change
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"?
Updated by Junxiao Shi about 7 years ago
- Blocked by Feature #3967: "ad hoc" property on multi-access face added
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.
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?
Updated by Davide Pesavento over 6 years ago
- Assignee deleted (
Yanbiao Li) - Target version deleted (
v0.7)
Updated by Davide Pesavento over 4 years ago
- Blocks deleted (Feature #4281: Develop self-learning for broadcast and ad hoc wireless faces)
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.