Methodology to Solve the Count-To-Infinity Problem

2009 IEEE International Advance Computing Conference (IACC 2009) Patiala, India, 6–7 March 2009

Methodology to Solve the Count-To-Infinity Problem by Accepting and Forwarding Correct and Updated Information Only Using “Test” Packet Amit D. Kothari, Dharmendra T. Patel Charotar Institute of Computer Application, Changa, Gujarat, India. the corresponding line in its new routing table. Note that the old routing table is not used in the calculation. This updating process is illustrated in Fig. shows a subnet. The first four column of part (b) show the delay vectors received from the neighbors of router J. A claims to have a 12-msec delay to B, a 25-msec delay to C, a 40-msec delay to D, etc. Suppose that J has measured or estimated its delay to its neighbors, A, I, H, and K as 8, 10, 12 and 6 msec, respectively. Consider how J computes its new route to router G. it knows that it can get to A in 8 msec, and A claims to be able to get to G in 18 msec, so J knows it can count on a delay of 26 msec to G if it forwards packets bound for G to A. Similarly, it computes the delay to G via I, H, and K as 41 (31 + 10), 18 (6 + 12) and 37 (31 + 6) msec, respectively. The best of these values is 18, so it makes an entry in its routing table that the delay to G is 18 msec and that the route to use is via H. The same calculation is performed for all the other destinations, with the new routing table shown in the last column of the figure 1 (b).

Abstract: In Distance Vector Routing [4,7, 9, 10] each router collects and forwards the information from and to the neighbors. It was the original ARPANET routing algorithm and use in the Internet under the RIP [2]. The methodology of collecting and broadcasting the routing related information initiates the problems i.e. (1) twoNode Loop Instability, (2) Three-Node Loop Instability and (3) Count-to-Infinity, are well known all over. We try to give the details of Distance Vector Routing Algorithm and the problems in the Introduction section and discuss the Related Works in direction of this problem. New algorithms are introduce to give the solution of the discuss problem along with the corrective actions for arising the problem due to implementation of new discuss methodology. We try to reduce the loopholes in the Distance Vector Routing Algorithm by applying the new concept of test packet, which is helpful in receiving and forwarding the correct and updated information regarding the available and non available routers to the other routers.

Key Words Linear Count-to-Infinity, Close neighbor, test packet, Split horizon, Split Horizon and Poison Reverse 1. Introduction 1.1 Distance Vector Routing In distance vector routing, [1] each router maintains a routing table indexed by, and containing one entry for, each router in the subnet. This entry contains two parts: the preferred outgoing line to use for that destination and an estimate of the time or distance to that destination. The metric used might be number of hops, time delay in milliseconds, total number of packets queued along the path, or something similar. The router is assumed to know the “distance” to each of its neighbors. If the metric is hops, the distance is just one hop. If the metric is queue length, the router simply examines each queue. If the metric is delay, the router can measure it directly with special ECHO packets that the receiver just timestamps and sends back as fast as it can. As an example assume that delay is used as a metric and that the router knows the delay to each of its neighbors. Once every T msec each router sends to each neighbor a list of its estimated delays to each destination. It has also a similar list from each neighbor. Imagine that one of these table has just come in from neighbor X, with Xi being X’s estimate of how long it takes to get to router I. If the router knows that the delay to X is m msec, it also know that it can reach router I via X in Xi + m msec. By performing this calculation for each neighbor, a router can find out which estimate seems the best and use that estimate and

Figure 1(a) A subnet. 1(b) Input from A, I, H, K, and the new routing table for J. 1.2 Problems 1.2.1 The Count-to-Infinity Problem [1] Distance Vector Routing reacts rapidly to good news, but leisurely to bad news. To see how slow bed news propagates, consider the situation of 2 (a) in which all the lines and router are initially up. Router B, C, D, and E has distance to A of 1, 2, 3 and 4 respectively. Suddenly A goes down, or alternatively, the line between A and B is cut, which is effectively the same thing from B’s point of view in figure 2(b). At the first packet exchange, B does not hear anything from A. Fortunately, C says: do not worry; I have a path to A of length 2. As a result, B thinks it can

32

reach A via C, with a path length of 3. D and E do not

update their entries for A on the first exchange.

