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?
----- 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
