Richard,
Richard Kelsey wrote:
Date: Tue, 16 Feb 2010 13:04:53 -0800
From: Owen Kirby <[email protected]>
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.
Perhaps I could use a little clarification on how reassembly and
forwarding would work in a 6LoWPAN mesh. Please correct me if I've
gotten anything wrong here.
In a route-over network, the IPv6 packet would need to be reassembled
and decompressed at every hop to decrement TTL and check the routing
headers. In this case, the forwarding node has control over all of the
fields and can change a compressed field into an uncompressed field (and
vice-versa) for the next hop in the route. As I suggested, this is not
the most efficient solution, but it works and requires the least amount
of change from what's in the RFC.
In the mesh-under case, the fragments get routed across the network
using the mesh routing header in RFC4944, and reassembly only happens at
the packet's final destination, the contents of the fragments can't be
modified in-flight anyways, so I don't see how this would cause a
problem, and changes in the MTU are something that the source would need
to allow for anyways.
FWIW, all of the 6LoWPAN implementations I know of work on the
assumption that compressed headers are always contained within the first
fragment only.
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.
I absolutely agree.
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?
Yes, this change would be very easy to implement.
Thanks,
Owen Kirby
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
