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 

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

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 <>, Sandelman Software Works
 -= IPv6 IoT consulting =-

Attachment: signature.asc
Description: PGP signature

6tisch mailing list

Reply via email to