Distance Vector Routing

Notes by Nitin Vaidya

Distance vector routing, unlike link state routing, does not disseminate the state of
all the links to all the hosts. Instead, each host periodically broadcasts (to its neighbors)
a distance vector, which contains a “digest” of the information available to that host. In
particular, each host maintains a routing table whose dimension is equal to the number of
hosts to which a route is known.
Let RX denote the routing table at host X, and let RX [Y ] be the entry in RX for
destination Y. RX [Y ] contains two pieces of information:

• Next-hop: The next host on the route from X to the destination Y. The next-hop
associated with RX [Y ] is denoted by RX [Y ].nexthop.

• Cost: The cost of the route from X to Y, for which the next hop is specified above.
The cost associated with RX [Y ] is denoted by RX [Y ].cost.

Each host maintains an estimate of the cost of the links to its neighbors. Let CXY
denote the cost of directed link XY. In general, the costs of directed links XY and YX may
be different. If a link from node X to Y is not known to exist, the cost of the link is deemed
to be ∞. Initially, if link XY is known to exist, then RX [Y ].nexthop is initialized to Y, and
RX [Y ].cost is initialized to CXY . If a route to some destination P is not know (or not valid),
then RX [P ].nexthop = ⊥ and RX [P ].cost = ∞. (Note that ⊥ denotes null.)
Each host periodically transmits a distance vector to its neighbors. The distance
vector sent by host X, denoted as DX , consists of the costs in the routing table. Specifically,
DX [Y ].cost = RX [Y ].cost. When a host Z receives a distance vector DX from host X, host
Z performs the following operation:
for all destinations Y such that Y 6= Z
if RZ [Y ].nexthop = X
RZ [Y ].cost = DX [Y ].cost + CZX
else if DX [Y ].cost + CZX < RZ [Y ].cost
then
RZ [Y ].cost = DX [Y ].cost + CZX
RZ [Y ].nexthop = X

In effect, if host Z learns a better route via host X to some destination Y, then host
Z will update its routing table entry for that destination. In addition, if host Z detects
that link ZX is broken, then for each destination Y for which X is the next hop (that is

i
RZ [Y ].nexthop = X), the route cost RZ [Y ].cost is updated to ∞, and the next hop is set
to ⊥.
This protocol is illustrated in Figure 1. In Figure 1(a), the routing tables at hosts A
and B are shown. Cost of each link is shown near the link in the figure. Subsequently, the
cost of link AD increases from 2 to 5, and this cost change is detected by host A. When host
D sends to A the distance vector shown in Figure 1(b), host A uses the new cost estimate
when computing the new routing table (as shown).
As shown in Figure 1(b), when host A receives the shown distance vector from host
D, it updates its own distance vector table entries for destinations C, D and E (note that
the next hop for these destinations is D, hence these entries must be updated); the new
routing table at host A is also shown in Figure 1(b). Subsequently, host A receives the
distance vector from host B (as shown in the figure). Now host A learns lower cost routes
to destinations C, D, E (via host B), and hence host A updates its routing table as shown
in Figure 1(b).
Consider a certain destination Y. The distance vector protocol allows the various
hosts in the network to determine their distance to destination Y. However, observe that,
the distance information propagates in the opposite direction, that is, away from Y. For
instance, in the algorithm above, when the distance vector is sent by X to Z (on the link from
X to Z), Z may update its routing table to start using the link from Z to X as the next hop
towards destination Y. Clearly, the distance vector was transmitted in a direction opposite
to the direction in which the link will be used. Thus, implicitly, we have assumed that the
links used by the algorithm are bidirectional. Although the costs in the two directions may
not be identical in general, we will assume identical costs in our examples.
When link failures occur, the distance vector protocol, as described above, can result
in monotonically increasing route costs in the distance vectors at some of the hosts, without
a convergence of the distance vectors to stable values. This problem is known as counting-
to-infinity. For a similar reason, when link costs increase substantially, significant number
of distance vector exchanges may be needed before the distance vectors stabilize. Let us
illustrate this using an example.
Example of counting-to-infinity: Suppose that the initial network state is as shown in
Figure 2(a). Note that costs of ∞ and null next hops are shown as − in Figure 2. Subse-
quently, let us assume that all the links in the network, except link AD, break simultaneously.
The cost of link AD remains unchanged. When D detects that links to C and E have failed,
it will consider the costs of those links as being ∞. In addition, D invalidates the routing
table entries for destinations B, C and E, since their next-hop entries were C or E (that is,
it sets the cost of routes to these destinations as ∞, and next hop as ⊥). Similarly, host A
modifies its state as shown in Figure 2(b).
Subsequently, host D receives the distance vector sent by host A, which specifies a
route to destination C with cost 3. In response, as shown in Figure 2(c), host D will update

