I think it's fair to say that we should continue working on IP header compression. However, I also think we must evaluate whether we are willing to specialize such compression schemes for route-over vs. mesh-under networks. I don't have a problem with such specialization, but I would have a problem if we required any 6LoWPAN implementation to support specialized schemes for both mesh-under and route-over simultaneously.
-- Jonathan Hui Pascal Thubert (pthubert) wrote: > Hi Jonathan > > I agree it's great we are having this discussion :) > > Multiple thread could spawn from it because there are multiple topic. > And some of this might belong to ROLL as you pointed out earlier. > > I'd wish to keep this thread for its original question on whether it is > desirable, in the context of what we already have, to further compress > HC1 and HC2 into a single HC3. For that specific thread, I retain that > you do not oppose but that you vote for retaining some information on > whether the addresses are elided or not. > > Is that fair? > > Pascal > >> -----Original Message----- >> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >> Sent: mercredi 5 mars 2008 09:28 >> To: Pascal Thubert (pthubert) >> Cc: 6lowpan; [EMAIL PROTECTED]; Jay Werb >> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >> >> >> Regarding the GW assumption on the link, I think we need to take a step >> back for a second. While it is true that most architectures up until >> this point follow this assumption, most architectures that I know of >> haven't been built using IP. ZigBee nodes, for example, only > communicate >> with ZigBee nodes at every hop and there isn't any effort to do >> internetworking. >> >> But now that we actually have IP, we are no longer constrained to a >> single link technology. Rather, nodes can communicate with each other, >> directly using 802.15.4, or over other technologies such as WiFi, >> Ethernet, GPRS, etc. This really opens up the network architecture >> possibilities, and there are many cases where adding these additional >> links are desirable. I know that ISA's proposed backbone routers > provide >> this functionality, but I'd rather support such networks at the IP >> layer, rather than abstracting a combination of link technologies as >> single IP link and defining any new machinery to do so. >> >> BTW it's great that we're having this discussion. It is long overdue. >> >> -- >> 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:[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
