[6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04

[gabriel montenegro]

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: 6lowpan@ietf.org
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,




Mario Mao

[EMAIL PROTECTED]

                                       

_______________________________________________
6lowpan mailing list
6lowpan@ietf.org
https://www1.ietf.org/mailman/listinfo/6lowpan