Subject: Re: [6lowpan] Fwd: New Version Notification for draft-ietf-6lowpan-hc-05

From: anthony schoofs <[email-masked]>
Date: Wed, 1 Jul 2009 15:14:51 +0100

Hi Jonathan, Pascal,

I had two general questions about the 6LoWPAN hc-05 draft.

- Sections 3.2 and 3.3 define compression formats for IPv6 extension and UDP
headers, using the LOWPAN_NHC header.
Wouldn't it be a good opportunity to include now more compression formats,
for instance for common headers such as TCP and ICMPv6? Having them included
in a RFC would ensure interoperability at later stage whenever people wish
to use them. This document might be the right place.

- As the hc draft aims at updating RFC4944, some extra text could indicate
what parts of RFC4944 are still valid, such as 6LoWPAN fragmentation. This
would help for understanding how RFC4944 and the updating RFC complete each
other.

Kind regards,
Anthony

On Tue, Jun 30, 2009 at 6:14 PM, Jonathan Hui <[email-masked]> wrote:

>
> Hi everyone,
>
> Below is a summary of changes in this draft. Please send comments. Thanks.
>
> 1) Specify use of context 0 when CID is 0.
> - addresses ticket #32
>
> 2) Made prefix-based multicast encoding format more explicit for  clarity.
> - addresses ticket #33
>
> 3) Indicate that first 64-bits is link-local prefix padded with zeros when
> link-local prefix is elided.
> - addresses ticket #34
>
> 4) Full 128-bit address inline only in stateless encoding.
> - Removes encoding redundancy and doesn't make sense to allow a
> non-stateful mode when stateful compression is specified.
>
> 5) Removed support for compressing unspecified address.
> - Falls out of change (4). Unspecified address probably won't be used much
> since we are changing how DAD works in 6LoWPAN networks.
>
> 6) Added support for IPv6 Extension Headers as well as IP-in-IP with new
> LOWPAN_NHC encodings.
> - Mostly what we talked about at the SF meeting.
>
> 7) Allow for completely stateful compression.
> - Changed wording around stateful compression so that inline bits can be
> used as an additional index to identify the compressed address.
>
> --
> Jonathan Hui
>
> Begin forwarded message:
>
>  From: IETF I-D Submission Tool <[email-masked]>
>> Date: June 30, 2009 10:05:12 AM PDT
>> To: [email-masked]
>> Cc: [email-masked]
>> Subject: New Version Notification for draft-ietf-6lowpan-hc-05
>>
>>
>> A new version of I-D, draft-ietf-6lowpan-hc-05.txt has been successfuly
>> submitted by Jonathan Hui and posted to the IETF repository.
>>
>> Filename:        draft-ietf-6lowpan-hc
>> Revision:        05
>> Title:           Compression Format for IPv6 Datagrams in 6LoWPAN Networks
>> Creation_date:   2009-06-30
>> WG ID:           6lowpan
>> Number_of_pages: 19
>>
>> Abstract:
>> This document specifies an IPv6 header compression format for IPv6
>> packet delivery in 6LoWPAN networks.  The compression format relies
>> on shared context to allow compression of arbitrary prefixes.  The
>> information that is maintained in that shared context is out of
>> scope.  This document specifies compression of multicast addresses
>> and a framework for compressing next headers.  This framework
>> specifies UDP compression and is prepared for additional transports.
>>
>>
>>
>> The IETF Secretariat.
>>
>>
>>
> _______________________________________________
> 6lowpan mailing list
> [email-masked]
> https://www.ietf.org/mailman/listinfo/6lowpan
>

---

From: Jonathan Hui <[email-masked]>
Date: Wed, 1 Jul 2009 15:55:39 -0700

Hi Anthony,

On Jul 1, 2009, at 7:14 AM, anthony schoofs wrote:
> - Sections 3.2 and 3.3 define compression formats for IPv6 extension  
> and UDP headers, using the LOWPAN_NHC header.
> Wouldn't it be a good opportunity to include now more compression  
> formats, for instance for common headers such as TCP and ICMPv6?  
> Having them included in a RFC would ensure interoperability at later  
> stage whenever people wish to use them. This document might be the  
> right place.

If we had a good proposal for compressing ICMPv6 and TCP, then I think  
you're right. We've basically punted on ICMPv6 and TCP simply because  
we haven't come up with something compelling yet. For TCP, we'd  
probably want some negotiation to avoid flow-based compression state  
and code complexity when that is undesired.

> - As the hc draft aims at updating RFC4944, some extra text could  
> indicate what parts of RFC4944 are still valid, such as 6LoWPAN  
> fragmentation. This would help for understanding how RFC4944 and the  
> updating RFC complete each other.

Sure. We'll add this into the next revision.

Thanks.

--
Jonathan Hui

> 3) Indicate that first 64-bits is link-local prefix padded with  
> zeros when link-local prefix is elided.
> - addresses ticket #34
>
> - Removes encoding redundancy and doesn't make sense to allow a non- 
> stateful mode when stateful compression is specified.
>
> - Falls out of change (4). Unspecified address probably won't be  
> used much since we are changing how DAD works in 6LoWPAN networks.
>
> 6) Added support for IPv6 Extension Headers as well as IP-in-IP with  
> new LOWPAN_NHC encodings.
> - Changed wording around stateful compression so that inline bits  
> can be used as an additional index to identify the compressed address.
>
> --
> Jonathan Hui
>
> Begin forwarded message:
>
> A new version of I-D, draft-ietf-6lowpan-hc-05.txt has been  
> successfuly submitted by Jonathan Hui and posted to the IETF  
> repository.
>