On 24/07/14 17:56, Alexander Aring wrote:
On Thu, Jul 24, 2014 at 06:46:10PM +0200, Alexander Aring wrote:
When using the fragmentation mechanism described in
Section 5.3 of [RFC4944], any header that cannot fit within the first
fragment MUST NOT be compressed.
Any header == sum of headers.
Maybe they mean to cover further application headers that can be compressed.
Look at the draft GHC spec for instance.
But we don't support these right now and on the receiving side it should
be okay to check if a fragmented 6LoWPAN header is compressed or not.
It's simple to check on IPHC or IPv6 dispatch value after fragmentation.
are more than the MTU of the device sending the packet, for us 127 MTU of
the 802.15.4 device. ie the sum of all the MAC headers/6 LoWPAN headers
and the compressed IPv6 header > 127.
Okay, I agree. That makes more sense, but when could happen this?
Not sure, what about ipv6 options?? again maybe they are future proofing
for future compression algorithms like GHC.
I think they mean all header MAC + 6LoWPAN and NHC (next header
compression). The only one NHC which we support is UDP at the moment.
I have a possible reason because this. Normally if we get FRAG1 we can
run decompression of HEADER on the fly after receiving FRAG1, but this
assumes we need to know that the whole compressed header is in FRAG1.
True, but I think the reason that all compressed headers must fit in the
first fragment is that the datagram size and offset in the fragment
header refer to the uncompressed size and offset in the uncompressed
packet. So all FRAGN fragments must contain uncompressed data.
Again from 6282
"
Section 5.3 of
[RFC4944] <http://tools.ietf.org/html/rfc4944#section-5.3> defines the
fragment header's datagram_size and
datagram_offset values as the size and offset of the IPv6 datagram
before compression. As a result, all fragment payload outside the
first fragment must carry their respective portions of the IPv6
datagram before compression."
Now the RFC6282 says that, otherwise it's not compressed, which is
great. If this would be compressed we can't decompress the IPHC on the
fly after receiving FRAG1.
At the moment we don't do that because it was simpler to implement it
not on the fly, but in the future we should decompress the header after
receiving FRAG1. I already thought about that.
Out of interest, why would you want to decompress FRAG1 early?
- Alex
- Martin.
------------------------------------------------------------------------------
Want fast and easy access to all the code in your enterprise? Index and
search up to 200,000 lines of code with a free copy of Black Duck
Code Sight - the same software that powers the world's largest code
search on Ohloh, the Black Duck Open Hub! Try it now.
http://p.sf.net/sfu/bds
_______________________________________________
Linux-zigbee-devel mailing list
Linux-zigbee-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/linux-zigbee-devel
