Pascal Thubert (pthubert) <[email protected]> wrote: > Fragment_offset: 11 bit unsigned integer; when set to 0, this field > indicates an abort condition; else, its value depends on the value > of the Sequence. When the sequence is not 0, this field indicates > the offset of the fragment in the compressed form. When the > sequence is 0, denoting the first fragment of a datagram, this
> reword. I think it means:
> if Sequence > 0; fragment_offset == 0 => abort.
> ; else offset of fragment
> if Sequence ==0; fragment_offset is total size of datagram.
> --------------------
> [Pascal] This is effectively a big stone you are unturning. The intent
> of the initial logic is:
> If fragment_offset == 0; forward of you can and cleanup (aka abort)
> ; else
> if Sequence ==0; fragment_offset is total size of datagram
> ; else fragment_offset is offset in the datagram in octets
> [Pascal] With the current text (sequence, offset) tuple of (0, 0) is
> significant whereas with your proposal, this tuple becomes a protocol
> error. Either way, we probably need some more text what nodes should do
> in that case. I'm not too much in favor of creating an error case;
> error flows have a tendency to not perform well.
I wasn't suggesting to change the protocol, I was trying to explain it.
I clearly did not understand it!
> [Pascal] Let's consider this: (0,0) could be useful, because it carries
> the original IP header so there's a chance it goes all the a to the
> reassembly end point even if the forwarding state is broken midway;
> this could be important because the end point is where the buffers are
> wasted. And because it may be routed differently than a previous (0,
> X>0), a (0, 0) may fail to clean up state along the old path even when
> the old path is not broken. We'll note that the old path may be cleanup
> all the way back (to the breakage if there's one) by a reset message
> from the end point. That reset message could be stimulated by receiving
> a (0, 0). But with the 6LoWPAN signaling as it stands now, the end
> point may not recognize that this is the same IP packet because the
> datagram tags would possibly be different, being switched differently
> along different routes. If we care to take that path, we need the end
> points to exchange end-to-end IDs for the flows. Doable but
> expensive. Worth it?
I think you've jumped ahead of me.
You are talking about a way to clean up state given multiple possible paths.
I'm just barely at the point where I can understand how the state is
created :-)
> section 5 says:
> The process ensures that at every hop, the source
> MAC address and the datagram_tag in the received fragment are enough
> information to send the RFRAG Acknowledgment back towards the source
> 6LoWPAN endpoint by reversing the MPLS operation.
> It seems that we are assuming SLAAC built addresses using EUI-64s?
> (which could well be 2-byte short addresses too!) otherwise, mapping
From MAC address back to an IPv6 address is not possible?
> [Pascal] I do not see how/why.
> [Pascal] All it means is that the MPLS operation address is indexed by
> the tuple (incoming link - as identifies by smac, label - the datagram
> tag). No big news there, once created an MPLS LSP can carry non IP
> traffic.
I think you are saying that since the final fragment assembler will have
reassembled the L3 header, that it will know where to send the ACK.
> ------------
> change the source MAC address to from MAC_prev to MAC_self
> "to from" --- is this correct, or is there an extra word here?
> [Pascal]
> [Pascal] fixed typo : )
okay, good. I thought that maybe there was some extra meaning I didn't get.
--
Michael Richardson <[email protected]>, Sandelman Software Works
-= IPv6 IoT consulting =-
signature.asc
Description: PGP signature
_______________________________________________ 6lo mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lo
