I've read draft-thubert-6lo-forwarding-fragments, and I think that we should go ahead with it. Here are some detailed comments. I can't say that I understand all the processing required yet, but it's clear that the authors do: the text simply needs improvement.
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?
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.
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)
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?
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?
seciton 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)
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.
change the source MAC address to from MAC_prev to MAC_self
"to from" --- is this correct, or is there an extra word here?
--
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
