On Feb 20, 2010, at 15:14, Richard Kelsey wrote:
>> From: Carsten Bormann <[email protected]>
>> Date: Sat, 20 Feb 2010 08:19:17 +0100
>>
>> On Feb 19, 2010, at 20:41, Dario Tedeschi wrote:
>>
>>> compressed headers spanning multiple RFC4944 fragments
>>> presents huge complexities in re-assembly
>>
>> My first reaction would be "don't do that, then!".
>> (http://catb.org/jargon/html/D/Don-t-do-that-then-.html)
>
> Even if I don't do it, how can I be sure that no one else
> will?
By dropping their packets.
(Seriously.)
> In the absence of any indication one way or the
> other in 4944,
I'm reading this text/figure in section 5 as pretty strong support:
A LoWPAN encapsulated LOWPAN_HC1 compressed IPv6 datagram that
requires fragmentation:
+-----------+-------------+--------------+------------+---------+
| Frag Type | Frag Header | HC1 Dispatch | HC1 Header | Payload |
+-----------+-------------+--------------+------------+---------+
Apart from that, 4944 simply does not say you *can* do it.
It would have to, because it would have to define the semantics of
"datagram_offset" for this specific case; the current text in 4944 clearly
assumes that additional fragments only carry payload.
The new HC of course can simply make it more explicit you can't continue
compressed headers into the additional fragments; that would be one WGLC
comment that could come out of this discussion.
> My one concern would be source routes, which are eminently
> suitable for compression and even when compressed could
> conceivably extend into the second fragment. It would be a
> shame to be able to compress short source routes but not
> long ones.
It may be worthwhile to compress source routes as part of the HC payload, not
in HC itself.
But then again, I find it weird to spend work to accommodate fragmentation of
routing headers (more precisely: to make that case. of splitting into
multi-frame packets just for routing, more efficient -- you can always choose
to not compress!).
Fragmenting for routing goes against a lot of things that 6lowpan stands for.
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