ii
 Destination next−hop cost
A * 0
Routing table
1 C 2 B B 2 at host A
C D 3
B E D D 2
1 E D 3
2
1 Destination next−hop cost
D
A 2 A A 2 Routing table
B * 0 at host B
C C 1
D C 2
E C 3

(a)

1 C 2

B E
1
2
1
D
A 5

Destination cost
Destination next−hop cost New routing
A 2 table at A
B 2 Distance A * 0
vector after receiving
C 1 B B 2 distance vector
sent by D C D 6
D 0 from D
D D 5
E 1 E D 6

Destination cost
Destination next−hop cost
A 2 Distance New routing
B 0 vector A * 0 table at A
C 1 sent by B B B 2 after receiving
C B 3 distance vector
D 2
D B 4 from B
E 3
E B 5

(b)

Figure 1 Illustration of distance vector protocol: Next-hop marked as * indicates that no

routing is required

iii
 Destination next−hop cost
Routing table
A * 0 at host A
1 C 2 B B 2
C D 3
B E
D D 2
1
E D 5
2
4 Destination next−hop cost
D
A 2 A A 2
B C 2
Routing table
C C 1
at host D
(a) D * 0
E C 3

Destination next−hop cost

Routing table
C A * 0 at host A
B − −
B E C D 3
D D 2
E D 5
D
Destination next−hop cost
A 2
A A 2
B − −
(b)
Routing table
C − − at host D
D * 0
E − −

Destination cost
Destination next−hop cost
A 0 Distance New routing
B − vector A A 2
table at D
sent by A B − − after receiving
C 3
C A 5 distance vector
D 2
E 5 D * 0 from A
E A 7

(c)

Destination cost Destination next−hop cost New routing

Distance table at A
A 2 A * 0 after receiving
vector
B − sent by D B − − distance vector
C 5 from D
C D 7
D 0 D D 2
E 7 E D 9

(d)

Figure 2 Illustration of distance vector protocol with link failure: ∞ costs and null next
hops are shown as - in the figure. Next hop * indicates that routing is not needed.

iv
its next-hop for destination C to be A, and cost to be 3 + 2 = 5 (cost of link DA is 2, and
the total cost of 5 is smaller than the ∞ cost of the route to C in D’s routing table).
Now, D sends a distance vector to host A, with cost for destination C being 5, as
shown in Figure 2(d). Since, D is the next-hop for destination C in A’s routing table, host
A must update its cost for the route to host C. In particular, host A updates the cost for
destination C to be 5 + 2 = 7.
Subsequently, when D receives distance vector from host A, D must update the cost
for destination C, since RD [C] = A. It should be easy to see that whenever D and A receive
distance vector from each other, they will increase the cost of the route to destination C.
Thus, the cost will continue to grow monotonically. Since the costs in the distance vector
can grow to infinity (at least in theory), this problem is referred to as counting-to-infinity
problem. 2
Several solutions have been proposed to try to solve the counting-to-infinity problem.
We discuss one such solution. Observe that the counting-to-infinity problem arises above
essentially because of formation of a loop. In particular, host A uses D as the next hop for
destination C, and D uses A as the next hop for destination C. When host D sets its cost
for route to C as ∞ (after detecting failure of link DC) the cost in A’s routing table is still
3, even though A’s route goes via host D. In other words, the routing table entry at host A
is obtained using information that is stale, or older than the information available at host
D. Yet, host D later relies on the distance vector received from host A to update its own
distance vector, making A the next hop towards destination C. This results in the formation
of a loop. As this example suggests, a mechanism to avoid using stale information may help.
One possible approach for this is to associate a tag with each routing table entry
and each distance vector entry. The tag can potentially be defined in various ways. We
will consider a tag formed using a destination sequence number [?]. Each host – acting as a
destination – is given a sequence number. The tag is formed as a tuple (destination sequence
number, distance). Distance is defined as the sum of the costs of links on a route. Tags
associated with invalid routes will have the distance component as ∞. We will say that tag
(s1 , d1 ) is better than or larger than tag (s2 , d2 ) if one of the two conditions below holds:

