Following Martine’s questions, please find proposed additions or updates to the
minimal fragment draft:
Before:
“
Conceptually, a reassembly buffer for 6LoWPAN contains:
o a datagram_size,
o a datagram_tag, associated to the link-layer sender and receiver
addresses to which the datagram_tag is local,
o the actual packet data from the fragments received so far, in a
form that makes it possible to detect when the whole packet has
been received and can be processed or forwarded,
o a timer that allows discarding a partially reassembled packet
after some timeout.
“
After
“
The reassembly buffer for 6LoWPAN is indexed in node B by
- a unique Identifier of Node A (e.g., Node A's link-layer address)
- the datagram_tag chosen by node A for this fragmented datagram
Because it may be hard for node B to correlate all possible link-layer
addresses that node A may use (e.g., short vs. long addresses), node A MUST use
the same link-layer address to send all the fragments of a same datagram to
node B.
Conceptually, the reassembly buffer in node B contains, assuming that node B is
neither the source or the final destination:
- a datagram_tag as received in the incoming fragments, associated to
link-layer address of node A to which the received datagram_tag is local,
- the link-layer address that node B uses to forward the fragments
- the link-layer address of the next hop that is resolved on the first fragment
- a datagram_tag that node B allocated for this datagram and that is used when
forwarding the fragments of the datagram
- the actual packet data from the fragments received so far, in a form that
makes it possible to detect when the whole packet has been received and can be
processed or forwarded,
- a datagram_size,
- a buffer for the remainder of a previous fragment left to be sent,
- a timer that allows discarding a partially reassembled packet after some
timeout.
“
And later:
Before
“ 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.
“
After
“
Each datagram can be uniquely identified by the sender link-layer addresses of
the frame that carries it and the datagram_tag that the sender allocated for
this datagram.
“
Please let me know if you see an issue with that. I wish to publish soon as we
enter the IESG review for this spec.
All the best,
Pascal
From: 6lo <[email protected]> On Behalf Of Pascal Thubert (pthubert)
Sent: vendredi 30 août 2019 13:44
To: Martine Lenders <[email protected]>; [email protected]
Subject: Re: [6lo] Question on draft-ietf-6lo-fragment-recovery and VRB
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
