On Mar 3, 2008, at 5:25 AM, Pascal Thubert (pthubert) wrote: > Hi: > > Per RFC 4944: > "The UDP header's checksum field is not compressed and is > therefore > carried in full." > > The UDP checksum is not the only way to protect the IP pseudo header, > the UDP header and the payload. > ISA 100.11a is defining a transport-level security that does all this > and more, since it has a larger signature and provides mutual > authentication at the same time. > > Also, the ISA100.11a transport-level security is usually > hardware-assisted, so it requires little power or CPU time on the > field > device, whereas UDP checksum will be a costly CPU operation. > > So ISA100.11a is an example where the UDP checksum could and actually > should be compressed over the LoWPAN, leaving it up to be > reconstructed > by a backbone router should the packet go any further than the LOWPAN > itself. > > Since bit 3 in the HC-UDP header is reserved anyway, it makes sense to > standardize it to mean that the UDP checksum is compressed, provided > that the headers and payload are equally or better protected than > if the > checksum was used. > > Note: that would be bit 7 in my HC3 proposal. As a result, the > complete > HC3 proposal could save us up to 4 additional bytes over RFC 4944 > for a > UDP packet. > > What do you think?
I'm wary of all of these very aggressive compression approaches. They shave off a few bits, but add to complexity. One of the challenges in lowpans is that their protocols need to remain simple. This isn't to say that saving four bytes isn't great; rather, it's a tradeoff to protocol complexity (read: code size requirement), and that tradeoff shouldn't be ignored. Phil _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