Figure 2. (a) Before and (b) After Count to infinity problem On the second exchange, C notices that each of its neighbors claims to have a path to A of length 3. It picks one of them at random and makes its new distance to A 4, as shown in the third row. Subsequent exchanges produce the history shown in the rest of Figure 2. (a) and 2 (b). 1.2.1 Two-Node Loop Instability [3] 2

X X

2

X

4

A

A

6

B

Before Failure ’

X

X

X

4

A

A

6 B

After Failure X

X

10

X

B

A

6

N

4

A

needed for our discussion. At the beginning, both nodes A and B know how to reach node X. But suddenly, the link between A and X fails. Node A changes its table. If A can send its table to B immediately, everything is fine. However, the system becomes unstable if B sends its routing table to A before receiving A’s routing table. Node A receives the update and, assuming that B has found a way to reach X, immediately updates its routing table. Base on the triggered update strategy, A sends its new update to B. now B thinks that something has been changed around A and updates its routing table. The cost of reaching X increases gradually until it reaches infinity. At this moment, both A and B know that X cannot be reached. However, during this time the system is not stable. Node A thinks that the route to X is via B; node B thinks that the route to X is via. If A receives a packet destined for X, it goes to B and then comes to B. Packets bounce between A and B, creating a two-node loop problem. 1.2.2 Three-Node Instability [3]

B X

After A receives update from B X

10

X

B

X

A

14

4

A

A

B

After B receives update from A

X X

’

A

X

4

’

P

A

B

Finally Figure 3. Two-node Instability Figure 3 shows a system with three nodes. We have shown only the portions of the routing table

Y

Q

D

C

B

J

Figure 4. Routers in Networks Above problem is for linear (sequential) architecture i.e. (A-B-C-D-…). But suppose we have vast network with scattered multiple routers as in figure 4. Now here router X is reachable via routers A, Y and N. Now D, C and B have an entry in their routing tables that they can reach to X via A. If X goes down, so in A’s routing table it is not reachable i.e. (’). Before/After A send this information to D, suppose P forward the information to D that it can reach to X via N. Now D checks the information came from P has an alternative path for X (i.e. via N) and D could not reach to X via A now. So it updates its table according to information gain from P and also forwards it to other

2009 IEEE International Advance Computing Conference (IACC 2009)

33

close neighbors (i.e. A and B). Now the information comes to A also, that it can reach to X via D. The path is (A-D-P-N-X). A can also spread this information to its other neighbors. Same way the wrong information is spread throughout the network in each transaction of information between routers. The loop stops when the cost in each node reaches infinity. When any packet sent by A for X cannot reach to X via N after traveling up to N (as discuss above) (in worst case), or it is stopped in between by any other node that has an updated information that X is not reachable via N in a fair condition, A and intermediate routers update X is not reachable (i.e. ’). So here X is not reachable by both A and N. But due to delay in correct information propagation makes the node A to accept the correction gained from D.

2. Related Works In Defining Infinity [1] [3] we redefine infinity to a smaller number, such as 100. The system will be stable in less than 20 updates. As a matter of fact, most implementations of the distance vector protocol define the distance between each node to be 1 and define 15 as infinity. However, this means that the distance vector routing cannot be used in large system. The size of the network, in each direction, can not exceed 15 hops. Split Horizon [3] and Split Horizon and Poison Reverse [3] are the solution of two-node instability. It requires partly information sharing or sharing with warning. In Split Horizon [3] each node sends only part of its table through each interface. As in figure 3 taking information from node A, modifying it, and sending it back to node A creates the confusion. Node B eliminates the line of X in its routing table before it sends it to A. In this case, node A keeps the value of infinity as the distance to X. Using the split horizon strategy has one draw back. Normally, the distance vector protocol uses a timer, and if there is no news about route the node deletes the route from its table. When node B in the previous scenario eliminates the route to X from its advertisement to A, node A cannot guess that this is due to the split horizon strategy (the source of information was A) or because B has not received any news about X recently. The split horizon strategy can be combined with the poison reverse [3] strategy. Node B can still advertise the value for X, but if the source of information is A, it can replace the distance with infinity as a warning: “Do not use this value; what I know about this route comes from you”. Link state [5, 6, 8] algorithm also free of count-to-infinity problem.

