Hi Zach. See below: Zach Shelby wrote: > Very nice discussion. > > I see the logic in going after a more aggressive HC3 compression for use > within the 6lowpan network. It also would incorporate elided CRC which I > would also like to see it for local use. So far from my implementation > and use experience HC3 would cover 95% of our use of 6lowpan.
This completely depends on how you implement your 6LoWPAN network. I can see how HC3 would work well for mesh-under networks where one or more 802.15.4 networks are abstracted as a single IP link. However, HC3 does not work well if we assume route-over, where every link/radio hop is an IP hop. Because I've been working with route-over networks, I can say that HC3 is insufficient for 95% of my use cases. > Why wouldn't the HC3 proposal work with both mesh under or route over? > e.g. MANET routing protocols are also mainly using flat IP addressing > within the MANET. So in reality route-over would likely use the MAC > address of the interface and elide the IPv6 address when using 6lowpan > at least, just as in 6lowpan "mesh under" as long as the destination > address is in the same subnet. It would be quite easy to switch to > HC1+HC2 or HC1g in the case that you detect that the destination address > has a different non link-local prefix. Please correct me if I am wrong > here... In my view, one difference between mesh-under and route-over is whether or not the 6LoWPAN Mesh Addressing header is used. In mesh-under, the Mesh Addressing header is used to deliver a datagram over multiple L2 hops but only a single IP hop, and when link-local addresses are used, both addresses in the IP header can be completely elided. In route-over, no Mesh Addressing header is used, every L2 hop is an IP hop, and the source and destination addresses are carried directly in the IP header. Given this difference, I don't see how HC3 would support carrying addresses in the IP header. Now, as you state, ad-hoc routing does often boil down to host based routing. For that very point, I think the difference between forwarding at L2 vs. forwarding at L3 is less than we think. At some level, it's about where do the addresses go. The goal of HC1g is to provide a way to express both extended and short addresses in the IP header, with the assumption that the Mesh Addressing header will not be used. -- Jonathan Hui > Of course both HC3 and HC1g would be needed in such networks, as HC1g > allows us to communicate outside the 6lowpan network with minimal > overhead. So I am in favor of both. Of course there is the question if > we would have a place for HC3 in the new charter? > > - Zach > > 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:[EMAIL PROTECTED] >>> Sent: mardi 4 mars 2008 18:05 >>> To: Pascal Thubert (pthubert) >>> Cc: 6lowpan; [EMAIL PROTECTED]; 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 >>>> [email protected] >>>> https://www.ietf.org/mailman/listinfo/6lowpan >> _______________________________________________ >> 6lowpan mailing list >> [email protected] >> https://www.ietf.org/mailman/listinfo/6lowpan > > _______________________________________________ 6lowpan mailing list [email protected] https://www.ietf.org/mailman/listinfo/6lowpan
