Future work

The link layer functionality is the only unfinished part of the OLSR implementation. RFC3626 describes link layer notification in a very loose way leaving many decisions to the coder and the user. As shown, the basic functionality for initiating, retrieving and maintaining link quality is implemented. But some action should also be taken based on the values retrieved. The link layer values could trigger updates of the link set or decide what packets the socket parser should discard. But further work is required to be able to know what thresholds to use.

Also, there is the problem of the maximum limit of MAC addresses one can register with the drivers. To overcome this, a simple recompilation of the drivers with a higher max-value, can be enough. But if running olsrd requires recompiling kernel drivers, the software could be to complicated to set up for many end users, this could however be an alternative solution for advanced users. Therefore the implementation should not be locked to a certain maximum value. A solution could be a scheme where neighbors selected as MPRs are prioritized if the maximum limit is reached when registering neighbors with the driver.

The MAC address query mechanism could also be improved. One can imagine a solution where the MAC address is fetched from the lower layers when receiving OLSR control traffic. This information could be injected into the ARP cache directly. Such a solution would also eliminate the ARP lookups when nodes initiate regular traffic to neighbors.