routing/rpl: adjusted RPL to use the FIB #2765

BytesGalore · 2015-04-08T18:01:34Z

Formerly the RPL implementation used internal routing and forwarding tables.
This PR changes it to use the new FIB instead of providing a get_next_hop_provider() to the current fading sixlowpan/ip implementation.
The provider registration and usage is replaced by calling the FIB for a next-hop directly.

cgundogan · 2015-04-08T18:04:29Z

sys/net/include/rpl.h

+/**
+ * @brief receive the set inteface id
+ *
+ * @return the set interface id of KERNEL_PID_UNDEF if no interface has been set


cgundogan · 2015-04-08T18:18:15Z

+137 −294. This is nice (: Need to do more testing and reviewing, though.

cgundogan · 2015-04-08T18:22:06Z

sys/net/network_layer/sixlowpan/ip.c

@@ -33,6 +33,7 @@
 #include "lowpan.h"


Does it also make sense to outsource the changes to this file to its own PR? Doesn't seem like that there are any dependencies to your RPL refactorings?

Basically yes, but then no routing protocol will work in mainline RIOT until we merge this PR or adjust the other protocols.

BytesGalore · 2015-04-10T11:18:51Z

does not depend, but would make sense to merge after #2782 has been merged, since this "compatibility" commit can be removed then.

cgundogan · 2015-04-12T17:08:41Z

sys/net/routing/rpl/rpl.c

@@ -279,32 +273,16 @@ void *rpl_process(void *arg)
 void _rpl_update_routing_table(void)
 {


Since FIB handles the lifetime of routes, would it make sense to remove this _rpl_update_routing_table thread completely and just pass a function callback (EDIT: or another kind of signalling) to the fib, which should be executed when a certain condition holds? (e.g. route lifetime expired) @BytesGalore @OlegHahm

@cgundogan the FIB works completely without threads. The exact invalidation point in time of a route is fixed and known, but not monitored by the FIB. A route lifetime and its invalidation is only performed on demand when the specific FIB entry is touched.
So if the lifetime of a route exceeds, probably the parent invalidation will not be triggered.

cgundogan · 2015-04-13T17:46:08Z

I had some warnings compiling your branch regarding return values in sc_fib.c. But I realized that this is fixed in master. A rebase would be appreciated (:

BytesGalore · 2015-04-14T05:21:04Z

rebased

cgundogan · 2015-04-14T09:08:36Z

@BytesGalore did you rebase to current master? I still get the warning regarding sc_fib.c and rpl_send_opt_target_buf->target still comprises a link-local address.

BytesGalore · 2015-04-14T09:12:25Z

@cgundogan yes the commits are ontop of this merge [1] 19 hours ago

[1] BytesGalore@1af6126

cgundogan · 2015-04-14T09:14:45Z

@BytesGalore could you rebase again please? (: This PR conflicts now with the merged #2607

BytesGalore · 2015-04-14T09:26:47Z

sure, done :)

cgundogan · 2015-04-14T09:57:17Z

sys/net/routing/rpl/rpl_control_messages.c

            rpl_send_opt_target_buf->type = RPL_OPT_TARGET;
            rpl_send_opt_target_buf->length = RPL_OPT_TARGET_LEN;
            rpl_send_opt_target_buf->flags = 0x00;
            rpl_send_opt_target_buf->prefix_length = RPL_DODAG_ID_LEN;
-            memcpy(&rpl_send_opt_target_buf->target, &rpl_get_routing_table()[i].address,
+            memcpy(&rpl_send_opt_target_buf->target, &rpl_parents[i].addr,


Taking the address from the parent results in these link-local addresses we see. In the former implementation rpl_get_routing_table()[i].address returned global addresses. I think the proper way would be to consult the fib and get the global destination address for those link-local addresses, and skip all parents without an entry in the fib.

EDIT: Or simply iterate over all entries in the fib istead of the parents, like in the implementation before

Unfortunately its not possible that the FIB replies a global address for a given next-hop address, since a next-hop address can be easily used for a large number of destinations.
Iterating is also not possible due to the separation concept of the FIB. But even if iterating would be possible, the FIB can have more entries than just the next-hops from RPL parents.

Fortunately not all is lost :D we could keep the global address for a parent in rpl_parents[i].addr instead of the local one, and ask the FIB for the global address when needed.

On second thought, iterating over the parents to fill the DAO is not the right way, because DAOs accumulate the routes they encounter up the dodag to the root. By iterating over the parents we can only put their addresses in the DAO but not the addresses the node accumulated through other DAOs (from children). In my opinion there should be a way to iterate over all targets in the fib and write them into the DAO.

This way we loose the downward route information for sub-DODAGS right?

I fear so, yes. How could we approach this issue? Is it possible to implement something like a generic iterator for the fib?

I have to think a bit more on it.
Just to clarify for myself, what we need to know here are all destinations addresses reachable from this node, which are constructed (storing MOP assumed) by receiving DIOs and all target options from all received DAOs right?

Correct, a DAO includes the address of the sending node in addition to all addresses it received from its children's DAOs, recursively. (storing MOP)

@cgundogan enhancing the data structures in the FIB or using the type field (uint32_t) for additional indication is no problem.
Maybe (and very related to your proposition), and this is also just thinking out loud, the FIB could return a full set of next-hop/destination tuples based on matching type field or just specific bits of it.

Maybe something like this:

typedef struct entries{ ng_ipv6_addr_t dst; ng_ipv6_addr_t next_hop; }; /** * param[in] bitmask indicate the bits to use in the search * param[in] typevalue the query type * param[out] arr_entries array to store matching entries * param[in, out] arr_entries_size indicates the storage spce on in and the use count when returned */ void fib_get_entry_set(uint32_t bitmask, uint32_t typevalue, entries* arr_entries, size_t* arr_entries_size);

