Hi all, On Wednesday 14 December 2011 16:41:28 Javier Cardona 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?
I work with Giovanni, who raised the point of supporting multi-radio operations. My vision is exactly that described by Javier: one single mesh, each mesh node has a single forwarding table and may have multiple interfaces, each of which is used to send traffic to a (possibly) distinct set of neighbors (depending on the channel assignment). There should be no need to use a bridge interface. I confirm that it is our interest to implement such functionality and we would be glad to coordinate our efforts with anyone else is interested (Bishal?) Cheers, Stefano > Cheers, > > Javier _______________________________________________ Devel mailing list [email protected] http://open80211s.com/mailman/listinfo/devel
