Ki-Hyung,
You
asked: "So, what is final look of the mesh delivery field?"
As
per Mario's suggestion, we'd use one of the 5 reserved bits to signal if
the
bcast/mcast mesh delivery
format is being used, and we'd call it the 'B' bit.
So
no change to the mesh delivery fields is required. Since the reserved
bits
are
common to all three lowpan header formats, the 'B' bit would apply to
all
three.
Mario
also had a comment on how the header compression forces alignment to not
fall
on octet boundaries:
At last, I find some problem when
impliment IPv6 header compression. Please note Traffic Class and Flow Label
bit in HC1. If we don't compress the two field, 28 bits (that is three
and half bytes) are sent. However, how to send the half byte? As I know,
most hardware could only transmit data in unit of BYTE. Should we need
4 bits pending data? The workdaround we used is combining the Traffic
Class and Flow Label with Version field. So, the Traffic Class and Flow
Label bit becomes Version, Traffic Class and Flow Label bit. Please see following as
detail.
Version, Traffic Class and Flow Label (bit 4):
0:
not compressed, full 4 bits for Version, 8 bits for Traffic Class and 20
bits for Flow Label are sent
1: Traffic Class and
Flow Label are zero
What
do people think of that? I'd rather not do that because
1. why send a version field if the version is already known (i.e.,
IPv6)?
2. this only fixes the alignment as far as the IPv6 header is concerned,
but
there
are more headers probably following, and those could also have
alignment
issues.
For
example, we also have an issue with UDP header compression (the only
header
compression scheme currently defined in addition to IPv6 header):
UDP source port (bit 0):
0: Not compressed, carried "in-line" (
Section
10.3.2)
1: Compressed
to 4 bits. The actual 16-bit source port
is
obtained by calculating: P + short_port value. P is
a
predetermined port number with value TBD. The short_port
is
expressed as a 4-bit value which is carried
"in-line"
(
Section
10.3.2)
UDP destination port (bit
1):
0: Not compressed,
carried "in-line" (
Section
10.3.2)
1: Compressed
to 4 bits. The actual 16-bit destination port
is
obtained by calculating: P + short_port value. P is
a
predetermined port number with value TBD. The short_port
is
expressed as a 4-bit value which is carried
"in-line"
(
Section
10.3.2)
Because
of the above, it seems quite possible that one would end up with 4 bits
for
either the UDP source or destination. In such a case, the misalignment in
the
IPv6
header could be offset by the misalignment in the UDP header compression,
and
we'd end up aligned on an octet boundary. Of course, if one uses the
funky
4-bit
port compression for both source and destination then one wouldn't
offset
the
previous misalignment. No way to know, so perhaps one should wait until
the
entire
header is laid out to figure out if any padding with zero bits is to
be
done.
So
perhaps what we can do is to add text to the effect that one packs the
entire
header
and then pads as appropriate to align to an octet boundary. Does this
sound
reasonable?
thanks
for any comments,
-gabriel
