Hi Jonathan:
>HC1g assumes the following: >- IID is either derived directly from EUI-64 or short address. >- All nodes within a PAN are assigned a single common routable prefix. [Pascal] yes, perfect. > >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? >- 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
