The main problems with the existing RFC4944 / HC-06 draft when the
compressed data can extend over more than one header are:-
(1) Detecting the subsequent fragments are compressed.
(2) That it is not possible to detect the final fragment by
(dgram_offset + fragment size == dgram_size).
These problems can solved by creating new dispatch codes.
We currently have 11 000 for first fragment FRAG1 and 11 100 for
subsequent fragments FRAGN. A new code can be created for a subsequent
fragment that contains compressed header information, e.g. 11 101 FRAGC.
The problem of detecting the final fragment does not occur for
implementations that use a bit map manager. A new final fragment code of
11 110 FRAGF can be added to assist implementations that detect the
final fragment by (dgram_offset + fragment size == dgram_size).
Changing the datagram_size and datagram_offset to refer to the
compressed rather than the uncompressed sizes causes the following
problems:-
(a) It would force major changes on existing implementations. It would
also completely break any compatibility with existing fragmentation code
which has already been developed by contributors on this list.
(b) It will make determination of whether a packet is complete more
difficult for implementations which use a bitmap based on uncompressed
offsets.
(c) Storing the entire packet before decode / forwarding should be an
implementation choice rather than something that is enforced because of
the way the standard is written. Copying from one buffer to another is
wasteful and not a luxury that an embedded engineer can count on, PC
implementations aren't going to feel the pain in the same way. It is
important that 6LP can be implemented in real-time with a minimum of
buffer copies - all that is needed is a buffer capable of storing 2 (or
more) fragments to get the system working when header creep is detected.
When forwarding packets, a router node may need to deal with several
packets at once and may not have space to fully buffer each IP datagram.
(d) In the most common case, there is only fragmentation in the first
header and then many fragments of uncompressed UDP payload. The
existing method of specifying the uncompressed offset allows this UDP
payload to be stored in the correct location as the incoming data arrives.
(e) Forwarding unknown headers through router nodes in a route over
implementation can be solved whether the length and offset are stored
compressed or uncompressed. There are different advantages in this case
with either method so we shouldn't let this cloud the issue.
(f) Not knowing the full uncompressed datagram size until the entire
packet has been decoded also has implications for ICMP error handling,
e.g. MTU exceeded.
Daniel.
__________________________________________________
Daniel Gavelle, Software Engineer
Tel: +44 114 281 2655
Fax: +44 114 281 2951
Jennic Ltd, Furnival Street, Sheffield, S1 4QT, UK
Comp Reg No: 3191371 Registered In England
http://www.jennic.com
__________________________________________________
Richard Kelsey wrote:
Date: Tue, 16 Feb 2010 13:04:53 -0800
From: Owen Kirby <[email protected]>
However, I suspect that this assumption is no longer true
in the case of the draft header compression. Especially
now that IPv6 extension headers can be compressed (what do
we do if ROLL adds ~160 bytes of routing headers to a
packet?).
Owen,
A long source route could quite possibly push the transport
header into the second fragment.
[...] We get stuck in a catch-22: can't
defragment until after decompression, but can't decompress
until after defragmentation.
[...] It also becomes necessary to store the state of your
decompressor across multiple packets, which can get very ugly if header
fields get split across fragments.
Either one of your recommended solutions would work, but if you want to
include the total number of fragments I would recommend that each packet
should also be identified by a sequence number. A simple, but less
efficient solution, could also be to simply state that any headers which
extend past the first fragment after compression should not be compressed.
This could be tricky because the size of the compressed IP
header and the MAC addressing and security overhead can
change hop-by-hop. What was in the first fragment on the
first hop may not be in the first fragment on a subsequent
hop, which causes a problem if the forwarding node does
not know how to uncompress the entire packet.
I think that the best solution would be to switch to using
the compressed size and offsets in the fragment headers.
This would allow (un)compression and (de)fragmentation to
be done independently.
Also, as the author of the 6LoWPAN dissectors for Wireshark, I'm pulling
my hair out trying to find a way to implement this without throwing away
all of Wireshark's reassembly support and starting from scratch, or
implementing some sort of wild speculative guessing.
Would using the compressed size and offsets in the fragment
headers solve this?
-Richard Kelsey
----------------
This message and the information it contains are the proprietary
and confidential property of Ember Corporation and may be privileged.
If you are not the intended recipient, please do not read, copy,
disclose or distribute its contents to any party, and notify the
sender immediately.
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
--
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
