The motivation behind this module is to allow for address handling
functions where they, but not the full IPv6 functionality might be
needed. This new version of the IPv6 address data type utilizes the
byteorder.h header to enforce network byte-order on its members.
When setting the `ENABLE_DEBUG` flag to *1* in ip.c,
the **rpl_udp** example won't compile, because the variable `addr_str`
is also defined in **rpl_udp.h** as extern.
Prefixing `addr_str` with `static` in ip.c solves this problem.
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.
Currently, when using vtimer_set_msg the corresponding msg_t is filled
with the MSG_TIMER ("12345") type.
This approach makes it difficult to differentiate between incoming
messages via vtimer_set_msg.
In this PR I introduce another parameter for the vtimer_set_msg
function to specify a custom msg_t type.
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)
