Hi Pascal The support for a potential long RPL header is just a special case. Other PHY/MAC technologies may have shorter frames than 128 bytes. Add L2 security and you may have an issue even before.
The main point is the two other issues: * Fragment offsets affected by header compression * Fix does not (seem to) introduce new problems. This small clarification let us work in a normal layered fashion: 1) Compress the header if you feel like. Or do not - the choice is yours. 2) Transmit the datagram - compressed or not. a) Use fragmentation if you have to. Offsets allow reassembly. 3) Load fragments in receive buffer. Option: Start at an offset into the buffer so that you do not have to memcpy the IP payload. 4) Decompress header. 5) Deliver to IP stack. This seems very simple and obvius to me. Where is the problem? - Anders > -----Original Message----- > From: Pascal Thubert (pthubert) [mailto:[email protected]] > Sent: Thursday, March 04, 2010 10:37 > To: Anders Brandt; Geoff Mulligan; 6lowpan > Subject: RE: [6lowpan] closing on update to HC draft > > Hi Anders: > > If RPL effectively needs the patch, I'll be more than willing > to make it urgently. > I think you have in mind a long string of routing headers, correct? > If so, do you have a concrete reason to believe that people > would do that rather than maintain some intermediate states? > > Pascal > > > > -----Original Message----- > > From: [email protected] [mailto:[email protected]] On > > Behalf Of Anders Brandt > > Sent: Thursday, March 04, 2010 8:55 AM > > To: Geoff Mulligan; 6lowpan > > Subject: Re: [6lowpan] closing on update to HC draft > > > > > >From what I can tell we appear to be closing in on the > idea (from > > > >Daniel plus others > > > > Agree. > > > > Pascal may be right that there are other nice things we > could consider > if we > > open all boxes again but this is a sufficient "metal fix" (in ASIC > design > > terminology) to resolve the current issue. > > > > It solves an existing, real problem. It allows RPL to run > long headers > (more > > than one fragment) and it does not (seem to) introduce new problems. > > > > - Anders > > > > > -----Original Message----- > > > From: [email protected] > > > [mailto:[email protected]] On Behalf Of Geoff Mulligan > > > Sent: Thursday, March 04, 2010 00:00 > > > To: 6lowpan > > > Subject: [6lowpan] closing on update to HC draft > > > > > > >From what I can tell we appear to be closing in on the > idea (from > > > >Daniel > > > plus others) that the HC draft should only: > > > - Allocate a new dispatch value for the "changed" frag > offset and > > > length value > > > - Define the frag offset and length to be the values > relevant for > > > the actual data in the packet (compresses or not) > > > - Strongly deprecate the old frag dispatch value > > > > > > Agree or disagree? > > > > > > geoff > > > > > > > > > _______________________________________________ > > > 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
