Hi Zach, I agree that we should have an approach that supports both mesh-under and route-over. I also think there is hope for us to get there.
In moving toward that direction, I can rev the HC1g draft and incorporate some of the ideas mentioned recently on this list. I can incorporate the UDP checksum optimization, that is easy to do as HC1g uses the same HC2 header. I can also work with Pascal to find a way in incorporating his suggestions. In this case, the name will probably change from HC1g since it's no longer just about routable addresses. I wasn't able to generate much discussion about the initial draft on HC1g, so hopefully the new rev will stimulate more discussion :-). -- Jonathan Hui Zach Shelby wrote: > Guys, > > I also would not like specialized solutions for mesh-under and > route-over, and in fact with ROLL certainly going L3.. I am foreseeing > already that the 6lowpan Mesh Header will depreciate eventually. > > So I agree with Jonathan that we need to allow for routing using > (compressed) L3 addresses, and any further compression option should > allow for this. I would encourage a combined HC3/HC1g which allows for > route-over for current usage and UDP Checksum eliding combining the most > common compression options. HC1g has been slow coming along, maybe this > combination would give it the wider support needed? > > We are currently using the 6lowpan Mesh Header for routing but also > employ ICMP messages with IPv6 hop-limit decrements, so it is really > just a matter of where to store the addresses. Whose idea was the mesh > header in the first place? ;-) It has at least used up tons of IETF > mailing list bandwidth! > > - Zach > > Jonathan Hui wrote: >> >> 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
