Hi Pascal: If one does fragmentation and has multiple frames, one should be able to compress 802.15.4 headers for the subsequent frames.
One could proceed as follows: a) first frame could use full header; b) subsequent frames would use truncated MAC header overhead (under assumption that this can be faithfully reconstructed at recipient's end (who stores header intelligence if frame pending bit is set). c) crypto overhead (message authentication tag) can be seriously shortened for typical frames. This would potentially lead to the following: a) first frame has full header; b) subsequent frames: 5 octets of non payload fields total; - reduced MAC header: 3 octets (sFCF: 1 octet; DSN: 1 octet; Header fields: 0 octets; AuxSecHeader: 1 octet); - reduced crypto expansion: 2 octets (typically - if realizing what I dubbed "Frame Security Dream"); - elided CRC-16: 0 octets (if one uses authenticity tag (with default key if no security)). Thus, with frame fragmentation, all but the first frame may have payload field of up to 122 octets. This is not always possible with 802.15.4-2006 techniques, but intention is that 802.15.4e amendment enables this. For further info, cf. IEEE 802.15.4e document: 15-08-0828-08-004e-security-and-efficiency-enhancements.ppt I should remember to take this into account when writing up the draft text for overhead reduction techniques for 802.15.4e, making sure to make the link to frame pending stuff. Any comments appreciated. Best regards, Rene -----Original Message----- From: [email protected] [mailto:[email protected]] On Behalf Of Pascal Thubert (pthubert) Sent: Wednesday, June 17, 2009 5:17 AM To: Carsten Bormann Cc: [email protected]; [email protected]; Fred Baker (fred) Subject: Re: [6lowpan] LoWPAN simple fragment Recovery Hi Carsten: I love your suggestions. Thanks a lot :) Since there is no additional data in the FRACK we could deduce the size of the ack bitmap from the packet length, but I would not go that way. Let's see what we have on the table A) As you say we could elide trailing zeroes. We'd use the first 2 bits to say how many bytes in the bitmap, trail all zeroes. Acknowledging within the first 6 fragments takes one octet coded as 00xxxxxx Acknowledging within the first 14 fragments takes one octet coded as 01xxxxxx xxxxxxxx Acknowledging within the first 22 fragments takes one octet coded as 10xxxxxx xxxxxxxx xxxxxxxx Acknowledging within the first 30 fragments takes one octet coded as 11xxxxxx xxxxxxxx xxxxxxxx xxxxxxxx B) Or we could use an encoding similar to the LOWPAN_NHC in the header compression draft. Acknowledging within the first 7 fragments takes one octet coded as 0xxxxxxx Acknowledging within the first 14 fragments takes 2 octets coded as 10xxxxxx xxxxxxxx Acknowledging within the first 21 fragments takes 3 octets coded as 110xxxxx xxxxxxxx xxxxxxxx Acknowledging within the first 28 fragments takes 3 octets coded as 1110xxxx xxxxxxxx xxxxxxxx xxxxxxxx Theoretically that could lead us as far as we care to go but it seems that 28 is enough. Also we might want to write right to left to avoid shifting bits around. Conclusion: A) gives us up to 30 fragments and a very simple encoding as opposed to 28 for B B) is more efficient in that it saves one octet for the 7th fragment whereas A saves on octet on the 22nd, which is probably a much rarer occasion. I'd be more inclined to use B) for the slightly better compression but I'd appreciate opinions on this. Opinions? Votes are: A, B, or B+read right to left. Pascal >-----Original Message----- >From: Carsten Bormann [mailto:[email protected]] >Sent: mercredi 17 juin 2009 08:22 >To: Pascal Thubert (pthubert) >Cc: Fred Baker (fred); [email protected]; [email protected] >Subject: Re: [6lowpan] LoWPAN simple fragment Recovery > >On Jun 17, 2009, at 07:54, Pascal Thubert (pthubert) wrote: > >> 80 bytes > >Well. > >MAC frame mac: 127 bytes >MAC header/trailer: 5 bytes >Adresses (usually, if EUI-64 is used): 18 bytes >Security Header: 0..14 bytes (depending e.g. on key identifier) >Security Trailer (MIC): 0/4/8/16 bytes > >Depending on how security is being used, the MAC payload may be as low >as 74 bytes. >With 6 bytes of fragment header overhead, we are at 68; with rounding >to a multiple of 8, we are at 64. >1280/64 = 20. > >The first fragment may have some additional header overhead (somewhat >unlikely, but possible), so I'd say: > >21 fragments > >This is without a mesh header. >If a mesh header in the current worst case configuration is needed, >make that 28 (!). > >I think rounding up to 32 is about right. >5 bits for the sequence number also happens to match up with the 11 >bits needed for the datagram size. > >Spending a bit or two of those for some form of huffman/rice coding >might be the more appropriate way to save bytes in the FRACK packet, >if that is a concern, because many packets will fit into much fewer >(eg., 7 or less, 14 or less) fragments. Or, simpler, trailing zeroes >might be suppressed in the FRACK. > >All this pesky bit fiddling... But someone has to do it. > >Gruesse, Carsten _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
