Optimizing Signaled LSPs

Once an LSP has been established, topology or resources changes might, over time, make the path suboptimal. A new path might have become available that is less congested, has a lower metric, and traverses fewer hops. You can configure the router to recompute paths periodically to determine whether a more optimal path has become available.

If reoptimization is enabled, an LSP can be rerouted through different paths by constrained-path recomputations. However, if reoptimization is disabled, the LSP has a fixed path and cannot take advantage of newly available network resources. The LSP is fixed until the next topology change breaks the LSP and forces a recomputation.

Reoptimization is not related to failover. A new path is always computed when topology failures occur that disrupt an established path.

Because of the potential system overhead involved, you need to control carefully the frequency of reoptimization. Network stability might suffer when reoptimization is enabled. By default, the optimize-timer statement is set to 0 (that is, it is disabled).

Configuring LSP optimization is meaningful only when constrained-path LSP computation is enabled, which is the default behavior. For more information about constrained-path LSP computation, see Disabling Constrained-Path LSP Computation.

To enable path reoptimization, include the optimize-timer statement:

For a list of hierarchy levels at which you can include this statement, see the statement summary section for this statement.

Once you have configured the optimize-timer statement, the reoptimization timer continues its countdown to the configured value even if you delete the optimize-timer statement from the configuration. The next optimization uses the new value. You can force the JUNOS software to use a new value immediately by deleting the old value, committing the configuration, configuring the new value for the optimize-timer statement, and then committing the configuration again.

After reoptimization is run, the result is accepted only if it meets the following criteria:

1. The new path is not higher in IGP metric. (The metric for the old path is updated during computation, so if a recent link metric changed somewhere along the old path, it is accounted for.)
2. If the new path has the same IGP metric, it is not more hops away.
3. The new path does not cause preemption. (This is to reduce the ripple effect of preemption causing more preemption.)
4. The new path does not worsen congestion overall.

   The relative congestion of the new path is determined as follows:

   1. The percentage of available bandwidth on each link traversed by the new path is compared to that for the old path, starting from the most congested links.
   2. For each current (old) path, the software stores the four smallest values for bandwidth availability for the links traversed in ascending order.
   3. If one of those four values is smaller than any of the new bandwidth availability values, it indicates that the new path has at least one link that is more congested than the least congested link used by the old path. Traffic is not switched to this new path.
   4. If none of those four values is smaller than any of the new bandwidth availability values, it indicates that the new path is less congested than the old path.

When all the above conditions are met, then:

5. If the new path has a lower IGP metric, it is accepted.
6. If the new path has an equal IGP metric and lower hop count, it is accepted.
7. If you choose least-fill as a load-balancing algorithm and if the new path reduces congestion by at least 10 percent aggregated over all links it traversed, it is accepted. For random or most-fill algorithms, this rule does not apply.
8. Otherwise, the new path is rejected.

You can disable the following reoptimization criteria (a subset of the criteria listed previously) by issuing the clear mpls optimize-aggressive command or including the optimize-aggressive statement at the [edit protocols mpls] hierarchy level:

• If the new path has the same IGP metric, it is not more hops away.
• The new path does not cause preemption. (This is to reduce the ripple effect of preemption causing more preemption.)
• The new path does not worsen congestion overall.
• If the new path has an equal IGP metric and lower hop count, it is accepted.

Including the optimize-aggressive statement in the configuration causes the reoptimization procedure to be triggered more often. Paths are rerouted more frequently. It also limits the reoptimization algorithm to the IGP metric only.

Copyright © 2008, Juniper Networks, Inc. All rights reserved. Trademark Notice.