sajjad akbar <[email protected]> wrote: > Compression mechanism is still expensive for these low power networks, > Do you think its affordable trade off?
This is not a generic compression mechanism. It might look like:
IID = truncate-lower-61-bits(PRF(L2Key|PANID|16-bits-from-IPHC))
Where PRF is ideally some AES based thing that leverages the hardware.
The 16-bits-from-IPHC is essentially assigned in the same way as short
addresses are otherwise (by DHCPv6, by taking the last-2-bytes of EUI-64, or
brute force).
Maybe it needs to be reverseable: so that senders can compress IIDs in
destination addresses that they send to. But I think that maybe it's enough
if it's cachable. So that when a node sees the 16-bits, it caches the
resulting IID, and can then use that mapping the other way. 6LRs could
probably put the 16-bits as index to routing entry and avoid any
expansion/compression cycle.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
