Hi Eunsook: >The current version of the "6LoWPAN Mesh Routing Requirements" draft doesn't fill up >the chapter 5, "Analysis of Existing Mesh Routing Candidates".
Seems the people in the MANEMO Mailing List are very interested in participating to that analysis, so I copy the list. Pascal >-----Original Message----- >From: Eunsook Kim [mailto:[EMAIL PROTECTED] >Sent: Monday, March 05, 2007 9:22 AM >To: Kris Pister; Dominik Kaspar >Cc: [email protected]; [email protected] >Subject: RE: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > >Kris, Ian, > >The "6LoWPAN Mesh Routing Requirements" draft >[http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00. txt] was written >based on cautioning against some discussion of designing routing protocols for 6lowpan. >We think the first step is to mull over the differences from manet work, from the routing >perspective. >I think it is very important to clarify of the design goals and requirements of 6lowpan routing, >before discussing detail solution space. > >In this point of view, I'm happy to see your comments and consideration of this work. >I don't think we are ready to build up specification of 6lowpan routing protocols >when we are not sure how much we can use Manet protocols; >if 6lowpan may use 100% of pure manet protocols or may need major changes of them. >That's why I would like to suggest to take some time to think of >our goals and requirement in routing. > >The current version of the "6LoWPAN Mesh Routing Requirements" draft doesn't fill up >the chapter 5, "Analysis of Existing Mesh Routing Candidates". >I think this is important job to do in 6lowpan. >We will see if we really need to define 6lowpan routing protocols or not. >If we find the answer that we can use manet works, we don't need to consider seperate routing >solution. > >I wish we could have nice discussion about more of fundamental points of 6lowpan routing in this >meeting, instead of details. > >- eunsook > >---------- >From: "Kris Pister" <[EMAIL PROTECTED]> >>From Date: 2007-03-03 ?? 1:52:34 >To: "Dominik Kaspar" <[EMAIL PROTECTED]> >Cc: "[email protected]" <[email protected]>, "[email protected]" <[email protected]> >Subject: RE: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > > > > >I would like to caution against designing the mesh routing protocols >from the top down, without paying careful attention to what the MAC >sub-layer will look like. In principle, from a strict >layer-separationist perspective, it shouldn't matter. In practice, when >some devices will be running at 100% duty cycle, and (most?) others will >be constrained to run at 0.1% duty cycle, it makes all the difference. >LQI is certainly important, but 1000x difference in available bandwidth >on different links is even more important, and *must* drive the design >of higher layers if they are to be efficient. >We have seen the results of traditional networking applied to this new >class of hardware platform, and they are entertaining, academically >interesting, and commercially disastrous. >I'm a newbie to IETF, so forgive me if I'm missing some key information, >but as I see it we have come up with a reasonable format for IPv6 over >15.4 when the radios are on. The next step should be to figure out when >the radios turn on, how they avoid interference, how they >learn/announce/enforce their duty cycles, etc. Once that's done, or at >least roughed out, then a rational discussion of routing can take place. > >ksjp > >Kristofer S.J.Pister >Prof. EECS, UC Berkeley >Founder & CTO, Dust Networks > >-----Original Message----- >From: Dominik Kaspar [mailto:[EMAIL PROTECTED] >Sent: Thursday, March 01, 2007 11:34 PM >To: Ian Chakeres >Cc: [email protected]; [email protected] >Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > >Ian, all, > > > >Ian, thanks a lot for your fast reply and detailed commenting on the >"6LoWPAN Mesh Routing Requirements" draft >[http://www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00. t >xt]. >I'm taking the right to post this answer to both the 6lowpan and MANET >working groups, as MANET folks might be interested in this discussion as > >well. > > > >Ian, I find your inputs very reasonable, but they made me feel that the >term >"6lowpan" is not yet defined precisely enough to set up a strict set of >6lowpan routing requirements. For example, you give me the scenario of a > >6lowpan network, in which all devices are powered and power usage is not > >important. But if I read the "6lowpan Problem Statement" >[http://tools.ietf.org/wg/6lowpan/draft-ietf-6lowpan-problem], I'm not >sure >if such a set-up could still be called a 6lowpan, because that document >explains that in a LoWPAN "typically, some or all devices are battery >operated." > > > >This draft's intention is to provide the primary design goals of 6lowpan > >mesh routing and to stimulate responses for defining a set of >requirements. >The requirements I listed are still as vague as the term "6lowpan" >itself, >not at all proven and not fixed yet. I will keep all of your detailed >comments on the requirements in mind for a next revision. Also, it has >already been my intention to include a Section about what exactly the >differences are between routing in a MANET and in a LoWPAN. > > > >Best regards, > >Dominik > > > > > >----- Original Message ----- >From: "Ian Chakeres" <[EMAIL PROTECTED]> >To: "Dominik Kaspar" <[EMAIL PROTECTED]> >Cc: <[email protected]> >Sent: Thursday, March 01, 2007 2:00 AM >Subject: Re: [6lowpan] For comments: 6LoWPAN Mesh Routing Requirements > > >> >> Good to see some requirements for 6lowpan routing. >> >> Personally, I'd like to know what can't be done with MANET protocols >> and why. Hopefully, a future version will include this information. If >> you have any comments please send them to me or the MANET list. >> >> Ian >> >> I have some quick comments about the document. >> >> I don't think LQI by itself should be used. LQI must be matched with >> other indicators to make good decisions. LQI can be bad for routing. >> Similarly, shortest path can be bad. >> >> I think that operating with low routing state should be an >> additionally goal. For example, if devices have only 32 forwarding >> entries available. This fact could probably be captured in one of the >> existing sections. >> >> Regarding the requirements section: >> >> I think that R2 is a bad requirement. I would instead say that routing >> should be efficient. Efficiency can be defined in many ways. There >> might be 6lowpan networks where all devices are power so power usage >> is not important. Alternatively there might be nodes that choose not >> to participate even though they have energy. I think that requiring >> minimal energy routing is too harsh and unrealistic. >> >> R3. I would say that 6lowpan works below IP. Therefore, >> interconnection is not seamless but below IP. Some device will need to >> bridge (PAN coordinator or gateway) this gap. For example, RFD edge >> devices will likely not include this capability. >> >> R4. I'm not sure that routing needs to be aware of sleeping nodes. We >> could reverse the requirement and say that sleeping nodes must be >> aware of routing. Or we could create a routing protocol that should >> work independent of the sleep schedule. For example, flooding. >> >> R5. How do we measure simplicity and robustness? How much simplicity >> and robustness are required by the various 6lowpan players? >> >> R6. How mobile? How dynamic? >> >> R7. Are you referring to IPv6 ND or routing (L2 in this case) >> neighbor(hood) discovery? >> >> R9. What is the scalability requirement? How many nodes & at what >density? >> >> R10. Is L2 (WEP like) security enough? >> >> Ian >> >> >> On 2/27/07, Dominik Kaspar <[EMAIL PROTECTED]> wrote: >>> Hi all, >>> >>> A new Internet-Draft has just been submitted to emphasize the >importance >>> of >>> mesh routing in LoWPANs. I believe that well thought-out mesh routing >is >>> a >>> vital precondition for fully functional LoWPANs and should be >discussed >>> in >>> more detail within the 6lowpan working group. >>> >>> Comments are welcomed for the Internet-Draft titled: >>> "Design Goals and Requirements for 6LoWPAN Mesh Routing" >>> >>> Abstract: >>> This document defines the problem statement, design goals, and >>> requirements >>> for mesh routing in low-power wireless personal area networks >(LoWPANs). >>> >>> A URL for this Internet-Draft is: >>> www.ietf.org/internet-drafts/draft-dokaspar-6lowpan-routreq-00.txt >>> >>> Best regards, >>> Dominik >>> >>> >>> >>> _______________________________________________ >>> 6lowpan mailing list >>> [email protected] >>> https://www1.ietf.org/mailman/listinfo/6lowpan >>> >> > > > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/6lowpan > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/6lowpan > > > >_______________________________________________ >6lowpan mailing list >[email protected] >https://www1.ietf.org/mailman/listinfo/6lowpan _______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
