Re: [6lo] Question on draft-ietf-6lo-fragment-recovery and VRB

[Martine Lenders <[e-mail]>]

Thanks for your quick response!

Cheers,
Martine

Am Fr., 30. Aug. 2019 um 13:44 Uhr schrieb Pascal Thubert (pthubert) <
[e-mail]>:

> Hello Martine
>
>
>
> Great to hear about your implementation. The group is interested to learn
> about your progress (keep us tuned) and happy to help you through. P
>
> lease do not hesitate to ask for more clarification as you feel needed.
> Even if you’re not too sure you should ask, if you wonder there’s probably
> a reason and you’re helping the implementors who will be following you.
>
>
>
> Please see below:
>
>
>
> 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.
>
> Ø    Correct, and the meaning is source MAC address not source IP
> address. The exact sentence is
>
> Ø                                       Upon a first fragment (i.e. with a
>
> Ø     sequence of zero), a VRB and the associated LSP state are created for
>
> Ø     the tuple (source MAC address, datagram_tag) and the fragment is
>
> Ø     forwarded along the IPv6 route that matches the destination IPv6
>
> Ø     address in the IPv6 header as prescribed by
>
> Ø     [I-D.ietf-6lo-minimal-fragment <https://tools.ietf.org/html/draft-ietf-6lo-fragment-recovery-05#ref-I-D.ietf-6lo-minimal-fragment>].
>
> Ø
>
> 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].
>
>    - It would not hurt to mention it though. Interesting. Minimal has:”
>    All fragments are tagged with a 16-bit
>
>    "    Each datagram can be uniquely identified by the source and final
>
>    destination link-layer addresses of the frame that carries it, the
>
>    fragment size and the datagram_tag.
>
>
>
> Ø    That’s  misleading… I’ll correct it.
>
> That in turn only recounts the classic (source address, destination
> address, size, tag) tuple defined in RFC4944
>
>    - When receiving a fragment, the destination is self and the size may
>    vary from a datagram to the next. So the only thing that really identify
>    the datagram is the source MAC and the tag.
>
> 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:
>
> Ø    Actually the forwarder sends the datagram with self as source to the
> source mac address is swapped naturally. It has to set the next hop’s mac
> address and the swapped datagram tag. The next hop’s MAC address identifies
> the node that should receive the packet and the datagram tag together with
> the source mac identify the reassembly buffer within the receiver. There is
> no contradiction.
>
> 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?
>
>
>
>    - It is.
>
>
>
> 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?
>
>
>
> Ø    Yes, the role of the destination MAC address is to reach the next
> hop, but does not change the processing within that node. I could change
> the L2 address I use to refer to the next hop in the middle of a fragmented
> packet, it is still the same fragmented packet. In other words, please do
> not use the dmac as to index the VRB. From your question I think the LWIG
> draft should clarify, and we can change minimal draft to clarify as well.
>
>
>
> 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?
>
>
>
> Ø    You should reduce the index : ) There can not be 2 different
> datagrams coming in parallel from a same previous hop and with a same
> datagram tag. There must be a sentence somewhere in the LWIG draft that
> says that a new and currently unused datagram tag is chosen for a new
> incoming datagram, correct?  Minimal says
>
> Ø                                                                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.
>
>
>
> Ø    This text only indexes the VRB with any identifier of node A and the
> tag… And this is correct. What’s a bit more ugly is that Node A should not
> change the source MAC in between fragments because that will confise node
> B. I need to add text on that too.
>
>
>
>
>
> Many thanks Martine for raising all this, and all the best for your
> implementation.
>
>
>
> Pascal
>