Subject: [6lowpan] HC-01 draft

From: Geoff Mulligan <[email-masked]>
Date: Thu, 09 Oct 2008 17:50:48 -0600

Folks,
  The draft of the new HC format has been published as a WG document:
http://www.ietf.org/internet-drafts/draft-ietf-6lowpan-hc-01.txt

There has been some good discussion around this, but would everyone take
up that task to read and review the current draft and provide feedback.

Jonathan do you already have updates for the draft or is -01 the most
current thoughts?

So that we can close on this document sooner rather than later I am
going to continue to bug the group to deal with this document.

Please read it now and send comments to the list.

	geoff

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

---

From: Jonathan Hui <[email-masked]>
Date: Thu, 9 Oct 2008 20:06:11 -0700

Hi Geoff,

> Jonathan do you already have updates for the draft or is -01 the most

Julien has already provided good comments on 01 and we're currently  
discussion minor updates to address his concerns.

Would love to get comments from others as well.

Thanks.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Sat, 11 Oct 2008 19:30:29 +0200

Hi Geoff:

Thanks for your help here. We certainly need some from all the WG at
this point.

This draft is a trade off between:
- compression coverage
- ease/size of code
- size of the dispatch/hc

As Julien commented in the list, we do not compress all types of
multicast addresses, and only compress matching scopes between source
and destination as follows:
- Global/ULA <--> Global/ULA
- Link local <--> Link local
- Link local  --> Multicast 
- unspecified --> Multicast

Also use 4 methods of compression:
- Stateful with 16 contexts
- Stateless based on MAC header
- Stateless based on well-known prefix (link local, default global)
- Stateless based on well-known patterns (multicast, zeroed out suffix
header)

Zach mentioned in the list that the stateful method might be too
expensive for some devices out there. In fact, the draft needs to
clarify which methods:
- MAY/SHOULD/MUST be supported for encoding
- MAY/SHOULD/MUST be supported for decoding.

The more cases we support, the more bits are required in the frame to
describe the encoding and the more code is necessary to encode/decode;
so we picked a trade-off based on existing experience. Clearly we need
more feedback from this group to feel whether the trade off is
acceptable or should be tuned, in particular from the angles of:

- ease of implementation. Are complexity and code size acceptable?
- coverage. Need more? Too much already?
- Make stateful compression 16 contexts a MAY? Make --> Multicast a MAY
or a SHOULD ?

Please provide your thoughts along these line on the list. Time is
running out.

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Geoff Mulligan
>Sent: vendredi 10 octobre 2008 01:51
>To: 6lowpan
>Subject: [6lowpan] HC-01 draft
>
>Folks,