Hi Jonathan: I'm not sure ROLL precludes the idea of prefix and aggregation, so I'm not sure every node operates as a router, not even than every node can operate as a router. In fact I'm not even sure that every forwarding node performs routing computations either. I think that ROLL is what we have not made it yet. 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:
- 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
