Reasons for unnecessary route changes: (1) not knowing the cause b c c withdraws its route f withdraws its route; but the withdrawal by e is delayed d e f Solution: propagate information about fault and its location g knows the invalidity of [e, c, a], and adopts [d, b, a] immediately g g will mistakenly regard route [e, c, a] as valid, and adopt it h

Reasons for unnecessary route changes : (2) uncertainty about fault type the fail-stop of links <a, b> and <a, c>, instead of the fail-stop of a, is detected b c b, c, e, f withdraw their routes; but the withdrawal by d is delayed d e f d withdraws its route Solution: G waits for certain time g will mistakenly regard [d, b, a] as valid, and adopt it g g withdraws its route h

Reasons for unnecessary route changes : (3) obsolete fault information <a, c> re-joins Information m0(<a, c>) is generated to signify the fail-stop of link <a, c> b c d e f m0(<a, c>) reaches f, but is delayed in reaching e c, f, and g change their routes back Delayed m0(<a, c>) reaches e, and then g g rejects the delayed m0(<a, c>), and does not change route g Solution: reject obsolete information by attaching seq. number to fault information g changes its route to [d, b, a] g changes its route to [d, b, a] h

Reasons for unnecessary route changes : (4) fault propagation state corruption at c: c withdraws its route b c c corrects its state Before the fault propagates to f, c corrects the state of itself Solution: execute “correction” action quicker than “propagation” action before c corrects its state, f withdraws its route. Thus, the fault at c propagates to f d f before f corrects its state, g changes its route. Thus, the fault at c propagates to g g h