[Re-sending after eliding all the thread due to size limitations on the 6lowpan alias.]
Ok, it seems like folks would like to have more flexibility in the header. I'm just having a hard time translating that
to actual bits and bytes within the header formats, and how much flexibility is fine.
The first packet format has 5 bits of reserved field:
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| rsv |Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LoWPAN unfragmented encapsulation header format
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| rsv |Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 1: LoWPAN unfragmented encapsulation header format
One bit out of that reserved field is what Mario Mao suggests we use to distinguish between the two current flavors
of mesh delivery header (unicast vs bcast/mcast). Is this sufficient flexibility?
The issue is that there is no such flexibility in the two other header formats, but we can certainly add such a
reserved field and make all 3 header formats the same up to the first 16 bits. Perhaps along these lines
(notice the new "reserved" field and the corresponding 5 bit shift for datagram_size and datagram_tag) :
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|reserved | datagram_size |dgram_tag|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dgram_tag| Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
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|reserved | datagram_size |dgram_tag|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dgram_tag| Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 2: LoWPAN first fragment encapsulation header format
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|reserved | datagram_size |dgram_tag|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dgram_tag| Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: LoWPAN subsequent fragment(s) encapsulation header format
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|reserved | datagram_size |dgram_tag|
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|dgram_tag| Payload (or Mesh Delivery Hdr)...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 3: LoWPAN subsequent fragment(s) encapsulation header format
Would this be enough? If not, how many bits should be allocated? Should there be a version field in addition
(as suggested by Vipul a while back)? What changes in the format are suggested? Folks, please be specific
as to the suggested changes by sending header formats with clearly proposed fields, etc.
tnx,
-gabriel
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
