Hi:
It seems that we are in a semantic loop WRT to the UDP checksum
compression.
For instance, ISA100 transport has all the required properties but since
it computes its MIC diffently then it is not really UDP as defined but a
derivative with equivalent or better properties.
So maybe we need to convey that difference in the 6LoWPAN header
compression to break the tie.
Here's a proposal for doing so, based on Jonathan's latest draft:
The idea here is to keep the spirit of Jonathan's compression but move
UDP to the right because we know we do not need more bits for UDP as we
know it though other transports might.
For real UDP
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 1 | 0 | S | D |
+---+---+---+---+---+---+---+---+
For protocols that are use UDP header format but can compress the
checksum
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| 1 | 1 | 1 | 1 | 0 | C | S | D |
+---+---+---+---+---+---+---+---+
Current text:
"
This document defines a compression format for UDP headers using
LOWPAN_NHC. The LOWPAN_UDP compression format is shown in Figure 7.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
|ID | S | D | C | rsv |
+---+---+---+---+---+---+---+---+
Figure 7: Compressed IPv6 Multicast Address Encoding
Hui Expires September 11, 2008 [Page 9]
Internet-Draft 6LoWPAN Compression of IPv6 Datagrams March 2008
ID: Identifier (bit 0):
0: Identities an IPv6 Next Header value of 17 and the LOWPAN_UDP
compression format.
1: Identifies an IPv6 Next Header value other than 17, the
following bits are used to identify the particular Next Header
value and compression format. The bit-patterns for other Next
Header values are left undefined in this document.
S: Source Port (bit 1):
0: All 16 bits of Source Port are carried in-line.
1: First 12 bits of Source Port are elided and the remaining 4
bits are carried in-line. The Source Port is recovered by: P +
short_port, where P is 61616 (0xF0B0).
D: Destination Port (bit 2):
0: All 16 bits of Destination Port are carried in-line.
1: First 12 bits of Destination Port are elided and the remaining
4 bits are carried in-line. The Destination Port is recovered
by: P + short_port, where P is 61616 (0xF0B0).
C: Checksum (bit 3):
0: All 16 bits of Checksum are carried in-line. The Checksum MUST
be included if there are no other end-to-end integrity checks
that are stronger than what is provided by the UDP checksum.
Such an integrity check MUST be end-to-end and cover the IPv6
pseudo-header, UDP header, and UDP payload.
1: All 16 bits of Checksum are elided. The Checksum is recovered
by recomputing it.
rsv: Reserved (bits 4-7).
"
Jonathan: pls note the wrong text in the figure description
What do you think?
Pascal
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
