Final MDSDV Design
5.4 MDSDV Mechanism
5.4.4 Receiving Control Packets
When a node receives a control packet, it follows the process in figure 5.6. The node checks the packet’s type and processes it as follows.
1. Receiving a Hello Message: When a node receives a Hello Message, it invokes the algorithm in figure 5.5 to deal with the Hello Message. The following is a description of the algorithm when node R receives a Hello Message from node S.
• If there is no entry belonging to node S in R’s NT table (i.e., new neigh-bour), node R adds a new entry including the address of node S, Link id (R-S), and TimeOut (The neighbour node is considered as unreachable node when the time in the TimeOut field has expired). Next, it adds an entry as a direct route for node S in R’s routing table, and unicasts a Full Dump (FD) to node S. FD includes the best route for each destination.
• If an entry for node S is available in R’s NT table (i.e., old neighbour), node R updates the TimeOut field of the entry that belongs to node S.
01 The receiver node checks its Neighbours Table (NT).
02 If (No entry belongs to the Hello Message sender in my NT) 03 {
04 Add an entry for the Hello Message sender in my NT.
05 Add an entry as a direct route for the Hello Message sender in my RT.
06 Unicast a Full Dump of my RT to the Hello Message sender.
07 } 08 else 09 {
10 Update the TimeOut field of the entry that belongs to the Hello Message sender in my NT.
11 Update the sequence number, Changed at, and TimeToLive fields of the entry that belongs to the Hello Message sender in my RT.
12 }
Figure 5.5: Receiving a Hello Message Algorithm
5.FinalMDSDVDesign
133
2. Receiving an Update Packet: When a node receives an Update Packet, it in-vokes the algorithms in figures 5.7 and 5.8 respectively to process the packet.
01 The receiver node checks whether the Update Packet is received from a new or an old neighbour.
02 If (No entry belongs to the Update Packet sender in my NT) 03 {
04 Add a new entry for the Update Packet sender in my NT.
05 Add a new entry as a direct route for the Update Packet sender in my RT.
06 Unicast a Full Dump of my RT to the Update Packet sender.
07 } 08 else 09 {
10 Update the TimeOut field of the entry that belongs to the UP sender in my NT.
11 Update the sequence number, Changed at, and TimeToLive fields of the entry that belongs to the Update Packet sender in my RT.
12 }
13 Invoke the algorithm in figure 5.8 to deal with the entries of the UP.
%11 Update the Sequence Number field of the entry that belongs to UP sender.
Figure 5.7: Receiving an Update Packet Algorithm
As soon as node R receives an Update Packet, it invokes the algorithm in figure 5.7. The following is a description of the algorithm executed at node R to check whether the packet is received from a new or a known neighbour.
• If the Update Packet is received from a new neighbour, node R does the following:
– Adds an entry for the Update Packet sender in its NT.
– Adds a new entry as a direct route to the Update Packet sender in its RT.
– Unicasts a Full Dump of its RT to the Update Packet sender con-taining the best route for each destination.
• If the Update Packet is received from an old neighbour, node R does the following:
– Updates the Timeout field of the corresponding entry in its NT table.
– Updates the sequence number of the corresponding entry in its RT table.
Next, node R invokes the algorithm in figure 5.8 to deal with each entry of the Update Packet.
The following is a description of the algorithm in figure 5.8 executed at node R to deal with each entry of the received packet (Full Dump or Update Packet).
We use the following notation:
• my Id: is the identifier of the node executing the algorithm.
• m.sender: is the packet sender ID.
• m.dst: is the destination field of the received entry.
• m.fh: is the first hop field of the received entry.
• m.sh: is the second hop field of the received entry.
• m.metric: is the number of hops field of the received entry.
• m.ln: is the link id field of the received entry.
• m.SeqNum: is the sequence number field of the received entry.
• DST: is the destination field of an entry in the routing table.
• FH: is the first hop field of an entry in the routing table.
• SH: is the second hop field of an entry in the routing table.
• Metric: is the number of hops field of an entry in the routing table.
• LN: is the link id field of an entry in the routing table.
• SeqNum: is the sequence number field of an entry in the routing table.
Node R discards the received entry if R’s address is equal to m.dst, m.fh or m.sh. If not, node R modifies the received entry’s fields where the m.sh field is set to m.fh field, the m.fh field is set to m.sender field, and m.metric field is incremented. Then, node R starts to compare the modified entry with the entries that are already in its routing table as follows:
• If no entries are available for this destination (m.dst), node R inserts the modified entry in its routing table.
• If the modified entry is not similar (m.fh 6=FH and m.sh 6=SH and m.ln 6=LN) to any entry in the routing table, node R inserts the modified entry in its routing table.
• If the modified entry is similar to more than one entry, node R discards the modified entry.
• If the modified entry is similar to only one entry, node R does one of the following:
– Overwrites the modified entry if it includes a route that is better than the existing one.
– Discards the modified entry if it includes a route that is worse than the existing one.
01 While (There are more entries in the received Packet) 02 {
03 The receiver node checks its address with the destination, first hop and second hop fields of the received entry
04 If (my Id = m.dst or my Id = m.fh or my Id = m.sh) 05 discard the received entry.
06 else
07 {
08 modify the received entry’s fields as follows:
09 m.sh = m.fh, m.fh = m.sender, m.metric++
10 If there is no entry in my routing table to m.dst 11 Insert the modified entry in my routing table.
12 else
13 {
14 If(the modified entry is not similar to any entry in my RT) 15 Insert the modified entry in my routing table.
16 else
17 {
18 If (the modified entry is similar to only one entry in my RT)
19 {
20 If (m.SeqNum > SeqNum OR (m.SeqNum = SeqNum and m.metric < Metric))
21 Overwrite with the modified entry.
Figure 5.8: Processing a Full Dump and an Update Packet Algorithm
How do we consider that a route is better than another one? As in DSDV, the route with larger sequence numbers is considered better. But if two routes have the same sequence numbers, the one with smaller metric is considered better.
The following example illustrates how nodes deal with a received Update Packet.
Figure 5.9 presents a network of 8 nodes. Node 8 has two neighbours (node 1 and node 5) as shown in table 5.7.
Figure 5.9: Ad Hoc network consists of 8 nodes
Neighbour ID Link Id TimeOut
1 8-1 167.3256
5 8-5 171.4325
Table 5.7: Neighbours Table of node 8
Each node periodically broadcasts a Hello Message or an Update Packet (de-pends on its NT table) as mentioned in section 5.3. Suppose that node 8 moves towards node 2, and let’s assume that node 8 checked its NT table and found that there are two neighbours (node 1 and node 5) as shown in table 5.7. So, node 8 broadcasts an Update Packet as shown in figure 5.10. All neighbours (node 1, node 2, and node 5) receive the Update Packet and respond as follows:
Because node 1 and node 5 are old neighbours of node 8, they update the Time-Out field in the corresponding entry in their neighbours tables. Next, node 1 and node 5 invoke the algorithm in figure 5.8 to deal with the entries of the Update Packet.
Figure 5.10: Node 8 is broadcasting an Update Packet and receiving a Full Dump
On the other hand, node 2 considers node 8 as a new neighbour. Thus, node 2 adds node 8 as a neighbour in its NT table and adds an entry as a direct route in its RT. Next, it unicasts a Full Dump of its routing table to node 8 as shown in figure 5.10. Then, it invokes the algorithm in figure 5.8 to deal with the entries of the Update Packet.
3. Receiving a Full Dump: When node R receives a Full Dump from node S, it checks if node S is a new or old neighbour. If node S is a new node neighbour, node R adds a new entry for node S in its NT table and adds a new entry as a direct route for node S in its RT table. Otherwise, node R updates the TimeOut field of the corresponding entry in R’s NT, and updates the sequence number, changed at, and TimeToLive fields of the corresponding entry in R’s RT. Next it invokes the algorithm in figure 5.8 to add, overwrite, or ignore the received entries.
4. Receiving an Error Packet: As described in chapter 4, any node that discovers a broken link should generate and broadcast an Error Packet containing the following fields:
Packet Sender: the node’s address that discovers the broken link.
Destination: the unreachable node address.
Link Id: the link id which is between the node that discovers the broken link and the unreachable node.
The following is a description of the algorithm in figure 5.11 executed at node R to deal with a received Error Packet . We use the following notation:
• my Id: is the identifier of the node executing the algorithm.
• m.sender: is the Packet Sender field in the received packet.
• m.dst: is the Destination field in the received packet.
• m.ln: is the Link Id field in the received packet.
• FH: is the first hop field of an entry in the routing table.
• LN: is the link id field of an entry in the routing table.
01 The receiver node checks its address with the packet sender (m.sender) field in the Error packet.
10 delete any entry in RT where FH = m.sender
11 }
12 else
13 {
14 delete any entry in RT where LN = m.ln.
15 }
16 }
Figure 5.11: Receiving an Error Packet Algorithm
When node R receives an Error Packet, it invokes the algorithm in figure 5.11 to do one of the following:
• Discard the Error Packet if its address is equal to the address in the Packet Sender(m.sender) field of the Error Packet. Or
• Delete any entry in its routing table where the first hop (FH) is equal to the packet sender (m.sender) field if R’s address is equal to the address in the Destination (m.dst) field of the Error Packet. Or
• Delete any entry in its routing table where the link id (LN) is equal to link id (m.ln) of the Error Packet.
Our aim is to minimize the large number of control packets that MDSDV0 suf-fers from. So, one modification is that a receiving node does not need to re-broadcast an Error Packet.
Figure 5.12: Node 1 discovers a broken link and broadcasts an Error Packet
For more illustration, we present an example describing the behaviour of each node when receiving an Error Packet.
Figure 5.12 presents a network with 8 mobile nodes. When node 1 discovers that the link between itself and node 2 is broken, it does the following:
• Considers node 2 as an unreachable node and deletes the corresponding entry from its NT as shown in Table 5.8.
• Deletes any entry from its routing table where node 2 acts as a first hop as shown in Figure 5.13.
• Generates and broadcasts an Error Packet as shown in Table 5.9
Neighbour ID Link Id TimeOut
2 1-2 151.3546
3 1-3 169.1256
5 1-5 170.2325
6 1-6 171.4357
Table 5.8: Neighbours table of node 1
Figure 5.13: Routing table of node 1 at the instance of discovering a broken link
Packet Sender Destination Link-Id
1 2 1-2
Table 5.9: Error Packet generated by node 1
All neighbours of node 1 (node 3, 5, and 6) will receive the Error Packet. As an example, we describe how node 3 deals with the received Error Packet.
Because node 3 is not the Error Packet sender nor the Destination, it deletes any entry where the link id is equal to 1-2. So, node 3 deletes the following paths as shown in Figure 5.14:
3 - 1 - 2 3 - 4 - 2 - 1
Figure 5.14: Routing table of node 3 after dealing with the received Error Packet
From Figure 5.14, we can notice that node 3 deletes the entries where link id = 1-2 (in red). But it is unable to delete other paths to other destinations that use the link 1-2. For example, node 3 has the path 3 - 1 -2 - 4 (yellow colour). Of course the entry that include this path should be deleted as well, but node 3 can
not delete it because it does not meet any condition of the Error packet. For this reason, we use the Failure packet which will be described later, and we use the TimeToLive field to delete the route when its time is expired.
5. Receiving a Failure Packet: Sometimes, the source node uses a path with a broken link to send data. When an intermediate node receives a data packet for forwarding and fails to forward it to an adjacent node, it generates and unicasts a Failure Packet to the source. The Failure Packet contains the following fields:
Data Packet Sender: the source node address that is sending the data.
First Hop: the neighbour node address that the source node used to send the data.
Destination: the destination node that the source node is communicating with.
When a node receives a Failure Packet, it invokes the algorithm in Figure 5.15.
The following is a description of the algorithm executed at node R to deal with the received Failure Packet. We use the following notation:
• my Id: is the identifier of the node executing the algorithm.
• m.sender: is the address in the Data Packet Sender field of the Failure Packet
• m.fh: is the address in the First Hop field of the Failure Packet .
• m.dst: is the address in the Destination field of the Failure Packet .
• FH: is the first hop field of an entry in the routing table.
• DST: is the destination field of an entry in the routing table.
When node R receives a Failure Packet, it invokes the algorithm in figure 5.15 to do one of the following:
• If R’s address is equal to the address in the source field (i.e., node R is the data sender), it deletes the entry where the destination and first hop are the the same as the destination and first hop included in the Failure packet. Then, node R selects an alternative path to continue sending the data.
• Otherwise (i.e., node R is not the data sender), it forwards the Failure Packet towards the source node.
01 The receiver node checks its address with the Data Packet Sender (m.sender) field in the Failure Packet.
02 If (my Id = m.sender) 03 {
04 Delete the entry where DST = m.dst and FH = m.fh 05 }
06 else 07 {
08 Forward the Failure Packet towards the source node.
09 }
Figure 5.15: Receiving Failure Packet Algorithm
For more illustration, we suppose that node 3 sends data using the path 3 1 -2 - 4 (yellow colour) in Figure 5.14. When node 1 receives the data packet and needs to forward it to node 2, it finds that the link between itself and node 2 is broken. In this case, node 1 generates and unicasts a Failure Packet to node 3 (the data packet sender) as shown in Table 5.10. When node 3 receives the Failure Packet, it deletes the route for node 4 through node 1 (3 - 1 -2 - 4).
Data Packet Sender First Hop Destination
3 1 4
Table 5.10: Failure Packet generated by node 1