Hi, I have an implementation question for the virtual reassembly buffer with regards to [draft-ietf-6lo-fragment-recovery]. Section 6.1 of this draft states that a tuple (source address, tag) is used to identify a VRB entry and cites [draft-ietf-6lo-minimal-fragment] for that. However, as far as I understand [draft-ietf-6lo-minimal-fragment] and [draft-ietf-lwig-6lowpan-virtual-reassembly] this is not the case. [draft-ietf-6lo-minimal-fragment] doesn't mention VRB entry identification and only refers to [draft-ietf-lwig-6lowpan-virtual-reassembly]. That in turn only recounts the classic (source address, destination address, size, tag) tuple defined in RFC4944 and states that the only difference between the classic and VRB is the lack of the reassembled packet and addition of the next hop's address and the newly assigned tag:
To reduce the memory requirement for reassembly buffers, the implementation > may opt to not keep the actual packet data in the reassembly buffer. > Instead, it may attempt to send out the data for a fragment in the form of > a forwarded fragment, as soon as all necessary information for that is > available. Obviously, all fragments need to be sent with the same outgoing > address (otherwise a full reassembly implementation would discard the > fragments) and the same datagram_tag. So my question is: Is the tuple definition in [draft-ietf-6lo-fragment-recovery] really correct? For exclusion datagram size I agree that it could be somewhat redundant. However, a node could have multiple destination addresses (either via multiple interfaces or IEEE-802.15.4-style short and long address). So, as the tag is link-specific (defined by a (source, destination) tuple), there could be distinct datagrams that have the same tuple (source, tag), or am I missing something? I already implemented the VRB with draft-ietf-6lo-minimal-fragment in mind and thus used the classic 4-tuple for indexing. But now I'm wondering: Can I reduce its index or would that be not advised? Kind regards, Martine
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
