The purpose of Route Damping is to control routing instability at receiving peers
Peers monitor received route announcements and maintain history of "flapping"
(route going up and down)
In order to provide stability, peer holds up announcement of routes detected to be flapping
Holding up of announcements is a good thing to do because it helps to
consolidate routing updates based upon incoming announcements into fewer
outgoing announcements.
However, don't want to hold up announcement of stable routes because this will
hamper route convergence
In order to do effective damping, delays will need to be on order of minutes
for unstable routes
The "trick" involved in route damping is to adapt the delay for the announcement
of an outgoing route to the measured stability of the route
Need to remember history for a long interval
Want to increase delay in proportion to number of flaps over the interval
Recent history of stability of a route is taken to be a predictor of
future behavior
A metric of instability at current time is maintained
This metric is decayed over time so that after an extended period of stability it tends to 0
Metric and algorithm chosen allow for a short delay of announcement of route
that has been stable with just a few flaps and long term suppression of route with many flaps
An exponential decay algorithm is used for maintaining the metric
Decay rate can vary for reachable and unreachable routes and also for
routes for which comparable alternative path exists
(i.e., more aggressive delay of non-critical path)
Use of exponential decay function allows for simple computation of metric.
Decay value array(s) are precomputed at initialization time and only require a multiply to compute during run time.
Arrays can be of fairly small size but still cover a large time interval.
The following configuration values will be used:
Cutoff Threshold
Reuse Threshold
Metric ceiling
Metric half-life time when reachable
Metric half-life time when unreachable
Instability history time interval
Initially these configuration values will be compiled in
Data structure will be added to associate a history with each route (rt_table) entry.
These entries can exist even if the rt_table entry is removed so that flapping routes can be identified when the destination is unreachable.
Decay of unstable route history entries is done in an efficient manner by queuing all
history entries eligible for reuse at the same time in the same slot of a slotted timing array.
A pointer is updated each time the timer expires to point to the next slot of
the slotted array.
All history entries queued on the last slot (the slot just before the current
pointer)
are considered to be expired.
In general, the damping algorithm (based upon a now expired internet draft
by Curtis Villamizar) is highly efficient in terms of processing and storage requirements.
Hope to have the basic work completed within a month. Enhancements, such as
run-time configuration of configuration parameters, will follow as time permits
or demand exists.