[olsr-dev] Fwd: Frottle and Meshes

[Dan Flett]

Hi Tim and Jim,

We in Melbourne Wireless have been playing with Frottle in an attempt to
create a version more usable in Mesh situations.

A Frottle patch and OpenWRT IPKs here:
http://www.melbournewireless.org.au/files/frottle/

It doesn't completely do away with Master and Client just yet but it
introduces "control domains".  We are testing a multi-master, multi-client
version for use on nodes with more than one wireless interface.  I was
recently testing the code but various events have put the testing on hold
for now.  Please feel free to test the code and report bugs! :)

I've been reading papers on Token circulation - I read the Wireless token
ring protocol paper from berkeley
http://www.eecs.berkeley.edu/~ergen/docs/wtrpiscc.pdf

However I think this protocol is limited because it specifies a maximum size
for a ring - if the ring reaches it's maximum size no new nodes are
admitted.  The paper suggests that those nodes change to a different channel
which doesn't seem a workable solution.

Another good paper on Token circulation can be found here:

http://faculty.cs.tamu.edu/welch/papers/icnp01.pdf 

It looks more at the logic behind efficient token-passing.

Using the knowledge obtained from these two papers I've come up with some
flowcharts that suggest possible code for a self-configuring,
distributed-token version of Frottle:

http://www.melbournewireless.org.au/wiki/?MWRPAdhocFrottleFlowcharts

It's been a little while since I put these flowcharts together, but they are
commented so if you follow them through it should make sense.  

Cheers,

Dan

-------------
View my blog:
http://freenetjazz.blogspot.com  

> -----Original Message-----
> From: (spam-protected) 
> [mailto:(spam-protected)] On Behalf Of Tim Schmidt
> Sent: Friday, 3 March 2006 3:08 PM
> To: OLSR development
> Subject: Re: [olsr-dev] Fwd: Frottle and Meshes
> 
> > just because you can't hear a node doesn't mean it can't hear you.
> 
> Of course.  I think I noted in my message that hearing the 
> 'permission slip' being passed to a node not in your ETX 
> table would allow you a one-time-use transmit window.  That's 
> a gamble.  I'm essentially relying on the fact that it's a 
> one-time-use only and that the MAC and IP stack on the node 
> with the legitimate permission can deal with any interference 
> so long as it only happens once.  Of course, transmission 
> window length would be pretty easy to play around with to 
> balance this out depending on the topology of your network, 
> or just in general. 
> For instance, the permission-window could be 3x the 
> one-time-use window.
> 
> > Also, I'm curious to know if you've thought about recovery, 
> should the 
> > node thats holding the 'permission slip' become unreachable.
> 
> Yup...  hence the timeout in the original mail.
> 
> > so write the perl and I'll see about convering it to 'C'.
> 
> I'll see what I can do.  Would you mind if I mailed you a 
> month or two from now upon completion?
> 
> > One of the *fundamental* problems with current 'mesh networks', 
> > however, is the 802.11 MAC.
> 
> Agreed.  However, it does perform some useful functions, and 
> even the most problematic machines, if at least reliably 
> problematic, can be exploited to do legitimate work.
> 
> --tim
> 
> _______________________________________________
> olsr-dev mailing list
> (spam-protected)
> https://www.olsr.org/mailman/listinfo/olsr-dev
>