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:[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
