Hi Jonathan: I do not see the backbone router as an ISA thing. I see that ISA requires a functionality and that some people at 6LoWPAN (that obviously includes me but I hope there's more) are willing to work on an IETF solution to help them out. So the requirement is ISA100 but the solution draft is 6LoWPAN for sure.
I'm very positive with ROLL and I'll help as much as I can there; I agree with all your points about architecture. Now, the problems to be solved are quite complex and that's certainly quite a lot of work ahead to get all the basic ingredients in place to propose a global solution. Just the compression of the addresses across multiple hops will be an interesting challenge. Will we use 2 bytes addresses as labels? Centralize routing? Now if we consider the time frames, the specs that we have available (that's mostly RFC 4944) and the cases that must be solved in the near term, then the single link with a gateway is a reasonable first step to crystallize what we have - though I'm 100% with you that it is certainly not the end of the way. So I'm looking for an HC3 that is an immediate improvement on HC1 and 2 as we know them for a very practical application that we have already in front of us waiting. Thus the proposals that you have seen. I do not see that as a threat for the future end-to-end IPv6 which will definitely come in time. Do we seem to agree after all? 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
