Thanks Cenk for giving a clear picture. Some comments inline... In general, I feel this is important to be handled, since even in small network this would result in DAO fragmentation and will impact its performance.
Also there are some other points i wanted to understand/clarify: 1. Currently RIOT does not handle L2 ACK for determining whether L2 send was successful or not. This feedback is not used at RPL/6lo layer. Scenario: A node receives a DIO from parent and sends a DAO. But lets say this DAO could not reach the parent. In this case L2 ACK would have failed and the child node could have handled it to switch parent. Even if K bit is set in the DAO, and if DAO-ACK is not received, the child node wont come to know since there is no state/timer maintained to handle this. Essentially this will lead to child node believing that it is connected to the network but the downstream path is never actually established. 2. RIOT does not handle L2 retry-count feedback to maintain RPL metric (for e.g. ETX). Pls correct if i m wrong. Thanks, Rahul On 19 October 2017 at 01:00, Cenk Gündoğan <[email protected]> wrote: > Hey Rahul, > > 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. [RJ] True. > 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). [RJ] Thats exactly what I had in mind. > 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). [RJ] This would have been a real nice feature. Supporting target aggregation in DAO without depending on 6lo frag. In the future, proposing/implementing prefix eliding (the way 6loRH does for SRH or by simply using 6lo CID) between target containers and standardising it would make sense ! Considering that DAO consumes the most amount of RPL control traffic, i feel this can be fairly important. But with the addition of a proper > 6lowpan fragmentation, we dropped that functionality. > [RJ] 6lo frag is not a good option to use and should be avoided as far as possible. > > 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. > [RJ] Wouldn't a simple compile-time flag such as DAO_TARGET_CONCAT_NUM=X be sufficient, where X could be 0 (no concat, send only 1 target container which will be node self IP addr), -1(for full concat, current implementation), and anything else which means non-self target container count. The other way to define such a flag would be DAO_TARGET_CONCAT_SZ=Ybytes ... which defines number of bytes instead of target count. > > Cheers, > Cenk Gündoğan > > 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. > > > > Scenario: > > 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 > > dropped. > > > > 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? > > > > Thanks, > > Rahul > > > > --------------[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 > > [email protected] > > https://lists.riot-os.org/mailman/listinfo/devel > > > -- > Cenk Gündoğan > > Hamburg University of Applied Sciences > Dept. of Computer Science / Internet Technologies Group > Berliner Tor 7, 20099 Hamburg, Germany > Fon: +49 40 42875 - 8426 > Mail: [email protected] > Web: https://www.inet.haw-hamburg.de/ > > _______________________________________________ > devel mailing list > [email protected] > https://lists.riot-os.org/mailman/listinfo/devel > >
_______________________________________________ devel mailing list [email protected] https://lists.riot-os.org/mailman/listinfo/devel
