Looking at contiki code [0], line 1582 onwards it looks to me like they process
fragmentation headers first and then could potentially process an uncompressed
IPv6 header.
[0] https://github.com/contiki-os/contiki/blob/master/core/net/ipv6/sicslowpan.c
Also I've just read in RFC 6282 on page 5 that
"
Section 5.3 of [RFC4944] <http://tools.ietf.org/html/rfc4944#section-5.3> also
defines how to fragment compressed IPv6
datagrams that do not fit within a single link frame. 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. This document does not change that
requirement. When using the fragmentation mechanism described in
Section 5.3 of [RFC4944] <http://tools.ietf.org/html/rfc4944#section-5.3>,
any header that cannot fit within the first
fragment MUST NOT be compressed.
"
my reading of this is that on tx if at the point of compressing the IPv6 header
it doesn't fit into 127 bytes then we should send the packet as uncompressed
IPv6 and then on receive we should process uncompressed IPv6 packets using
6LoWPAN fragmentation mechanism, or am I wrong in this?
-Martin.
On 24/07/14 13:30, Martin Townsend wrote:
> 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
------------------------------------------------------------------------------
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
