Hi again,
I included the FIB to `RIOT/net/sixlowpan/ip` replacing
`ip_get_next_hop()` by the FIB one.
Additionally I edited RPL to feed/update the FIB with the preferred parent.
(I set `23` arbitrary for the protocol ID and 0 for the interface.)
Best regards,
Martin
[1]
https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/network_layer/fib/fib.c#L354
On 19.11.2014 09:59, Martin wrote:
Hi all,
> a significant question is of course how to deal with competing
routing protocols
Form my understanding we have two distinct directions we can choose to
approach the problem:
1. We strictly push it away from the FIB, i.e. only allowing to have
unique entries for each global prefix.
pro: no handling needed here, the process, e.g. routing protocol,
adding next hops to the FIB must care about this.
con: we loose the possibility to take link/topology/interface
capabilities into account to forward a packet
2. We allow competing entries and apply (sort of) policies to always
return a unambiguous next hop from the FIB.
pro: we are able to direct data and control plane flows, taking
the routing protocol capabilities into account.
con: to have a preference on one FIB entry over another competing
entry, requires a valuing weighting
and decision mechanism. This creates overhead and lowers
the lookup/response time on next hop requests.
> Typically, these routing protocols split horizon according to IP
address ranges
Using a separation on IP address ranges would shift the problem away
from the FIB to the RIB.
This approach is definitely useful on non-moving routers with an
organized and static hierarchy and a good argument for following 1.
But I think in some IoT scenarios with moving routers, this approach
might have a poor performance
when the connected networks between the IoT routers periodically change.
> how does the FIB decide which next hop to choose if more than
routing protocol made an entry pointing to it?
I've built in [1] to the FIB to provide an entry point to handle such
conflicts.
Best Regards,
Martin
[1]
https://github.com/BytesGalore/RIOT/blob/add_fib/sys/net/network_layer/fib/fib.c#L260
On 19.11.2014 00:47, Thomas C. Schmidt wrote:
Hi Martine,
a FIB always only provides unique forwarding rules. So there are no
priorities attached to FIB entries. Priorities of routes may occur in
RIBs associated with routing protocols ... and a significant question
is of course how to deal with competing routing protocols that feed
the FIB. (Typically, these routing protocols split horizon according
to IP address ranges.)
Still, a routing protocol either overrides FIB entries or it doesn't.
Cheers,
Thomas
On 18.11.2014 21:56, Martine Lenders wrote:
Hi,
it's me again, dumping my latest brainstorm into the thread :D.
Don't we need some kind of priorities for the routing protocols,
too? Or
how does the FIB decide which next hop to choose if more than routing
protocol made an entry pointing to it?
Cheers,
Martine
2014-11-17 8:05 GMT+01:00 Martin <[email protected]
<mailto:[email protected]>>:
Hi Martine,
>... Except you mean the routing protocol by this.
yes, the `prot_id` is the actual used (running) protocol, i.e. RPL.
This identifier must be unique for the running RIOT on the node,
i.e. arbitrary but fixed for the lifetime.
The "binding" of FIB table entries to a specific (running) protocol
is necessary only for updates on them.
Probably `kernel_pid_t` for the would be a waste of one byte for
each FIB table entry.
I will keep it `uint8_t` for now, but test a bit with
`kernel_pid_t`.
Best regards,
Martin
On 15.11.2014 02:03, Martine Lenders wrote:
Hi Martin,
2014-11-14 15:23 GMT+01:00 Martin <[email protected]
<mailto:[email protected]>>:
Hi Martine,
I will change the interface and protocol IDs to
`kernel_type_t` as you suggested.
For the FIB handling perspective this seems also to be the
best (and easiest) way to have the IDs unique on one
RIOT/node.
For protocol IDs I suggest `netdev_proto_t` [1]. Except you mean
the routing protocol by this. It aims, at least regarding my
design, to be the RIOT-global identifier for all network protocol
RIOT supports.
Cheers,
Martine
[1]
https://github.com/RIOT-OS/RIOT/blob/038beb0f99215207c09fd862ac7712982cedb3ef/drivers/include/netdev/base.h#L57
_______________________________________________
devel mailing list
[email protected] <mailto:[email protected]>
http://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected] <mailto:[email protected]>
http://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
_______________________________________________
devel mailing list
[email protected]
http://lists.riot-os.org/mailman/listinfo/devel
