Routing Metrics Used for Path Calculation in Low-Power and Lossy Networks
Extracted elements (31)
A single link or node characteristic can serve simultaneously as a metric (to optimize path cost) and as a constraint (to filter links/nodes). For example, hop count may be minimized as an additive metric while a maximum-hop constraint prunes paths that exceed an operator-defined bound.
Dynamic routing metrics are essential in LLNs because link and node characteristics change frequently, but uncontrolled updates cause routing oscillations. Implementations should use multi-threshold algorithms, low-pass filtering, and hysteresis rather than fine-grained updates to avoid spurious routing changes and excessive power consumption from unnecessary route recomputation.
Routing metrics and constraints are deliberately decoupled from the Objective Function so that a generic OF can be combined with any subset of metrics and constraints. This separation allows new metrics to be introduced by future documents without requiring changes to existing Objective Functions.
The Node Energy object provides two levels of fidelity: a simple 2-bit node type (mains/battery/scavenger) for straightforward deployments, and a mid-complexity 8-bit E_E percentage field encoding energetic health for both battery-powered (current lifetime vs. desired lifetime) and scavenging nodes (power in vs. power out). This dual approach avoids mandating complex energy accounting across all LLN nodes.
When multiple Routing Metric objects share the same DAG Metric Container, the Prec (Precedence) field (0=highest) governs their use as tiebreakers in path selection. If several aggregated metrics bear the same Prec value, behavior is implementation-dependent.
Implementations must clearly state which metric and constraint options they include, which are default, and which are configurable. The ROLL working group will produce applicability statements clarifying which options apply to specific LLN deployment scenarios (industrial, home automation, urban, building automation).
If a RPL implementation receives more than one object of a type where at most one is permitted per DAG Metric Container (as constraint or as metric), the second object MUST be silently ignored.
In the presence of a constraint, a node MUST include a metric of the same type to allow checking whether the constraint is met, and a node MUST NOT change the content of a constraint object.
It is RECOMMENDED for RPL implementations to use multi-threshold algorithms to determine when metric updates should be sent, and to use low-pass filtering and hysteresis when practical. It is RECOMMENDED to carefully design the route optimization algorithm to avoid too-frequent computation of new routes upon metric value changes.
Reserved bits in the Routing Metric/Constraint Flag field MUST be set to zero on transmission and MUST be ignored on receipt. The O flag MUST be set to zero when C=0; the R flag MUST be cleared when C=1; the A field MUST be set to 0 and MUST be ignored on receipt when the R bit is set or the C flag is set.
The first node along a path inserting a Hop Count metric object MUST set the Hop Count field value to 1.
The Throughput object MUST at least comprise one Throughput sub-object, and the first Throughput sub-object MUST be the most recently estimated actual throughput.
Unrecognized TLVs MUST be silently ignored while still being propagated in DIOs generated by the receiving node.
When the LC object is used as a recorded metric and a node encounters a link color already present in an existing LC sub-object, the node MUST NOT add another identical LC sub-object but MUST increment the counter field of the existing one.
The DAG Metric Container carries Routing Metric/Constraint objects with a common header. The C flag distinguishes constraint from metric; the O flag marks a constraint as optional; the R flag indicates recorded (versus aggregated) metric; the A field encodes aggregation as additive (0), maximum (1), minimum (2), or multiplicative (3).
The ETX (Expected Transmission Count) object (type 7) encodes the expected number of transmissions needed to successfully deliver a packet to a neighbor. ETX may be computed as 1/(Df*Dr), though no specific formula is mandated. It may be used as a constraint or an aggregated additive path metric.
The Hop Count (HP) object (type 3) has a 4-bit reserved Res field, a 4-bit Flags field (no flags currently defined), and an 8-bit Hop Count field. When used as a constraint, the DAG root sets the maximum allowed hops; when used as a metric, each visited node increments the field.
The Latency object (type 5) carries one or more 4-byte sub-objects each encoding latency as a 32-bit unsigned integer in microseconds. It may be used as a maximum-latency constraint or as an aggregated additive path metric reflecting cumulative path latency.
The Link Color (LC) object (type 8) is an administrative 10-bit link characteristic used to attract or avoid specific links. LC Type 1 sub-objects (recorded metric) encode a 10-bit Link Color and 6-bit Counter; LC Type 2 sub-objects (constraint) encode a 10-bit Link Color, 5 reserved bits, and an 'I' bit for inclusion or exclusion.
The Link Quality Level (LQL) object (type 6) quantifies link reliability on a discrete scale from 0 (unknown) to 7, where 1 is the highest quality. When recorded, the LQL object body contains one or more 1-byte Type 1 sub-objects each encoding a 3-bit Val and 5-bit Counter (number of links at that LQL value) to compress path-wide link quality information.
The Node Energy (NE) object (type 2) uses sub-objects each encoding a 2-bit T field (node type: 0=mains, 1=battery, 2=scavenger), an 'I' bit (include/exclude), an 'E' bit (estimation present), and an 8-bit E_E field (estimated percentage of remaining energy). Multiple sub-objects combine to build inclusion/exclusion sets when used as a constraint.
The Node State and Attribute (NSA) object (type 1) carries an 8-bit Flags field with 'A' (aggregator capable) and 'O' (overloaded) bits. At most one NSA object may appear as a constraint and one as a metric per DAG Metric Container. Optional TLVs may convey additional node characteristics.
The Throughput object (type 4) carries one or more 4-byte sub-objects each encoding throughput as a 32-bit unsigned integer in bytes per second. The object MUST comprise at least one sub-object, and the first sub-object MUST be the most recently estimated actual throughput.
IANA created the 'RPL Routing Metric/Constraint' top-level registry with sub-registries for: Routing Metric/Constraint Type (types 1–8: NSA, Node Energy, Hop Count, Throughput, Latency, LQL, ETX, Link Color), Routing Metric/Constraint TLVs, Common Header Flag Field (bits 5–8 assigned), Common Header A Field (values 0–3 assigned), NSA Object Flags, Hop-Count Object Flags, and Node Type Field. All allocations require IETF Review.
A malicious node could falsely advertise favorable routing metrics to attract and intercept traffic. It is RECOMMENDED that RPL implementations put in place mechanisms to stop advertising routing metrics for highly unstable links that may be subject to attacks.
Routing metrics may reveal network weaknesses—unreliable links, energy-depleted nodes—to potential attackers. It is RECOMMENDED to carefully consider which metrics are used and their visibility, or to apply the security measures specified in RFC 6550 to protect advertised metric information.
Each ETX sub-object is 16 bits encoding ETX*128 as an unsigned integer rounded to the nearest whole number (e.g., ETX=3.569 → 457). If ETX exceeds 511.9921875, the value is capped at 65535.
The LQL Type 1 sub-object is a single byte: 3-bit Val field (LQL value 0–7, where 0 means undetermined and 1 is highest quality) and a 5-bit Counter field (number of links with that LQL value).
The NE sub-object Flags byte encodes: bits 7–4 reserved, bit 3 'I' (included/excluded), bits 2–1 'T' (node type), and bit 0 'E' (estimation present). The following 8-bit E_E field gives estimated percentage of remaining energy and MUST be set to 0 when the 'E' flag is cleared.
The NSA Object body has an 8-bit Res field (MUST be set to zero on transmission), an 8-bit Flags field with 'A' (bit 6, aggregator) and 'O' (bit 7, overloaded) bits defined, and optional TLVs. Unassigned flag bits MUST be set to zero on transmission and MUST be ignored on receipt.
The Routing Metric/Constraint Object Generic Format has an 8-bit Routing-MC-Type, a 16-bit Res Flags field containing P/C/O/R flag bits, a 3-bit A field (aggregation type), a 4-bit Prec field (precedence), and an 8-bit Length field defining the object body length in bytes.