On Feb 20, 2010, at 6:48 AM, Richard Kelsey wrote:
From: Jonathan Hui <[email protected]>
Date: Sat, 20 Feb 2010 00:42:57 -0800
On Feb 19, 2010, at 11:19 PM, Carsten Bormann wrote:
I don't think that 4944 specifies anything that lets you have the
compressed header extend beyond the first frame.
I'm not sure we explicitly discussed this, but certainly I didn't
see a need.
If we now do, I'd like to first learn more about this use case.
I'm not convinced of this use case either and I'm fine with limiting
use of IPHC/NHC to the first fragment.
Richard's future-compatibility case that he spawned this thread with
is more important to consider.
The two issues are related.
[... Richard's explanation of how the issues are related ...]
Yes, I agree they are related. But I find it more useful to think of
it as a forward-compatibility issue. Note that RFC 4944 did not allow
any kind of forward compatibility. If you need to insert a routing
header, the encoding of Section 10 of RFC 4944 would require expansion
of any compressed UDP/ICMPv6/TCP headers. Because 6lowpan-hc
decouples the encoding for each individual header, we now have the
chance to start considering forward compatibility for higher-layer
headers. If we were to continue the limitations implicitly defined by
RFC 4944, then there would be no fundamental flaws in the
fragmentation mechanism to talk about.
The use of the compressed offsets in the fragment headers
introduces a number of complicated layering issues. It
makes fragmentation and compression interdependent. It
makes relaying nodes process transport headers. It
interacts with the use of routing headers. What benefits
does it bring that make it worth all of the headaches?
I think you meant to say "The use of *uncompressed* offsets". I
completely agree and I noted the same layering/dependency issues in an
earlier mail. Viewing the fragmentation payload as opaque would
eliminate these dependencies. Carsten suggested that we could treat
higher-layer compression as payload of 6lowpan-hc (rather than as a
part of), but that would eliminate any benefit from using uncompressed
offsets.
Regardless of what we decide to do with the fragmentation header, I
would really like to see a clean separation between fragmentation and
header compression. Note that saying "compressed offsets/lengths" is
a bit of a misnomer. It's better to say that offsets and lengths
simply reflect the actual payload being fragmented (which may or may
not use header compression).
--
Jonathan Hui
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