• s1 > s2 (that is, the first tag has a larger sequence number)

• s1 = s2 and d1 < d2 (that is, the two tags have the same sequence number, but the
first tag contains smaller distance).

We will use the notation > to represent the better than relation. Thus (s1 , d1 ) > (s2 , d1)
represents “(s1 , d1) better than (s2 , d2 )”. A tag is associated with each routing table entry;
the tag is computed as described below. Initially, before a host learns any route to a certain
destination, tag for the route entry for that destination is deemed to be (−1, ∞) by default.

v
 Distance vector sent by a host X contains the next hop and tag associated with
each routing table entry at host X. Specifically, DX [Y ].cost = RX [Y ].cost and DX [Y ].tag =
RX [Y ].tag. Note that we use the dot (.) notation as a shorthand for “associated with”.
Thus, DX [Y ].tag means the tag associated with distance vector entry DX [Y ].
Before transmitting a new distance vector to the neighbors, host X increments its
own destination sequence number (in the tag corresponding to itself as destination) by 2.
This new tag is included in the distance vector. The distance value used to form this tag is
0. Thus, the tag attached by a host to its own entry is of the form (n, 0), where n is always
even (n is initially 0, and incremented by 2 before each new distance vector is transmitted
to neighbors).
The distance vector algorithm using tags has two components:

• Response to link failure: Suppose that a host Z has a valid routing table entry RZ [Y ]
with tag (m, d) and next hop as node P (a routing table entry is valid, if the next
hop is not null). Now, suppose that host Z detects that the link ZP has failed. In
this case, host Z increments the sequence number in routing table entry RZ [Y ].tag by
1, and the distance to destination Y is now deemed to be ∞. Thus, the new tag for
RZ [Y ] will be (m + 1, ∞), and the corresponding next hop is set to null (⊥). Note
that (m + 1, ∞) > (m, d).
Due to the manner in which tags are updated on receipt of a distance vector, the
sequence number field of each valid route table entry (that is route table entry with
finite distance metric) is always even. Thus, the above increment-by-1 operation on
detection of a broken next hop causes the sequence number in the tag associated with
the newly invalidated routing table entry to be odd, and larger than the previous
destination sequence number in the tag. In particular, in our example above, m + 1
will be odd.

• Response to a received distance vector:

Consider host Z that receives distance vector DX from host X (on link XZ). The first
step on receipt of the distance vector is to modify the tags in the distance vector:

for all destinations Y such that Y 6= Z

if tag associated with DX [Y ] is (a, b)
modify that tag to be (a, b + cost of link ZX)

The above step increments the second component of the tags in DX by the cost of link
ZX, so that the distance component of the tags in the distance vector now represents
the cost of routing to the various destination from Z via host X. In the discussion
below, the tags in DX before performing the above step will be referred as the original

vi
 tags in DX , and the tags after the above step are called modified tags. The modified
tags are used below in the pseudo-code for the remaining steps taken by host Z on
receipt of DX .

for all destinations Y such that Y 6= Z

if RZ [Y ].nexthop = X
RZ [Y ].tag = DX [Y ].tag
else if ((distance in DX [Y ].tag 6= ∞)
and DX [Y ].tag > RZ [Y ].tag)) then
RZ [Y ].nexthop = X
RZ [Y ].tag = DX [Y ].tag

The above steps ensure that, for any X, Y and Z, if RZ [Y ].nexthop = X then the
condition RX [Y ].tag > RZ [Y ].tag is true (as argued below). This implies that, starting
from any host, if we follow the next hop entries for any particular destination, the tag
associated with the routing table entries (corresponding to that destination) monotonically
increase until we reach the destination, or reach a host with a null next hop entry. This
monotonicity property ensures that no routing loops occur.
To see that the monotonicity property continues to hold, consider the following:

