Skip to main content

8.2.2. Neighbors and Parents across DODAG Versions

The above rules govern a single DODAG Version. The rules in this section define how RPL operates when there are multiple DODAG Versions.

8.2.2.1. DODAG Version​

  1. The tuple (RPLInstanceID, DODAGID, DODAGVersionNumber) uniquely defines a DODAG Version. Every element of a node's DODAG parent set, as conveyed by the last heard DIO message from each DODAG parent, MUST belong to the same DODAG Version. Elements of a node's candidate neighbor set MAY belong to different DODAG Versions.

  2. A node is a member of a DODAG Version if every element of its DODAG parent set belongs to that DODAG Version, or if that node is the root of the corresponding DODAG.

  3. A node MUST NOT send DIOs for DODAG Versions of which it is not a member.

  4. DODAG roots MAY increment the DODAGVersionNumber that they advertise and thus move to a new DODAG Version. When a DODAG root increments its DODAGVersionNumber, it MUST follow the conventions of Serial Number Arithmetic as described in Section 7. Events triggering the increment of the DODAGVersionNumber are described later in this section and in Section 18.

  5. Within a given DODAG, a node that is a not a root MUST NOT advertise a DODAGVersionNumber higher than the highest DODAGVersionNumber it has heard. Higher is defined as the greater-than operator in Section 7.

  6. Once a node has advertised a DODAG Version by sending a DIO, it MUST NOT be a member of a previous DODAG Version of the same DODAG (i.e., with the same RPLInstanceID, the same DODAGID, and a lower DODAGVersionNumber). Lower is defined as the less-than operator in Section 7.

When the DODAG parent set becomes empty on a node that is not a root, (i.e., the last parent has been removed, causing the node no longer to be associated with that DODAG), then the DODAG information should not be suppressed until after the expiration of an implementation-specific local timer. During the interval prior to suppression of the "old" DODAG state, the node will be able to observe if the DODAGVersionNumber has been incremented should any new parents appear. This will help protect against the possibility of loops that may occur if that node were to inadvertently rejoin the old DODAG Version in its own prior sub-DODAG.

As the DODAGVersionNumber is incremented, a new DODAG Version spreads outward from the DODAG root. A parent that advertises the new DODAGVersionNumber cannot belong to the sub-DODAG of a node advertising an older DODAGVersionNumber. Therefore, a node can safely add a parent of any Rank with a newer DODAGVersionNumber without forming a loop.

For example, suppose that a node has left a DODAG with DODAGVersionNumber N. Suppose that a node had a sub-DODAG and did attempt to poison that sub-DODAG by advertising a Rank of INFINITE_RANK, but those advertisements may have become lost in the LLN. Then, if the node did observe a candidate neighbor advertising a position in that original DODAG at DODAGVersionNumber N, that candidate neighbor could possibly have been in the node's former sub-DODAG, and there is a possible case where adding that candidate neighbor as a parent could cause a loop. In this case, if that candidate neighbor is observed to advertise a DODAGVersionNumber N+1, then that candidate neighbor is certain to be safe, since it is certain not to be in that original node's sub-DODAG, as it has been able to increment the DODAGVersionNumber by hearing from the DODAG root while that original node was detached. For this reason, it is useful for the detached node to remember the original DODAG information, including the DODAGVersionNumber N.

Exactly when a DODAG root increments the DODAGVersionNumber is implementation dependent and out of scope for this specification. Examples include incrementing the DODAGVersionNumber periodically, upon administrative intervention, or on application-level detection of lost connectivity or DODAG inefficiency.

After a node transitions to and advertises a new DODAG Version, the rules above make it unable to advertise the previous DODAG Version (prior DODAGVersionNumber) once it has committed to advertising the new DODAG Version.

8.2.2.2. DODAG Roots​

  1. A DODAG root without possibility to satisfy the application-defined goal MUST NOT set the Grounded bit.

  2. A DODAG root MUST advertise a Rank of ROOT_RANK.

  3. A node whose DODAG parent set is empty MAY become the DODAG root of a floating DODAG. It MAY also set its DAGPreference such that it is less preferred.

In a deployment that uses non-LLN links to federate a number of LLN roots, it is possible to run RPL over those non-RPL links and use one router as a "backbone root". The backbone root is the virtual root of the DODAG and exposes a Rank of BASE_RANK over the backbone. All the LLN roots that are parented to that backbone root, including the backbone root if it also serves as the LLN root itself, expose a Rank of ROOT_RANK to the LLN. These virtual roots are part of the same DODAG and advertise the same DODAGID. They coordinate DODAGVersionNumbers and other DODAG parameters with the virtual root over the backbone. The method of coordination is out of scope for this specification (to be defined in future companion specifications).

