Hi Julien,
Fixing UDP compression was definitely on the list of TODOs.
So there are a few options:
1) Expand the compressed range to 256 ports (the encoding lengths for
the ports are then 2, 3, or 4 bytes).
2) When compressing only one port, add a 4-bit pad as you suggest.
However, I would rather add the 4-bit pad to be with the 4-bit
compressed port and keep the 16-bit uncompressed port byte-aligned
(the encoding options would be 1, 3, or 4 bytes).
3) A hybrid of the two: When only one port is compressed, the
compressed form is 8 bits (don't waste the 4 bits on padding). But
when both ports are compressed, both only 4 bits.
00 - Neither source nor dest are compressed
01 - Source port uncompressed, dest port 8 bits.
10 - Source port 8 bits, dest port uncompressed
11 - Source port 4 bits, dest port 4 bits.
Basic question to ask the group is if compressing both source and dest
ports to 4 bits simultaneously useful?
--
Jonathan Hui
On Oct 8, 2008, at 2:22 AM, Julien Abeille (jabeille) wrote:
Hi Jonathan, all,
one comment regarding hc-01 LOWPAN_UDP encoding
for now source and destination ports compression are splitted. It
means if only one of them is compressed, the UDP compressed fields
will be 36 bits long (4bits port + 16 bits port + checksum). We lose
byte alignment this way.
to avoid this, you could either not split the compression of ports,
or when only one is compressed, pad to 3bytes (4 bits port + 16 bits
port + 4bits padding)
What do you think?
Cheers,
Julien
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
