Re: [6lo] fragment forwarding document

[Michael Richardson <[e-mail]>]

Pascal Thubert (pthubert) <[e-mail]> 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 <[e-mail]>, Sandelman Software Works
 -= IPv6 IoT consulting =-