Open Shortest Path First version 3 (OSPFv3) Extensions optimize OSPFv3 behavior for more efficient routing in Mobile Ad Hoc Networks (MANETs). The OSPFv3 extensions improve routing efficiency and reduce overhead traffic in MANET environments so that network clusters can scale to support more users. The OSPFv3 extensions boost performance for delay-sensitive, mission-critical voice, video, and data traffic, and it facilitates the integration of wireless MANETs with existing wire-line products.
Your software release
may not support all the features documented in this module. For the latest
caveats and feature information, see
Bug Search Tool and the
release notes for your platform and software release. To find information about
the features documented in this module, and to see a list of the releases in
which each feature is supported, see the feature information table.
Use Cisco Feature
Navigator to find information about platform support and Cisco software image
support. To access Cisco Feature Navigator, go to
An account on Cisco.com is not required.
Prerequisites for OSPFv3 Extensions for MANETs
You must create the subscriber profile for PPP over Ethernet (PPPoE) service selection, assign the subscriber profile to a PPPoE profile, and enable PPPoE sessions on the interface. For details, see the "Mobile Ad Hoc Networks for Router-to-Radio Communications" module.
To optimize the use of OSPFv3 with MANETs, Cisco software implements extensions to OSPFv3 as defined in draft-chandra-ospf-manet-ext-02
. The result is a well-understood routing protocol (OSPF) used in a network topology that is constantly changing and where bandwidth is limited.
OSPF is optimized in these ways:
Tightly couples OSPFv3 with Radio Aware Routing (RAR)-compliant radios to provide faster convergence and reconvergence through neighbor presence indications and help determine accurate, real-time link metric costs.
Minimizes OSPFv3 packet size by implementing incremental hellos.
Minimizes the number of OSPFv3 packet transmissions by caching multicast link-state advertisements (LSAs).
Implements optimized flooding (overlapping relay) functionality to minimize the number of flooded LSAs.
Implements selective peering to reduce the OSPF network overhead by minimizing the number of redundant full adjacencies that an OSPF node maintains.
Radio-Aware Link-Metrics Tuning for OSPFv3
The RAR-compliant radio reports link-quality metrics to the router that are used by OSPFv3 as link metrics. You can fine-tune to adjust how these radio metrics are used by OSPFv3:
Configure how the radio-reported bandwidth, latency, resource, and relative link-quality metrics are converted to an OSPFv3 link cost.
Configure a hysteresis threshold on this resultant link cost to minimize the propagation of LSAs that report link-metric changes.
OSPFv3 receives raw radio-link data and computes a composite. In computing these metrics, you should consider these factors (see the figure "OSPF Cost Calculation for VMI Interfaces"):
Maximum data rate--the theoretical maximum data rate of the radio link, in bytes per second
Current data rate--the current data rate achieved on the link, in bytes per second
Resources--a percentage (0 to100) that can represent the remaining amount of a resource (such as battery power)
Latency--the transmission delay packets encounter, in milliseconds
Relative link quality (RLQ)--a numeric value (0 to 100) representing relative quality, with 100 being the highest quality
You can weight metrics during the configuration process to emphasize or de-emphasize particular characteristics. For example, if throughput is a particular concern, you can weight the current data rate metric so that it is factored more heavily into the composite metric. Similarly, you can omit a metric that is of no concern from the composite calculation.
Link metrics can change rapidly, often by very small degrees, which can result in a flood of meaningless routing updates. In a worst-case scenario, the network churns almost continuously as it struggles to react to minor variations in link quality. To alleviate this concern, you can use a tunable dampening mechanism to configure threshold values. Any metric change that falls below the threshold is ignored.
With the tunable hysteresis mechanism, you can adjust the threshold to the routing changes that occur when the router receives a signal that a new peer has been discovered, or that an existing peer is unreachable. The tunable metric is weighted and is adjusted dynamically to account for these characteristics:
Current and maximum bandwidth
You can deconfigure individual weights and clear all weights so that the cost is returned to the default value for the interface type. Based on the routing changes that occur, the cost can be determined by the application of these metrics.
For a dynamic cost to have the same cost as a default cost, all parameters must equal zero.
Each Layer 2 feedback can contribute a cost in the range of 0 to 65535. To tune down this cost range, use the optional
weight keyword with the
L2-factor keyword with the
ospfv3cost command. Each of these weights has a default value of 100 percent and can be configured in the range from 0 to 100. When 0 is configured for a specific weight, that weight does not contribute to the OSPF cost.
Because cost components can change rapidly, you might need to dampen the number of changes to reduce network-wide churn. Use the optional
hysteresis keyword with the
thresholdthreshold-value keyword and argument with the
ospfv3cost command to set a cost change threshold. Any cost change below this threshold is ignored.
You can use the
hysteresis keyword to specify a hysteresis value based on the percentage of change of the currently stored value in the routing table for the peer.
Each time the router receives a new packet discovery quality (PADQ) packet from the radio for a peer, a new cost is calculated for it. The
hysteresis keyword specifies the amount of change required before the router saves the new value.
The hysteresis percent calculated is performed as follows:
If the absolute value of (new_cost - saved_cost) is greater than (hysteresis_percent*saved_cost), then the new_cost is saved.
Because cost components can change rapidly, you might need to dampen the volume of changes to reduce network-wide churn. The recommended values for S2, S3, and S4 are based on network simulations that might reduce the rate of network changes. The recommended value for S1 is zero to eliminate this variable from the route cost calculation.
Each network might have unique characteristics that require different settings to optimize actual network performance, the table below lists the recommended cost settings intended as a starting point for optimizing an OSPFv3 network.
Table 1 Recommended Value Settings for OSPF Cost Metrics
ospfv3 6 cost dynamic weight throughout
ospfv3 6 cost dynamic weight resources
ospfv3 6 cost dynamic weight latency
ospfv3 6 cost dynamic weight L2-factor
The overall link cost is computed by using the formula shown in the figure below.
Figure 1. OSPF Cost Calculation for VMI Interfaces
To illustrate these settings, the following example shows how OSPF cost metrics might be defined for a VMI interface with one type of radio:
Selective peering reduces the OSPF network overhead by minimizing the number of redundant full adjacencies that an OSPF node maintains. Adjacencies to nodes that do not provide additional reachability can be kept in a two-way state. Selective peering reduces control-plane bandwidth utilization by reducing the number of database exchanges and routing updates.
Dataplane connectivity is not reduced when selective peering is enabled. User traffic flows over two-way links if they provide the best path through the network.
In the simplest example, selective peering determines if an adjacency should be formed when a new neighbor is discovered (a hello is received from a new neighbor). If the neighbor is not in the OSPF link state database, or if it is not reachable in the Shortest Path Tree (SPT), then the adjacency is formed. If the neighbor is in the OSPF link state database and is reachable, the neighbor is kept in the two-way state if the configured number of redundant paths to this neighbor is already formed.
Topology changes might cause the number of redundant paths to a given neighbor to fall below the configured level. When this occurs, selective peering can bring up adjacencies that were previously kept in the two-way state.
Selective peering takes link cost into consideration when determining which adjacencies to form. The objective is to have the reduced numbers of adjacencies formed over the lowest cost links. You can manually configure per-neighbor OSPF link costs, but with RAR-compliant radio interfaces, link costs are dynamically obtained from the radio through the VMI.
Selective Peering Link-Metrics Tuning
If the configured selective peering redundancy level is greater than 0,
then at least two OSPFv3 control plane paths are maintained for every one hop
neighbor. As new neighbors are discovered, full peering relationships are
formed regardless of the link cost (as long as the cost satisfies the
optionally configured minimum threshold specified in the
As additional neighbors are brought to the full peering state to
achieve the configured number of redundant paths to every neighbor, the router
evaluates the path costs resulting from these new peering relationships to
determine if they are incrementally better than the existing path costs. If
they are not, the router keeps these links in a two-way state until other
peering opportunities arise. The result is better path costs.
Consider the topology shown in the figure below. The configured
redundancy level is 1 (the default), meaning that Router A attempts to maintain
two paths to every one hop neighbor. Router A is in a full peering relationship
with Router B and the link cost is 50. Router B is in a full peering
relationship with Router D and the link cost is 30. Now Router D comes into
radio range of Router A with a link cost of 70. Because the number of paths
from Router A to Router D is currently 1 (through Router B), Router A brings
this relationship to the full state.
Figure 2. Selective Peering with Link Metrics
You can keep Routers A and D in a two-way state until the link cost
between them improves, or until another router comes into range that has better
link costs to both of them. This can be achieved by configuring a redundant
path cost threshold. In the figure above, if a redundant path cost threshold of
20 is configured, then Routers A and D will not transition to the full state
until their link cost falls below the current path cost of 80 (50 + 30) minus
20, or 60. Because the depicted path cost is 70, the routers remain in the
Configuring OSPFv3 in MANETs for Radio-Aware Routing
Perform this required task to create the VMI interface for OSPFv3 and associate it with the interface on which PPPoE is enabled. For OSPFv3 to take advantage of radio feedback, you must configure OSPFv3 MANET on the VMI. By default, VMI uses neighbor presence and link-metric data from the radio.
Enables selective peering only for instances of the OSPF process for which the corresponding interface has been configured with the ospfv3networkmanet command.
(Optional) redundancyredundancy-count--Changes the preferred number of redundant paths to any given peer.
(Optional) per-interface--Applies selective peering on a per-interface basis.
(Optional) Returns to privileged EXEC mode.
Preventing Full Peering with Neighbors with Poor Link Metrics
An RAR-compliant radio might not advertise link metrics to the router before a new OSPFv3 neighbor is discovered. You can configure OSPFv3 to wait for link metrics before considering a neighbor for OSPFv3 peering. You can specify a minimum metric threshold. If the radio-reported link metric is above this threshold, the neighbor will be held in two-way state. With this configuration, full peering with neighbors with poor link metrics can be effectively prevented.
Configures an OSPFv3 process to wait for link metrics from a neighbor before attempting selective peering with that neighbor.
(Optional) threshold--Specifies that the link cost computed from the received link metrics from the radio must be below this value. Otherwise, the neighbor is held in a two-way state until metrics are received that result in a link cost below the configured level. The range is 0 to 65535.
PPP over Ethernet (PPPoE) Extensions for Credit Flow and Link Metrics
Extensions to OSPF to Support Mobile Ad Hoc Networks
The Cisco Support and Documentation website provides online resources to download documentation, software, and tools. Use these resources to install and configure the software and to troubleshoot and resolve technical issues with Cisco products and technologies. Access to most tools on the Cisco Support and Documentation website requires a Cisco.com user ID and password.
Feature Information for OSPFv3 Extensions for MANETs
The following table
provides release information about the feature or features described in this
module. This table lists only the software release that introduced support for
a given feature in a given software release train. Unless noted otherwise,
subsequent releases of that software release train also support that feature.
Use Cisco Feature Navigator to find information about platform
support and Cisco software image support. To access Cisco Feature Navigator, go
An account on Cisco.com is not required.
Table 2 Feature Information for OSPFv3 Extensions for MANETs
OSPFv3 Extensions for MANETs
The OSPFv3 Extensions for MANETs feature optimizes OSPFv3 behavior for more efficient routing in highly mobile ad hoc environments.
The following commands were introduced or modified: