Subject: Re: [6lowpan] Mesh Delivery Field

From: "Ki-Hyung Kim" <[email-masked]>
Date: Sun, 22 Oct 2006 19:37:38 +0900

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 <[email-masked]>
> *To:* Ki-Hyung Kim <[email-masked]>
> *Cc:* David Culler <[email-masked]> ; Geoff Mulligan<[email-masked]>; Soohong
> Daniel Park <[email-masked]> ; [email-masked] ; Mario Mao<[email-masked]>
> *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<http://tools.ietf.org/html/draft-ietf-6lowpan-format-04#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<http://tools.ietf.org/html/draft-ietf-6lowpan-format-04#section-10.3.2>
> )
>
>       UDP destination port (bit 1):
>          0: Not compressed, carried "in-line" (Section 10.3.2<http://tools.ietf.org/html/draft-ietf-6lowpan-format-04#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<http://tools.ietf.org/html/draft-ietf-6lowpan-format-04#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