Hi Yeoh, On Thu, Dec 15, 2011 at 2:07 AM, Yeoh Chun-Yeow <[email protected]> wrote: > 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?
When we had prototyped this in the past we had used two (or more) mac addresses, one per radio. I am not sure what you mean by "how are we going to differentiate the MAC addresses" (specially if they *are* different :). The way I see it, a host with two interfaces should have separate MAC addresses per interface. Locally originated traffic sent via one of the interfaces would trigger PREQs (with the originator interface's MAC address in the body of the PREQ) out of *both* interfaces. Direct neighbors to the originator interface could establish one-hop paths. But neighbors to the second interface would see two-hop paths to the originator interface (the internal forwarding between local interfaces would appear to other nodes as an extra hop with zero cost). I can see that a single MAC may avoid this "zero-cost hop" but it would not work if both radios were on the same channel. And that is a likely use case (for instance, hosts with multiple radios with directive antennas on the same channel). That said, this is just my opinion. The standard is silent about how one should implement multi-channel support, leaving that as a design task for implementers. > 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. Hmmm. Interesting, but not sure if applicable to o11s... Cheers, Javier > > 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 > > -- Javier Cardona cozybit Inc. http://www.cozybit.com _______________________________________________ Devel mailing list [email protected] http://open80211s.com/mailman/listinfo/devel