• Claim 1: The condition RX [Y ].tag > RZ [Y ].tag holds at the time that RZ [Y ] is set
equal to X, assuming that RX [Y ].tag does not change from the time X transmits DX
to Z until Z updates RZ [Y ].tag in response to DX : When RZ [Y ] is modified, RZ [Y ].tag
is set equal to modified DX [Y ].tag. Also, original DX [Y ].tag > modified DX [Y ].tag,
and original DX [Y ].tag = RX [Y ].tag (at the time X transmits DX to Z). Thus, it
follows that statement above (that RX [Y ].tag > RZ [Y ].tag) is true. Also, it is easy to
see that new RX [Y ].tag > old RX [Y ].tag.
• Claim 2: Once RZ [Y ].nexthop is set equal to X, the condition RX [Y ].tag > RZ [Y ].tag
continues to hold true so long as RZ [Y ].nexthop is not updated: To argue the correct-
ness of this claim, we need to consider two possibilities:
– While RZ [Y ].nexthop remains equal to X, host X modifies the tag associated with
RX [Y ]:
This tag is modified only under two conditions:
∗ The next hop is broken, in which case the new RX [Y ].tag is larger than the
old RX [Y ].tag, as we have seen previously.
∗ The routing table entry RX [Y ] is modified on receipt of a distance vector,
resulting in a new RX [Y ].tag . Since RX [Y ] is modified, it must result in the
new RX [Y ].tag being larger than the old RX [Y ].tag (due to claim 1 above).

vii
 Thus, the new RX [Y ].tag can only be larger than the old tag. Therefore, the
inequality RX [Y ].tag > RZ [Y ].tag will continue to hold.
– Tag RZ [Y ].tag is modified:
Again, there are two possibilities.
∗ Failure detection of link ZX resulted in the tag for RZ [Y ] being modified.
After this update, we will no longer have RZ [Y ].nexthop = X.
∗ RZ [Y ].tag was modified due to the receipt of a distance vector from another
host. In this case, again, due to claim 1 above, the desired property will hold
for the new next hop for RZ [Y ].

The above argument suggests that so long as RZ [Y ].nexthop = X, we will have

RX [Y ].tag > RZ [Y ].tag. Since the tags must monotonically increase along any valid route,
the route cannot contain loops. Does the use of tags help avoid the counting-to-infinity
problem? Let us revisit our example.
Counting-to-Infinity Example Continued: Reconsider the example in Figure 2. Fig-
ure 3(a) shows the routing tables containing tags at some point of time. Observe that all
sequence numbers in these tags are even, since all the routing entries are valid. Subsequently,
when nodes A and D detect the link failures, they update their own routing tables as shown
in Figure 3(b). Before host A sends a distance vector to D, it increments own destination
sequence number from 2 to 4. The distance vector sent by host A to host D is shown in
Figure 3(c), as well as the distance vector received from A after the tags are modified by
host D (recall that host D will decrement the distance component of the tags on receipt
of the distance vector from host A). Unlike the case of Figure 2(c), now host D does not
modify its routing table entries for destinations C and E, because the modified tag included
in the distance vector entries for destinations C and E are not better than the corresponding
entries in D’s own routing table. In particular, the tags for destination C in the routing
table at D, and the modified distance vector from A, are (7, −) and (6, −5) respectively.

viii
 Destination next−hop tag

C 2 A * (2,0) Routing table

1
B B (4,2) at host A
B E C D (6,3)
1 D D (2,2)
2 E D (8,5)
4
D
A 2 Destination next−hop tag
A A (2,2) Routing table
B C (4,2) at host D
(a)
C C (6,3)
D * (2,0)
E C (8,3)

Destination next−hop tag

A * (2,0) Routing table

B − (5,−) at host A
C C D (6,3)
D D (2,2)
B E E D (8,5)

Destination next−hop tag

D Routing table
A A A (2,2)
2 at host D
B − (5,−)
C − (7,−)
D * (2,0)
E − (9,−)

(b)

Destination tag Destination tag Distance vector

Distance received
vector A (4,0) A (4,2) by D from A
sent by A B (5,−) B (5,−) after distances in the
C (6,3) C (6,5) distance vector are
to D incremented by D
D (2,2) D (2,4)
E (8,5) E (8,7)

(c)

Figure 3 Distance vectors using tags

ix
 REFERENCES

[1] C. E. Perkins and P. Bhagwat, “Highly dynamic destination-sequenced distance-vector

routing for mobile computers,” in ACM SIGCOMM Symposium on Communication,
Architectures and Protocols, 1994.