You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Currently the design is that every node has its own node_id. The IID used at the link layer corresponds to this node_id .. Thus in Airline when a packet is received we derive the node_id from the MAC address's dest_addr.
Reasons for supporting any IIDs in Airline/stackline?
In case of OpenThread, the nodes might use combinations of short/long address modes and randomized IIDs.
There are possibilities of implementations using randomized IIDs even in contiki/riot.
Anyways the design decision to tie node_id and IID was not a good one and hence should be changed.
How to implement?
Stackline can register there extended and short address to the Airline. Openthread already has a mechanism to register these addresses. In context of contiki/riot, the shim layer can take care of this.
Airline on receiving packets can match against these addresses. Note addresses can be more than one.
Also in some cases (for e.g. openthread), the MAC header framing is done in Openthread internally. So Airline will receive an mbuf with 802154 header. Thus Airline needs to support only LLC layer and below in such case.
The text was updated successfully, but these errors were encountered:
Currently the design is that every node has its own node_id. The IID used at the link layer corresponds to this node_id .. Thus in Airline when a packet is received we derive the node_id from the MAC address's dest_addr.
Reasons for supporting any IIDs in Airline/stackline?
How to implement?
The text was updated successfully, but these errors were encountered: