In the last months some issues emerged with the original plan of my project.
After implementing topology export in NetJSON format for BIRD, I started investigating how to modify the timers of OSPF, and finally found that OSPF has a limitation regarding the timers, which states that all the routers on the same network must have the same timers. This is surprising, since the RFC supports specifying the timer in the messages, and thus it would be trivial to have nodes with differentiated timers (as OLSR and other protocols do, for instance). Actually somewhere else in the RFC it is stated that even if the timers could be diversified, they must be used as a network-wide parameter, otherwise routers wont pair as neighbor. This issue is not easy to solve, and would break the compatibility with other OSPF implementations, thus, together with my mentor we decided to change the project on something that we could accomplish in the remaining time and that was still helpful for Wireless Communities.
Since many WCNs in Europe are still using OLSRv1 we’ve decided to implement PopRouting on it. The NetJSON plugin is already available so we only had to implement the Timer’s plugin and the PRINCE plugin to communicate with it.
During this mont I’ve implemented and alpha version of the Pop-Routing plugin for OLSRd. This plugin is quite simple, it listens to a specified port and it parse two commands : “/HelloTimer=xx.yy” and “/TcTimer=xx.yy”, where xx.yy are floating point numbers.
I’ve also implemented the Prince plugin that communicate with OLSRd. It fetches the topology from the NetJSON plugin and it pushes the updated timers to the PopRouting Plugin.
The next month I am going to fix all the bugs I found, document the plugins and test Pop-Routing with NEPA test.
Despite those problems the implementation of NetJSON for OSPF is working and we hope it will be merged in the BIRD codebase soon.