I am not quite clear on the need of version for lowpan layer ; how are other
ipv6 over protocol foo defined in this respect?
Also, datagram tag size increament to 16bits does not seem to be a
clear need to me. I am not sure if there is a need for fragmentation
tax. Today folks run IP datagram over 10Gb/s ethernet, but IP
identification
fileld size is not changing. We need to be very sure that the datagram tag
rollover is an issue before increasing bit numbers in the lowpan header.
BTW, currently protocol field is 11 bits - we should reduce that number
to 8 bits. We may want to use 1 bit (8bit +1) in highest order bit, to
indicate
private or standard protocol-type if folks think that might be useful.
IMHO, we need more discussion and input from folks before changing
the tagsize to 16bits. My recommendation would be to start with the current
size and change later if needed based on implementations input , ie, when
we have more experience with IPv6 over lowpan.
Thanks,
-Samita
gabriel montenegro wrote:
--- Vipul Gupta <[EMAIL PROTECTED]> wrote:
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)?
If one were to do both (add a fixed version field, say 2 bits, and
add one bit to the datagram tag), we'd need 3 bits in header formats
2 and 3, where both the version and the enlarged datagram tag appear.
In the header formats 1 and 2, these 3 bits could come from the protocol type
(reducing to 8 from 11 bits, which is still enough, I think), and in
header format 3 they'd come from the datagram tag (meaning we'd specify
offsets in 8 octet units). Here's what formats might look like:
Format 1:
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|Ver| prot_type |M| rsv |Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|Ver| prot_type |M| datagram_size | datagram_tag...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|...datagram_tag| Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|Ver|datagram_offset|M| datagram_size | datagram_tag...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|...datagram_tag| Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
protocol type and datagram offset now at 8bits
datagram tag now at 16 bits
Comments?
-gabriel
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www1.ietf.org/mailman/listinfo/6lowpan
