This PR proposes an approach to reduce the thread count of RPL.
The current RPL/Trickle stack needs about 5 threads to handle tasks
like updating the trickle timer, routing entries and the transmission of
DAOs.
This PR modifies RPL to use only one thread with a looped `msg_recv()` call.
The message is then multiplexed to the right task.
In the main function of RPL (rpl_process thread)
a mutex is used after receiving a message via msg_recv.
However, this mutex is never used in another thread and thus is rendered
obsolete.
This implementation is based on RFC 6550 with addition of RFC 6554 (Source Routing Header for RPL). Both can be found under the following links:
- http://tools.ietf.org/html/rfc6550
- http://tools.ietf.org/html/rfc6554
The PR provides basic functionality for handling and forwarding packages in non-storing mode. In addition the structure of the previous implemented RPL storing mode is now revised, so that readability and modularity is increased. The following features are implemented:
- building function for a SRH and integration in common packets
- source-route build algorithm based on the structure of the DODAG
- an RPL-based interpretation of the SRH and removal at destination
- new structure for RPl-module with extracted beaconing-functionality
- leaf nodes are now supported
There are some missed goals and should be included in future updates:
- building a common routing table structure for different types of routing protocols
- routing tables are statically assigned via source code, future update should have an optional variable at build-time, which sets the size of the routing table depending on the desired functionality of a node in the network (root, node, leaf)
This PR depends on #1766.
It contains a minimal implementation of the AODVv2 routing protocol.
*Not* implemented are:
- AckReqs
- alternate metrics
- multiple interfaces
- clients and Client Networks
- buffering
- all addresses, TLVs, and features that are marked as optional
An example application can be found at https://github.com/Lotterleben/RIOT-AODVv2/tree/master/aodvv2_demo.
The implementation relies heavily on a functioning Neighbor Discovery Protocol.
It might be necessary to fill the neighbor cache manually with the current state
of RIOTs NDP implementation.
The value of AODVV2_MAX_UNREACHABLE_NODES has been chosen arbitrarily and will be subject to
future improvement.
Please note that based on my experience, with the default transceiver
buffer size (3) of the native port, about 2/3 of the route discoveries
will fail. This has been addressed in issue #1747. It is advised to increase
the transceiver buffer size when using AODVv2 as a routing protocol.
