Thanks for your quick response! Cheers, Martine
Am Fr., 30. Aug. 2019 um 13:44 Uhr schrieb Pascal Thubert (pthubert) < [email protected]>: > 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 >
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
