Hi Jonathan,
Would you prefer to list ECN and DSCP separately and in the order
that they appear in a LOWPAN_IPHC encoded header? For example:
00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
01: ECN + 2-bit Pad + Flow Label (3 bytes)
10: ECN + DSCP (1 byte)
11: Version, Traffic Class, and Flow Label are compressed.
Great. Concise and precise. I'd maybe add:
00: ECN + DSCP + 4-bit Pad + Flow Label (4 bytes)
01: ECN + 2-bit Pad + Flow Label (3 bytes), DSCP is elided
10: ECN + DSCP (1 byte), Flow Label is elided
11: (0 bytes), Traffic Class and Flow Label are elided.
All elided fields are decompressed as zero, except that Version is
always elided and decompressed as 6.
As usual, bit fields are concatenated by filling the most
significant bits first.
There is a proposal to make SAC=1, SAM=00 to indicate the
Unspecified Address.
So why don't we stick with the way this was done in -04, not risking
any incompatibilities with ISA100?
(Of course, we should wait until we fully understand the ISA100
situation.)
Would you prefer text that says they are the same with exception?
Or keep the text as is?
When they (SAC/SAM and DAC/DAM) really are the same, or there is one
value that only is allowed for SAC/SAM, I'd prefer to unify them
(editorial preference). Technical preference is of course that we can
have as much code reuse as possible.
The wart, of course, is M/SAC/SAM = 1/1/00. Why do we have that
again? 0/0/00 means exactly the same.
Why is SAC=1 for this stateless case (I know, because we already took
all four stateless cases.)
If we really want to have a special multicast case, why don't we
compress out at least the first byte of the address, which is always
0xFF in this case?
(Changes for multicast don't impact ISA100.)
Gruesse, Carsten
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan
