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
