Destination Sequenced Distance Vector (DSDV)

DSDV [94][38] is a proactive routing protocol which maintains routes regardless of their usage. It is based on the Bellman-Ford routing algorithm, which can become un-acceptable in mobile ad hoc networks because of its long convergence time. Numer-ous extensions or modifications to DSDV have been proposed to improve its perfor-mance such as [3][13][52][60][70][71][72][118]. DSDV is a distance vector routing

protocol and it solves the major problem associated with the Distance Vector routing of wired networks (i.e., Count-to-infinity), by using destination sequence numbers.

Also, at all times, the DSDV protocol guarantees loop-free paths to each destination.

Using DSDV, each mobile node maintains a routing table, that lists one route for each destination. Each routing table entry consists of the destination node, the first hop towards the destination, the metric (number of hops to reach the destination), and the sequence number which is originally generated by the destination node. Sequence numbers are used to distinguish the new routes from the stale routes. The routing table is used to transmit packets between the nodes of the network.

In DSDV, each mobile node advertises its routing table (e.g., by broadcasting its en-tries) to its current neighbours. The entries in the routing table may change dynami-cally over time, so the routing information should be advertised to ensure that every node can always locate every other mobile node. Additionally, each mobile node agrees to relay data packets to other nodes upon request. Before each advertisement of a new routing table, mobile node increases its sequence number by 2.

DSDV takes care of topology changes by using a certain procedure which is based on two kinds of updating: time-driven updates, which are periodic transmissions of a node’s routing table, and event-driven updates which react to link failures. Nodes schedule the newly recorded routes for immediate advertisement to the current node’s neighbours. Routes with an improved metric are scheduled for advertisement at a time which depends on the average settling time for routes to the particular destination under consideration.

To reduce the amount of information in the routing information packets, DSDV uses two different types of update packets: a “full dump” or an incremental update. A full dump is the sending of all the routing table entries to the current neighbours and could span many packets. In contrast, in an incremental update, the node only sends those entries that are changed since the last full dump. The incremental update must fit in only one Network Protocol Data Unit (NPDU). The node implements some

means to determine which routes have significant changes, and includes them in each incremental advertisement. For example, if a stabilized route shows a better metric for some destination, it is likely to be considered as a significant change. But if a route with a new sequence number and the same metric is received, it is unlikely to be considered as a significant change.

As mobile nodes are free to move from place to place, this movement may cause a link breakage. The broken link may be detected by the MAC layer or by not receiving broadcasts for a certain time from a former neighbour. When a link to a neighbour is broken, the route to that neighbour and any route through that neighbour is im-mediately assigned a ∞ metric. Because this change qualifies as a substantial route change, such updated routes are immediately broadcast as new routing information.

When a node receives new routing information, it compares this information with the information that is already available in its routing table. Any route with a greater sequence number is used. Routes with a lower sequence number are ignored. A route with the same sequence number as an existing one is chosen if it has a better metric, and the existing one is discarded. The metrics of the chosen routes from the received information are each incremented by one hop. The new stored routes are scheduled for immediate advertisement to the current neighbours.

DSDV uses the settling time table to prevent fluctuations of routing table entry adver-tisements. The settling time table fields are Destination address, Last settling time, and Average settling time. A node consults its settling time table to decide how long to wait before advertising the new route. When new routing information is received by a node, and applying the updates to the table, processing occurs to delete stale routes. A node expects to receive a regular update from its neighbours; when no up-dates are received from a neighbour, the node may decide that this neighbour is no longer available as a neighbour. When that occurs, any route that uses that neighbour as a next hop should be deleted, including that node as the actual destination. The main problem of DSDV comes from the time it needs to converge, because a route

can not be used after a certain time elapse from the periodic broadcast. This may not be acceptable in mobile ad hoc networks, where the topology changes frequently.

Moreover, the periodic broadcast adds a great amount of overhead.

For illustration, Figure 3.2 presents an example of an ad hoc network consists of 8 nodes before and after the movement of node N1. Table 3.2 is the routing table of node N6 at the moment before the movement. The Install time field is used to determine when to delete stale routes.

Figure 3.2: An example of Ad hoc Network

Routing Update Process: In the routing table updating process, the node tags each update packet with a sequence number to distinguish stale from new updates. This sequence number is an increasing number that uniquely identifies each update packet from a given node. The update packet may contain more than one entry. So, if a node receives an update packet, the sequence number of each entry is compared with the sequence number of the corresponding node already stored in the routing table. If the sequence number of the update packet is smaller, the newly received information should be ignored because it is stale. If the sequence number of the received information is larger, the entries should be entered into the routing table. If the sequence numbers are equal, then the metric is compared and the route with the

lower metric will be used.

Suppose that node N7 in Figure 3.2 advertises its routing information by broadcasting an update packet to its neighbours as shown in table 3.1

Destination Next hop Metric Seq. No

Table 3.1: An Update Packet advertised by node N7

When node N6 receives the update packet, it checks the received routing information of each entry contained in both the update packet (Table 3.1) and its routing table (Table 3.2). From the table 3.3 which shows the routing table of node N6 after dealing with the received update packet, we can see the following:

• The entries with higher sequence numbers are always entered into the routing table, regardless of metric value. For example, the entry belongs to node N1 has higher sequence number (S516 N1) in the update packet (Table 3.1). This entry is entered into the routing table of node N6 (Table 3.3).

• If sequence numbers are the same, the metric is compared. If the metric in the update packet is smaller, the entry is entered into the routing table, otherwise, the entry is ignored. For example, the entry belongs to node N5 has the same sequence number (S502 N5) in both the update packet and the routing table, but the entry in the routing table (Table 3.2) has a lower metric, so the entry in the update packet is ignored.

• The entries with old sequence numbers in the update packet are always ignored.

For example, entries belonging to nodes N2 and N8 have old sequence numbers respectively in the update packet, so both of them are ignored.

Destination Next hop Metric Seq. No Install

N1 N4 3 S406 N1 T001 N6

Table 3.2: Routing table of node N6 when receiving the Update Packet from node N7

Destination Next hop Metric Seq. No Install

N1 N7 2 S516 N1 T810 N6

Table 3.3: Routing table of node N6 after dealing with the Update Packet

Link Failure Process: To describe the Link Failure Process, let’s assume that node N1 moves away from node N7 (Figure 3.2). Node N7 detects that the link between itself and node N1 is broken. Node N7 immediately assigns ∞ metric and increments

the sequence number of node N1 (becomes odd sequence number S517 N1). Next, it generates, and broadcasts an update packet as shown in Table 3.4. When node N6 receives the update packet, it updates its routing table (Table 3.3) with the received information (odd sequence number and ∞ metric) in the entry that belongs to node N1 as shown in Table 3.5. This means that link to node N1 is broken. The route to a lost node is re-created when that node comes back again, and broadcasts an update packet with an equal or greater sequence number and finite metric.

Destination Next hop Metric Seq. No

Table 3.4: An Update Packet advertised by node N7 with a broken link

Destination Next hop Metric Seq. No Install

N1 N7 ∞ S517 N1 T810 N6

Table 3.5: Routing table of node N6 after dealing with the broken link