Hi!
My name is Vojislav Marinkovic and I am a student of Electrical Engineering at the Royal Institute of Technology in Stockholm. My major is Communication Networks and right now I am looking for an interesting subject for my masters thesis. While browsing the Internet for some interesting topics, I ran into your project which is very similar to (yet better than) one of my own ideas. So I thought "why should I put time on inventing wet water instead of joining the project?",
On your homepage you stated that you have a lot of ideas but you don't have the time to implement them all. My question is, do you have any ideas that would fit to be done as a masters thesis in communication networks? It could be anything from an issue related to the protocol itself or it could be porting an already deployed technology on other types of networks to the B.A.T.M.A.N. (I'm not suggesting anything, but as an example let's say potential issues with live streaming over a B.A.T.M.A.N.-network), comparing B.A.T.M.A.N. some other routing protocol/s or any other topic related to my major subject. I really don't have any idea on what problems you have encountered so please help me find a good topic for my masters thesis.
The thesis will be done during this summer.
Thank you in advance Vojislav Marinkovic
Hello Vojislav!
I have a personal wish list of things that would be great to have in Batman. I don't know if any of these would be suitable/interesting for you, but I will use the opportunity to post it to the list now:
* Modify Batman-0.3.X in order to support IPv6 * Improve Batman with regards to protocol overhead and convergence speed * Get support for other operating systems working (so far it only works with Linux) * Implement a minimalistic and power saving Batman client version for embedded mobile devices * Modify Batman-0.3.X code so we have an option to compile it without policy routing support * Modify the way that Batman-Advanced (Layer 2) deals with broadcast/multicast payload packages (on multihop wireless routes there is always packet loss, protocols like DHCP use broadcast or multicast messages which are not send redundantly and not acknowledged, so these protocols which are not designed to deal with a high level of packetloss have difficulties to work on a Layer 2 mesh as the number of hops and packet loss on the media increases)
Cheers, elektra
Hi!
My name is Vojislav Marinkovic and I am a student of Electrical Engineering at the Royal Institute of Technology in Stockholm. My major is Communication Networks and right now I am looking for an interesting subject for my masters thesis. While browsing the Internet for some interesting topics, I ran into your project which is very similar to (yet better than) one of my own ideas. So I thought "why should I put time on inventing wet water instead of joining the project?",
On your homepage you stated that you have a lot of ideas but you don't have the time to implement them all. My question is, do you have any ideas that would fit to be done as a masters thesis in communication networks? It could be anything from an issue related to the protocol itself or it could be porting an already deployed technology on other types of networks to the B.A.T.M.A.N. (I'm not suggesting anything, but as an example let's say potential issues with live streaming over a B.A.T.M.A.N.-network), comparing B.A.T.M.A.N. some other routing protocol/s or any other topic related to my major subject. I really don't have any idea on what problems you have encountered so please help me find a good topic for my masters thesis.
The thesis will be done during this summer.
Thank you in advance Vojislav Marinkovic _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Thank you for your suggestions!
There are a couple of things in your wish list that could be interesting for me. I'll take a closer look before I make a decision. One thing that I can tell you right away is that support for IPv6 came to my mind, but since I'm really (and I mean REALLY) new to B.A.T.M.A.N. and I don't know what is going on in the community, I thought it might be a good idea to ask.
Once again thank you! ________________________________________ Från: b.a.t.m.a.n-bounces@open-mesh.net [b.a.t.m.a.n-bounces@open-mesh.net] för elektra [onelektra@gmx.net] Skickat: den 27 april 2009 18:44 Till: The list for a Better Approach To Mobile Ad-hoc Networking Ämne: Re: [B.A.T.M.A.N.] Masters thesis
Hello Vojislav!
I have a personal wish list of things that would be great to have in Batman. I don't know if any of these would be suitable/interesting for you, but I will use the opportunity to post it to the list now:
* Modify Batman-0.3.X in order to support IPv6 * Improve Batman with regards to protocol overhead and convergence speed * Get support for other operating systems working (so far it only works with Linux) * Implement a minimalistic and power saving Batman client version for embedded mobile devices * Modify Batman-0.3.X code so we have an option to compile it without policy routing support * Modify the way that Batman-Advanced (Layer 2) deals with broadcast/multicast payload packages (on multihop wireless routes there is always packet loss, protocols like DHCP use broadcast or multicast messages which are not send redundantly and not acknowledged, so these protocols which are not designed to deal with a high level of packetloss have difficulties to work on a Layer 2 mesh as the number of hops and packet loss on the media increases)
Cheers, elektra
Hi!
My name is Vojislav Marinkovic and I am a student of Electrical Engineering at the Royal Institute of Technology in Stockholm. My major is Communication Networks and right now I am looking for an interesting subject for my masters thesis. While browsing the Internet for some interesting topics, I ran into your project which is very similar to (yet better than) one of my own ideas. So I thought "why should I put time on inventing wet water instead of joining the project?",
On your homepage you stated that you have a lot of ideas but you don't have the time to implement them all. My question is, do you have any ideas that would fit to be done as a masters thesis in communication networks? It could be anything from an issue related to the protocol itself or it could be porting an already deployed technology on other types of networks to the B.A.T.M.A.N. (I'm not suggesting anything, but as an example let's say potential issues with live streaming over a B.A.T.M.A.N.-network), comparing B.A.T.M.A.N. some other routing protocol/s or any other topic related to my major subject. I really don't have any idea on what problems you have encountered so please help me find a good topic for my masters thesis.
The thesis will be done during this summer.
Thank you in advance Vojislav Marinkovic _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
_______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hi Vojislav and Electra,
Was the protocol implemented yet on a simulation platform like omnet? For comparing purposes (for example with OLSR) it could be interesting to simulate the protocol.
Further the package load will be tunnelled through batman network by an udp tunnel. There was reasons to do this. But why we can not establish an tcp-tunel on top of the existing tunnels. So earn more overhead but the delivery of the related packages are granted.
In respect to IPv6: What is the problem with IPv6? The batman protocol self should work with ipv6? As payload it could be realized by an tunnel too.
regards
Maik
elektra schrieb:
Hello Vojislav!
I have a personal wish list of things that would be great to have in Batman. I don't know if any of these would be suitable/interesting for you, but I will use the opportunity to post it to the list now:
- Modify Batman-0.3.X in order to support IPv6
- Improve Batman with regards to protocol overhead and convergence speed
- Get support for other operating systems working (so far it only works
with Linux)
- Implement a minimalistic and power saving Batman client version for
embedded mobile devices
- Modify Batman-0.3.X code so we have an option to compile it without
policy routing support
- Modify the way that Batman-Advanced (Layer 2) deals with
broadcast/multicast payload packages (on multihop wireless routes there is always packet loss, protocols like DHCP use broadcast or multicast messages which are not send redundantly and not acknowledged, so these protocols which are not designed to deal with a high level of packetloss have difficulties to work on a Layer 2 mesh as the number of hops and packet loss on the media increases)
Cheers, elektra
Hi!
My name is Vojislav Marinkovic and I am a student of Electrical Engineering at the Royal Institute of Technology in Stockholm. My major is Communication Networks and right now I am looking for an interesting subject for my masters thesis. While browsing the Internet for some interesting topics, I ran into your project which is very similar to (yet better than) one of my own ideas. So I thought "why should I put time on inventing wet water instead of joining the project?",
On your homepage you stated that you have a lot of ideas but you don't have the time to implement them all. My question is, do you have any ideas that would fit to be done as a masters thesis in communication networks? It could be anything from an issue related to the protocol itself or it could be porting an already deployed technology on other types of networks to the B.A.T.M.A.N. (I'm not suggesting anything, but as an example let's say potential issues with live streaming over a B.A.T.M.A.N.-network), comparing B.A.T.M.A.N. some other routing protocol/s or any other topic related to my major subject. I really don't have any idea on what problems you have encountered so please help me find a good topic for my masters thesis.
The thesis will be done during this summer.
Thank you in advance Vojislav Marinkovic _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
Hi,
Was the protocol implemented yet on a simulation platform like omnet? For comparing purposes (for example with OLSR) it could be interesting to simulate the protocol.
there is no simulator support that I know of.
Further the package load will be tunnelled through batman network by an udp tunnel. There was reasons to do this. But why we can not establish an tcp-tunel on top of the existing tunnels. So earn more overhead but the delivery of the related packages are granted.
It is not necessary to implement the tunnel with TCP as all protocols that use the tunnel already have a mechanism to detect packet lost. If you issue a HTTP query over a tunnel it will look like this: HTTP -> TCP -> UDP Tunnel -> Internet
Your setup would look like this: HTTP -> TCP -> TCP Tunnel -> Internet
Next to the overhead which comes with TCP you will face a double congestion window (see TCP congestion avoidance). In a lossy environment TCP over TCP connection will run at the lowest speed possible without a chance to recover.
In respect to IPv6: What is the problem with IPv6? The batman protocol self should work with ipv6? As payload it could be realized by an tunnel too.
Its not a problem - just somebody needs to do it. :-)
Regards, Marek
Hello Maik!
Was the protocol implemented yet on a simulation platform like omnet? For comparing purposes (for example with OLSR) it could be interesting to simulate the protocol.
There is no implementation of Batman for NS2 or Omnet, as far as I'm aware of. However there is a paper about the simulation of Batman-0.1 (Mark I of the Batman algorithm without bidirectional link check) and Batman-0.2 (Mark II of the Batman algorithm with bidirectional link check): http://www.olsr.org/~aaron/olsr/batman_report.pdf
Note: The paper is nice, the results were encouraging but the study is dated. The lack of a bidirectional link check was a known limitation of Mark I when we just wanted to do a quick and dirty test to prove the feasibility of the Batman idea. So the first version we expected to work well in the real world was Mark II. Mark II was replaced quickly by Mark III because as Axel Neumann has pointed out there was a bug in the algorithm in both Mark I and Mark II which can cause routing loops.
Addressing this problem in Mark III also had the benefit to reduce protocol overhead. Mark III works nice, but we found that the link metric we used still had a flaw. All Batman algorithms can route asymmetric, which is great. However Mark I-III tend to prefer routing paths from which they *receive* protocol messages well as paths in the opposite direction to *transmit* payload. This can be unfortunate, because there could be an alternate routing path which works better in transmit direction than the path which works better in receive direction. In Mark II and III we tried to address this via the bidirectional link check, to achieve a symmetric ETX like routing behavior. This mitigated the problem but didn't solve it completely. Also it was not what we really were aiming for: Routing asymmetric in the transmit direction if this is the best routing path to go. Hence Mark IV was introduced.
We have tested and compared Olsrd 0.5.0 and Batman-Experimental (Mark IV ) in the "Massive Mesh" wireless indoor grid at the Meraka institute of the CSIR in Tshwane (aka Pretoria) in South Africa. At the time we ran the tests Batman-0.3 was pretty much in its alpha state so we were concentrating on the Batman-Experimental branch because the implementation was more mature. (Batman-0.3.X and Batman-Experimental represent two different ideas for Mark IV of the Batman algorithm.)
http://researchspace.csir.co.za/dspace/bitstream/10204/3035/1/Johnson3_2008....
Note that time has passed over this study as well. Olsr fans will point out that they have improved the code much since the study and fixed at least one crucial bug (ETX was not only calculated based on Hello packet loss in Olsrd, as I had suggested it to Thomas Lopatic when we were both designing the ETX/LQ implementation in Olsr in 2004. Thomas had decided to use all protocol messages to calculate TQ/NLQ in the implementation of olsr-0.4.8, so the LQ/NLQ values would change quicker than I expected - depending on the number of TC messages floating around in the network)
However some general conclusions still remain the same if you compare both protocol ideas:
* Batman-IV floods protocol messages selectively i.e. only on paths following the best route for each destination. Olsr has to flood all topology messages everywhere - the only optimization being the idea of multipoint relays. (MPR redundancy was set to 7 MPRs per node, since I tried my best to avoid routing loops). However - enabling multi-point relays or not - Olsr tries to sync every topology update with all nodes. Since the grid has thousands of alternate propagation paths to redundantly flood messages the protocol overhead is drastic, because there is not much protocol message loss.
* Olsr needs more protocol information (topology data) to operate than Batman.
* We did the best to stop Olsr from looping payload packets - i.e. send topology updates redundant - however this comes at a price. In order to avoid loops the topology information has to be synced with all OLSR nodes. Despite the high level of redundancy less than 70% of the routes used were symmetric. This is a clear indication that the topology data bases were not in sync, because ETX would route symmetric at all times if the topology data is in sync. Despite the great deal of of effort to sync topology information Olsr still had transient routing loops under heavy payload. It would be interesting to see how a current Olsr behaves today, since the fix of the fore mentioned issue.
* Batman-IV didn't loop, no matter how hard we saturated the network with payload traffic. This is not a surprise because it was the main goal of the algorithm design. Transient routing loops were the main motivation for Thomas and me to drop development of Olsr.
In respect to IPv6: What is the problem with IPv6?
No problem regarding the protocol - we are just missing IPv6 support so far in the OSI-Layer 3 implementations of Batman (both Experimental and 0.3.X). Batman-Advanced doesn't have this problem, as a Layer 2 protocol it can carry any protocol you like.
The batman protocol self should work with ipv6?
Absolutely.
As payload it could be realized by an tunnel too.
Yes. As a side-note: Batman uses tunnels for Internet connectivity to address the problem of gateway switching when NAT is used on the gateway. With IPv6 NAT on gateways should become superfluous one sunny day :-)
Cheers, elektra
Hi,
On your homepage you stated that you have a lot of ideas but you don't have the time to implement them all. My question is, do you have any ideas that would fit to be done as a masters thesis in communication networks? It could be anything from an issue related to the protocol itself or it could be porting an already deployed technology on other types of networks to the B.A.T.M.A.N.
welcome on board. :-)
I'm very happy that you ask. Elektra already suggested a few things. I'm going to extend this list and group it a bit to outline the focus of the corresponding tasks. That should give you a good starting point. I suggest you choose your candidates out of these before we dive into the details. Then you will have an idea what to expect and you can make a decision whether you want to do it. :-)
one afternoon of work (at maximum): * Modify Batman-0.3.X code so we have an option to compile it without policy routing support * Modify the way that Batman-Advanced (Layer 2) deals with broadcast/multicast payload packages (on multihop wireless routes there is always packet loss, protocols like DHCP use broadcast or multicast messages which are not send redundantly and not acknowledged, so these protocols which are not designed to deal with a high level of packetloss have difficulties to work on a Layer 2 mesh as the number of hops and packet loss on the media increases)
several weeks of coding effort (including tests): * Modify Batman-0.3.X in order to support IPv6 * Get support for other operating systems working (so far it only works with Linux) -> depends on your knowledge of "other" systems * merge batman adv userspace & kernelland code to reduce the maintenance overhead * automatic interface bonding for better throughput (layer 2)
requires in depth knowlegde about batman: * Improve Batman with regards to protocol overhead and convergence speed
mt. everest: * Implement a minimalistic and power saving Batman client version for embedded mobile devices (requires extensive knowledge of 802.11 power saving mechanisms and how to bring them into the mesh) * multipath routing (as it always appears over and over again: http://en.wikipedia.org/wiki/Multipath_routing)
Regards, Marek
Hello!
I have about 20 weeks to do the master thesis. This time includes: getting familiar with the protocol, gathering other information needed for the task, analysis, report writing, coding, presentation preparation and probably some more stuff that I can't remember right now.
Based on this list i would say that the tasks which could fit me are IPv6 support (the other tasks in this group seem to be more development towards the OS) and "Improve Batman with regards to protocol overhead and convergence speed" (with a risk that it would only result in a report). Maybe IPv6 would be more interesting to you guys since you would get something in return for helping me out.
Another idea that came to my mind is building a B.A.T.M.A.N. module for ns2, and I have seen it being discussed here the last couple of days.
The easiest task for me would be IPv6 support. It would also give me the opportunity to get some in-depth knowledge about IPv6 and some hands-on experience with it. But I would need to check if my professor would accept this topic. Otherwise, I'm not a fastidious (I just learned a new word in English :) ) person, so it wouldn't be a problem for me to do any of the tasks mentioned above.
The next step is choosing one task and then making a thesis proposal, including a rough time-plan.
Any comments or suggestions?
Vojislav Marinkovic
________________________________________
one afternoon of work (at maximum): * Modify Batman-0.3.X code so we have an option to compile it without policy routing support * Modify the way that Batman-Advanced (Layer 2) deals with broadcast/multicast payload packages (on multihop wireless routes there is always packet loss, protocols like DHCP use broadcast or multicast messages which are not send redundantly and not acknowledged, so these protocols which are not designed to deal with a high level of packetloss have difficulties to work on a Layer 2 mesh as the number of hops and packet loss on the media increases)
several weeks of coding effort (including tests): * Modify Batman-0.3.X in order to support IPv6 * Get support for other operating systems working (so far it only works with Linux) -> depends on your knowledge of "other" systems * merge batman adv userspace & kernelland code to reduce the maintenance overhead * automatic interface bonding for better throughput (layer 2)
requires in depth knowlegde about batman: * Improve Batman with regards to protocol overhead and convergence speed
mt. everest: * Implement a minimalistic and power saving Batman client version for embedded mobile devices (requires extensive knowledge of 802.11 power saving mechanisms and how to bring them into the mesh) * multipath routing (as it always appears over and over again: http://en.wikipedia.org/wiki/Multipath_routing) _______________________________________________
Hello Vojislav!
My personal and very biased opinion is that simulations suck - simulating a wireless mesh in all its complexity (the complexity of RF propagation and interference is the first issue that comes to my mind) needs a very, very sophisticated software and a really powerful computer. Not to mention simulating real CPU load in mesh nodes and real problems with wireless interfaces, unexpected problems of the MAC layer and so on.
I'd dare to say that the computational effort of simulating what is going on in a mesh for 10 seconds is higher than taking 50 real machines with real wireless interfaces, running them for days and getting real results. Simulation seems to be important for the scientific world, though. Having a implementation for the popular simulation programs could increase the interest in Batman from the scientific world, but honestly I don't care much. At a unit price of 25€ per mesh-capable wireless router running Open-WRT (D-Link DIR-300 for example) I don't think it is necessary to do simulations anymore. However such a el-cheapo grid would be only capable to test algorithms running on one wireless interface and up to 5 wired interfaces. There are real testbeds on this planet (like the "Meraka Massive Mesh") which are idling most of the time, I guess.
It would be awesome to have IPv6 support in Batman, to be up to the changes and challenges that are knocking at the door. Also protocol improvements regarding protocol overhead and convergence speed (both topics are linked to each other, of course) is something we should work on - and hammering your head on algorithms is fun.
Cheers, elektra
Hello!
I have about 20 weeks to do the master thesis. This time includes: getting familiar with the protocol, gathering other information needed for the task, analysis, report writing, coding, presentation preparation and probably some more stuff that I can't remember right now.
Based on this list i would say that the tasks which could fit me are IPv6 support (the other tasks in this group seem to be more development towards the OS) and "Improve Batman with regards to protocol overhead and convergence speed" (with a risk that it would only result in a report). Maybe IPv6 would be more interesting to you guys since you would get something in return for helping me out.
Another idea that came to my mind is building a B.A.T.M.A.N. module for ns2, and I have seen it being discussed here the last couple of days.
The easiest task for me would be IPv6 support. It would also give me the opportunity to get some in-depth knowledge about IPv6 and some hands-on experience with it. But I would need to check if my professor would accept this topic. Otherwise, I'm not a fastidious (I just learned a new word in English :) ) person, so it wouldn't be a problem for me to do any of the tasks mentioned above.
The next step is choosing one task and then making a thesis proposal, including a rough time-plan.
Any comments or suggestions?
Vojislav Marinkovic
one afternoon of work (at maximum):
- Modify Batman-0.3.X code so we have an option to compile it without
policy routing support
- Modify the way that Batman-Advanced (Layer 2) deals with
broadcast/multicast payload packages (on multihop wireless routes there is always packet loss, protocols like DHCP use broadcast or multicast messages which are not send redundantly and not acknowledged, so these protocols which are not designed to deal with a high level of packetloss have difficulties to work on a Layer 2 mesh as the number of hops and packet loss on the media increases)
several weeks of coding effort (including tests):
- Modify Batman-0.3.X in order to support IPv6
- Get support for other operating systems working (so far it only works
with Linux) -> depends on your knowledge of "other" systems
- merge batman adv userspace & kernelland code to reduce the maintenance
overhead
- automatic interface bonding for better throughput (layer 2)
requires in depth knowlegde about batman:
- Improve Batman with regards to protocol overhead and convergence speed
mt. everest:
- Implement a minimalistic and power saving Batman client version for
embedded mobile devices (requires extensive knowledge of 802.11 power saving mechanisms and how to bring them into the mesh)
- multipath routing (as it always appears over and over again:
http://en.wikipedia.org/wiki/Multipath_routing) _______________________________________________ _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
I have somewhat the same opinion of simulations.. garbage in, garbage out. HOWEVER, being that my paying job is maintaining systems that DO large simulations, I think there would be a HUGE benefit to both the research community and the BATMAN software development for a coherent simulation model.
The simulation is *deterministic*, and does not depend on whether someone has the microwave running when you're sending packets or not. This allows you to perform repeatable tests on a proposed routing algorithm change.
The problem with most simulations is they take some toy algorithm, that is never actually used in the real world, and then someone publishes a paper saying how great it is.
Now, if you could make a simulation engine than can take as input data probabilities of packet loss or MAC layer problems, which was gathered from a REAL running mesh network, then you have something. Even better if you can compile the same BATMAN routing code and move data around with virtual machines. You *could* use something like qemu to even emulate the embedded CPU's, but I think the computation cost would be far too high. However, running many native linux instances (kvm, or somthing libvirt-based .. http://libvirt.org/drvuml.html) would probably allow a pretty large mesh (maybe over 1000 nodes) to run in pretty much real-time on a 64-128 node cluster.
Now you have the real-world system providing data to the simulation, which can then allow testing of new algorithm tweaks in a repeatable manner, which is quite hard with a real network.
All that being said, if you do IPv6 instead, I would use it for my scheme to use wireless mesh networks for smart power grid applications ;)
On Fri, May 01, 2009 at 05:11:06PM +0200, elektra wrote:
Hello Vojislav!
My personal and very biased opinion is that simulations suck - simulating a wireless mesh in all its complexity (the complexity of RF propagation and interference is the first issue that comes to my mind) needs a very, very sophisticated software and a really powerful computer. Not to mention simulating real CPU load in mesh nodes and real problems with wireless interfaces, unexpected problems of the MAC layer and so on.
I'd dare to say that the computational effort of simulating what is going on in a mesh for 10 seconds is higher than taking 50 real machines with real wireless interfaces, running them for days and getting real results. Simulation seems to be important for the scientific world, though. Having a implementation for the popular simulation programs could increase the interest in Batman from the scientific world, but honestly I don't care much. At a unit price of 25? per mesh-capable wireless router running Open-WRT (D-Link DIR-300 for example) I don't think it is necessary to do simulations anymore. However such a el-cheapo grid would be only capable to test algorithms running on one wireless interface and up to 5 wired interfaces. There are real testbeds on this planet (like the "Meraka Massive Mesh") which are idling most of the time, I guess.
It would be awesome to have IPv6 support in Batman, to be up to the changes and challenges that are knocking at the door. Also protocol improvements regarding protocol overhead and convergence speed (both topics are linked to each other, of course) is something we should work on - and hammering your head on algorithms is fun.
Cheers, elektra
Hello!
I have about 20 weeks to do the master thesis. This time includes: getting familiar with the protocol, gathering other information needed for the task, analysis, report writing, coding, presentation preparation and probably some more stuff that I can't remember right now.
Based on this list i would say that the tasks which could fit me are IPv6 support (the other tasks in this group seem to be more development towards the OS) and "Improve Batman with regards to protocol overhead and convergence speed" (with a risk that it would only result in a report). Maybe IPv6 would be more interesting to you guys since you would get something in return for helping me out.
Another idea that came to my mind is building a B.A.T.M.A.N. module for ns2, and I have seen it being discussed here the last couple of days.
The easiest task for me would be IPv6 support. It would also give me the opportunity to get some in-depth knowledge about IPv6 and some hands-on experience with it. But I would need to check if my professor would accept this topic. Otherwise, I'm not a fastidious (I just learned a new word in English :) ) person, so it wouldn't be a problem for me to do any of the tasks mentioned above.
The next step is choosing one task and then making a thesis proposal, including a rough time-plan.
Any comments or suggestions?
Vojislav Marinkovic
one afternoon of work (at maximum):
- Modify Batman-0.3.X code so we have an option to compile it without
policy routing support
- Modify the way that Batman-Advanced (Layer 2) deals with
broadcast/multicast payload packages (on multihop wireless routes there is always packet loss, protocols like DHCP use broadcast or multicast messages which are not send redundantly and not acknowledged, so these protocols which are not designed to deal with a high level of packetloss have difficulties to work on a Layer 2 mesh as the number of hops and packet loss on the media increases)
several weeks of coding effort (including tests):
- Modify Batman-0.3.X in order to support IPv6
- Get support for other operating systems working (so far it only works
with Linux) -> depends on your knowledge of "other" systems
- merge batman adv userspace & kernelland code to reduce the maintenance
overhead
- automatic interface bonding for better throughput (layer 2)
requires in depth knowlegde about batman:
- Improve Batman with regards to protocol overhead and convergence speed
mt. everest:
- Implement a minimalistic and power saving Batman client version for
embedded mobile devices (requires extensive knowledge of 802.11 power saving mechanisms and how to bring them into the mesh)
- multipath routing (as it always appears over and over again:
http://en.wikipedia.org/wiki/Multipath_routing) _______________________________________________ _______________________________________________ B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
B.A.T.M.A.N mailing list B.A.T.M.A.N@open-mesh.net https://lists.open-mesh.net/mm/listinfo/b.a.t.m.a.n
b.a.t.m.a.n@lists.open-mesh.org
-
elektra -
Maik Wodarz -
Marek Lindner -
Troy Benjegerdes -
Vojislav Marinkovic