OSPF Reverse Metric
Extracted elements (27)
RM is signaled via LLS in Hello packets rather than LSAs to ensure the signal is scoped only to a specific link and neighbor, and persists only as long as the signaling router continues to include the TLV.
The H (higher-only) and O (offset) flags are provided to cover two distinct operational modes: H ensures RM only increases metrics (safe for maintenance), while O enables additive adjustment for adaptive traffic engineering without replacing the provisioned value.
The RM mechanism is applied only on the signaling router's side (e.g., hub/aggregation router) rather than requiring configuration changes on potentially many spoke/leaf routers. This is particularly valuable for hub-and-spoke or Clos topologies with large numbers of edge devices.
The RM mechanism is not applicable for broadcast or NBMA links because the same objective is achieved there using the OSPF Two-Part Metric mechanism (RFC 8042) for OSPFv2. The OSPFv3 solution for those link types is out of scope.
A router that does not support this specification will ignore the Reverse Metric and Reverse TE Metric LLS TLVs and not update its metrics. The behavior is identical to pre-specification behavior, so no backward compatibility issues arise.
The Reverse TE Metric TLV may be used to signal reverse TE metrics so that the neighbor updates the TE Metric sub-TLV of the Link TLV in its TE Opaque LSA (RFC 3630), analogous to the procedures for the Router-LSA metric.
When using multi-topology OSPF (RFC 4915), a router MAY include multiple instances of the Reverse Metric TLV (one per topology MTID) in a single Hello packet's LLS block.
A router receiving a Hello packet containing the Reverse Metric TLV on a link MUST use the RM value to derive the metric for the link to the advertising router in its Router-LSA when the RM feature is enabled.
An implementation MUST NOT signal RM to neighbors by default and MUST provide a configuration option to enable RM signaling on specific links. An implementation MUST NOT accept RM from its neighbors by default.
An implementation MUST support configuration to enable/disable acceptance of RM from neighbors on specific links, to safeguard against inadvertent use of RM.
If authentication is used in the OSPFv2 routing domain, the Cryptographic Authentication TLV (RFC 5613) MUST also be used to protect the contents of the LLS block, including the Reverse Metric TLVs.
It is RECOMMENDED that implementations support detection of frequent changes in RM signaling and ignore RM (reverting to provisioned metric) during such conditions, to prevent network churn caused by a misbehaving or misconfigured router.
Reception of malformed LLS TLVs or sub-TLVs SHOULD be logged, but such logging MUST be rate-limited to prevent Denial of Service (DoS) attacks.
Routers that receive an RM advertisement SHOULD log an event to notify system administration, to assist in rapidly identifying the node advertising a metric different from local configuration.
The H flag is ignored when the O flag is set; these two flags are mutually exclusive. When H is set and O is clear, the metric from the TLV is used only when it is higher than the provisioned metric.
To avoid metric instability when multiple routers signal RM on the same link, it is RECOMMENDED that the RM value signaled by a router not be derived from RM being signaled by any of its neighbors; routers should use their provisioned local metric values when computing RM to signal.
When a router stops including the Reverse Metric TLV in its Hello packets, a router that modified its metric in response MUST revert to using its provisioned metric value.
When the link TE metric is raised to maximum (either by RM or explicit configuration), this SHOULD immediately trigger CSPF recalculation to move TE traffic away from that link.
When the O (offset) flag is clear, the metric value to be advertised is copied directly from the TLV value. When the O flag is set, the signaled value is added to the provisioned metric; if the sum exceeds maximum interface cost (0xffff), the maximum cost is advertised.
When using multi-topology OSPF, a router MUST NOT include more than one instance of the Reverse Metric TLV per MTID. If more than one instance per MTID is present, the receiving router MUST only use the value from the first instance and ignore the others.
The OSPF Reverse Metric (RM) mechanism uses LLS TLVs in Hello packets to allow a router to signal to its neighbor(s) the metric value that neighbor should advertise for the link back towards the signaling router. This enables a router to influence inbound traffic without requiring configuration changes on the neighbor.
The signaled RM does not alter the OSPF metric parameters stored in the receiving router's persistent provisioning database; it only affects the value advertised in LSAs for as long as the RM TLV is being received.
IANA registered two new code points in the 'Link Local Signalling TLV Identifiers (LLS Types)' registry: type 19 for the Reverse Metric TLV and type 20 for the Reverse TE Metric TLV.
A misbehaving or misconfigured router that frequently changes RM signaling values can cause neighbors to repeatedly update their Router-LSAs, leading to network churn and instability. Implementations SHOULD detect this and revert to provisioned metrics under such conditions.
Modification of the Reverse Metric and Reverse TE Metric TLVs may result in traffic being misrouted. The security considerations from RFC 5613 (OSPF LLS) apply, and when OSPFv2 authentication is in use, the Cryptographic Authentication TLV MUST protect the entire LLS block.
The LLS Reverse Metric TLV (Type=19, Length=4 octets) carries an 8-bit MTID, an 8-bit Flags field (with H=0x1 and O=0x2 flags defined), and a 16-bit unsigned Reverse Metric value. Remaining flag bits MUST be set to 0 on transmission and ignored on reception.
The LLS Reverse TE Metric TLV (Type=20, Length=4 octets) carries an 8-bit Flags field (H=0x1, O=0x2), a 24-bit RESERVED field (MUST be 0 on transmission, ignored on receipt), and a 32-bit unsigned Reverse TE Metric value.