Good
point, yes. The confusion is that upon reception it is not easy to
determine which of the two following mesh header formats is being used
because
the fixed part of the header does not tell us:
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|F| Hops Left | Originator Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Final Destination Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 10: Mesh Delivery
Field
1 2 3
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
|O|F| Hops Left |Sequence Number| Originator Address...
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
...Final Destination Address
+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
Figure 11: Mesh Broadcast or Multicast Delivery Field
We could put the indication in the fixed part of the header by :
1. adding a bit field to distinguish. Two alternatives: (a) We could
add one bit and move everything after it over one bit. Not that our
alignment was
great to begin with, but this would make it uglier. (b) We could
make this bit field larger than 1 bit, in which case we'd be able
to distinguish between the two current formats and leave some bit
patterns reserved in case we end up defining other .
mesh headers in the future.
2. adding a bit by stealing one from, say, hops_left. This means we'd
have a max of 32 hops instead of the current 64. I still think this
is enough. This would not alter whatever alignment we now have.
3. Grow the 'F' field by one more bit, and assign bit patterns for 64
bit address, 16-bit address and 16-bit bcast/mcast address (as per
the current draft).
This would leave one bit pattern reserved.
4. Move the distinguishing field, "Final Destination Address" into the
fixed part of the header (right after hops_left). Sequence number and
originator
address would relocate after final destination address. This does
not waste any bits, but is esthetically unpleasant. But we may not care
about such
things.
Any others?
Comments? Would the folks who are implementing this please express
their opinions?
-gabriel
-----
Original Message ----
From: Mario Mao
<[EMAIL PROTECTED]>
To: gabriel montenegro
<[EMAIL PROTECTED]>
Cc:
[email protected]
Sent: Saturday, August 5, 2006 2:52:52 AM
Subject: Some comments about draft-ietf-6lowpan-format-04
Hi Gabriel,
There is some comments about the
last draft, thanks.
In Section 11, the draft mentions
that a special format of "Mesh Delivery" field should be used when
Broadcast or Multicast. This kind of field is called as Mesh Broadcast
or Multicast Delivery Field and a "Sequence Number" is added.
For Source Node, it will be clear
that which kind of format it should use. But for Destination Node or
Relay Node, looks like there will be some confusion when they trying to
explain this format.
The cause of such confusion is the
way inbound Node identifying such kind of field format. As the draft
mentioned, the destination address is the identification of such kind
of field. However, for the Final Destination Address is behind the
Sequence Number, the inbound Node will be unaware of the existence of
this field before it check the Final Destination Address. If inbound
Node handle all Broadcast Delivery Field as the normal "Mesh Delivery"
field, when it begins to check the Final Destination Address,
there will be 8-bits shift of the right position. This scenario must
lead to an mistake.
There is also another way to
identify the Broadcast Delivery Field. That is checking the destination
MAC address in the IEEE 802.15.4 header (0xFFFF). But in practice, an
IEEE 802.15.4 broadcast frame can't be delivered to every END DEVICE
(RFD). This is because the END DEVICE disable its transceiver during
CAP when there is no frame directly sent to it.
To avoid such incorrect scenario,
one flag may be needed in the fixed filed (in Adaptation Header). That
make all node could recognize the special Broadcast Delivery Field in
right way.
Regards,
