> >Pascal Thubert (pthubert) wrote: >>> For demonstration purposes, let's first assume that every node acts as >>> an L3 forwarder. In this case, no Mesh Addressing header is used and >>> compressed addresses are carried in the compressed L3 header. >>> >> [Pascal] But if there's no mesh, why can't we pick the addresses from >> the MAC header? > >I think our ideas of the network are still not matching up. In one case, >I'm assuming that every node is doing L3 forwarding, meaning that each >15.4 hop is an IP hop. Every 15.4 hop decrements the IPv6 Hop Limit by >one. In this case, you can deliver messages over multiple hops without a >Mesh Addressing header. But you still need source and destination >addresses distinct from the MAC header. If you are delivering a message >over a single L2 hop, then the IP addresses can be completely elided and >derived from the 15.4 header.
[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. [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? 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