3. Solution of the Two-Node Loop Instability and Linear Count-to-Infinity As describe in figure 3 every router maintain three fields in their table i.e. . So as figure 3 when B forward the information that it has a path to X of Length 6. It has to forward this information with its successor name also i.e. = . So A can conclude that the successor node is me and X is not reachable by me and this communication is moving in Count to Infinity and Two-Node Instability direction. So A does not update any information related to X coming from any such type of node in which itself A is as an intermediate node or A can verify this personally sending echo packet to X before making any kind of correction. And even node A can also immediately ask to node B to make the correction for the same entry in its routing table also. Now suppose before node B update its local table, Here if node C sends the information to B that it can forward the message to Node X via B in hope 3. So node B does not interested because if it updates the information regarding node X in its own table it creates loop. i.e. If it B updates the table then The entry of Node B for node X is . And entry of Node C for node A is . So it’s a loop “C to D and D to C” So now suppose node B does not have any other alternatives it concludes that node A is not reachable to me. Now the entry for node X in B’s table is . So now forwarding the information regarding node X via A and B to the rest of the nodes is correct and can avoid the spreading of the wrong information in the other areas of the network gradually. So this way when any two nodes exchange the information if they also send the successor node (along with destination and value) via which they can forward the packet, so receiver router can check the occurrence of looping and avoid it. And we can stop the Two-Node Loop Instability and Linear Count-to-Infinity problem. Unlike Split Horizon each node forwarding detail information but it removes the draw back of delete the route of the router whose information does not revise within the time period.

4. Solution of Three-or-More-Node Instability and Count-to-Infinity 4.1 Route Verification Algorithm When node X goes down, A has an idea about X’s non-availability. So it has ’ entry in its routing table. Now A gets the information about the other alternative path toward X from D. If A follows the following methodology it can stop spreading of incorrect information further. All the routers following the pure DistanceVector-Routing are good enough but changes are required only when… “1. Any router (i.e. A) which has an entry like ’ only in its routing table for any other router has to verify the availability and correctness of the other recommended new alternative path first by sending the test packet to the desire router (i.e. X) via the recommended new path and make the correction for the path to the desire router only if it founds the positive response from the destination and 2. Router that has any value in its routing table for any destination and it gets ’ (not reachable) status from its neighbor for the same destination.

2009 IEEE International Advance Computing Conference (IACC 2009)

Before modifying its current status by ’ regarding the destination router, it has to check the availability of the path towards the destination router via its current route using test packet and if it founds its correct avoid the correction otherwise make the delay by ’”. For the optimality if we maintain one more column “Close Neighbor” for each destination router in the routing table of each router which indicate via which any forwarded packets are to be forwarded to the destination router at last, in figure 4, after the non availability of link between A and X when A found the alternative path towards X from D through the close neighbor N. It can send the test packet to X via N first, (if A has the information about optimum path from A to N) through the optimum path i.e. (A-D-N-X) available in its own routing table instead of A-D-P-N-X and collect the status from N if X is down or not. (If X is not down it can select the optimum path i.e. (A-D-N-X) for future purpose also). For simplicity we will not consider the implementation of the “close neighbor” attribute2. in routing table of router. 4.2 Overhead of Test Packet in the Network The above algorithm increases the overhead of generating the test packet every time before making3.the correction for ’ entry in routing table, but using it we can avoid spreading of the wrong information in the network which causes unnecessarily wasting the bandwidth on larger amount. 4.2 Problem of Increasing the Load of Neighbor Nodes One problem in the implementation of the above methodology is that when any router goes down, answering the test packets generated by the others increases its neighbors’ load.

5. Solution of Problem of Increasing the Load of Neighbor Node 5.1 Router X Goes Down As in the above figure 4 when router X goes down its neighbors A and N’s load is increase by answering the test packet. To solve this problem router can implement the following methodology. Any one of “close neighbor” router (i.e. A and N) of down router (X), had replied negative for the test packet at once, sent by the other available intermediate routers from each available incoming route to the “close neighbor” (i.e. towards A and N), in the network, for the their successive router (i.e. X), such type of packets do not forwarded to “close neighbor” router again, via other intermediate routers(C, P, D) in future for the test packet who were in the path at once in the past to the above routers (i.e. A or N) and got the “negative” answer only. They cache locally only the negative answers and update their own routing table in case of negative answer by ‘’’ All the intermediate router become conscious and cache the “negative” answer only, comes from “close neighbor” router or from other intermediate router who has already cache the answer before and replying regarding the availability of desire router against the query generated by any other routers in the network. Once they received the answer about the test

