Broadcast Forwarding Methodology
in [Wireless Internet]
|
Prev: Draft paper submission deadline is extended: CCN-10, Orlando, USA
Next: NEWS: Adobe Shows Flash and AIR Apps for Google Android
From: atevewr on 15 Feb 2010 12:54 Can somebody please explain me how the broadcasts work in multihop wireless networks. Are the packets unicast forwarded or broadcast forwarded. For e.g. A,B,C,D are four nodes, (A&B) in each other's range & (B,C & D) in the other range. When A broadcasts a packet, how will B forward the packet to C & D ? Unicast forwarding or it too will broadcast? If it will be broadcasted, it creates a broadcast storm, How will that be handled? Thanks in advance.
From: Jeff Liebermann on 15 Feb 2010 13:54 On Mon, 15 Feb 2010 09:54:03 -0800 (PST), atevewr <atevewr(a)gmail.com> wrote: >Can somebody please explain me how the broadcasts work in multihop >wireless networks. Are the packets unicast forwarded or broadcast >forwarded. For e.g. A,B,C,D are four nodes, (A&B) in each other's >range & (B,C & D) in the other range. When A broadcasts a packet, how >will B forward the packet to C & D ? >Unicast forwarding or it too will broadcast? >If it will be broadcasted, it creates a broadcast storm, How will that >be handled? It depends on the mesh network wireless bridge implimentation. Most early versions were your worst nightmare, where any packet without a destination MAC address is treated like a broadcast and is sprayed all over the network. STP (spanning tree) will eliminate loops, but there's still quite a bit of broadcast (and sometimes multicast) traffic. Monitoring one local municipal mesh network, all I saw were continuous ARP requests from all over the internet. This is one of the first things that mesh software and firmware has to fix. I don't know how it's done without looking at the code, but my guess(tm) is that they might cheat and insert the destination MAC address in the IP header, thus preventing the broadcast from propogating more than one hop. The routers might also cache ARP requests. Dive into some of the open source mesh networking code and see what (if anything) they do about the problem. <http://opensourcemesh.org> (Meraki based) More code: <http://opensourcemesh.org/links.html> -- Jeff Liebermann jeffl(a)cruzio.com 150 Felker St #D http://www.LearnByDestroying.com Santa Cruz CA 95060 http://802.11junk.com Skype: JeffLiebermann AE6KS 831-336-2558
From: atevewr on 16 Feb 2010 15:26 On Feb 15, 11:54 pm, Jeff Liebermann <je...(a)cruzio.com> wrote: > On Mon, 15 Feb 2010 09:54:03 -0800 (PST), atevewr <atev...(a)gmail.com> > wrote: > > >Can somebody please explain me how the broadcasts work in multihop > >wireless networks. Are the packets unicast forwarded or broadcast > >forwarded. For e.g. A,B,C,D are four nodes, (A&B) in each other's > >range & (B,C & D) in the other range. When A broadcasts a packet, how > >will B forward the packet to C & D ? > >Unicast forwarding or it too will broadcast? > >If it will be broadcasted, it creates a broadcast storm, How will that > >be handled? > > It depends on the mesh network wireless bridge implimentation. Most > early versions were your worst nightmare, where any packet without a > destination MAC address is treated like a broadcast and is sprayed all > over the network. STP (spanning tree) will eliminate loops, but > there's still quite a bit of broadcast (and sometimes multicast) > traffic. > > Monitoring one local municipal mesh network, all I saw were continuous > ARP requests from all over the internet. This is one of the first > things that mesh software and firmware has to fix. I don't know how > it's done without looking at the code, but my guess(tm) is that they > might cheat and insert the destination MAC address in the IP header, > thus preventing the broadcast from propogating more than one hop. The > routers might also cache ARP requests. Dive into some of the open > source mesh networking code and see what (if anything) they do about > the problem. > <http://opensourcemesh.org> (Meraki based) > More code: > <http://opensourcemesh.org/links.html> > > -- > Jeff Liebermann je...(a)cruzio.com > 150 Felker St #D http://www.LearnByDestroying.com > Santa Cruz CA 95060http://802.11junk.com > Skype: JeffLiebermann AE6KS 831-336-2558 Thank you sir, I tried to find some info for some protocols: While BATMAN keeps on forwarding the broadcasts "OGMs are send and repeated as UDP broadcasts, therefore OGMs are flooded until every node has received it at least once, or until they got lost due to packet loss of communication links, or until their TTL (time to live) value has expired. " OLSR anyways has its MPR's which take the responsibility of doing so. Though i am still pondering over how the opportunistic protocols handles them. The broadcast information is overheard, so whether the broadcasts should be forwarded or not. I think i should read a little more. Thanks again.
From: Jeff Liebermann on 16 Feb 2010 19:10
On Tue, 16 Feb 2010 12:26:50 -0800 (PST), atevewr <atevewr(a)gmail.com> wrote: >While BATMAN keeps on forwarding the broadcasts >"OGMs are send > and repeated as UDP broadcasts, therefore OGMs are flooded until > every node has received it at least once, or until they got lost > due > to packet loss of communication links, or until their TTL (time to > live) value has expired. " <http://tools.ietf.org/html/draft-wunderlich-openmesh-manet-routing-00> OGM's (Originator Messages) are just one type of broadcast packet. The simply announce that the node is alive and well, which is picked up by neighboring nodes in order to establish a (dynamic) route. Section 5 deals with "Flooding Mechanism" which doesn't mean generating a broadcast storm, but instead has something to do with announcing the arrival of a new node. <http://docwiki.cisco.com/wiki/Internetwork_Design_Guide_--_UDP_Broadcast_Flooding#UDP_Broadcast_Flooding> If you drop down to Section 8, there is a list of value ranges. Doesn't look like TTL is used to restrict broadcast repropagation. Otherwise, there's nothing in the BATMAN spec that talks about other types of broacasts. >OLSR anyways has its MPR's which take the responsibility of doing so. >Though i am still pondering over how the opportunistic protocols >handles them. The broadcast information is overheard, so whether the >broadcasts should be forwarded or not. >I think i should read a little more. Sorry, I don't have an instant answer. How it handles broadcasts has to be in the code somewhere. However, if you don't find a specific mechanism to limit broadcast retransmission (other than STP to prevent loops), I think it may default to handling broadcasts exactly as in the wired ethernet model, where each packet goes to ALL nodes on the network. -- # Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060 # 831-336-2558 # http://802.11junk.com jeffl(a)cruzio.com # http://www.LearnByDestroying.com AE6KS |