Subject: [6lowpan] New 6LoWPAN HC Draft Availble

From: Jonathan Hui <[email-masked]>
Date: Mon, 10 Mar 2008 11:04:03 -0700

6LoWPAN WG,

There's a new draft available that specifies a new header compression 
format for 6LoWPAN networks. It's a follow-on to the HC1g draft. It also 
captures some of the discussion with Pascal last week.

http://www.ietf.org/internet-drafts/draft-hui-6lowpan-hc-00.txt

Read it over before the WG meeting if you get a chance. Provide comments 
or suggestions on the list.

Thanks.

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

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Mar 2008 12:53:02 +0100

Hi Jonathan:

Thanks a lot for this excellent draft. From the standpoint of
ISA100.11a, it is going a long way in the right direction. I think it is
actually ripe for election as WG document and you've got my vote for it.
This is hardly surprising considering your earlier work on RFC 4944 and
HC1G.

I'll provide my detailed comments separately; the substance, though, is
that:
- we need to refine the Hop limit text as you point out
- we should be able to extend the concept of common prefix compress
global addresses that result from states without being specific on how
the addresses are passed on, which I understand is another charter item.
- I'm still interesting in compressing the HCs, but that can be done
separately.

Thanks again,

Pascal

>-----Original Message-----
>From: [email-masked] [mailto:[email-masked]] On
Behalf Of Jonathan Hui
>Sent: lundi 10 mars 2008 19:04
>To: 6lowpan
>Subject: [6lowpan] New 6LoWPAN HC Draft Availble
>
>
>6LoWPAN WG,
>

---

From: Jonathan Hui <[email-masked]>
Date: Tue, 11 Mar 2008 05:27:48 -0700

Hi Pascal,

Thanks.

> - we need to refine the Hop limit text as you point out

After some discussion with Carsten, it seems that we may need both bits 
for Hop Limit compression. Current idea now is that 1-bit indicates 
compression, another bit indicates whether the elided Hop Limit is 63 or 
1. I originally thought we could do egress filtering based on the 
destination address, but Carsten thought that it missed the point of the 
Hop Limit. The cost is we utilize the reserved bit in the IPHC encoding 
and remove any flexibility it could have provided.

> the addresses are passed on, which I understand is another charter item.

Right.

> - I'm still interesting in compressing the HCs, but that can be done

Sure.

Thanks.

--
Jonathan Hui

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Mar 2008 14:31:24 +0100

>and remove any flexibility it could have provided.

You know I started exactly like Carsten. 

In the thread with you, we discussed that the router that performs a
local delivery could elide the Hop limit without the additional bit
because it expects that the packet will never appear at L3 again. There
are a number of caveats to that approach, including proxy, and
indirection. So I do feel safer if we stick to the 2 bits.

This might look expensive but if we do the fast path HC3 that we
discussed already, then the first bit will be easily defaulted due to
the assumption that the LoWPAN is a stub, so the fast path clearly
compresses the hop limit.

So I'm all for the proposed change.

Pascal

>From: Jonathan Hui [mailto:[email-masked]]
>Sent: mardi 11 mars 2008 13:28
>To: Pascal Thubert (pthubert)
>Cc: 6lowpan
>Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble
>
>
>Hi Pascal,
>

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 11 Mar 2008 16:46:26 +0100

>> the addresses are passed on, which I understand is another charter
item.

Let me propose some text then. I feel that a limited change in section
2.2 
should do the trick:

Before

"   IPv6 unicast addresses may be compressed to 64, 16, or 0 bits.  When
   an IPv6 unicast address is compressed, the elided bits are implicitly
   the Common Prefix (CP).  The CP can either be the link-local prefix
   or Common Routable Prefix (CRP).  The 6LoWPAN dispatch value
   identifies which CP is being used.  A 6LoWPAN dispatch value of 0x03
   (TBD) indicates a LOWPAN_IPHC compressed IPv6 header and the CP is
   the link-local prefix.  A 6LoWPAN dispatch value of 0x04 (TBD)
   indicates a LOWPAN_IPHC compressed IPv6 header and the CP is the
   Common Routable Prefix.  The Common Routable Prefix may be obtained
   with IPv6 Stateless Address Autoconfiguration when autoconfiguring an
   address[RFC4862].  Other mechanisms for obtaining the CRP or
   selecting a CRP among two or more routable prefixes are out of scope
   of this document.
"

What about

"  IPv6 unicast addresses may be compressed to 64, 16, or 0 bits.  
   A 6LoWPAN dispatch value of 0x03 indicates that the compressed
   Address is a link local address whereas a 6LoWPAN dispatch value 
   of 0x04 (TBD) indicates a wider scope, for instance a Unique 
   Local Address or a Global Unicast address. In the latter case, 
   it is expected that the IPv6 address can be unambiguously 
   inferred from the information in the packet and states present 
   in the LoWPAN node. 

   For instance, if the address is compressed to 64 bits, then the
prefix 
   is elided and it is expected that there is a Common Routable Prefix 
   that can unambiguously be determined to recover the complete address.

   The Common Routable Prefix may be obtained with IPv6 Stateless
Address
   Autoconfiguration when autoconfiguring an address[RFC4862].  
   Other mechanisms for obtaining the elided information are out of
scope 
   of this document.
"
Pascal

---

From: Carsten Bormann <[email-masked]>
Date: Tue, 11 Mar 2008 11:55:48 -0400

On Mar 11 2008, at 08:27, Jonathan Hui wrote:

> The cost is we utilize the reserved bit in the IPHC encoding

We still have 1/2 bit (we use only 3 out of 4 bit combinations).

Gruesse, Carsten