Richard and Owen,
I think that the best solution would be to switch to using
the compressed size and offsets in the fragment headers.
This would allow (un)compression and (de)fragmentation to
be done independently.
I absolutely agree.
I agree.
I think it should be simplified further by making datagram_offset 11bits
long. Having datagram_offset as 8bits (forcing fragment length to a
multiple of 8) may save 1 byte, but it also means that up to 7 bytes at
the end of a fragment can be left unused (save 1 byte to, potentially,
lose 7). So how about a new fragmentation header where both
datagram_size and datagram_offset are 11bits and the datagram_tag is
reduced to 13bits (how big does the tag need to be anyway). A new
dispatch pattern would indicate a new fragmentation header where _offset
and _size are relative to the compressed datagram. Something like the
following:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5
6 7 8 9
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 1 1| datagram_size | datagram_tag |
datagram_offset |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
From an implementation point of view, bits 0 to 28 can be used as a
pseudo tag in identifying fragments that belong to one datagram. It
could be stored in 4 bytes with the last three bits of the last byte
masked out, but that's just an idea for trying to be a little more
efficient.
Regards
Dario
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
