The Minimum Rank with Hysteresis Objective Function
Extracted elements (25)
A node advertises the path cost of the worst (highest-cost) member of the parent set, not the preferred parent's cost. This conservative advertisement ensures that other nodes selecting this node as a parent can rely on any member of the parent set, but may result in suboptimal routing if parent set path costs vary widely.
MRHOF cannot be directly used for metric maximization, but a maximization problem can be converted to minimization if a fixed best-case metric value exists and all metric values are negative (e.g., using the logarithm of link reliability). MRHOF is not required to work with such converted metrics.
MRHOF selects paths with the smallest metric value while using hysteresis to prevent excessive churn. It switches to a minimum-cost path only if that path is cheaper than the current path by at least PARENT_SWITCH_THRESHOLD, avoiding instability from small metric fluctuations.
Setting a large MinHopRankIncrease can cause MRHOF to be unable to distinguish paths with different hop counts but similar metric values. If MinHopRankIncrease increment exceeds link cost, metrics drive parent selection but advertised Rank becomes a simple hop count, which may be unintended.
If MaxRankIncrease (an RPL parameter) is smaller than PARENT_SWITCH_THRESHOLD (an MRHOF parameter), a node may enter a state where its preferred parent causes a Rank increase exceeding MaxRankIncrease but MRHOF does not switch parents, potentially causing the node to leave the routing topology.
When ETX is the selected metric, recommended parameter values are: MAX_LINK_METRIC=512 (4 expected transmissions), MAX_PATH_COST=32768 (256 expected transmissions), PARENT_SWITCH_THRESHOLD=192 (1.5 fewer transmissions), PARENT_SET_SIZE=3, and ALLOW_FLOATING_ROOT=0.
A MRHOF implementation MUST support the DODAG Configuration option as described in RFC 6550 and apply the parameters it specifies, including MaxRankIncrease, which must be coordinated with PARENT_SWITCH_THRESHOLD to avoid nodes leaving the topology unnecessarily.
A MRHOF implementation SHOULD perform parent selection each time the path cost for any existing candidate neighbor (including the preferred parent) changes, or when a new candidate neighbor is inserted into the neighbor table.
A node MUST select the candidate neighbor with the lowest path cost as its preferred parent, except: it MAY continue using the current preferred parent if the minimum available path cost is not smaller than cur_min_path_cost by at least PARENT_SWITCH_THRESHOLD (the hysteresis condition).
A node SHOULD compute the path cost for the path through each candidate neighbor reachable through an interface. If a node cannot compute the path cost for the path through a candidate neighbor, the node MUST NOT select that candidate neighbor as its preferred parent.
An implementation SHOULD allow MAX_LINK_METRIC, MAX_PATH_COST, PARENT_SWITCH_THRESHOLD, PARENT_SET_SIZE, and ALLOW_FLOATING_ROOT to be configured at installation time, and MAY allow dynamic runtime configuration. Unless configured otherwise, SHOULD use the default parameters from Section 5.
If a non-root node does not have metrics to compute the path cost through any of the candidate neighbors, it MUST join one of the candidate neighbors as a RPL Leaf node.
If ALLOW_FLOATING_ROOT is 0 and no neighbors are discovered, the node does not have a preferred parent and MUST set cur_min_path_cost to MAX_PATH_COST.
If ETX is the selected metric, a node MUST NOT advertise it in a metric container; instead, it MUST advertise an approximation of its ETX in its advertised Rank value. If a node receives a DIO with a Metric Container holding an ETX metric, MRHOF MUST ignore that ETX value in Rank calculations.
If the selected metric for a link is greater than MAX_LINK_METRIC, the node SHOULD exclude that link from consideration during parent selection.
If the selected metric is a link metric and the metric of the link to a neighbor is not available, the path cost for that path SHOULD be set to MAX_PATH_COST, preventing it from being selected.
In the absence of a Metric Container, MRHOF uses ETX as its metric. The node computes ETX locally for links to neighbors, adds to their advertised Rank, and MUST NOT include a metric container in its DIO messages. ETX Rank is assigned as ETX * 128.
Nodes MUST support at least one of the following metrics: hop count, latency, or ETX. Nodes SHOULD support the ETX metric. MRHOF does not support non-additive metrics.
Path cost SHOULD be recomputed each time the selected link metric is updated, the selected node metric is updated, or a new metric advertisement is received from a candidate neighbor. This computation SHOULD also be performed periodically.
A node's Rank is computed as the maximum of: (1) the Rank for the path through the preferred parent, (2) the highest advertised Rank among parent set members rounded up to the next integral Rank, and (3) the largest calculated Rank among parent set paths minus MaxRankIncrease.
MRHOF defines a metric-to-Rank conversion table: Hop-Count maps Cost directly to Rank; Latency maps Cost/65536 to Rank; ETX maps Cost directly to Rank. For other metrics, Rank is undefined and the node must join as a Leaf.
MRHOF defines five configuration parameters: MAX_LINK_METRIC (maximum per-link metric), MAX_PATH_COST (maximum end-to-end path metric), PARENT_SWITCH_THRESHOLD (hysteresis threshold for parent switching), PARENT_SET_SIZE (maximum number of parents), and ALLOW_FLOATING_ROOT (permits becoming a floating root).
MRHOF's parent selection maintains a variable cur_min_path_cost representing the path cost of the current preferred parent. When a new preferred parent is selected, cur_min_path_cost is updated to the path cost corresponding to that parent, and this value is carried in the DIO Metric Container.
IANA allocated Objective Code Point (OCP) value 1 to MRHOF in the 'Objective Code Point (OCP)' sub-registry of the 'Routing Protocol for Low Power and Lossy Networks (RPL)' registry.
MRHOF inherits the security vulnerabilities and mechanisms of RPL (RFC 6550). It does not introduce new flows or messages, but depends on RPL protocol elements whose compromise could cause misrouting. Deployments are RECOMMENDED to use RPL security mechanisms if routing information might be modified or spoofed.