Re: [6lowpan] Mesh Delivery Field

Sun, 22 Oct 2006 03:41:51 -0700

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 PROTECTED]> 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 -----
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 protected]
https://www1.ietf.org/mailman/listinfo/6lowpan

Reply via email to