[riot-devel] RPL DAO target concat from fib
list-riot at cgundogan.de
Wed Oct 18 21:30:33 CEST 2017
you are correct. The current RPL DAO building routine does not take
into account the MTU size, which is IMO the appropriate approach,
because on that level (ICMPv6) there is usually no knowledge about the
link-layer in use. If I understand you correctly, then you basically
want to move the fragmentation from the 6lowpan layer up to the
ICMPv6/RPL layer (and only for DAOs). I think in one of the older
iterations of our RPL implementation we once had a functionality to
limit the number of Target Options in the DAO to a specific number
(configurable on compile-time). But with the addition of a proper
6lowpan fragmentation, we dropped that functionality.
I may take a look at it during the weekend. If I remember correctly,
then we used to have a further parameter to the "send_DAO" function that
tracked the number of already sent Target Options. Further calls to
"send_DAO" would then add the next Target Options. If such functionality
is needed (@bergzand, @BytesGalore, @smlng any comments on this?) then
we should aim to come up with an unintrusive approach to activate /
deactivate such a behaviour with compile flags.
On 17-10-19 00:00:34, Rahul Jadhav wrote:
> Hello RIOT team,
> While experimenting with RIOT i found the RPL module implementation
> behaviour which sort of stops my network from building up.
> If i have a RIOT 6lr node and it has an FIB with, let's say, 10 active
> entries, then when the 6lr next sends DAO, it concatenates multiple target
> containers (from multiple FIB entries) in the same DAO message. This
> results in a packet size crossing link MTU limit (127 in my case) and for
> my case i do not have 6lo fragmentation enabled. Thus the DAO is getting
> I skimmed through the code but could not find a way to send DAO with max x
> target containers, where x is predefined.
> To reiterate, if the FIB active entries are more, then RIOT aggregates all
> the entries into the same DAO as target containers and forwards it. While
> aggregating if the packet crosses MTU boundary and if the 6lo frag is not
> on then it (6lo module) will drop the packet. Thus the network wont form.
> (i do not want 6lo fragmentation to happen for RPL control packets).
> Just want to understand, is there any way to handle this situation without
> turning on 6lo frag?
> --------------[log snippet]-------
> RPL: Send DAO - building internal transit
> RPL: Send DAO - building target fd00::302:304:506:3/128
> RPL: Send DAO - building target fd00::302:304:506:8/128
> RPL: Send DAO - building target fd00::302:304:506:d/128
> RPL: Send DAO - building target fd00::302:304:506:10/128
> RPL: Send DAO - building target fd00::302:304:506:11/128
> RPL: Send DAO - building target fd00::302:304:506:12/128
> RPL: Send DAO - building target fd00::302:304:506:e/128
> RPL: Send DAO - building target fd00::302:304:506:9/128
> RPL: Send DAO - building target fd00::302:304:506:4/128
> RPL: Send DAO - building target fd00::302:304:506:6/128
> 6lo: iface->max_frag_size = 127 for interface 6
> 6lo: packet too big (254 > 127)
> 6lo: waiting for incoming message.
> -----------[end of log]------------
> devel mailing list
> devel at riot-os.org
Hamburg University of Applied Sciences
Dept. of Computer Science / Internet Technologies Group
Berliner Tor 7, 20099 Hamburg, Germany
Fon: +49 40 42875 - 8426
Mail: cenk.guendogan at haw-hamburg.de
-------------- next part --------------
A non-text attachment was scrubbed...
Size: 833 bytes
Desc: not available
More information about the devel