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
