Subject: [6lowpan] Proposal for the new LOWPAN_NHC

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Thu, 12 Jun 2008 11:17:51 +0200

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-masked]
https://www.ietf.org/mailman/listinfo/6lowpan