The ID explains how the slots are created from a hash of MAC address:
Receiver-based slotframe: Nodes have one receive (option Rx) cell at
coordinates derived from a hash of their MAC address. For
transmitting to a given neighbor, nodes maintain a cell (options
Tx, Shared) at coordinates derived from a hash of the neighbor's
MAC address. For instance, a node may maintain such a transmit
cell for each known neighbor in the IPv6 NDP cache, or to a subset
such as the RPL preferred parent(s) or TSCH time source(s).And this makes lots of sense to me, if the MAC addresses are uniformly distributed EUI-64 based addresses.... Much less so if the addresses are 2-byte addresses assigned by a Join Coordinator. While nodes have EUI-64 address built-in (I am still uncertain, btw, in the 6lo context if an ND can discover both long and short L2 addresses...) and they could use it, it isn't clear that nodes will know the long address of all neighbors. So I wonder some things: 1) a naive Join Coordinator will hand out incrementing short addresses. Nodes closer to the J(R)C will get lower numbers, and be higher in the LLN mesh. What happens to the simulation if the addresses are skewed in this fashion? 2) can the JRC hand out short addresses in a way that benefits ASF? 3) could/should the RPL rank be incorporated in some way into the hash? -- Michael Richardson <[email protected]>, Sandelman Software Works -= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6tisch mailing list [email protected] https://www.ietf.org/mailman/listinfo/6tisch
