Hi Jonathan:

>> - 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.
>
>Right.  

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

>-----Original Message-----
>From: Jonathan Hui [mailto:[EMAIL PROTECTED]
>Sent: mardi 11 mars 2008 13:28
>To: Pascal Thubert (pthubert)
>Cc: 6lowpan
>Subject: Re: [6lowpan] New 6LoWPAN HC Draft Availble
>
>
>Hi Pascal,
>
>Pascal Thubert (pthubert) wrote:
>> 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.
>
>Thanks.
>
>> I'll provide my detailed comments separately; the substance, though,
is
>> that:
>> - 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.
>
>> - 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.
>
>Right.
>
>> - I'm still interesting in compressing the HCs, but that can be done
>> separately.
>
>Sure.
>
>Thanks.
>
>--
>Jonathan Hui
>
>>
>> Thanks again,
>>
>> Pascal
>>
>>> -----Original Message-----
>>> From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED] On
>> Behalf Of Jonathan Hui
>>> Sent: lundi 10 mars 2008 19:04
>>> To: 6lowpan
>>> Subject: [6lowpan] New 6LoWPAN HC Draft Availble
>>>
>>>
>>> 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 protected]
>>> https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[email protected]
https://www.ietf.org/mailman/listinfo/6lowpan

Reply via email to