Subject: [Roll] Section 11.2.2.3. of draft-ietf-roll-rpl-19

From: Vincent Brillault <[email-masked]>
Date: Thu, 7 Jul 2011 11:21:45 +0200

Hi all,

I have some problems with Section 11.2.2.3. and its "DAO inconsistency
loop recovery". It seems to work, but only if I interpret some terms in
two different ways:

----

Let's consider a single DODAG, operating in storing mode without
multicast support and without the behaviors described in rpl-p2p. Let's
consider 6 nodes. Each have one preferred parent, the OF is not relevant
here.
A1 --- A2 --!--
|             |
|----- B2 --- C1 --- C2 --- D

"--" or "|" means that the connection is used.
"-!-" means that an existing connection is unused.

D sends a DAO, the routing states for D are:
A1     A2
|
|----> B2 --> C1 --> C2 --> D

C1 reboots, and attaches to A2. C2 and D follow C1 :
A1 --- A2 --- C1 --- C2 --- D
|             |
|----- B2 --!--

D sends a DAO, the routing states for D are :
A1 --> A2 --> C1 --> C2 --> D
              |
       B2 --->|

We can see that, as D just re-announces the new route and A1 is not able
to transfer to B2 the cleaning information, that B2 has an unclean state
that will stay until a time-out.
D disappears (it could for example reattach directly to A1 or just die
from energy exhaustion):

A1 --- A2 --- C1 --- C2
|             |
|----- B2 --!-- 

A1 --> A2 --> C1 --> C2
              |
       B2 --->|

Now B2 wants to send a message to D. As B2 has a recorded route to C2
and we don't use rpl-p2p, B2 sends a message directly to C1.
C1 receives a downward message to D, with a correct Packet Information
(correct instance and rank) and forwards it to C2.
Section 11.2.2.3. of the current draft apply :
"""
In a general manner, a packet that goes Down should never go Up
again.  If DAO inconsistency loop recovery is applied, then the
router SHOULD send the packet back to the parent that passed it with
the Forwarding-Error 'F' bit set and the 'O' bit left untouched.
Otherwise the router MUST silently discard the packet.
"""

C2 will send back the message to C1, with the O flag untouched.
C1 will clean the route and try to send it. I don't understand the end
of Section 11.2.2.3. :
"""
Upon receiving a packet with a Forwarding-Error bit set, the node
MUST remove the routing states that caused forwarding to that
neighbor, clear the Forwarding-Error bit and attempt to send the
packet again.  The packet may be sent to an alternate neighbor, after
the expiration of a user-configurable implementation specific timer.
If that alternate neighbor still has an inconsistent DAO state via
this node, the process will recurse, this node will set the
Forwarding-Error 'F' bit and the routing state in the alternate
neighbor will be cleaned up as well.
"""
C1 receive a packet with a Forwarding-Error bit set and wants to send it
to the only route present : its parent. The draft is unclear on this
situation : Can the node change the 'O' flag or not ?
I think that the correct behaviour should be to send the packet to a
parent (if we have more than one parent, I don't really know how to
choose), with the O flag untouched and the Forwarding-Error bit 
set. As a result, this parent will do the same and as a result the route
will be cleaned back to the root. 
It's an interpretation of the current draft that make the following
assumptions:
- "neighbor" is RPL independent: it can be a parent
- The node MUST NOT change the 'O' flag.
- When trying to forward the packet to the parent, "a packet that goes
  Down " tries to "go Up", so "DAO inconsistency loop recovery is
  applied"
- The terms "the parent that passed it" is interpreted here as "a
  parent"

As a result, the message will go up to A1 (if D reattached to A1, it can
receive the message) and the resulting state will be:
A1     A2    C1    C2
              |
       B2 --->|

One of the two unclean routes have been cleaned.

Now B2 tries to reach D again.
C1 will receive a correct packet again, but has no route to D so
according to its routing table, the packet would have to go up; and then
"DAO inconsistency loop recovery is applied". 
I think that the correct behaviour should be to send the packet with the
'F' bit set to B2.
It's an interpretation of the current draft that make the following
assumption:
- The terms "the parent that passed it" is interpreted here as "the node
  that passed it"

B2 will clean the unclean route state and, as A2 did, will send it back
to A1:
A1     A2    C1    C2

       B2

It works !

----

RPL seems to be able to clear the irregular routing states but only if
we understand the "the parent that passed it" terms in two different
ways...
Maybe this part of the draft should be rewritten ?

Perhaps another way to clear the unclean statecould be to reject
directly downward trafic from a node that isn't in the node's parents
set. It seems dangerous during Version Number increase but allows faster
clean-up.

If I missed a part in the current draft(s), please give me the
references.

Yours Sincerely,

Vincent Brillault