Subject: Re: [6lowpan] Mesh Delivery Field

From: gabriel montenegro <[email-masked]>
Date: Sun, 22 Oct 2006 12:26:18 -0700 (PDT)

Thanks for coming forward and expressing your opinion on this. I don't know if
we have consensus (it's the WG chairs' job to judge that). But perhaps we can move
forward with the latest understanding based on recent exchanges, as you suggested.
I will prepare a version to reflect this and submit. 

I encourage those involved in the discussion to express their opinion on that version
so we can gauge if we're done with it as a WG or not.

-gabriel

----- Original Message ----
From: Ki-Hyung Kim <[email-masked]>
To: Geoff Mulligan <[email-masked]>; gabriel montenegro <[email-masked]>
Cc: David Culler <[email-masked]>; Soohong Daniel Park <[email-masked]>; Mario Mao <[email-masked]>; [email-masked]; [email-masked]
Sent: Sunday, October 22, 2006 3:37:38 AM
Subject: Re: [6lowpan] Mesh Delivery Field

Geoff, 
I think we should move forward for "the next" stuff in San Diego.
I think we have reached a concensus with regard to the mesh delivery field. 
Gabriel replied to all requests including the David's, Mario's, and Mine.
I think the current format document is enough to contain the future flexibility which is mentioned by David.
Also the allignment stuff of IP flow label and traffic class could be handled by padding zero's right now without having any problem, as Gabriel replied.
 
Isn's it enough for moving forward at this stage?
Gabriel, if there is anything we have missed, please let us know and discuss on line before next meeting.
 
As Mark mentioned, we are now spending too much time for shipping  base deliverables.
Geoff, please let us know what is the thing we have to do right now for moving forward.

>Daniel,
> There is no next.  We cannot do anything new until we complete the two
>documents.  We have completed the problem statement and I feel that we
>have consensus on the document.
> 
>On the format document I do not feel we have reached consensus on how to
>"fix" the mesh delivery field issue nor some of the significant points
>that David Culler brought up about diagnostics and future capabilities. 
>
>Folks, if we can't solve these on the list before the meeting I suspect
>that we will spend the entire hour on just trying to get consensus on
>this one document.
>
>Please every speak up on your thoughts about the mesh delivery field and 
>David Culler's email.
>
>Speak now or nothing new at the next ietf!

On 9/30/06, Mario Mao <[email-masked]> wrote: 
 
Hi Gabriel,
 
Thanks for you feedback.
 
As I mentioned before, the way to combining the Traffic Class and Flow Label with Version field just is a workaround we used temporarily. Also, the same method is used to solve the UDP compression alignment problem, that is, only compress the port field when both source and destination ports could be compressed. 
 
Clearly, my workaround is somewhat ugly and not reasonable, but it do make the implementation more easily. In fact, we do wait for new draft to clarify this alignment problem. For personal opinion, it is a good idea to pad bits till all compression fininshed. However, I think we should pay caution to the facility for implementation. I hope we can get conclusion in the next version, thanks. 
 
Best Regards,
 
Mario Mao
----- Original Message ----- 
From: gabriel montenegro 
To: Ki-Hyung Kim 
Cc: David Culler ; Geoff Mulligan ; Soohong Daniel Park ; [email-masked] ; Mario Mao 
Sent: Saturday, September 30, 2006 10:16 AM
Subject: Re: [6lowpan] Mesh Delivery Field

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

-- 
Ki-Hyung Kim (김기형, 金起亨)
Associate Professor 
Division of Information and Computer Eng., Ajou University, Suwon, Korea 442-749
Tel: +82-31-219-2433, Cel: +82-17-760-2551,  Fax: +82-31-219-2433 http://www.6lowpan.org

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

---

From: Philip Levis <[email-masked]>
Date: Sun, 22 Oct 2006 12:52:34 -0700

> so we can gauge if we're done with it as a WG or not.

I think that the approach of making the first 16 bits the same on all  
three header formats is a good idea. At the very least, it simplifies  
protocol processing, reducing code size and complexity.

I am unsure whether the five bits will be sufficient. However, we are  
likely to only know this from practice, rather than idle postulation.  
I think David raised this point when he asked active developers  
whether they have found it sufficient.

Even with these reservations, though, I think it is OK to be  
standards track. It is common for standards track RFCs to have  
subsequent versions that obsolete earlier ones, based on experience  
and use.

Phil