Pascal Thubert (pthubert) wrote:
Hi Erik:
If the compressor is a router forwarding a packet into the lowpan, then
it can not so it will not compress the checksum. The only node that can
compress the checksum is the transport endpoint that sources the
compressed packet.
Today, 99.9 percent of the packets that transit in such networks are
data measurements transmitted from a sensor node towards an application
that resides on a gateway or on the backbone. So it's worth the effort.
Doesn't this imply that the sender needs to know whether the destination
is on the far side of a router which does the decompression?
How can the sender determine this?
I don't see how it can tell that since we've been talking about
- using the same subnet prefix for an extended 6lowpan
- having the decompression happen in the ER
- having hosts on the backbone
Thus when a host on the backbone sends a packet your first paragraph
seems to say that the UDP checksum can not be compressed, since the
packet is forwarded by a (compressing) ER.
Assuming the sending 6lowpan node uses the destination prefix ("is it in
my subnet prefix?") to determine whether or not a MIC is included and
the UDP checksum compressed out, then the hosts on the backbone will
receive some UDP packets with a MIC, and other UDP packets (from other
hosts) without a MIC.
IMHO it would be a lot more robust to define a new IP protocol number
for the "UDP with a MIC" protocol.
Erik
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
