After considering how one might go about implementing
draft-ietf-6lo-fragment-recover, I came across a problem with the
fragment_offset field.
Since the value in the fragment_offset field is based on the compressed
version of a datagram, this field would potentially need to change for
all fragments of a single datagram as it traverses the network.
Consider a datagram of length L{D}. On the first hop the datagram is
compressed and fragmented into 2 fragments A and B with lengths L{A} and
L{B} respectively. The total length of the "compressed datagram" C is
therefore L{A} + L{B} = L{C}. It is also true therefore that the offset
of fragment B within the compressed frame is Offset{B} = L{A}
Assuming the datagram is being forwarded, the next hop would likely need
to re-compress the first fragment (because the link-layer addresses in
the 15.4 packet would change). In turn L{A} would also likely change to
L{A`}. This means that the frame_offset value in the second fragment
would no longer be correct, since Offset{B} != L{A`}.
As I see it, this problem makes the current draft unusable, because the
originator of the 6LoWPAN fragments can't allow for slack in the first
fragment to accommodate for re-compression changes at each subsequent hop.
In RFC4944, the datagram offsets were based on the uncompressed
datagram. This gave us two advantages:
1. The receiver of any fragment would immediately know what buffer size
to allocate to store the entire uncompressed datagram
2. The originator of the 6LoWPAN fragments would by default provide
slack in the first fragment for subsequent hops, because the offsets
of fragments were based on the uncompressed datagram.
Could the RFRAG format be changed so that fragment_offset be based on
the uncompressed datagram (similar to RFC 4944) or have I misunderstood
the draft?
Regards
Dario Tedeschi
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
