Hi René; This seems great in principle but my layer violation flag raised in full red. How can L2 know that this is a subsequent L3 fragment? Seems to me we need a mac layer support to do what compress/expand at mac layer.
What I'd really love to see that might enable this is a form of mac extension for mac layer label switching. Any new packet would be given a new label that is locally significant for a hop A -> B created by A and unique in (A->B). MAC states could be associated at hop by hop and 6LoWPAN states end to end for that flow. In particular we could forward fragments that way as opposed to recompose hop by hop. At least some of this does not belong to us. What are they doing at 4E? Pascal >-----Original Message----- >From: [email protected] [mailto:[email protected]] On Behalf Of >Rene Struik >Sent: mercredi 17 juin 2009 16:03 >To: [email protected] >Subject: [6lowpan] (cutting overhead) RE: LoWPAN simple fragment Recovery > >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 _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
