Objective Function Zero for the Routing Protocol for Low-Power and Lossy Networks (RPL)
Extracted elements (26)
OF0 aims to find the nearest Grounded DODAG root while maintaining path diversity. When no Grounded root exists, floating DAGs rooted at nodes with the highest administrative preference are still formed to preserve inner LLN connectivity.
OF0 deliberately does not specify how link properties are transformed into rank_increase; instead it enforces the acceptable range of step_of_rank values. This separation leaves implementation freedom while ensuring interoperability through normalized rank semantics rather than a prescribed computation.
OF0 ignores RPL metric containers entirely. Its goal is connectivity to a Grounded root rather than optimization along a specific metric, making metric containers unnecessary and keeping the OF simple and universally applicable.
OF0 is designed as a default Objective Function to enable interoperation between RPL implementations across a wide spectrum of use cases. Because RPL has no built-in default OF and no metric container, two implementations without a common OF cannot interoperate; OF0 fills that gap without requiring protocol extensions.
RPL requires the use of a common Objective Function by all nodes in a network. Because RPL includes no default OF or metric container, implementations lacking a common OF cannot interoperate; OF0 (OCP 0) is defined to serve as that common baseline.
A candidate neighbor that would not satisfy the generic re-parenting rules of RFC 6550 Section 8 — including the boundaries on Rank augmentation within a DODAG Version — MUST NOT be considered as a preferred parent.
An implementation MAY allow configuration of a maximum stretch_of_rank, which MUST be less than or equal to MAXIMUM_RANK_STRETCH (5). If none is configured, a value of 0 is assumed and the step_of_rank is not stretched.
An implementation MUST maintain the stretched step_of_rank between the fixed constants MINIMUM_STEP_OF_RANK (1) and MAXIMUM_STEP_OF_RANK (9). This range reflects the allowable variation in link quality.
An implementation SHOULD allow the operator to configure a rank_factor and apply it to all links to multiply the effect of link properties in rank_increase computation. The rank_factor MUST be set between MINIMUM_RANK_FACTOR (1) and MAXIMUM_RANK_FACTOR (4).
An OF0 implementation SHOULD support the DODAG Configuration option (RFC 6550 Section 6.7.6) and apply the parameters therein, including MinHopRankIncrease, which overrides the DEFAULT_MIN_HOP_RANK_INCREASE constant. This requirement may be overridden by application-scenario guidance.
It is RECOMMENDED to base the computation of step_of_rank on dynamic link properties such as the Expected Transmission Count (ETX) metric rather than static administrative cost, because static cost favors paths with fewer but longer hops of poorer connectivity.
Out of the box, the default constant values SHOULD be used: rank_factor = DEFAULT_RANK_FACTOR (1), maximum stretch_of_rank = DEFAULT_RANK_STRETCH (0), and MinHopRankIncrease = DEFAULT_MIN_HOP_RANK_INCREASE (256 per RFC 6550).
Prior to selecting a router as preferred parent, an implementation SHOULD validate its Layer 2 and Layer 3 connectivity and suitability. A router that succeeds this validation SHOULD be preferred over one that did not.
Stretching the step_of_rank is NOT RECOMMENDED because it increases the apparent distance to the root, distorts the DODAG from its optimal shape, and may cause instabilities from greedy behaviors where nodes augment their Ranks to use each other as parents in a loop.
The backup feasible successor MUST NOT be the preferred parent, and MUST be in the same or a subsequent DODAG Version as this node. A router in the same DODAG Version with a Rank higher than this node's computed Rank MUST NOT be selected as a feasible successor.
Backup feasible successor selection applies seven ordered criteria: not the preferred parent, same or subsequent DODAG Version, no higher-Rank same-version router, lesser Rank preferred, implementation-dependent validation preferred, higher-order interface preferred, and currently-in-use successor preferred. These rules MAY be varied by configured policy.
Device monitoring for OF0 MUST provide at minimum: DAG information (DODAGID, RPLInstanceID, Mode of Operation, this node's Rank, current Version Number, Grounded flag) and a neighbor list indicating the preferred parent and alternate feasible successor with their Rank, Version Number, and Grounded flag.
OF0 defines two intermediate variables: step_of_rank, a strictly positive integer derived from link properties with a neighbor; and rank_increase, a strictly positive integer representing the delta between the preferred parent's Rank and this node's Rank.
OF0 defines two optional configurable parameters: stretch_of_rank (unsigned integer, max augmentation to step_of_rank to enable a backup feasible successor; defaults to 0 if unconfigured) and rank_factor (strictly positive integer multiplier on link properties in rank_increase computation; defaults to 1).
OF0 fixes the following constants: DEFAULT_STEP_OF_RANK=3, MINIMUM_STEP_OF_RANK=1, MAXIMUM_STEP_OF_RANK=9, DEFAULT_RANK_STRETCH=0, MAXIMUM_RANK_STRETCH=5, DEFAULT_RANK_FACTOR=1, MINIMUM_RANK_FACTOR=1, MAXIMUM_RANK_FACTOR=4. With DEFAULT_MIN_HOP_RANK_INCREASE=256, these allow encoding a minimum of 28 (worst) to a maximum of 255 (excellent) hops.
OF0 is triggered by the Objective Code Point (OCP) field in received DIO messages. OCP value 0 identifies OF0. The abstract interface also provides DAG information (DODAGID, Role, Rank), an ordered parent/feasible-successor list with transit option material, and triggered update events to the RPL core.
Preferred parent selection applies eleven ordered criteria: RPL Section 8 compliance, connectivity validation, interface policy, root administrative preference override, Grounded DODAG preference, more preferable root, most recent DODAG Version, lesser resulting Rank, DODAG Version with alternate parent, currently-in-use parent, and most recent DIO announcement. These criteria and their order MAY be varied by configured policy.
Rank computation formula: R(N) = R(P) + rank_increase, where rank_increase = (Rf * Sp + Sr) * MinHopRankIncrease. Rf is the rank_factor, Sp is the step_of_rank for the link, and Sr is the stretch term (≤ stretch_of_rank). MinHopRankIncrease defaults to DEFAULT_MIN_HOP_RANK_INCREASE (256).
An Objective Code Point (OCP) value of 0 has been assigned in the RPL Objective Code Point Registry (defined in RFC 6550 Section 20.5) for OF0, described as 'A basic Objective Function that relies only on the objects that are defined in RFC 6550.' Defining RFC is RFC 6552.
OF0 depends on the Rank and OCP protocol elements. If those elements are compromised — through modification or spoofing — an OF0 implementation may generate incorrect paths causing packets to be misrouted. Deployments are RECOMMENDED to use RPL security mechanisms where there is risk of routing information tampering.
OF0 introduces no new flows or messages and therefore requires no specific mitigation for new threats. It inherits all security vulnerabilities and mechanisms described in RFC 6550 and the ROLL security framework.