Self-Stabilizing Leader Election in Dynamic Networks

Abstract

Two silent self-stabilizing asynchronous distributed algorithms are given for the leader election problem in a dynamic network with unique IDs. A leader is elected for each connected component of the network. A BFS DAG, rooted at the leader, is constructed in each component. The construction takes O(D i a m) rounds, where D i a m is the maximum diameter of any component. Both algorithms are self-stabilizing, silent, and work under the unfair daemon, but use one unbounded integer variable. Algorithm DLE selects an arbitrary process to be the leader of each component. Algorithm DLEND (Distributed Leader Election No Dithering) has the incumbency property and the no dithering property. If the configuration is legitimate and a topological fault occurs, each component will elect, if possible, an incumbent to be its leader, i.e., a process which was a leader before the fault. Furthermore, during this computation, no process will change its choice of leader more than once.

Appendix A: Emulations of DLEND

In Figs. 11 and 12, we illustrate two emulations of DLEND. For simplicity, our emulations use synchronous computation, i.e., every enabled process executes at every step.

In Fig. 10, we illustrate a legitimate configuration. We do not show the entire network, but only that portion that is relevant for the emulation on one component. We then assume that a topological change occurs, resulting in a new configuration, one of whose components is shown in Fig. 11.

In Fig. 12, we illustrate an emulation of DLEND starting from a configuration that is not post-legitimate. Observe that the incumbency and no dithering properties do not hold for this emulation.

In both emulations, we assume that I n t r i n s i c_P r i o r i t y(x) is equal to the negative of the degree of x. (Suppose that the application would prefer a process of higher degree to be the final leader.) This value can be changed by a topological fault; for example, I n t r i n s i c_P r i o r i t y(L) = −3 in Fig. 10, but I n t r i n s i c_P r i o r i t y(L) = −4 in Fig. 11a–x. The value of L.i l p, however, does not change until L executes Action C5, as shown in Fig. 11m.

1.1 A.1 Legend

• 1. Each process x is represented by a circle, labeled by the ID of that process.

• 2. A line between x and y indicates that x and y are neighbors. This line may or may not have an open arrow head. An open arrow from x to y indicates that x is a child of y in the preliminary BFS DAG, i.e., x.p_v e c t o r = S u c c(y.p_v e c t o r).

• 3. The color of a process x is represented as follows.

  • (a) White represents 0.

  • (b) A cross represents 1.

  • (c) Grey represents 2.

  • (d) Black represents 3.

• 4. A double circle indicates that x.p_l i d = x.i d.

• 5. A hexagon indicates that x.f_l i d = x.i d.

• 6. Eight symbols are written next to each process x, in three rows.

  • (a) The first row is x.p_v e c t o r = (x.n p l p,x.p_l i d,x.p_l e v e l), the preliminary vector of x.

  • (b) The second row is x.i_v e c t o r = (x.n f l,x.i l p,x.i_l i d), the intermediate vector of x.

  • (c) The third row is x.f_v e c t o r = (x.f_l i d,x.f_l e v e l), the final vector of x.

• 7. Links of the preliminary BFS DAG are shown as open-headed arrows. An open arrowhead on the edge from x to y indicates that x ∈ P_C h l d r n (y), y ∈ P_P r n t s(x), and x.p_v e c t o r = S u c c(y.p_v e c t o r), i.e., x.l e a d_p a i r = y.l e a d_p a i r and x.p_l e v e l = 1 + y.p_l e v e l. (Recall that x.l e a d_p a i r = (x.n p l p,x.p_l i d)).

• 8. Dashed polygonal lines separate components of the preliminary BFS DAG.

• 9. Links of the final BFS DAG are shown as solid arrows. A solid arrow from x to y indicates that x.f_v e c t o r = S u c c(y.f_v e c t o r), i.e., x.f_l i d = y.f_l i d and x.f_l e v e l = 1 + y.f_l e v e l.

1.2 A.2 Emulation Starting from a Post-Legitimate Configuration

Fig. 10

Initial legitimate configuration. S, W, and Y are preliminary leaders of their components, while the final leaders of the components are G, L, and M. M is the final leader of the component containing Y. After a purely topological fault, D will be connected to Q and S, and will no longer be in the same component as M, which is not shown in this figure since, after the first step, M will be irrelevant to our discussion

Fig. 11

Emulation of DLEND starting from a post-legitimate state. The emulation is synchronous, and every enabled process is selected at each step

1.3 A.3 Emulation Starting from an Arbitrary Configuration

In Fig. 12, we illustrate a computation of DLEND starting from an “arbitrary” configuration, i.e., one which is not post-legitimate. The initial configuration, illustrated in Fig. 12a, the network has just experienced a topological fault. The dashed “fault line” shows where the smaller set, which consists of the processes D, S, and Y has now joined the larger set of fourteen processes, with the creation of three new links. In addition, a link from R to another process has been deleted; this link connected the larger set to their leader, a process whose ID is Z and which is not shown. The condition for leadership stability does not hold, since neither set was in a legitimate configuration before the fault.

The new component now has seventeen processes, and contains an “incumbent” leader, D; yet, D will not be elected leader. The no dithering property also fails, as we observe during the emulation.

Fig. 12

Emulation of DLEND starting from a configuration which is not post-legitimate. The incumbency property fails, because Process D is the only incumbent, and yet B is chosen to be the final leader. The no-dithering property fails, because Process Y’s chosen final leader is initially Z, then changes to S, and then again to B

1.4 A.4 Benchmarks which Hold during the Emulations

We now list the benchmarks which hold at each of the figures of each of the two emulations given here. Whenever a benchmark holds at some configuration, it holds at all subsequent configurations.

In the computation shown in Fig. 11, Benchmark 0 holds at (a), Benchmark 1 holds at (b), Benchmark 2 holds at (g), Benchmark 4 holds at (g), Benchmark 5 holds at (i), Benchmark 6 holds at (o), Benchmark 7 holds at (v), and Benchmark 8 holds at (z).

In the computation shown in Fig. 12, Benchmark 0 holds at (a), Benchmark 1 holds at (b), Benchmark 2 holds at (c), Benchmark 4 holds at (f), Benchmark 5 holds at (f), Benchmark 6 holds at (m), Benchmark 7 holds at (t), and Benchmark 8 holds at (x).