On Thu, Jul 24, 2014 at 09:57:12PM +0100, Martin Townsend wrote: > 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
Yes, the datagram_size and datagram_offset refers ALWAYS to uncompressed size. Doesn't matter if compressed or not. And that's the current beheaviour what we do. Assumption: If a compressed packet doesn't fit into FRAG1 then you can't uncompress after receiving FRAG1 on the fly and the implementation would be harder. Also the fragmentation is a very poor mechanism you receive FRAG1 and you don't know if you get next fragment, which would be necessary for a uncompression. But if the compression headers doesn't fit in FRAG1, then we never use compression and this makes the life much easier, because we can simply put the fragments in the fragments bucket(that's the offical linux kernel name for the datastructure). I try to see the things from the IETF people side, only. This helps us to get implementation ideas. :) > " > > 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? This is inperformant, currently. If we receive FRAG1 then we need to calculate the the real size of package to estimate the real size. If you are working on receiving fragmented packets which are not compressed you need to change that(evaluate the dispatch value). See [0]. That's needed to finding the end if (fq->q.meat == fq->q.len). Then afterwards we do the uncompression. It's better to replace the real size calculation and doing uncompression on the fly there. But the current implementation of the shared iphc code doesn't allow this. We need to change the bluetooth 6lowpan stack also for this. When I did this I want first a basically fragmentation implementation that works, the FRAG1 on-the-fly uncompression was a idea there. But it was another problem to change others 6LoWPAN implementations so I did a workaround solution and put it on the todo list. It should easy to change the implementation according to this that we have a on the fly uncompression after receiving FRAG1, then the real size is known. Conclusion: Yes, we need a more generic iphc implementation. But there are also some ugly places there. I have patches in for-martin branch and some local branches but I need to wait until the movement patch is in net-next. [0] https://github.com/linux-wpan/linux-wpan-next/blob/master/net/ieee802154/reassembly.c#L208 - Alex ------------------------------------------------------------------------------ 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
