Hi, Bishal and Javier, In terms of implementation, I just wish to know how are we going to differentiate the MAC addresses for a particular Mesh Node with multiple radio support. If let say Mesh Node A has two radio cards creating two mesh node interfaces separately, it will have two MAC addresses. We should assume only one MAC address occurs in our mesh forwarding table, am I right?
A quick check on indicates batman node ( http://www.open-mesh.org/wiki/batman-adv/Understand-your-batman-adv-network) only announcing one MAC address which is the batX interface. Please advice. Thanks Regards, Chun-Yeow On Thu, Dec 15, 2011 at 8:41 AM, Javier Cardona <[email protected]> wrote: > On Wed, Dec 14, 2011 at 8:48 AM, Bishal Thapa <[email protected]> wrote: > > Hi Chun-Yeow, > > I agree and disagree. I agree in part, because I like the idea of one > single forwarding table (instead of "n" mesh path tables for "n" > interfaces) indicating which out-going interface for next-hop. But I > disagree about the bridge concept. There will be overhead specially if we > were to make this a scalable solution. Plus, the forwarding table that goes > with the bridge, I am assuming you mean ebtables. Ebtables lose the > advantage that our mesh tables have: If there are two entries for the same > destination, but leaving from two different interfaces, the airtime metric, > by definition, would enable picking the "better" interface. What do you > think? Did I misunderstand any/all of your suggestion? > > FWIW, currently there is only one single forwarding table per host. > If there are multiple mesh interfaces, they all share that same table. > There is no forwarding between mesh interfaces, but as I said, it > would not be hard to implement. The way I envisioned this working > from userspace was to have a single mesh configuration parameter > (mesh_iface_forwarding or something like that) that, when set, would > enable forwarding between compatible mesh interfaces. > And by compatible I mean in the 802.11s standard sense: same mesh id, > same metric, etc. and not necessarily the same channel. > But I'm not sure what would be the advantage of having another > interface that combines all the compatible mesh interfaces. If > mesh_iface_forwarding was enabled, one could use indistictly use any > of the compatible mesh interfaces to send traffic. Thoughts? > > Cheers, > > Javier > > > ----- Original Message ----- > > From: "Yeoh Chun-Yeow" <[email protected]> > > To: [email protected] > > Cc: "Bishal Thapa" <[email protected]> > > Sent: Tuesday, December 13, 2011 7:49:44 PM GMT -05:00 US/Canada Eastern > > Subject: Re: Question about joining meshes together > > > > Hi, Bishal > > > > > > IMHO, we should borrow the concept from the batman-adv. One single > bridge interfaces combining all the mesh interfaces and one single > forwarding table indicating which out-going interface for next-hop. > > > > > > Regards, > > Chun-Yeow > > > > > > On Wed, Dec 14, 2011 at 6:53 AM, Bishal Thapa < [email protected] > > wrote: > > > > > > Hi Javier, > > I am thinking about implementing this (while I wait for more hardware to > do various multi-hop tests). One quick question to what you suggested: > Isn't the forwarding table different for different interfaces in a > multi-radio mesh node. Unless we create a "massive" super mesh path table, > we would have to populate each of the "n" mesh path tables for "n" mesh > interfaces ( with updates to the interface field, etc. on how to get to > next hop for reaching a destination). An alternate could be (again if we do > not create a super mesh table), to enumerate through each of the "n" mesh > path tables and find if there is a path for that specific destination in > one of the "n" mesh path tables (not efficient though)? > > > > Thanks, > > > > > > Javier Cardona wrote on Fri, 02 Dec 2011 07:19:38 -0800: > > > > Hi Giovanni, > > > > On Fri, Dec 2, 2011 at 6:49 AM, David Goodenough > > < [email protected] > wrote: > >> On Friday 02 Dec 2011, Giovanni Di Stasi wrote: > >>> Hi Javier, > >>> > >>> thanks for your reply. > >>> > >>> Would it be difficult to add multi-channel support in the > implementation? > >>> Could you please briefly describe the parts of the implementation that > need > >>> to be modified? > > > > In order to add multi-channel support you need to: > > > > - Modify the PREQ propagation mechanism so PREQs are retransmitted on > > all interfaces, not just on the one on which the PREQ was received. > > - Modify the forwarding table to add which interface should be used > > to reach the next hop. > > - Modify the mesh data frame forwarding function to forward frames > > via the right interface. > > > > Cheers, > > > > Javier > > > > _______________________________________________ > > Devel mailing list > > [email protected] > > http://open80211s.com/mailman/listinfo/devel > > > > -- > > Bishal Thapa, Ph.D. > > Wireless Security Lab - 202 WVH > > College of Computer and Information Science > > Northeastern University > > Boston, MA 02115 > > www.ccs.neu.edu/home/bthapa > > _______________________________________________ > > Devel mailing list > > [email protected] > > http://open80211s.com/mailman/listinfo/devel > > > > -- > Javier Cardona > cozybit Inc. > http://www.cozybit.com >
_______________________________________________ Devel mailing list [email protected] http://open80211s.com/mailman/listinfo/devel
