Skip to main content

8. Upward Routes

This section describes how RPL discovers and maintains Upward routes. It describes the use of DODAG Information Objects (DIOs), the messages used to discover and maintain these routes. It specifies how RPL generates and responds to DIOs. It also describes DODAG Information Solicitation (DIS) messages, which are used to trigger DIO transmissions.

As mentioned in Section 3.2.8, nodes that decide to join a DODAG MUST provision at least one DODAG parent as a default route for the associated instance. This default route enables a packet to be forwarded Upward until it eventually hits a common ancestor from which it will be routed Downward to the destination. If the destination is not in the DODAG, then the DODAG root may be able to forward the packet using connectivity to the outside of the DODAG; if it cannot forward the packet outside, then the DODAG root has to drop it.

A DIO message can also transport explicit routing information:

  • DODAGID: The DODAGID is a Global or Unique Local IPv6 address of the root. A node that joins a DODAG SHOULD provision a host route via a DODAG parent to the address used by the root as the DODAGID.

  • RIO Prefix: The root MAY place one or more Route Information options in a DIO message. The RIO is used to advertise an external route that is reachable via the root, associated with a preference, as presented in Section 6.7.5, which incorporates the RIO from [RFC4191]. It is interpreted as a capability of the root as opposed to a routing advertisement, and it MUST NOT be redistributed in another routing protocol though it SHOULD be used by an ingress RPL router to select a DODAG when a packet is injected in a RPL domain from a node attached to that RPL router. An Objective Function MAY use the routes advertised in RIO or the preference for those routes in order to favor a DODAG versus another one for the same instance.

8.1. DIO Base Rules​

  1. For the following DIO Base fields, a node that is not a DODAG root MUST advertise the same values as its preferred DODAG parent (defined in Section 8.2.1). In this way, these values will propagate Down the DODAG unchanged and advertised by every node that has a route to that DODAG root. These fields are as follows:

    1. Grounded (G)
    2. Mode of Operation (MOP)
    3. DAGPreference (Prf)
    4. Version
    5. RPLInstanceID
    6. DODAGID

  2. A node MAY update the following fields at each hop:

    1. Rank
    2. DTSN

  3. The DODAGID field each root sets MUST be unique within the RPL Instance and MUST be a routable IPv6 address belonging to the root.

8.2. Upward Route Discovery and Maintenance​

Upward route discovery allows a node to join a DODAG by discovering neighbors that are members of the DODAG of interest and identifying a set of parents. The exact policies for selecting neighbors and parents is implementation dependent and driven by the OF. This section specifies the set of rules those policies must follow for interoperability.

8.2.1. Neighbors and Parents within a DODAG Version​

RPL's Upward route discovery algorithms and processing are in terms of three logical sets of link-local nodes. First, the candidate neighbor set is a subset of the nodes that can be reached via link-local multicast. The selection of this set is implementation and OF dependent. Second, the parent set is a restricted subset of the candidate neighbor set. Finally, the preferred parent is a member of the parent set that is the preferred next hop in Upward routes. Conceptually, the preferred parent is a single parent; although, it may be a set of multiple parents if those parents are equally preferred and have identical Rank.

More precisely:

  1. The DODAG parent set MUST be a subset of the candidate neighbor set.

  2. A DODAG root MUST have a DODAG parent set of size zero.

  3. A node that is not a DODAG root MAY maintain a DODAG parent set of size greater than or equal to one.

  4. A node's preferred DODAG parent MUST be a member of its DODAG parent set.

  5. A node's Rank MUST be greater than all elements of its DODAG parent set.

  6. When Neighbor Unreachability Detection (NUD) [RFC4861], or an equivalent mechanism, determines that a neighbor is no longer reachable, a RPL node MUST NOT consider this node in the candidate neighbor set when calculating and advertising routes until it determines that it is again reachable. Routes through an unreachable neighbor MUST be removed from the routing table.

These rules ensure that there is a consistent partial order on nodes within the DODAG. As long as node Ranks do not change, following the above rules ensures that every node's route to a DODAG root is loop-free, as Rank decreases on each hop to the root.

The OF can guide candidate neighbor set and parent set selection, as discussed in [RFC6552].

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.

8.2.3. DIO Message Communication​

When a DIO message is received, the receiving node must first determine whether or not the DIO message should be accepted for further processing, and subsequently present the DIO message for further processing if eligible.

  1. If the DIO message is malformed, then the DIO message is not eligible for further processing and a node MUST silently discard it. (See Section 18 for error logging).

  2. If the sender of the DIO message is a member of the candidate neighbor set and the DIO message is not malformed, the node MUST process the DIO.

8.2.3.1. DIO Message Processing​

As DIO messages are received from candidate neighbors, the neighbors may be promoted to DODAG parents by following the rules of DODAG discovery as described in Section 8.2. When a node places a neighbor into the DODAG parent set, the node becomes attached to the DODAG through the new DODAG parent node.

The most preferred parent should be used to restrict which other nodes may become DODAG parents. Some nodes in the DODAG parent set may be of a Rank less than or equal to the most preferred DODAG parent. (This case may occur, for example, if an energy-constrained device is at a lesser Rank but should be avoided per an optimization objective, resulting in a more preferred parent at a greater Rank.)

