This is my understanding which may be totally wrong by the way :) 4944 defines a header stack of
mesh header broadcast header fragmentation header which encapsulate the LoWPAN payload. We don't support the first 2 so we have only have a fragmentation header that allows link layer fragmentation of a layer 3 datagram (IPv6 packet) or the LoWPAN payload. This LoWPAN payload can contain an IPv6 with an uncompressed or compressed header as defined by the dispatch byte. So to summarise each of the mesh, broadcast and fragmentation header have a dispatch byte which is like the next header in IPv6 so after processing each header you look at the dispatch byte to see what the next header is. Once all have been processed and the packet has been potentially reassembled you are left with the IPv6 payload which also has a dispatch byte to indicate whether it's uncompressed or compressed with whatever compression is indicated. -Martin. On 24/07/14 11:44, Alexander Aring wrote: > Martin, > > On Thu, Jul 24, 2014 at 11:17:48AM +0100, Martin Townsend wrote: >> It's doesn't specifically say you can, but then again it doesn't >> specifically say you can't, it's just my interpretation :) >> It makes sense that you would only send uncompressed if the packet is small >> anyway so I'll park this one unless we find a 6lowpan implementation that >> does this. >> > you said that it's also possible that we send uncompressed header WHILE > fragmentation. But I don't see this, where do you read this in rfc4944? > Maybe I don't see it. > > What I mean there exist a way in non fragmented packet and a > uncompressed header. My last mail describes about the dispatch value > "IPv6", see [0]. > > If we get a "FRAG1" dispatch value then it can't be a "IPv6" dispatch > value, because this value is "FRAG1". It's really necessary to know > that, we should not handle this in the sending part, but very IMPORTANT > is to handle it at RECEIVING part, otherwise we are not RFC complaint. > For me it looks like that 6lowpan packets which have "FRAG1" as dispatch > value are always compressed. > > > > I mean in my last mail is that we handle uncompressed NOT > fragmented 6lowpan packets only at receiving part to be rfc complaint. > We don't do this at sending side and this is part of design (too see > what is better or make it user accessible to decide if we do that or > not) but only on sending part. At receiving part we MUST handle it. > > - Alex > > [0] http://tools.ietf.org/html/rfc4944#section-5.1 ------------------------------------------------------------------------------ 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
