RPL DAO target concat from fib

Development archive
1

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]------------

2

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. 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.

Cheers, Cenk Gündoğan

3

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

4

Hey Rahul,

Unfortunately I don’t have time right now to read and comment on your email in depth :frowning: About the ETX metrics for RPL, please have a look at #6873 and #7450.

I want to take a better look at your ideas and proposal in the weekend.

Regards, Koen Zandberg

#6873: #7450:

5

Hey Rahul, Cenk, Koen,

6lo frag is not a good option to use and should be avoided as far as possible. right, but as we all know it cannot be achieved all the time.

Supporting target aggregation in DAO without depending on 6lo frag I think that would be the right direction for mitigating the symptom of sending elidable redundant information in DAOs options, which exceed the MTU.

I don’t remember exactly if the rfc6550 et al. restrict the behaviour of constructing and distributing DAO transit/target options to parents in solely a single packet. If splitting the downward information does not violate the RFCs, then taking the MTU into account up to a cetrain degree, would be just an implementation specific detail and probably the way to go (again).

But I would always prefer letting the underlying layer to provide fragmentation over an customized approach.

Best regards,

Martin

6

Hi Rahul!

Just a small remark regarding one of your comments:

2. RIOT does not handle L2 retry-count feedback to maintain RPL metric (for e.g. ETX). Pls correct if i m wrong.

One problem here is that not all radio devices report back the number of L2 retries if this is implemented by the device itself. In some cases it is possible to deactivate this feature and take care of L2 ACK handling and retries as part of the device driver, but this is currently not implemented for all drivers.

Cheers, Oleg

7

Hey Rahul,

another clarification question:

> 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.

Is this your personal opinion or some IETF consensus? I agree that fragmented ICMPv6 messages are somewhat pointless, but to rely on IPv6 fragmentation for link layers that do not support the minimum MTU for IPv6 and do not offer fragmentation (like IEEE 802.15.4) it still seems to be the best choice to me. Can you elaborate a bit?

Cheers, Oleg

8

Rahul,

6LoWPAN does not give you that choice. If you need interoperability, you need to support adaptation layer fragmentation.

Grüße, Carsten

9

I have disabled 6lo frag just to check which all cases results in fragmentation and to check if an alternative is available/possible. “6lo frag is mandatorily needed”, no doubt (and its must as per specs). It s just best to avoid it if possible. One reason (which also is applicable in the DAO scenario discussed) is, any loss of single 6lo fragment results in complete pkt retransmission. Assume if we have the DAO mechanism (like discussed in this mail chain), any single loss of DAO should result only in its retransmission (turns out it also is trivial to implement).

Regards, Rahul

10

Hi Oleg,

Pls find my comments inline.

Regards, Rahul

11

Hey Rahul,

> > > 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. > > Is this your personal opinion or some IETF consensus?

[RJ] In IETF98, Pascal had presented the problem stmts related to 6lo fragmentation and post-session there was a discussion ( Re: [6lo] Thomas' review of draft-thubert-6lo-forwarding-fragments-04). Also my experience with regards to 6lo frag also points to problems similar to what were mentioned during that session.

Thanks for the pointer.

> I agree that fragmented ICMPv6 messages are somewhat pointless, but to > rely on IPv6 fragmentation for link layers that do not support the minimum > MTU for IPv6 and do not offer fragmentation (like IEEE 802.15.4) it still > seems to be the best choice to me. > Can you elaborate a bit?

[RJ] i think i didnt appropriately word my stmts. I never suggested to not support or disable 6lo fragmentation. In my experiment i have disabled it just to check if there are any reasons why RIOT should result in 6lo fragmentation. I found this (DAO) case and thought, may be, this is not a good candidate to result in 6lo frag and can be avoided and hence the mail.

Thanks for the clarification. That makes absolutely sense - and I agree that fragmented DAOs are not a good idea.

Cheers, Oleg