packet positive or negative from desire router or from “close neighbor” router respectively they react according to the answer in future as following manner. If any router got positive answer from X itself…. 1. Intermediate routers (i.e. C, P, D) do not keep track of the positive answer comes from the desire router and select the best of two routes ( one route in routing table and second route came with answer of “test” packet) and update the routing table in case of positive answer. If they have ’ entry related to the desire router X before and they got the positive answer from X itself, they directly update their own routing table entry by replacing the ’ value according the hope count value available in the reply of test packet to avoid the test packet generation work by them in future. But they do not cache the positive answer and use to replies on behalf of router X in future instead of forwarding the request (i.e. test packet) to X. If router caches the positive answer also and replies in between, this method again directs the network in the same direction of count-to-infinity and instability problem. In negative answer the intermediate router update their routing table by ’ entry for the destination router (i.e. X) and cache the answer. So when in future they found test packet for the same destination, the intermediate node can replied directly without asking to the “close neighbor”. This technique reduces the load of “close neighbor” routers and all the other routers came in test packet reply path at once in each transaction. Any intermediate router goes down and wakes up after some time; it lost the status of other routers in the network. It can collect the information easily from its neighbors and generating or forwarding the upcoming test packet to it; get the reply, cache it for the future usage. Example In Figure 4 when X goes down and N and A replied negative at once for the test packet of X to C and D. So C and D both have an idea about nonavailability of node X and they have make ’ entry in to their routing table. Now suppose D got the other route from router P (P-N-X), D first send the test packet via that route (i.e. through P) and N replied negative for it and P got the negative response from it (updating its own routing table by making entry ’ in its routing table) and D is also maintain the previous ’ entry in its table as it is. Q and J have not any idea regarding this. Now suppose node J wants to send the message to X but it is not forwarded from P onwards and when any neighbor router of P try to forward any other available route information node P first verify the same new route first. So this way we can avoid spreading of wrong information in further into the network and information regarding non-availability of X is also spreading correctly and in faster manner than previous one.

2009 IEEE International Advance Computing Conference (IACC 2009)

35

5.2 Router X Up 5.2.1 X Up After Long Time If router X up after a long time may the other routers had already deleted the entry related to X. In case of new entry of router X Distance Vector routing methodology is good enough for other routers in the network. Router X can also use the same strategy for generating its own routing table. During the table generation if it founds any entry regarding any other routers is having ’ value it follows the rules as describe in section 4.1. 5.2.1 X Up After Short Time If X up after shorter period of time, entry related to X is mark with ’ in the routing table of the other routers. Now when Node X up its “close neighbor” updates the table first, only after verifying the route by generating the test packet because the entry related to X is ’ in A, N or Y. Same way when A informed to D that it has an available route for X, D verifies it personally by test packet first, up to it does not found ’ from any intermediate node (negative answer) or get the positive answer from desire router X only. Router X can also use the Distance-VectorRouting strategy for generating its own routing table. During the table generation if it founds any entry regarding any other routers is having ’ value it follows the rules as describe in section 4.1. The following methodology is also helpful to avoid the mass generation of test packet for node X by all the routers who have ’ value in their routing table for X. 5.2.1 If X Generate the Test Packet If X generates the test packet first for the other router then… 1. Test packet forwarded with the hope count value start from 0 and increasing it gradually as the packet is forwarded ahead. 2. When test packet is forwarded to the destination router the hope count field is incremented by each node in the path and all the intermediate routers and destination router make a new entry or update optimally information related to the source router (i.e. X) with hope count, so we can avoid the generation of test packet for X by other intermediate routers in future. 3. If test packet reaches to the destination router then destination router make or update the entry related to X. 4. If destination node replies positively for the test packet then same as above all the intermediate routers and source router X updates information related to destination router optimally if it exists or make a new entry related to the destination router respectively. If intermediate routers have ’ value related to destination router before, they can update their value if and only if the reply comes from destination node itself. So we can decrease some number of test packets in the network. 5.2.2 If Any Other Router Generate the Test Packet for X If any other router generate the test packet first for the router X then…

36

