RFC4101]. Protocol details can be found in further sections.
one or more Destination Oriented DAGs (DODAGs), one DODAG per sink. If the DAG has multiple roots, then it is expected that the roots are federated by a common backbone, such as a transit link.
o multiple uncoordinated DODAGs with independent roots (differing DODAGIDs) * For example, multiple data collection points in an urban data collection application that do not have suitable connectivity to coordinate with each other or that use the formation of multiple DODAGs as a means to dynamically and autonomously partition the network. o a single DODAG with a virtual root that coordinates LLN sinks (with the same DODAGID) over a backbone network. * For example, multiple border routers operating with a reliable transit link, e.g., in support of an IPv6 Low-Power Wireless Personal Area Network (6LoWPAN) application, that are capable of acting as logically equivalent interfaces to the sink of the same DODAG. o a combination of the above as suited to some application scenario. Each RPL packet is associated with a particular RPLInstanceID (see Section 11.2) and, therefore, RPL Instance (Section 5). The provisioning or automated discovery of a mapping between a RPLInstanceID and a type or service of application traffic is out of scope for this specification (to be defined in future companion specifications). Figure 1 depicts an example of a RPL Instance comprising three DODAGs with DODAG roots R1, R2, and R3. Each of these DODAG roots advertises the same RPLInstanceID. The lines depict connectivity between parents and children. Figure 2 depicts how a DODAGVersionNumber increment leads to a new DODAG Version. This depiction illustrates a DODAGVersionNumber increment that results in a different DODAG topology. Note that a new DODAG Version does not always imply a different DODAG topology. To accommodate certain topology changes requires a new DODAG Version, as described later in this specification. In the following examples, please note that tree-like structures are depicted for simplicity, although the DODAG structure allows for each node to have multiple parents when the connectivity supports it.
+----------------------------------------------------------------+ | | | +--------------+ | | | | | | | (R1) | (R2) (R3) | | | / \ | /| \ / | \ | | | / \ | / | \ / | \ | | | (A) (B) | (C) | (D) ... (F) (G) (H) | | | /|\ |\ | / | / |\ |\ | | | | | : : : : : | : (E) : : : `: : | | | | / \ | | +--------------+ : : | | DODAG | | | +----------------------------------------------------------------+ RPL Instance Figure 1: RPL Instance +----------------+ +----------------+ | | | | | (R1) | | (R1) | | / \ | | / | | / \ | | / | | (A) (B) | \ | (A) | | /|\ / |\ | ------\ | /|\ | | : : (C) : : | \ | : : (C) | | | / | \ | | | ------/ | \ | | | / | (B) | | | | |\ | | | | : : | | | | | +----------------+ +----------------+ Version N Version N+1 Figure 2: DODAG Version
RFC6551], into a value called Rank, which approximates the node's distance from a DODAG root. An OF also defines how nodes select parents. Further details may be found in Section 14, [RFC6551], [RFC6552], and related companion specifications.
implementation to securely operate in authenticated mode. For a RPL implementation to operate securely in authenticated mode, it is necessary for a future companion specification to detail the mechanisms by which a node obtains/requests the authentication material (e.g., key, certificate) and to determine from where that material should be obtained. See also Section 10.3.
The RPL Packet Information that is transported with data packets includes the Rank of the transmitter. An inconsistency between the routing decision for a packet (Upward or Downward) and the Rank relationship between the two nodes indicates a possible loop. On receiving such a packet, a node institutes a local repair operation. For example, if a node receives a packet flagged as moving in the Upward direction, and if that packet records that the transmitter is of a lower (lesser) Rank than the receiving node, then the receiving node is able to conclude that the packet has not progressed in the Upward direction and that the DODAG is inconsistent. Section 9. Any given RPL Instance is either storing or non-storing. In both cases, P2P packets travel Up toward a DODAG root then Down to the final destination (unless the destination is on the Upward route). In the Non-Storing case, the packet will travel all the way to a DODAG root before traveling Down. In the Storing case, the
packet may be directed Down towards the destination by a common ancestor of the source and the destination prior to reaching a DODAG root. As of the writing of this specification, no implementation is expected to support both Storing and Non-Storing modes of operation. Most implementations are expected to support either no Downward routes, Non-Storing mode only, or Storing mode only. Other modes of operation, such as a hybrid mix of Storing and Non-Storing mode, are out of scope for this specification and may be described in other companion specifications. This specification describes a basic mode of operation in support of P2P traffic. Note that more optimized P2P solutions may be described in companion specifications. Section 14 for more information. The Rank is not a path cost, although its value can be derived from and influenced by path metrics. The Rank has properties of its own that are not necessarily those of all metrics:
Type: The Rank is an abstract numeric value. Function: The Rank is the expression of a relative position within a DODAG Version with regard to neighbors, and it is not necessarily a good indication or a proper expression of a distance or a path cost to the root. Stability: The stability of the Rank determines the stability of the routing topology. Some dampening or filtering is RECOMMENDED to keep the topology stable; thus, the Rank does not necessarily change as fast as some link or node metrics would. A new DODAG Version would be a good opportunity to reconcile the discrepancies that might form over time between metrics and Ranks within a DODAG Version. Properties: The Rank is incremented in a strictly monotonic fashion, and it can be used to validate a progression from or towards the root. A metric, like bandwidth or jitter, does not necessarily exhibit this property. Abstract: The Rank does not have a physical unit, but rather a range of increment per hop, where the assignment of each increment is to be determined by the Objective Function. The Rank value feeds into DODAG parent selection, according to the RPL loop-avoidance strategy. Once a parent has been added, and a Rank value for the node within the DODAG has been advertised, the node's further options with regard to DODAG parent selection and movement within the DODAG are restricted in favor of loop avoidance.
integer portion of the Rank is computed by the DAGRank() macro as follows, where floor(x) is the function that evaluates to the greatest integer less than or equal to x: DAGRank(rank) = floor(rank/MinHopRankIncrease) For example, if a 16-bit Rank quantity is decimal 27, and the MinHopRankIncrease is decimal 16, then DAGRank(27) = floor(1.6875) = 1. The integer part of the Rank is 1 and the fractional part is 11/16. Following the conventions in this document, using the macro DAGRank(node) may be interpreted as DAGRank(node.rank), where node.rank is the Rank value as maintained by the node. A Node A has a Rank less than the Rank of a Node B if DAGRank(A) is less than DAGRank(B). A Node A has a Rank equal to the Rank of a Node B if DAGRank(A) is equal to DAGRank(B). A Node A has a Rank greater than the Rank of a Node B if DAGRank(A) is greater than DAGRank(B).
DAGRank(M) is greater than DAGRank(N): In this case, the position of M is farther from the DODAG root than the position of N. Further, Node M may in fact be in the sub-DODAG of Node N. If Node N selects Node M as DODAG parent, there is a risk of creating a loop. As an example, the Rank could be computed in such a way so as to closely track ETX (expected transmission count, a fairly common routing metric used in LLN and defined in [RFC6551]) when the metric that an Objective Function minimizes is ETX, or latency, or in a more complicated way as appropriate to the Objective Function being used within the DODAG. RFC5120]) and OSPF ([RFC4915]) use static link metrics. Such link metrics can simply reflect the bandwidth or can also be computed according to a polynomial function of several metrics defining different link characteristics. Some routing protocols support more than one metric: in the vast majority of the cases, one metric is used per (sub-)topology. Less often, a second metric may be used as a tiebreaker in the presence of Equal Cost Multiple Paths (ECMPs). The optimization of multiple metrics is known as an NP-complete problem and is sometimes supported by some centralized path computation engine. In contrast, LLNs do require the support of both static and dynamic metrics. Furthermore, both link and node metrics are required. In the case of RPL, it is virtually impossible to define one metric, or even a composite metric, that will satisfy all use cases. In addition, RPL supports constraint-based routing where constraints may be applied to both link and nodes. If a link or a node does not satisfy a required constraint, it is "pruned" from the candidate neighbor set, thus leading to a constrained shortest path. An Objective Function specifies the objectives used to compute the (constrained) path. Furthermore, nodes are configured to support a set of metrics and constraints and select their parents in the DODAG according to the metrics and constraints advertised in the DIO messages. Upstream and Downstream metrics may be merged or advertised separately depending on the OF and the metrics. When they are advertised separately, it may happen that the set of DIO parents
is different from the set of DAO parents (a DAO parent is a node to which unicast DAO messages are sent). Yet, all are DODAG parents with regard to the rules for Rank computation. The Objective Function is decoupled from the routing metrics and constraints used by RPL. Whereas the OF dictates rules such as DODAG parent selection, load balancing, and so on, the set of metrics and/or constraints used, and thus those that determine the preferred path, are based on the information carried within the DAG container option in DIO messages. The set of supported link/node constraints and metrics is specified in [RFC6551]. Example 1: Shortest path: path offering the shortest end-to-end delay. Example 2: Shortest Constrained path: the path that does not traverse any battery-operated node and that optimizes the path reliability. Section 11 for more details). In practice, this means that RPL guarantees neither loop-free path selection nor tight delay convergence times, but it can detect and repair a loop as soon as it is used. RPL uses this loop detection to ensure that packets make forward progress within the DODAG Version and trigger repairs when necessary.
"event horizon", whereby a node cannot be influenced beyond some limit into an instability by the action of nodes that may be in its own sub-DODAG. (A) (A) (A) |\ |\ |\ | `-----. | `-----. | `-----. | \ | \ | \ (B) (C) (B) \ | (C) \ | | / `-----. | | .-----' \| |/ (C) (B) -1- -2- -3- Figure 3: Greedy DODAG Parent Selection Figure 3 depicts a DODAG in three different configurations. A usable link between (B) and (C) exists in all three configurations. In Figure 3-1, Node (A) is a DODAG parent for Nodes (B) and (C). In Figure 3-2, Node (A) is a DODAG parent for Nodes (B) and (C), and Node (B) is also a DODAG parent for Node (C). In Figure 3-3, Node (A) is a DODAG parent for Nodes (B) and (C), and Node (C) is also a DODAG parent for Node (B). If a RPL node is too greedy, in that it attempts to optimize for an additional number of parents beyond its most preferred parents, then an instability can result. Consider the DODAG illustrated in Figure 3-1. In this example, Nodes (B) and (C) may most prefer Node (A) as a DODAG parent, but we will consider the case when they are operating under the greedy condition that will try to optimize for two parents. o Let Figure 3-1 be the initial condition. o Suppose Node (C) first is able to leave the DODAG and rejoin at a lower Rank, taking both Nodes (A) and (B) as DODAG parents as depicted in Figure 3-2. Now Node (C) is deeper than both Nodes (A) and (B), and Node (C) is satisfied to have two DODAG parents. o Suppose Node (B), in its greediness, is willing to receive and process a DIO message from Node (C) (against the rules of RPL), and then Node (B) leaves the DODAG and rejoins at a lower Rank,
taking both Nodes (A) and (C) as DODAG parents. Now Node (B) is deeper than both Nodes (A) and (C) and is satisfied with two DAG parents. o Then, Node (C), because it is also greedy, will leave and rejoin deeper, to again get two parents and have a lower Rank then both of them. o Next, Node (B) will again leave and rejoin deeper, to again get two parents. o Again, Node (C) leaves and rejoins deeper. o The process will repeat, and the DODAG will oscillate between Figure 3-2 and Figure 3-3 until the nodes count to infinity and restart the cycle again. o This cycle can be averted through mechanisms in RPL: * Nodes (B) and (C) stay at a Rank sufficient to attach to their most preferred parent (A) and don't go for any deeper (worse) alternate parents (Nodes are not greedy). * Nodes (B) and (C) do not process DIO messages from nodes deeper than themselves (because such nodes are possibly in their own sub-DODAGs). These mechanisms are further described in Section 18.104.22.168.
Section 6.4.3) was missed and persists until all state has been cleaned up. RPL includes an optional mechanism to acknowledge DAO messages, which may mitigate the impact of a single DAO message being missed. RPL includes loop detection mechanisms that mitigate the impact of DAO loops and trigger their repair. (See Section 22.214.171.124.) RFC5867], [RFC5826], [RFC5673], and [RFC5548]). The destinations of MP2P flows are designated nodes that have some application significance, such as providing connectivity to the larger Internet or core private IP network. RPL supports MP2P traffic by allowing MP2P destinations to be reached via DODAG roots. RFC5867], [RFC5826], [RFC5673], and [RFC5548]). RPL supports P2MP traffic by using a destination advertisement mechanism that provisions Down routes toward destinations (prefixes, addresses, or multicast groups), and away from roots. Destination advertisements can update routing tables as the underlying DODAG topology changes.
RPL also supports the case where a P2P destination is a 'one-hop' neighbor. RPL neither specifies nor precludes additional mechanisms for computing and installing potentially more optimal routes to support arbitrary P2P traffic. Section 11.2. For data packets coming from outside the RPL network, the ingress router determines the RPLInstanceID and places it into the resulting packet that it injects into the RPL network.
0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |0| ID | Global RPLInstanceID in 0..127 +-+-+-+-+-+-+-+-+ Figure 4: RPLInstanceID Field Format for Global Instances A local RPLInstanceID is autoconfigured by the node that owns the DODAGID and it MUST be unique for that DODAGID. The DODAGID used to configure the local RPLInstanceID MUST be a reachable IPv6 address of the node, and it MUST be used as an endpoint of all communications within that Local instance. A local RPLInstanceID is encoded in a RPLInstanceID field as follows: 0 1 2 3 4 5 6 7 +-+-+-+-+-+-+-+-+ |1|D| ID | Local RPLInstanceID in 0..63 +-+-+-+-+-+-+-+-+ Figure 5: RPLInstanceID Field Format for Local Instances The 'D' flag in a local RPLInstanceID is always set to 0 in RPL control messages. It is used in data packets to indicate whether the DODAGID is the source or the destination of the packet. If the 'D' flag is set to 1, then the destination address of the IPv6 packet MUST be the DODAGID. If the 'D' flag is cleared, then the source address of the IPv6 packet MUST be the DODAGID. For example, consider a Node A that is the DODAG root of a Local RPL Instance, and has allocated a local RPLInstanceID. By definition, all traffic traversing that Local RPL Instance will either originate or terminate at Node A. In this case, the DODAGID will be the
reachable IPv6 address of Node A. All traffic will contain the address of Node A, and thus the DODAGID, in either the source or destination address. Thus, the local RPLInstanceID may indicate that the DODAGID is equivalent to either the source address or the destination address by setting the 'D' flag appropriately.