8.2.2.3. DODAG Selection​

The Objective Function and the set of advertised routing metrics and constraints of a DAG determine how a node selects its neighbor set, parent set, and preferred parents. This selection implicitly also determines the DODAG within a DAG. Such selection can include administrative preference (Prf) as well as metrics or other considerations.

If a node has the option to join a more preferred DODAG while still meeting other optimization objectives, then the node will generally seek to join the more preferred DODAG as determined by the OF. All else being equal, it is left to the implementation to determine which DODAG is most preferred (since, as a reminder, a node must only join one DODAG per RPL Instance).

8.2.2.4. Rank and Movement within a DODAG Version​

  1. A node MUST NOT advertise a Rank less than or equal to any member of its parent set within the DODAG Version.

  2. A node MAY advertise a Rank lower than its prior advertisement within the DODAG Version.

  3. Let L be the lowest Rank within a DODAG Version that a given node has advertised. Within the same DODAG Version, that node MUST NOT advertise an effective Rank higher than L + DAGMaxRankIncrease. INFINITE_RANK is an exception to this rule: a node MAY advertise an INFINITE_RANK within a DODAG Version without restriction. If a node's Rank were to be higher than allowed by L + DAGMaxRankIncrease, when it advertises Rank, it MUST advertise its Rank as INFINITE_RANK.

  4. A node MAY, at any time, choose to join a different DODAG within a RPL Instance. Such a join has no Rank restrictions, unless that different DODAG is a DODAG Version of which this node has previously been a member; in which case, the rule of the previous bullet (3) must be observed. Until a node transmits a DIO indicating its new DODAG membership, it MUST forward packets along the previous DODAG.

  5. A node MAY, at any time after hearing the next DODAGVersionNumber advertised from suitable DODAG parents, choose to migrate to the next DODAG Version within the DODAG.

Conceptually, an implementation is maintaining a DODAG parent set within the DODAG Version. Movement entails changes to the DODAG parent set. Moving Up does not present the risk to create a loop but moving Down might, so that operation is subject to additional constraints.

When a node migrates to the next DODAG Version, the DODAG parent set needs to be rebuilt for the new Version. An implementation could defer to migrate for some reasonable amount of time, to see if some other neighbors with potentially better metrics but higher Rank announce themselves. Similarly, when a node jumps into a new DODAG, it needs to construct a new DODAG parent set for this new DODAG.

If a node needs to move Down a DODAG that it is attached to, increasing its Rank, then it MAY poison its routes and delay before moving as described in Section 8.2.2.5.

A node is allowed to join any DODAG Version that it has never been a prior member of without any restrictions, but if the node has been a prior member of the DODAG Version, then it must continue to observe the rule that it may not advertise a Rank higher than L+DAGMaxRankIncrease at any point in the life of the DODAG Version. This rule must be observed so as not to create a loophole that would allow the node to effectively increment its Rank all the way to INFINITE_RANK, which may have impact on other nodes and create a resource-wasting count-to-infinity scenario.

8.2.2.5. Poisoning​

  1. A node poisons routes by advertising a Rank of INFINITE_RANK.

  2. A node MUST NOT have any nodes with a Rank of INFINITE_RANK in its parent set.

Although an implementation may advertise INFINITE_RANK for the purposes of poisoning, doing so is not the same as setting Rank to INFINITE_RANK. For example, a node may continue to send data packets whose RPL Packet Information includes a Rank that is not INFINITE_RANK, yet still advertise INFINITE_RANK in its DIOs.

When a (former) parent is observed to advertise a Rank of INFINITE_RANK, that (former) parent has detached from the DODAG and is no longer able to act as a parent, nor is there any way that another node may be considered to have a Rank greater-than INFINITE_RANK. Therefore, that (former) parent cannot act as a parent any longer and is removed from the parent set.

8.2.2.6. Detaching​

  1. A node unable to stay connected to a DODAG within a given DODAG Version, i.e., that cannot retain non-empty parent set without violating the rules of this specification, MAY detach from this DODAG Version. A node that detaches becomes the root of its own floating DODAG and SHOULD immediately advertise this new situation in a DIO as an alternate to poisoning.

8.2.2.7. Following a Parent​

  1. If a node receives a DIO from one of its DODAG parents, indicating that the parent has left the DODAG, that node SHOULD stay in its current DODAG through an alternative DODAG parent, if possible. It MAY follow the leaving parent.

A DODAG parent may have moved, migrated to the next DODAG Version, or jumped to a different DODAG. A node ought to give some preference to remaining in the current DODAG, if possible via an alternate parent, but ought to follow the parent if there are no other options.

Last updated on