15 bits should be ok for the data rates we are dealing with
and still support reassembly timers in the order of 1min.
However, if we need an extra bit, one could possibly take
that from the prot_type and the datagram_offset fields
(for the latter one could use a mechanism similar to what's
used in IPv4 and IPv6 and specify the offset in 2 byte
units -- IPv4 and IPv6 use 8-byte units).
It might also make sense to reserve a portion of the prot_type
space for private use among consenting parties. Has there
been any discussion on including a version field in the
LowPAN header for future extensions (it could be fairly
short 2-4 bits)?
vipul
On Oct 19, 2005, at 12:33 PM, gabriel montenegro wrote:
If we just look at the packet formats, and extrapolate, here's an
example of what
one might end up with:
Format 2:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF| prot_type |M| datagram_size |datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Format 3:
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
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| LF| datagram_offset |M| datagram_size |datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
| datagram_tag |
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
What do folks think?
We haven't discussed at all about alignment issues (perhaps a
discussion
to have with respect to IPv6 header alignment requirements,
implications
and what we wish to do about it), but the above keeps
an octet alignment. Typical radio chips will read in min 1 octet most
probably 2 octets at a time, I believe.
Comments?
-gabriel
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
