My 2 cents are in line;
The slide (see the pdf above) is pretty clear about the scope of the "mesh routing" item: in 6lowpan we are not chartered to develop a new routing protocol (as in the algorithm, or the engine to generate routing tables). We have something that looks like consensus (just need the chairs to declare it so) on *adapting* routing protocols developed elsewhere. 6lowpan cannot develop protocols cuz it's not in the routing area. /snip/
In my understanding, we had some concerns to work routing solutions at 6lowpan, as you said it's not in the routing area. However, it doesn't mean that 6lowpan doesn't need to consider routing related issues for 6lowpan. IMHO, to make a solution and to handle routing related issues are different. If RSN successfully stages in the IETF, surely, RSN would be a good place to discuss routing issues for sensor networks. However, as you said below, for 6lowpan, sub-IP operations for multi-hop delivery should be considered, as RSN considers L3 routing. In my understanding, 6lowpan can be one of the applications for RSN. One way to consider 6lowpan routing issues is to put 6lowpan specific mesh-under routing requirements to RSN, as RSN is now gathering various requirements based on different applications. 6lowpan can discuss its own requirements with RSN, or input the requirements to RSN. -eunsook
As I understand it, RSN operates at layer 3, and it is arguing that there is room for another multi-hop routing WG in the routing area. Perhaps MANET can't really satisfy requirements for wireless sensors. Whether this is solved by integrating the RSN charter/deliverables into a re-chartered MANET, or by starting a new WG, from 6lowpan's point of view, 6lowpan can benefit from the resultant protocols. Of course, adaptation from layer 3 to sub-IP operation will be required, along the lines of the existing independent submissions in 6lowpan. My 2 motes (hopefully one day those will cost 1 cent each...) -gabriel ----- Original Message ---- From: Dominik Kaspar <[EMAIL PROTECTED]> To: Geoff Mulligan <[EMAIL PROTECTED]> Cc: [EMAIL PROTECTED] Sent: Sunday, June 10, 2007 9:17:11 PM Subject: Re: [RSN] The need for RSN Geoff, As far as I know, there has not been any consensus yet to what is in the scope of 6lowpan and what is not. But concering the RSN/R2LN efforts, it would be favorable to find consensus as soon as possible, so that it's clear where to dedicate new work to. Dominik On 6/8/07, Geoff Mulligan <[EMAIL PROTECTED]> wrote: > I would like to reiterate that I think that the work RSN group has > suggested taking on is very important to my working group - 6lowpan. > > Our working group is looking to recharter and the scope of the work will > be focused on issues related to interoperability for 6lowpan networks. > This include things like MIC identifiers, alternative mesh headers, > security, ... > > What is not in the scope is routing. I think the RSN concept is > important in that the devices we are anticipating have significant > constraints (power, memory, processing) and as such the current set of > protocols and development is probably not appropriate for these types of > devices. > > geoff > > > > _______________________________________________ > RSN mailing list > [EMAIL PROTECTED] > https://www1.ietf.org/mailman/listinfo/rsn > _______________________________________________ RSN mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/rsn _______________________________________________ RSN mailing list [EMAIL PROTECTED] https://www1.ietf.org/mailman/listinfo/rsn
_______________________________________________ 6lowpan mailing list [email protected] https://www1.ietf.org/mailman/listinfo/6lowpan
