Pascal Thubert (pthubert) wrote: > We are in sync on what HC1g does and why; that makes all the sense in > the world to me and you've got my support and help if needed. My > question was really what is the HG1g pattern that you expect most times? > I mean, if you propose a compression mechanism you intend to use it. And > I'd say heavily. If I follow you well:
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. 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. - 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). - For communication that crosses the PAN boundary, one of the IP addresses is always compressed and the other is not compressed. 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. - 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). - 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. Do you think this is a reasonable approach? -- 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
