The Optimized Link State Routing Protocol Version 2
updated by
- rfc-7183 — Integrity Protection for the Neighborhood Discovery Protocol (NHDP) and Optimized Link State Routing Protocol Version 2 (OLSRv2)
- rfc-7187 — Routing Multipoint Relay Optimization for the Optimized Link State Routing Protocol Version 2 (OLSRv2)
- rfc-7188 — Optimized Link State Routing Protocol Version 2 (OLSRv2) and MANET Neighborhood Discovery Protocol (NHDP) Extension TLVs
- rfc-7466 — An Optimization for the Mobile Ad Hoc Network (MANET) Neighborhood Discovery Protocol (NHDP)
Extracted elements (32)
OLSRv2 replaces OLSRv1's hop-count metric with general additive directional link metrics so that routes can optimize quality of service. The specification intentionally does not define how metric values are measured — that is left to external processes — and uses type extensions to allow multiple metric types to be defined without modifying the protocol.
TC messages may be 'complete' (advertising all routing MPR selectors) or 'incomplete' (reporting only additions), allowing a router to report incremental changes rapidly without repeating unchanged information, while periodic complete messages ensure eventual consistency.
Two separate MPR sets are used because flooding MPRs use outgoing link metrics and are selected per OLSRv2 interface, whereas routing MPRs use incoming neighbor metrics and are selected per router. A single shared set would force a suboptimal compromise between these incompatible selection criteria.
Different routers within the same MANET MAY use different MPR selection algorithms without loss of interoperability, provided each algorithm satisfies the required coverage property (all symmetric 2-hop neighbors reachable through selected MPRs with appropriate path metrics).
A broadcast, multicast, or anycast address MUST NOT be chosen as an originator address. If a routable address is selected, it MUST be one the router will accept as a destination.
A router MUST forward a received TC message on all OLSRv2 interfaces if and only if: the message did not originate at this router, has not been previously forwarded, is received for the first time on this interface, and was received from a flooding MPR selector.
A router running OLSRv2 MUST have at least one OLSRv2 interface.
Broadcast, multicast, and addresses limited in scope to less than the entire MANET MUST NOT be considered as routable addresses. Anycast addresses MAY be considered routable.
Each router's WILL_FLOODING and WILL_ROUTING MUST each be in the range WILL_NEVER (0) to WILL_ALWAYS (15). It MUST be ensured by administrative or other means that too many routers do not have either willingness equal to WILL_NEVER.
In a given MANET, TC messages and HELLO messages MUST both use IP or both use UDP so that messages of both protocols can be combined into the same RFC 5444 packet.
T_HOLD_TIME MUST be >= TC_INTERVAL. If TC messages can be lost, both T_HOLD_TIME and A_HOLD_TIME SHOULD be >= 3 × TC_INTERVAL. T_HOLD_TIME MUST be representable in the RFC 5497 exponent-mantissa notation.
TC message packets MUST be sent using the 'manet' IP protocol number or the 'manet' UDP well-known port number, as specified in RFC 5498.
TC messages MUST NOT be sent purely responsively; periodic transmission is required because a router has no knowledge of routers more than two hops away joining the network.
The maximum value of TC_HOP_LIMIT MUST be >= the network diameter in hops (255 is RECOMMENDED), and all values of TC_HOP_LIMIT MUST be >= 2. When multiple values are used, the pattern MUST ensure each router at each hop distance sees a regular message interval.
The originator address MUST be unique to this router and MUST NOT be used by any other router as an originator address or included in any network address in any other router's I_local_iface_addr_list.
When LINK_METRIC_TYPE changes, all link metric information is invalid; the router MUST invalidate all Link Tuples (setting L_out_metric := UNKNOWN_METRIC, L_SYM_time := EXPIRED) and remove all Router Topology, Routable Address Topology, Attached Network, and Routing Tuples.
MPR flooding is the optimized MANET-wide distribution mechanism in which a message is relayed only by routers that are flooding MPR selectors of the message's most recent forwarder, significantly reducing redundant retransmissions compared to blind flooding.
TC (Topology Control) is the sole OLSRv2-defined Message Type. TC messages are sent periodically by each router to advertise links to its routing MPR selectors and locally attached networks, and are distributed throughout the MANET via MPR flooding.
The Advertised Neighbor Sequence Number (ANSN) is a per-router counter included in TC messages and incremented whenever the set of advertised neighbors changes, allowing recipients to identify and discard stale out-of-order TC messages.
The Neighbor Information Base is extended to carry, per neighbor: originator address, incoming/outgoing neighbor metrics, flooding and routing willingness, flooding/routing MPR selection flags, routing MPR selector flag, and an N_advertised flag controlling TC message advertisement.
The Received Message Information Base (per-interface Received Set, Processed Set, Forwarded Set) ensures each TC message is processed exactly once and forwarded at most once per OLSRv2 interface, keyed by message type, originator address, and sequence number.
The Topology Information Base comprises the Advertising Remote Router Set, Router Topology Set, Routable Address Topology Set, Attached Network Set, and Routing Set — collectively recording network topology derived from TC messages and used to populate the IP routing table.
Two separate MPR sets are maintained per router: flooding MPRs (used to forward TC messages) and routing MPRs (used as intermediate hops in routes and as the set of neighbors whose links are declared in TC messages). A neighbor may be in both sets simultaneously.
OLSRv2 creates or updates Address Block TLV Type registries allocating: NBR_ADDR_TYPE (Type 8), GATEWAY (Type 9), MPR (Type 10), and LINK_METRIC (Type 11), plus separate registries for NBR_ADDR_TYPE values and MPR values.
OLSRv2 creates or updates Message TLV Type registries allocating: MPR_WILLING (Type 7) and CONT_SEQ_NUM (Type 8), each with their own type-extension sub-registries for HELLO and TC messages.
OLSRv2 registers Message Type TC (value 2) in the RFC 5444 Message Type registry managed by IANA, alongside HELLO (value 1) registered by RFC 6130.
Because OLSRv2 uses a reduced topology (only routing MPR selectors advertise links), integrity protection of HELLO and TC messages is strongly recommended. Without it, an attacker injecting false TC messages can manipulate the entire MANET's routing table. Key management for any security mechanism is a separate, unsolved problem addressed in Section 23.6.
OLSRv2 does not mandate any specific security mechanism in the base specification; security is delegated to companion documents. A compromised or malicious router can disrupt routing by advertising false topology, refusing to forward, or manipulating MPR selection to create black holes or routing loops.
TC message forwarding decision: upon receipt, a router checks (1) message not self-originated, (2) not in Forwarded Set, (3) not previously received on this interface (Received Set), (4) sender is a flooding MPR selector. All four conditions MUST hold to forward; otherwise the message is dropped or only processed.
Link metrics are encoded in a 12-bit compressed form consisting of an 8-bit mantissa (a) and a 4-bit exponent (b); the represented value is (257+a)×2^b − 256, spanning MINIMUM_METRIC=1 to MAXIMUM_METRIC=16776960 (2^24 − 256).
OLSRv2 defines Address Block TLVs for HELLO and TC messages including NBR_ADDR_TYPE (neighbor address type), MPR (MPR selection indication), LINK_METRIC (12-bit directional link metric, type extension selects metric type), and GATEWAY (attached network with hop count and metric).
OLSRv2 defines Message TLVs including MPR_WILLING (4-bit flooding willingness in high nibble, 4-bit routing willingness in low nibble) and CONT_SEQ_NUM (ANSN value, with type extension distinguishing complete from incomplete TC messages).