Hi Carsten,
That means you need a second table of datagram_tag values “already seen and
done” (obviously with a timeout, or maybe with some serial number logic).
Maybe not a bad optimization to handle trailing duplicates.
Yes, some mechanism to track datagram_tag is needed, which is implied by
draft-ietf-6lo-minimal-fragment-00:
[From Section 1, draft-ietf-6lo-minimal-fragment-00]
Node B's typical behavior, per [RFC4944], is as follows. Upon
receiving a fragment from node A with a datagram_tag previously
unseen from node A, node B allocates a buffer large enough to hold
the entire packet.
Since datagram_tag is expected to be incremented (by one) as RFC4944
specifies, holding the last datagram_tag per peer may be enough,
although this kind of thing could be "implementation-specific":
[Section 5.3, RFC4944]
datagram_tag: The value of datagram_tag (datagram tag) SHALL be the
same for all link fragments of a payload (e.g., IPv6) datagram.
The sender SHALL increment datagram_tag for successive, fragmented
datagrams. The incremented value of datagram_tag SHALL wrap from
65535 back to zero. This field is 16 bits long, and its initial
value is not defined.
Best,
Yatch
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
