While a agree with Phil, I think that Pascal does have an interesting
suggestion in using one of reserved bits to indicated that the UDP
checksum has been elided because the protocol being used provides
protection of the same headers and data with at least the same strength.
It would then be required by any bridge/router that is expanding the
packet to calculate the UDP checksum and insert it.
geoff
On Mon, 2008-03-03 at 10:11 -0800, Philip Levis wrote:
> 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
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
