As was discussed previously on the mailing list, the datagram-tag
size was a bit aggressively small at 10 bits, which got us another
DISCUSS comment.
Datagram-Tags need to be unique over the time a receiver keeps
fragments for reassembly, and Geoff has calculated a sender could
only use half a 256 kbit/s link with 10 bits of datagram-tag, a
situation that would become worse with the faster links in the pipeline.
So we need to add a byte. What do we do with the 8 new bits?
Allocate them all to the datagram-tag? This provides some future-
proofing, but we only really need 4 or 5 bits in the immediate future.
We couldn't quite figure out what to do with any "reserved bits" so
far, so the mailing list consensus so far was to use all 8 bits.
This leads to a somewhat awkward tag size of 18 bits.
In the meeting today, we discussed cutting back to 16, reshuffling
the header to obtain alignment, and assigning the two "reserved bits"
to the header type discriminator. Simpler to implement, and future-
proofing in a different way (by leaving bits for extensions).
The text proposal below does not attempt to fix the ambiguity of:
The sender SHALL increment datagram_tag for successive,
fragmented
datagrams.
If anyone thinks this is absolutely required, they should define
whether this is a single value per sender, incremented for every new
datagram, or whether a sender has to keep (indefinitely!?) per-
receiver counters.
Separate from this detail, if there are any issues with the text
proposed below, we need to know quickly.
Gruesse, Carsten
OLD:
1 2
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0| datagram_tag | datagram_size |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: First Fragment
NEW:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 0 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: First Fragment
OLD:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1| datagram_tag | datagram_size |datagram_offset|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Subsequent Fragments
NEW:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|1 1 1 0 0| datagram_size | datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|datagram_offset|
+-+-+-+-+-+-+-+-+
Figure 11: Subsequent Fragments
OLD:
datagram_tag: The value of datagram_tag (datagram tag) SHALL be the
same for all link fragments of a payload (e.g., IPv6) datagram.
The sender SHALL increment datagram_tag for successive,
fragmented
datagrams. The incremented value of datagram_tag SHALL wrap from
1023 back to zero. This field is 10 bits long, and its initial
value is not defined.
NEW:
datagram_tag: The value of datagram_tag (datagram tag) SHALL be the
same for all link fragments of a payload (e.g., IPv6) datagram.
The sender SHALL increment datagram_tag for successive,
fragmented
datagrams. The incremented value of datagram_tag SHALL wrap from
65535 back to zero. This field is 16 bits long, and its initial
value is not defined.
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
