Skip to main content

11. Packet Forwarding and Loop Avoidance/Detection

11.1. Suggestions for Packet Forwarding​

This document specifies a routing protocol. These non-normative suggestions are provided to aid in the design of a forwarding implementation by illustrating how such an implementation could work with RPL.

When forwarding a packet to a destination, precedence is given to selection of a next-hop successor as follows:

  1. This specification only covers how a successor is selected from the DODAG Version that matches the RPLInstanceID marked in the IPv6 header of the packet being forwarded. Routing outside the instance can be done as long as additional rules are put in place such as strict ordering of instances and routing protocols to protect against loops. Such rules may be defined in a separate document.

  2. If a local administrative preference favors a route that has been learned from a different routing protocol than RPL, then use that successor.

  3. If the packet header specifies a source route by including an RH4 header as specified in [RFC6554], then use that route. If the node fails to forward the packet with that specified source route, then that packet should be dropped. The node MAY log an error. The node may send an ICMPv6 error in Source Routing Header message to the source of the packet (see Section 20.18).

  4. If there is an entry in the routing table matching the destination that has been learned from a multicast destination advertisement (e.g., the destination is a one-hop neighbor), then use that successor.

  5. If there is an entry in the routing table matching the destination that has been learned from a unicast destination advertisement (e.g., the destination is located Down the sub-DODAG), then use that successor. If there are DAO Path Control bits associated with multiple successors, then consult the Path Control bits to order the successors by preference when choosing. If, for a given DAO Path Control bit, multiple successors are recorded as having asserted that bit, precedence should be given to the successor who most recently asserted that bit.

  6. If there is a DODAG Version offering a route to a prefix matching the destination, then select one of those DODAG parents as a successor according to the OF and routing metrics.

  7. Any other as-yet-unattempted DODAG parent may be chosen for the next attempt to forward a unicast packet when no better match exists.

  8. Finally, the packet is dropped. ICMP Destination Unreachable MAY be invoked (an inconsistency is detected).

Hop Limit MUST be decremented when forwarding per [RFC2460].

Note that the chosen successor MUST NOT be the neighbor that was the predecessor of the packet (split horizon), except in the case where it is intended for the packet to change from an Upward to a Downward direction, as determined by the routing table of the node making the change, such as switching from DIO routes to DAO routes as the destination is neared in order to continue traveling toward the destination.

11.2. Loop Avoidance and Detection​

RPL loop avoidance mechanisms are kept simple and designed to minimize churn and states. Loops may form for a number of reasons, e.g., control packet loss. RPL includes a reactive loop detection technique that protects from meltdown and triggers repair of broken paths.

RPL loop detection uses RPL Packet Information that is transported within the data packets, relying on an external mechanism such as [RFC6553] that places in the RPL Packet Information in an IPv6 Hop-by-Hop option header.

The content of RPL Packet Information is defined as follows:

  • Down 'O': 1-bit flag indicating whether the packet is expected to progress Up or Down. A router sets the 'O' flag when the packet is expected to progress Down (using DAO routes), and clears it when forwarding toward the DODAG root (to a node with a lower Rank). A host or RPL leaf node MUST set the 'O' flag to 0.

  • Rank-Error 'R': 1-bit flag indicating whether a Rank error was detected. A Rank error is detected when there is a mismatch in the relative Ranks and the direction as indicated in the 'O' bit. A host or RPL leaf node MUST set the 'R' bit to 0.

  • Forwarding-Error 'F': 1-bit flag indicating that this node cannot forward the packet further towards the destination. The 'F' bit might be set by a child node that does not have a route to destination for a packet with the Down 'O' bit set. A host or RPL leaf node MUST set the 'F' bit to 0.

  • RPLInstanceID: 8-bit field indicating the DODAG instance along which the packet is sent.

  • SenderRank: 16-bit field set to zero by the source and to DAGRank(rank) by a router that forwards inside the RPL network.

11.2.1. Source Node Operation​

If the source is aware of the RPLInstanceID that is preferred for the packet, then it MUST set the RPLInstanceID field associated with the packet accordingly; otherwise, it MUST set it to the RPL_DEFAULT_INSTANCE.

11.2.2. Router Operation​

11.2.2.1. Instance Forwarding​

The RPLInstanceID is associated by the source with the packet. This RPLInstanceID MUST match the RPL Instance onto which the packet is placed by any node, be it a host or router. The RPLInstanceID is part of the RPL Packet Information.

A RPL router that forwards a packet in the RPL network MUST check if the packet includes the RPL Packet Information. If not, then the RPL router MUST insert the RPL Packet Information. If the router is an ingress router that injects the packet into the RPL network, the router MUST set the RPLInstanceID field in the RPL Packet Information. The details of how that router determines the mapping to a RPLInstanceID are out of scope for this specification and left to future specification.

A router that forwards a packet outside the RPL network MUST remove the RPL Packet Information.

When a router receives a packet that specifies a given RPLInstanceID and the node can forward the packet along the DODAG associated to that instance, then the router MUST do so and leave the RPLInstanceID value unchanged.

If any node cannot forward a packet along the DODAG associated with the RPLInstanceID, then the node SHOULD discard the packet and send an ICMP error message.

11.2.2.2. DAG Inconsistency Loop Detection​

The DODAG is inconsistent if the direction of a packet does not match the Rank relationship. A receiver detects an inconsistency if it receives a packet with either:

  • the 'O' bit set (to Down) from a node of a higher Rank.

  • the 'O' bit cleared (for Up) from a node of a lower Rank.

When the DODAG root increments the DODAGVersionNumber, a temporary Rank discontinuity may form between the next DODAG Version and the prior DODAG Version, in particular, if nodes are adjusting their Rank in the next DODAG Version and deferring their migration into the next DODAG Version. A router that is still a member of the prior DODAG Version may choose to forward a packet to a (future) parent that is in the next DODAG Version. In some cases, this could cause the parent to detect an inconsistency because the Rank-ordering in the prior DODAG Version is not necessarily the same as in the next DODAG Version, and the packet may be judged not to be making forward progress. If the sending router is aware that the chosen successor has already joined the next DODAG Version, then the sending router MUST update the SenderRank to INFINITE_RANK as it forwards the packets across the discontinuity into the next DODAG Version in order to avoid a false detection of Rank inconsistency.

One inconsistency along the path is not considered a critical error and the packet may continue. However, a second detection along the path of the same packet should not occur and the packet MUST be dropped.

This process is controlled by the Rank-Error bit associated with the packet. When an inconsistency is detected on a packet, if the Rank-Error bit was not set, then the Rank-Error bit is set. If it was set the packet MUST be discarded and the Trickle timer MUST be reset.

11.2.2.3. DAO Inconsistency Detection and Recovery​

DAO inconsistency loop recovery is a mechanism that applies to Storing mode of operation only.

In Non-Storing mode, the packets are source routed to the destination, and DAO inconsistencies are not corrected locally. Instead, an ICMP error with a new code "Error in Source Routing Header" is sent back to the root. The "Error in Source Routing Header" message has the same format as the "Destination Unreachable Message", as specified in [RFC4443]. The portion of the invoking packet that is sent back in the ICMP message should record at least up to the routing header, and the routing header should be consumed by this node so that the destination in the IPv6 header is the next hop that this node could not reach.

A DAO inconsistency happens when a router has a Downward route that was previously learned from a DAO message via a child, but that Downward route is not longer valid in the child, e.g., because that related state in the child has been cleaned up. With DAO inconsistency loop recovery, a packet can be used to recursively explore and clean up the obsolete DAO states along a sub-DODAG.

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.

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.

Last updated on