Re: [6lowpan] Compressing HC1 and HC2 into HC3

[Jonathan Hui <[e-mail]>]

In your draft, you claim that 6LoWPAN nodes address each other and the 
backbone router using link-local addresses. If that occurs over multiple 
radio hops, that sounds like mesh under to me... In other words, you are 
assuming that an entire PAN functions as a single IP link (the IPv6 
definition of a link). Am I missing something here?

--
Jonathan Hui


Pascal Thubert (pthubert) wrote:
> Hi Jonathan:
> 
> You are assuming explicitly that I am assuming implicitly... mesh
> under... Hum.
> 
> Please have a look at
> http://www.ietf.org/internet-drafts/draft-thubert-lowpan-backbone-router
> -00.txt and it should be apparent that I'm not. In particular the
> backbone router is the device that will set and use the hop limit bit.
> So will all those interconnecting devices used in pseudowire, split
> bridges, IP Mobility, etc... if they are deployed in this space.
> 
> What I'm really assuming is a gateway or an edge server on the link.
> It's there in most architectures that I know of at this point that's why
> I included it in the case we shoot for and saved 2 bits. Note that when
> the ULA and global addresses are used on top of link local, it makes
> sense that we define a mechanism to compress them as well. But this is
> not what HC3 is about.
> 
> The goal of my initial proposal is illustrative, to foster this very
> discussion around the idea that we can shoot for a favorite case and
> make an HC3 out of HC1 and HC2 for that case. Now, if we as a group
> think that the GW assumption is not reasonable, then, fine, let us
> affect 2 bits in HC3 to indicate whether the addresses are compressed. 
> 
> What do the others think?
> 
> Pascal
>> -----Original Message-----
>> From: Jonathan Hui [mailto:[e-mail]]
>> Sent: mardi 4 mars 2008 18:05
>> To: Pascal Thubert (pthubert)
>> Cc: 6lowpan; [e-mail]; Jay Werb
>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3
>>
>>
>> Hi Pascal,
>>
>> Thanks for sharing your thoughts.
>>
>> By assuming the first 5 bits in HC1 are '1', you're staking a claim
> that
>> mesh-under link-local communication within a PAN is going to be most
>> common case and the one we've "shot for". If link-local is all we focus
>> on, then we are missing the point of IP. Frankly, I don't see much
>> benefit of IP if communication is limited to the PAN.
>>
>> W.r.t mesh-under, there are efforts within the IETF that assume 6LoWPAN
>> nodes will communicate via route-over using routable addresses (e.g.
>> ROLL). This brings us back to a broader topic of route-under vs.
>> mesh-under. While both will probably exist for some time, it raises the
>> question of whether 6LoWPAN implementations can support one or do they
>> have to support both.
>>
>> W.r.t compressing Hop Limit, I don't quite understand why you're using
> a
>> bit in HC3 to indicate where the message originated. If you're assuming
>> link-local communication, then messages shouldn't be forwarded across
>> links anyway.
>>
>> I do agree that there is work to do on compression and agree that there
>> are cases where HC1 and HC2 are not sufficient. This is why I've been
>> working, albeit slowly, on HC1g.
>>
>> --
>> Jonathan Hui
>>
>>
>> Pascal Thubert (pthubert) wrote:
>>> Dear 6LoWPANers,
>>>
>>> Though HC1 and HC2 provide us with the capability to express any
>>> combination of compression, the most expected (or at least shot for)
>>> case does not lead to a better compression of the HC headers
> themselves.
>>> Seems that we could define an HC3 that would compress the pair of HC1
>>> and HC2 for that best case. My proposal for doing this would be to:
>>>
>>> - define a new dispatch
>>>          | 01  000011 | LOWPAN_HC3 - LOWPAN_HC3 compressed IPv6 and
>>> transport
>>>
>>> - define HC3 itself to:
>>>
>>> 	- implicitly say that the first 5 bits of HC1 are all ones
>>> 	- carry HC1 bits 5 and 6 (Next Header)
>>>       - replace HC2 so bit 7 of HC1 is useless
>>>       - provide transport specific bits such as those defined for
>>> HC-UDP,
>>>         then again assuming a predefined best case if room is missing
>>>
>>> An example of what the HC3 octet could be:
>>>
>>>   bits        0                  1              2-3
>>> 4-7
>>>
>>>
> +------------------+-------------+-----------------+--------------------
>>> ---------------------+
>>>        | reserved         |  reserved   |  Next Header    |
> transport
>>> specific control bits      |
>>>
>>>
> +------------------+-------------+-----------------+--------------------
>>> ---------------------+
>>>
>>> Next header:  as defined in HC1, bits 5 and 6
>>>
>>> transport specific control bits for UDP:
>>>    bit 4 echoes HC-UDP bit 0 on UDP source port
>>>    bit 5 echoes HC-UDP bit 1 on UDP destination port
>>>    bit 6 echoes HC-UDP bit 2 on UDP length
>>>    bit 7 is reserved
>>>
>>> What do you think?
>>>
>>> Pascal
>>> _______________________________________________
>>> 6lowpan mailing list
>>> [e-mail]
>>> https://www.ietf.org/mailman/listinfo/6lowpan
_______________________________________________
6lowpan mailing list
[e-mail]
https://www.ietf.org/mailman/listinfo/6lowpan