Subject: [Roll] question about DAO-ACK

From: Michael Richardson <[email-masked]>
Date: Wed, 02 Jul 2014 16:23:01 -0400

<REMOVES CHAIR HAT>

Given:
        - a storing implementation
        - DAO-ACKs requested
        - three nodes: A <- B <- C. A is the root.

C sends a DAO with the K bit set to selected parent B.
B will need to send a DAO to A indicating that it knows about C.

Question
1) should B wait until it receives a DAOACK from A before
   sending a DAOACK back to C?
   (before you answer, consider the the tree could be very
   deep, and that this implies that the intermediate nodes
   have to keep potentially many outgoing DAOACKs in a queue)

   Or is it enough that B says, "okay, I got you", and then
   takes responsibility for sending reachability information
   on its own?

   The problem I have with not waiting is that if C thinks
   it is on the network when it gets the DAOACK, it can start
   sending traffic upwards, but downward packets would get lost for awhile.
   Further, it is going to start sending DIOs, and start attracting
   traffic from other nodes when really, it isn't ready to do so.

2) if B recieves a DAO with the K bit set from, does this imply
   that it ought to set the K bit to its parent?
   If the answer is no, and you answer the question (1) that B ought to
   wait until it has heard from A before answering, but B
   has a policy of not setting the K bit, should B then
   answer immediately?

3) in the non-storing case, if a parent (B) of C, in fact had
   multiple interfaces, node C might not see the interface
   that is closer to A, and can only, in the Transit option,
   indicate the interface that it does see.  This implies
   that root A, may have to do two lookups to figure out
   where Bdown is, as it likely only has route to Bup.

4) what is the use case for the RPL Target Descriptor?

======

The DAO-ACK mechanism is pretty important to assure bi-directional
reachability, and the security-threads document makes reference to it.

I had not clued in that the K bit was optional before.

--
Michael Richardson <[email-masked]>, Sandelman Software Works
 -= IPv6 IoT consulting =-

---

From: "Pascal Thubert (pthubert)" <[email-masked]>
Date: Tue, 15 Jul 2014 08:33:03 +0000

Hello Michael:

>    takes responsibility for sending reachability information
[PT] The design was the latter, that it was OK for B to say "I got you".
Today it is mostly an alternate to MAC layer Ack, but the design is richer than that since a status code is provisioned though not used.
A negative status code could say things like "I'm overloaded with DAO state already" or "I'm out of battery".

>    traffic from other nodes when really, it isn't ready to do so.
[PT] This could effectively happen; mostly if you are considering the join process.
This suggests that leveraging a tunnel from a joined parent could effectively be a good idea there (eg piggy backing join info to system/security manager on DAR/DAC message).
Also that piggybacking security info to the DAO could effectively improve the trust in the DAO content and ensure that the next phases of join process can be responded to.

>    has a policy of not setting the K bit, should B then

[PT] No, this is not the case. The design for the K-bit was a one-hop thing that may depend on the link properties. 

>    where Bdown is, as it likely only has route to Bup.
[PT] You seem to imply that BDown would be advertised as reachable via BUp. Could be, e.g. in a mobility scenario where 1) you have many BDowns and 2) BUp changes parents frequently; in which case doing this would save advertisements: in case of a movement you'd only advertise the change of parent of BUp. But the more common case is that B would advertise all its addresses as being reachable via its parent, but concatenating multiple target options for all its interfaces and then placing a transit option for the parent that is factorized.

> 4) what is the use case for the RPL Target Descriptor?
[PT] The intent was route tagging. I did not get feedback that anyone is using it so far, but it is a classical thing and probably was a good idea to support it from the start. A tag may be placed to influence routing based on policies, and redistribution between protocols or domains. A tag could for instance indicate which RPL domain or subdomain the node is effectively attached to. In classical networks you want to stay within the same area/ routing protocol domain and tags are used to prevent reinjection into the original domain from an different domain. With RPL, if you have a fast (OSPF / Ethernet backbone) and a slow network (RPL LLN) then you may have more complex / asymmetric rules, since going though the fast network is probably a good idea.

Cheers,

Pascal

---

From: Michael Richardson <[email-masked]>
Date: Sat, 19 Jul 2014 14:34:59 -0400

<CHAIR HAT OFF>

Pascal Thubert (pthubert) <[email-masked]> wrote:
    >> Or is it enough that B says, "okay, I got you", and then takes
    >> responsibility for sending reachability information on its own?

    > [PT] The design was the latter, that it was OK for B to say "I got
    > you".  Today it is mostly an alternate to MAC layer Ack, but the design
    > is richer than that since a status code is provisioned though not used.

Yes... so if the sender does set the K bit, they might still get the MAC
layer ACK, which tells them the packet was received, but can not tell them
anything about being overloaded, etc.   What reason would there be not
to set the K bit?

In non-storing mode, if you set the K bit, can you expect to ever get a
negative reply,  if the root is overloaded, or otherwises refuses to accept
your DAO?
(You can't get a reply, because the root can't route to you, since it didn't
accept your DAO...)

    >> The problem I have with not waiting is that if C thinks it is on the
    >> network when it gets the DAOACK, it can start sending traffic upwards,
    >> but downward packets would get lost for awhile.  Further, it is going
    >> to start sending DIOs, and start attracting traffic from other nodes
    >> when really, it isn't ready to do so.

    > [PT] This could effectively happen; mostly if you are considering the
    > join process.  This suggests that leveraging a tunnel from a joined
    > parent could effectively be a good idea there (eg piggy backing join
    > info to system/security manager on DAR/DAC message).  Also that
    > piggybacking security info to the DAO could effectively improve the
    > trust in the DAO content and ensure that the next phases of join
    > process can be responded to.

I was not thinking about any of the (initial) join process; it could just be
a node rejoining after a movement, an RF change reveals a new parent, or
just a cold restart of the node.

    >> 3) in the non-storing case, if a parent (B) of C, in fact had multiple
    >> interfaces, node C might not see the interface that is closer to A,
    >> and can only, in the Transit option, indicate the interface that it
    >> does see.  This implies that root A, may have to do two lookups to
    >> figure out where Bdown is, as it likely only has route to Bup.

    > [PT] You seem to imply that BDown would be advertised as reachable via
    > BUp.

Yes, that's right.  The root would have a (source) route to Bup (whether
direct or via other layers of the mesh), and another source route to Bdown
(via Bup)
The important thing is that C can not mention Bup, it can only mention Bown.