@cgundogan I've opened #2818 as proposition for a function that could help here

jnohlgard · 2015-07-14T14:42:08Z

needs rebase

BytesGalore · 2015-07-15T06:11:26Z

rebased.

…le, this will be fixed with RIOT-OS#2782 merged

renamed `parents[]` to `rpl_parents[]` and made it `extern`

…takes

BytesGalore · 2015-07-27T12:11:25Z

Anyone interested to keep this PR?

cgundogan · 2015-08-17T13:57:21Z

@BytesGalore not really (: I will close it as this references the former rpl implementation and the new ng_rpl implementation has already the fib included.

BytesGalore added Type: enhancement The issue suggests enhanceable parts / The PR enhances parts of the codebase / documentation Area: network Area: Networking Discussion: RFC The issue/PR is used as a discussion starting point about the item of the issue/PR NSTF labels Apr 8, 2015

BytesGalore assigned cgundogan Apr 8, 2015

cgundogan reviewed Apr 8, 2015
View reviewed changes

miri64 mentioned this pull request Apr 9, 2015

Network stack refactoring: TODO list #2278

Closed

36 tasks

BytesGalore mentioned this pull request Apr 10, 2015

sys/shell: removed route to show the RPL internal routing table #2782

Closed

BytesGalore force-pushed the rpl_and_fib branch from 56753d2 to b555f60 Compare April 10, 2015 07:41

BytesGalore added CI: needs squashing Commits in this PR need to be squashed; If set, CI systems will mark this PR as unmergable State: waiting for other PR State: The PR requires another PR to be merged first labels Apr 10, 2015

cgundogan reviewed Apr 12, 2015
View reviewed changes

BytesGalore force-pushed the rpl_and_fib branch from 7e5aff3 to 50b02c1 Compare April 13, 2015 05:43

BytesGalore force-pushed the rpl_and_fib branch from 50b02c1 to 5851954 Compare April 14, 2015 05:20

BytesGalore force-pushed the rpl_and_fib branch from 5851954 to 5b2101a Compare April 14, 2015 09:26

cgundogan reviewed Apr 14, 2015
View reviewed changes

BytesGalore force-pushed the rpl_and_fib branch from 5b2101a to 76ad7c4 Compare April 27, 2015 06:08

cgundogan mentioned this pull request Apr 28, 2015

sys/net/fib: added function to request a set of destination addresses #2818

Merged

BytesGalore force-pushed the rpl_and_fib branch from 76ad7c4 to 90ea180 Compare April 28, 2015 20:59

OlegHahm modified the milestone: Release 2015.06 Apr 29, 2015

BytesGalore force-pushed the rpl_and_fib branch from 90ea180 to b94ed00 Compare May 4, 2015 09:34

BytesGalore mentioned this pull request May 19, 2015

aodvv2: add routes to FIB #2985

Merged

jnohlgard mentioned this pull request Jul 14, 2015

ng_rpl: port to the new network stack #3050

Merged

5 tasks

BytesGalore force-pushed the rpl_and_fib branch from b94ed00 to 9057782 Compare July 15, 2015 06:11

BytesGalore added 6 commits July 20, 2015 08:47

routing/rpl: adjusted RPL to use the FIB

9d629e4

[SQUASH ME] reverted unnecessary "getter" for the rpl_if_id

823b151

[SQUASH ME] reverted changes to shell commands

eadd9e7

[FINALLY REMOVE ME] fixed error resulted from the removed routing tab…

57c6067

…le, this will be fixed with RIOT-OS#2782 merged

[SQUASH ME] exposed the "getter" for parents,

1737d11

renamed `parents[]` to `rpl_parents[]` and made it `extern`

[SQUASH ME] added proper return values to sc_fib and fixed rebase mis…

3304b09

…takes

BytesGalore force-pushed the rpl_and_fib branch from 9057782 to 3304b09 Compare July 20, 2015 06:48

cgundogan closed this Aug 17, 2015

BytesGalore deleted the rpl_and_fib branch November 2, 2015 07:06

Provide feedback

Saved searches

Use saved searches to filter your results more quickly

routing/rpl: adjusted RPL to use the FIB #2765

routing/rpl: adjusted RPL to use the FIB #2765

BytesGalore commented Apr 8, 2015

cgundogan Apr 8, 2015

cgundogan commented Apr 8, 2015

cgundogan Apr 8, 2015

BytesGalore Apr 10, 2015

BytesGalore commented Apr 10, 2015

cgundogan Apr 12, 2015

BytesGalore Apr 13, 2015

cgundogan commented Apr 13, 2015

BytesGalore commented Apr 14, 2015

cgundogan commented Apr 14, 2015

BytesGalore commented Apr 14, 2015

cgundogan commented Apr 14, 2015

BytesGalore commented Apr 14, 2015

cgundogan Apr 14, 2015

BytesGalore Apr 14, 2015

cgundogan Apr 14, 2015

BytesGalore Apr 14, 2015

cgundogan Apr 14, 2015

BytesGalore Apr 14, 2015

cgundogan Apr 14, 2015

BytesGalore Apr 14, 2015

BytesGalore Apr 14, 2015

BytesGalore Apr 14, 2015

jnohlgard commented Jul 14, 2015

BytesGalore commented Jul 15, 2015

BytesGalore commented Jul 27, 2015

cgundogan commented Aug 17, 2015

		@@ -279,32 +273,16 @@ void rpl_process(void arg)
		void _rpl_update_routing_table(void)
		{

routing/rpl: adjusted RPL to use the FIB #2765

routing/rpl: adjusted RPL to use the FIB #2765

Conversation

BytesGalore commented Apr 8, 2015

Choose a reason for hiding this comment

cgundogan commented Apr 8, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

BytesGalore commented Apr 10, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

cgundogan commented Apr 13, 2015

BytesGalore commented Apr 14, 2015

cgundogan commented Apr 14, 2015

BytesGalore commented Apr 14, 2015

cgundogan commented Apr 14, 2015

BytesGalore commented Apr 14, 2015

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

Choose a reason for hiding this comment

jnohlgard commented Jul 14, 2015

BytesGalore commented Jul 15, 2015

BytesGalore commented Jul 27, 2015

cgundogan commented Aug 17, 2015