> 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. If it were possible to
guarantee that no compressed header would ever extend into
the second fragment, then future compatibility would not be
a problem. A relaying node could treat any unknown
compressed header as if it and all subsequent headers were
uncompressed. As long as compression only occured in the
first fragment the second fragment's offset would be
correct.
Similarly, if all relayed messages could be completely
uncompressed, we could mandate that compressed headers must
never extend into the second fragment. A relaying node
would stop compressing when it reached the end of the first
outgoing fragment.
The rub is that we can't enforce the requirement in
precisely the case where it matters, which is when a
relaying node gets a header that it doesn't know how to
uncompress. The boundary between the first two fragments
can move a lot from one hop to another, especially with
anything like RPL's piecewise source routes in use. If a
relay gets an unknown compressed header and has to add, say,
an eight-hop source route, what can it do? How can it
know that it hasn't pushed part of the compressed header
into the second fragment?
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?
-Richard Kelsey
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
