Hi Pascal, Pascal Thubert (pthubert) wrote: > [Pascal] Now I think I'm with you. I was confused by what you design as > a PAN that I associated with a link. So you have a single 802.15.4 short > address domain but still multiple IP hops. I guess you're doing host > routes in the original MANET fashion within the PAN and then aggregate > outside the PAN.
Yes, that's right. But, if we step back a bit, it's not much different than routing at L2, nodes are still named by their 15.4 addresses. > [Pascal] I a formal world, you should undo/redo 6lowpan at each hop and > present the encompressed packet to routing. Obviously you do not want to > do that so you accept a routing plane at L3 and a forwarding at 6LoWPAN > shim. If that's so, why not keep the mesh header format when you stay in > the same PAN? I am technically undoing/redoing 6lowpan at each L2 hop. One way to look at my L3 forwarding proposal is that the 6LoWPAN Mesh Addressing header is always compressed out because the Mesh Addressing source and destination addresses are identical to the 15.4 source and destination. Then we are left with a header that includes the 15.4 header and the compressed IP header. - When a node communicates with other nodes within a single radio hop, then both source and destination addresses may be completely elided, deriving them from the lower layers. - When a node communicates over multiple IP hops but stay within the PAN, then compressed source and destination addresses appear in the IP header. - When a node communicates with devices outside the PAN, then one of the addresses are carried uncompressed in the IP header. There's no need to use the Mesh Addressing header in any of these cases. I hope I'm making myself more clear. -- Jonathan Hui > > Talk to you soon, > > Pascal >> -- >> Jonathan Hui >> >> >>>> - For communication that stays within the PAN, there is between 4 > and >>> 16 >>>> bytes for L3 compressed addresses depending on whether the IID is >>>> derived from the short or extended address. The resulting compressed > L3 >>>> header is as small as 6 bytes (HC1, hlim, src, dst). >>> [Pascal] Why not use HC1 with link local in that case? Seems not a > most >>> probable case for HC3. >>> >>>> - For communication that crosses the PAN boundary, one of the IP >>>> addresses is always compressed and the other is not compressed. >>> [Pascal] makes sense. I guess that's the right case for HC3? >>> >>>> Although, I am planning to put in provisions to allow stateful >>>> compression by using a reserved short address range as defined in >>>> RFC4944 similar to how I've proposed to compress well-known > multicast >>>> addresses. The resulting compressed L3 header is 20 bytes, but only > 6 >>>> bytes if stateful compression is used. >>> [Pascal] great but definitely further work. >>> >>>> - When the communication occurs over a single IP hop, then the IIDs > can >>>> be completely compressed and the resulting compressed IP header does >>> not >>>> contain any addressing information. This also works when L2 > forwarding >>>> occurs and the Mesh Addressing header is used. The resulting > compressed >>>> L3 header is only 2 bytes (HC1, hlim). >>> [Pascal] I miss the rationale for the single IP hop... I must be > tired >>> :) >>> >>>> - To support both link-local and the common routable prefix, two >>>> different dispatch values are used. I was originally thinking that > the >>>> same compression format could be used in both cases. But, as you > point >>>> out, we might have greater optimizations here. The nice thing with > the >>>> same compression format is that the same parsing code path can be > used >>>> for both link-local and routable cases, but comes at the cost of one >>>> additional byte per datagram. So there is a tradeoff between > code-size >>>> and compression efficiency, as discussed early in this thread. >>> [Pascal] I agree with that too. Still HC1g needs an HC2. The real > issue >>> with HC3 seems to be the code-size compression trade off. Maybe > writing >>> some pseudo code will help figuring that out. If that's one byte in > most >>> packets it might be worth it. Also, it could mean a fast path though > the >>> parsing, and thus a better energy-efficiency. >>> >>>> Do you think this is a reasonable approach? >>> [Pascal] It is. Comments: >>> >>> 1) I'm missing the 2 bits to compress the hop limit though > considering >>> your assumptions there's a great chance that the PAN is a stub. I'd > take >>> the next header 2 bits off to HC2 to make room for this. >>> >>> 2) there's a well identified best case for HC3. I still think we can >>> make room in HC3 to indicate this and have a common HC3 for 1 and 1g. >>> >>> On the side) I fail to see why we can not fully compress a EUI-64 > based >>> suffix with HC1G. >>> >>> Pascal >>>> -- >>>> Jonathan Hui >>>> >>>>> - It seems obvious that the local address suffix can be compressed > if >>> it >>>>> is based on EUI-64 or is unambiguously associated to a 16 bits >>> address >>>>> using states somewhere (nd, reverse-ND, ...). The prefix can be >>>>> compressed if it is the only one on-link, or then again > unambiguously >>>>> associated to a 16-bits address. I'd assume that for both, >>> considering >>>>> the value of compressing, people will make sure that the conditions >>> are >>>>> met for the compression to happen. >>>>> >>>>> - It seems pretty obvious too that the remote address will not be >>>>> compressed: if it was on-link the nodes could and should use link >>> local >>>>> addresses; So it is arbitrary. So the answer I expect for my > question >>>>> above is that you expect that most times we will fully compress the >>>>> local address and not at all the remote address. >>>>> >>>>> Would that be your guess too? >>>>> >>>>> Pascal >>>>> >>>>>> -----Original Message----- >>>>>> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >>>>>> Sent: mercredi 5 mars 2008 18:32 >>>>>> To: Pascal Thubert (pthubert) >>>>>> Cc: 6lowpan; [EMAIL PROTECTED]; Jay Werb >>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>> >>>>>> >>>>>> Hi Pascal, see below: >>>>>> >>>>>> Pascal Thubert (pthubert) wrote: >>>>>>> Hi Jonathan: >>>>>>> >>>>>>> I'm certainly not willing to specialize HC3 to mesh-under > whatever >>>>> your >>>>>>> definition of the term. I'm willing to specialize HC3 to elide a >>>>> number >>>>>>> off "always on" bits so that when these bits are on, HC3 is used >>>>> instead >>>>>>> of HC1 and HC2. I hope this much is clear by now. >>>>>> Yes, this is clear now. >>>>>> >>>>>>> Consider this: even HC1g is specialized; it is specilized to the >>> case >>>>>>> when only the terminating networks are LoWPANs. For instance, how >>> do >>>>> you >>>>>>> compress a packet in a LoWPAN that would sit between the source >>>>> LoWPAN >>>>>>> and the destination LoWPAN - that's ROLL for you? >>>>>> I never said that HC1g wasn't specialized. Any compression scheme >>> must >>>>>> make assumptions about the underlying pattern, otherwise there is > no >>>>>> compression to be had. >>>>>> >>>>>> ROLL for me is where every node operates as an IP router. HC1g is >>>>> trying >>>>>> to address a PAN where each L2 hop is an IP hop. However, it is > not >>>>>> trying to address cases where the PAN is a transit network for >>> external >>>>>> networks that can have arbitrary prefixes. In other words, any >>> messages >>>>>> going into the PAN will be destined for those nodes in the PAN, > and >>>>>> similarly any messages leaving the PAN will be sourced by a node > in >>> the >>>>>> PAN. But in both cases, the addresses used are routable addresses. >>> This >>>>>> is the case I'm shooting for. Is this scenario realistic to you? >>>>>> >>>>>> -- >>>>>> Jonathan Hui >>>>>> >>>>>>> Like I said in another mail, this is a pretty difficult issue, >>> maybe >>>>>>> more complex than laying labels. My point is we do not know what >>> ROLL >>>>>>> will be made of; it will certainly be very interesting but it > would >>>>> be >>>>>>> hazardous at this point to reserve bits for assumptions we could >>> make >>>>> on >>>>>>> it. >>>>>>> >>>>>>> Let's look at what we have, which are the most important toggles >>> and >>>>> fit >>>>>>> those in HC3. I'll be glad to define that the address that > designs >>> a >>>>>>> node on this LoWPAN (the local address) is elided but is not a >>>>>>> link-local-address and that the remote address is not elided. Or >>>>>>> something else that makes sense like the local address is elided >>> and >>>>> is >>>>>>> the one that unabiguously matches the scope of the remote > address. >>>>>>> So what's the case you're shooting for? >>>>>>> >>>>>>> Pascal >>>>>>> >>>>>>>> -----Original Message----- >>>>>>>> From: Jonathan Hui [mailto:[EMAIL PROTECTED] >>>>>>>> Sent: mercredi 5 mars 2008 17:31 >>>>>>>> To: Pascal Thubert (pthubert) >>>>>>>> Cc: 6lowpan; [EMAIL PROTECTED]; Jay Werb >>>>>>>> Subject: Re: [6lowpan] Compressing HC1 and HC2 into HC3 >>>>>>>> >>>>>>>> >>>>>>>> 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
