Hi Jonathan:
We've been discussing HC1g quite extensively. I'd wish to discuss
variations on your initial proposal:
------------------------------------------------------
The LOWPAN_HC1g encoding as currently in the draft
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| SC | DC |VTF| NH |L4C|
+---+---+---+---+---+---+---+---+
HC2g for UDP
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| S | D | L | reserved |
+---+---+---+---+---+---+---+---+
------------------------------------------------------
What seeems to be missing:
- Hop limit compression (takes 2 bits)
- UDP checksum compression
My proposal includes to keep using the mesh header format for route over
to carry the short addresses and hop limit.
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| SC | DC |VTF| Hlim |L4C|
+---+---+---+---+---+---+---+---+
HLIM:
00 not compressed
01 placed in the mesh header to count PAN hops
10 fully elided, packet generated inside the PAN
11 fully elided, packet came in a stub
HC2g for UDP
0 1 2 3 4 5 6 7
+---+---+---+---+---+---+---+---+
| NH | S | D | L | C | rsvrd |
+---+---+---+---+---+---+---+---+
C: checksum is compressed.
Note1: with that new format you need an HC2g to be able to compress NH.
I do not mind.
Note2: if NH is 0 then the NH is placed after the HC2G as it is taken as
an L4 parm not between HC1G and HC2G. The parsing of bits 2..7 depends
on that NH.
What do you think?
Pascal
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
