Hello Michael:
Huge thanks.
Let's see:
pg: 6, section 4.1:
Sequence: 5 bit unsigned integer; the sequence number of the
fragment. Fragments are sequence numbered [0..N] where N is in
[0..31]. As long as the overheads enable a fragment size of 64
bits or more, this enables to fragment a packet of 2047 octets.
^^^^ <- I think you mean octets?
[Pascal] that's a oups, fixed in 07.
-------------------
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.
[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?
[Pascal] In order to protect the future, I'd say that (0, 0) should be
supported. It should be routed, using the same label path if one exists that is
not broken on this next hop. Cleanup should be performed. I reformed the text
along those line
-------------------------------
Are FRFRAG-ACK's subject to 6loRH compression in anyway?
(I don't think it helps, but, whenever I see a potential series of zeros, I
wonder)
[Pascal] No to the 6LoRH piece, but possibly yes to the idea of compression.
You'll find in earlier versions of the draft that a compression of the bitmap
was proposed. I spent iterations adding and removing it based on one person's
feedback; not an easy choice since it is a tradeoff between over the air
performance and code complexity.
More in section 6.2 of
https://tools.ietf.org/html/draft-thubert-6lowpan-simple-fragment-recovery-06
Let's reach consensus on that!
-------------------------------
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.
[Pascal] The novelty is rather that the LSP is created on the fly with the
first fragment of an IP packet, and removed once the packet as fully flown
through.
----------------------------------------
then says:
It is
expected that the upper layer retries obey the same or friendly rules
in which case a single round of fragment recovery should fit within
the upper layer recovery timers.
"the same or friendly rules" <-- missing a word?
[Pascal] slight rewording, added ref to 8085
[Pascal]
----------------
section 6:
Upon the first
fragment, the routers along the path install a label-switched path
(LSP), and the sollowing fragments are label-switched along that
path.
s/sollowing/following/
6.1: s/ia route lookup/a route lookup/
allocates a label-swap entry indexed by (MAC_previous,
DT_previous) that contains (MAC_next, DT_next)
[Pascal] done, thanks!
----------------------
It seems that really do have to go read LSP documents to understand things :-)
RFC3031 had better be a normative reference then, or section 6.1 needs to have
some pictures and much more explanation. I will have to go re-read
3031 to understand what a "label-swap entry" is exactly.
[Pascal] well, this refers to text in this spec:
"
allocates an abstract label-swap entry indexed by (MAC_previous, DT_previous)
that contains (MAC_next, DT_next)
"
Maybe some reorg is needed to highlight that structure.
------------
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 : )
--
I just pushed 07. Thanks again Michael!
Pascal
_______________________________________________
6lo mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lo