1. Test packet forwarded with the hope count value start from 0 from the source router and increasing it gradually as the packet is forwarded ahead. 2. If any intermediate router has information regarding non availability of node X (’) as discuss previously in cache it can reply directly with negative answer. 3. Otherwise All the intermediate routers and router X update optimally or make a new entry of information respectively, related to the source router with hope count, so we can avoid the generation of multiple test packet for the destination router i.e. X by others in future. 4. If node X exists, it replies positively for the test packet and reply route of test packet is differ than request route, all the intermediate routers and source router update information optimally related to node X if it exists or makes a new entry related to the X router respectively. If intermediate routers have ’ value related to X before they can also update their value if and only if the positive reply comes from Node X itself. So we can decrease the generation of some number of test packets in the network.

6. Format of Test packet According to the figure 5

1. Source Address: - Field contain the address of source router 2. Destination Address: - Field contain the address of Destination router 3. Sequence Number: - The new number is generated by the source router of the each test packet 4. Type: - Type field contain the type of the packet (Q/A) i.e. Query for any router or Answer of the query by any router 5. Hope count: - It is initializing to 0 and incremented by each intermediate router. 6. Intermediate Source Address: - The address of router through the packet lastly traveled before coming to any router. 7. Intermediate Destination Address: - The address of next router via test packet is to be forwarded. 8. Status: - Status is 1 i.e. “positive” if destination router exists and 0 i.e. “negative” if not exist. The status field is considered only when type field is Answer. 9. Neighbor Delay: - Delay value from last neighbor. 10. Check Sum: - For error handling

7. Advantages

During the single transition of test packet (any node to X or X to any node) only correct information is spread in the network as discuss below… 1. The test packet gives the idea regarding the availability/non availability of the route towards the node X from the other router. 2. It also gives the idea about the route towards other router to the node X with hope value. 3. All the intermediate nodes of the test packet get a refresh idea about their neighbors as follows. If test packet moves from Node X to other router

2009 IEEE International Advance Computing Conference (IACC 2009)

Source Address 4

Dest. Address

4

Seq. No.

2

Type 1 Bit

Hop Count

2

Interm. Source Address

4

Interm. Dest. Address

4

Status

Neighbor Delay

1 Bit

1

Check Sum

4

Figure 5. Format of TEST Packet

1. Information of route and hope value regarding X and 2. Hope value regarding right/left neighbor from where test packet comes is gain by others If test packet moves from any other router to node X 1. Information regarding route and hope value of the other router and 2. Hope value regarding left/right neighbor from where test packet comes is gain by the X and others.

8. Conclusion So in this algorithm information regarding the availability or non-availability of the path through any router is spreading only after verifying the correctness and availability. It spread in faster way and accurately. In some conditions test packet seems as an extra overhead but it stopped the forwarding of the wrong information and many times useful in collecting the information regarding newly available router in the network and other neighbor routers. References: [1] “Computer Networks” Fourth Edition. Pearson Education. Author: Andrew S. Tanenbaum. pages 357 to 360 [2] C. Hedrick. Routing Information Protocol. RFC1058, June 1988. [3] “Data Communications and Networking” Fourth Edition. The McGraw-Hill Companies Author: Behrouz A Forouzan. pages 659 to 665 [4] Gursharan S. Sidhu, Richard F. Andrews, and Alan B. Oppenheimer. Inside AppleTalk. AddisonWesley, Reading, Massachusetts, 1990. [5] International Standards Organization. Intermediate system to intermediate system intra-domain routing exchange protocol for use in conjunction with the protocol for providing the connectionlessmode network service (ISO 8473). ISO DP 10589, February 1990. [6] John M. McQuillan, Ira Richer, and Eric C. Rosen. The new routing algorithm for the ARPANET. IEEE Transactions on Communications, COM-28(5):711–719, May 1980. [7] John M. McQuillan and David C.Walden. The ARPA network design decisions. Computer Networks, 1(5):243–289, August 1977. [8] J. Moy. OSPF version 2. Internet Request For Comments RFC 1247, July 1991 [9] Paul Turner. NetWare communications processes. NetWare Application Notes, Novell Research, pages 25–81, September 1990. [10] Xerox Corporation. Internet transport protocols. Xerox System Integration Standard 028112, December 1981.

2009 IEEE International Advance Computing Conference (IACC 2009)

37