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

From: gabriel montenegro <[email-masked]>
Date: Thu, 7 Sep 2006 01:42:38 -0700 (PDT)

Since there has been no feedback on this, I will go with option #4 below unless I hear otherwise within the next few
days. We can always revisit this during IETF LC. But if we make no decision we will never get to IETF LC.
 
-gabriel

----- Original Message ----
From: gabriel montenegro <[email-masked]>
To: Mario Mao <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, August 8, 2006 8:56:24 AM
Subject: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04

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-masked]>
To: gabriel montenegro <[email-masked]>
Cc: [email-masked]
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-masked]

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

_______________________________________________
6lowpan mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/6lowpan

---

From: Mario Mao <[email-masked]>
Date: Thu, 7 Sep 2006 20:31:34 +0800

Hi Gabriel,

Sorry for the delay, here are some comments about the newly modified Broadcast field, thanks.

About the option #4, I think it is a good way to solve the confusion. In addition, here is the way we used, hope it could do some help, thanks.

I remember I had suggested a way of introducing a "M" bit which indicates Mesh Broadcast or Multicast Delivery Field immediately following the LoWPAN header. The "M" will use one of the 4 rsv bits in fixed header and not affect the alignment.

                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
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+
 | LF|  prot_type    |M|B| rsv   |Payload (Mesh B/M Field)...
 +-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+-+

When encountering adaptation layer fragment, no more bit are free for the special bit. However, we find it's a nightmare to broadcast fragments in actual 802.15.4 network. The working channel would be full of broadcast fragments even using kinds of optimized algorithm and the result is high possibility of discarding and re-transmitting, and high energy-cost . So, to avoid such situation, we decide to disable broadcast when the packet need to be fragmented into several frames (ugly but useful way). With this strategy, no modification to the fragment encapsulation header format is needed too.

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

Best Regards,

Mario Mao
  ----- Original Message ----- 
  From: gabriel montenegro 
  To: gabriel montenegro ; Mario Mao 
  Cc: [email-masked] 
  Sent: Thursday, September 07, 2006 4:42 PM
  Subject: Re: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04

  -gabriel

  ----- Original Message ----
  From: gabriel montenegro <[email-masked]>
  To: Mario Mao <[email-masked]>
  Cc: [email-masked]
  Sent: Tuesday, August 8, 2006 8:56:24 AM
  Subject: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04

                           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 FieldWe could put the indication in the fixed part of the header by :

      to distinguish between the two current formats and leave some bit patterns reserved in case we end up defining other .

  Any others?

  -gabriel

  ----- Original Message ----
  From: Mario Mao <[email-masked]>
  To: gabriel montenegro <[email-masked]>
  Cc: [email-masked]
  Sent: Saturday, August 5, 2006 2:52:52 AM
  Subject: Some comments about draft-ietf-6lowpan-format-04

  Hi Gabriel,

  Regards,

  Mario Mao
  [email-masked]

---

From: "Dave Green" <[email-masked]>
Date: Thu, 7 Sep 2006 15:43:14 -0400

Would anyone in this group be interested in working on an open-source free (as in free beer) IPv6 6LowPAN stack for 802.15.4 if we make the project available? The license would likely be creative commons. The first target environment is a 32 bit ARM-7 controller. My company would supply the reference stack for all to hack on and compile for their architectures. We would do the ARM-7 port and hope others would port to their architectures and post. This would create a license free alternative to Zigbee so we can buy cheap sensor radios for our work. 

If interested, please let me know. I believe we could have this set up by year's end. 

David Green | VP of R&D | Command Information
13655 Dulles Technology Drive, Suite 100 |  Herndon, VA 20171
O: 703.561.5937 | M: 703.899.9663 | [email-masked]

________________________________________
From: Mario Mao [mailto:[email-masked]] 
Sent: Thursday, September 07, 2006 8:32 AM
To: gabriel montenegro
Cc: [email-masked]
Subject: Re: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04

Hi Gabriel,

 
 
                1                   2                   3

 
Best Regards,
 
Mario Mao
----- Original Message ----- 
From: gabriel montenegro 
To: gabriel montenegro ; Mario Mao 
Cc: [email-masked] 
Sent: Thursday, September 07, 2006 4:42 PM
Subject: Re: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04

-gabriel
----- Original Message ----
From: gabriel montenegro <[email-masked]>
To: Mario Mao <[email-masked]>
Cc: [email-masked]
Sent: Tuesday, August 8, 2006 8:56:24 AM
Subject: [6lowpan] Re: Some comments about draft-ietf-6lowpan-format-04
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 :

Any others?

-gabriel
----- Original Message ----
From: Mario Mao <[email-masked]>
To: gabriel montenegro <[email-masked]>
Cc: [email-masked]
Sent: Saturday, August 5, 2006 2:52:52 AM
Subject: Some comments about draft-ietf-6lowpan-format-04
Hi Gabriel,

 

 
 