8.3. DIO Transmission​

RPL nodes transmit DIOs using a Trickle timer [RFC6206]. A DIO from a sender with a lesser DAGRank that causes no changes to the recipient's parent set, preferred parent, or Rank SHOULD be considered consistent with respect to the Trickle timer.

The following packets and events MUST be considered inconsistencies with respect to the Trickle timer, and cause the Trickle timer to reset:

  • When a node detects an inconsistency when forwarding a packet, as detailed in Section 11.2.

  • When a node receives a multicast DIS message without a Solicited Information option, unless a DIS flag restricts this behavior.

  • When a node receives a multicast DIS with a Solicited Information option and the node matches all of the predicates in the Solicited Information option, unless a DIS flag restricts this behavior.

  • When a node joins a new DODAG Version (e.g., by updating its DODAGVersionNumber, joining a new RPL Instance, etc.).

Note that this list is not exhaustive, and an implementation MAY consider other messages or events to be inconsistencies.

A node SHOULD NOT reset its DIO Trickle timer in response to unicast DIS messages. When a node receives a unicast DIS without a Solicited Information option, it MUST unicast a DIO to the sender in response. This DIO MUST include a DODAG Configuration option. When a node receives a unicast DIS message with a Solicited Information option and matches the predicates of that Solicited Information option, it MUST unicast a DIO to the sender in response. This unicast DIO MUST include a DODAG Configuration option. Thus, a node MAY transmit a unicast DIS message to a potential DODAG parent in order to probe for DODAG Configuration and other parameters.

8.3.1. Trickle Parameters​

The configuration parameters of the Trickle timer are specified as follows:

  • Imin: learned from the DIO message as (2^DIOIntervalMin) ms. The default value of DIOIntervalMin is DEFAULT_DIO_INTERVAL_MIN.

  • Imax: learned from the DIO message as DIOIntervalDoublings. The default value of DIOIntervalDoublings is DEFAULT_DIO_INTERVAL_DOUBLINGS.

  • k: learned from the DIO message as DIORedundancyConstant. The default value of DIORedundancyConstant is DEFAULT_DIO_REDUNDANCY_CONSTANT. In RPL, when k has the value of 0x00, this is to be treated as a redundancy constant of infinity in RPL, i.e., Trickle never suppresses messages.

8.4. DODAG Selection​

The DODAG selection is implementation and OF dependent. In order to limit erratic movements, and all metrics being equal, nodes SHOULD keep their previous selection. Also, nodes SHOULD provide a means to filter out a parent whose availability is detected as fluctuating, at least when more stable choices are available.

When connection to a grounded DODAG is not possible or preferable for security or other reasons, scattered DODAGs MAY aggregate as much as possible into larger DODAGs in order to allow connectivity within the LLN.

A node SHOULD verify that bidirectional connectivity and adequate link quality is available with a candidate neighbor before it considers that candidate as a DODAG parent.

8.5. Operation as a Leaf Node​

In some cases, a RPL node may attach to a DODAG as a leaf node only. One example of such a case is when a node does not understand or does not support (policy) the RPL Instance's OF or advertised metric/constraint. As specified in Section 18.6, related to policy function, the node may either join the DODAG as a leaf node or may not join the DODAG. As mentioned in Section 18.5, it is then recommended to log a fault.

A leaf node does not extend DODAG connectivity; however, in some cases, the leaf node may still need to transmit DIOs on occasion, in particular, when the leaf node may not have always been acting as a leaf node and an inconsistency is detected.

A node operating as a leaf node must obey the following rules:

  1. It MUST NOT transmit DIOs containing the DAG Metric Container.

  2. Its DIOs MUST advertise a DAGRank of INFINITE_RANK.

  3. It MAY suppress DIO transmission, unless the DIO transmission has been triggered due to detection of inconsistency when a packet is being forwarded or in response to a unicast DIS message, in which case the DIO transmission MUST NOT be suppressed.

  4. It MAY transmit unicast DAOs as described in Section 9.2.

  5. It MAY transmit multicast DAOs to the '1 hop' neighborhood as described in Section 9.10.

A particular case that requires a leaf node to send a DIO is if that leaf node was a prior member of another DODAG and another node forwards a message assuming the old topology, triggering an inconsistency. The leaf node needs to transmit a DIO in order to repair the inconsistency. Note that due to the lossy nature of LLNs, even though the leaf node may have optimistically poisoned its routes by advertising a Rank of INFINITE_RANK in the old DODAG prior to becoming a leaf node, that advertisement may have become lost and a leaf node must be capable to send a DIO later in order to repair the inconsistency.

In the general case, the leaf node MUST NOT advertise itself as a router (i.e., send DIOs).

8.6. Administrative Rank​

In some cases, it might be beneficial to adjust the Rank advertised by a node beyond that computed by the OF based on some implementation-specific policy and properties of the node. For example, a node that has a limited battery should be a leaf unless there is no other choice, and may then augment the Rank computation specified by the OF in order to expose an exaggerated Rank.

Last updated on