Regards,

Mario Mao
[email-masked]

---

From: Pere Salvatella <[email-masked]>
Date: Fri, 8 Sep 2006 14:44:37 +0200

Hi Dave,

  Here in Wireless Network Group (WNG) from UPC we are currently developing an
open-source free IPv6 6LowPAN stack for 802.15.4. Our platform environment is
TelosB mote from CrossBow, the code is written in NesC and it runs over TinyOS
on its first version (tinyos-1.x).

  We would like to ask you: on which platform/OS is your reference stack
running? In which programming language is it written?

  We can keep in contact, to explore collaboration opportunities.

  Best regards,

  Pere Salvatella

Quoting Dave Green <[email-masked]>:

> Would anyone in this group be interested in working on an open-source free
> (as in free beer) IPv6 6LowPAN stack for 802.15.4 if we make the project
> available? The license would likely be creative commons. The first target
> environment is a 32 bit ARM-7 controller. My company would supply the
> reference stack for all to hack on and compile for their architectures. We
> would do the ARM-7 port and hope others would port to their architectures and
> post. This would create a license free alternative to Zigbee so we can buy
> cheap sensor radios for our work. 
> 
> About the option #4, I think it is a good way to solve the confusion. In
> addition, here is the way we used, hope it could do some help, thanks.
>  
> I remember I had suggested a way of introducing a "M" bit which indicates
> Mesh Broadcast or Multicast Delivery Field immediately following the LoWPAN
> header. The "M" will use one of the 4 rsv bits in fixed header and not affect
> the alignment.
>  
>                 1                   2                   3
> When encountering adaptation layer fragment, no more bit are free for the
> special bit. However, we find it's a nightmare to broadcast fragments in
> actual 802.15.4 network. The working channel would be full of broadcast
> fragments even using kinds of optimized algorithm and the result is high
> possibility of discarding and re-transmitting, and high energy-cost . So, to
> avoid such situation, we decide to disable broadcast when the packet need to
> be fragmented into several frames (ugly but useful way). With this strategy,
> no modification to the fragment encapsulation header format is needed too.
>  
> 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.
>  
> Since there has been no feedback on this, I will go with option #4 below
> unless I hear otherwise within the next few
> 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
> 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 .
> 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
> 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). 
> 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?
> 
> 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-masked]
>                                        
> 

-------------------------------------------------
This mail sent through IMP: http://horde.org/imp/

---

From: Carles Gómez <[email-masked]>
Date: Sun, 17 Sep 2006 00:16:57 +0200

Dear all,
 
     I would like to express the opinion our group has about this topic. To
sum up, our preferences are, in decreasing order:
 
     - Option proposed by Mario Mao (i.e. using a reserved bit)
     - Option 4 (i.e. "final address moved up")
     - Others like options 2 and 3, which are assumable
 
    We would rather discourage option 1, since it would add complexity 
in handling bits instead of bytes.

     Best regards,
 
     Carles Gomez
     Wireless Networks Group
     Technical University of Catalonia

Mario Mao wrote:

> About the option #4, I think it is a good way to solve the confusion. 
> In addition, here is the way we used, hope it could do some help, thanks.
>  
> I remember I had suggested a way of introducing a "M" bit which 
> indicates Mesh Broadcast or Multicast Delivery Field immediately 
> following the LoWPAN header. The "M" will use one of the 4 rsv bits in 
> fixed header and not affect the alignment.
>  
>                 1                   2                   3
> When encountering adaptation layer fragment, no more bit are free for 
> the special bit. However, we find it's a nightmare to broadcast 
> fragments in actual 802.15.4 network. The working channel would be 
> full of broadcast fragments even using kinds of optimized algorithm 
> and the result is high possibility of discarding and re-transmitting, 
> and high energy-cost . So, to avoid such situation, we decide to 
> disable broadcast when the packet need to be fragmented into several 
> frames (ugly but useful way). With this strategy, no modification to 
> the fragment encapsulation header format is needed too.
>  
> 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.
>  
>     From: gabriel montenegro <mailto:[email-masked]>
>     To: gabriel montenegro <mailto:[email-masked]>
>     ; Mario Mao <mailto:[email-masked]>
>     Cc: [email-masked] <mailto:[email-masked]>
>     Since there has been no feedback on this, I will go with option #4
>     below unless I hear otherwise within the next few
>     From: gabriel montenegro <[email-masked]
>     <mailto:[email-masked]>>
>     To: Mario Mao <[email-masked] <mailto:[email-masked]>>
>     Cc: [email-masked] <mailto:[email-masked]>
>     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
>     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 .
>     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
>     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).
>     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?
>
>     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-masked] <mailto:[email-masked]>
>                                            
>
>------------------------------------------------------------------------
>