A New Framework for Loop-Free On-Demand Routing Using Destination Sequence Numbers

Transcription

1 New Framework for Loop-Free On-emand Routing Using estination Sequence Numbers J.J. Garcia-Luna-ceves Hari Rangarajan epartment of omputer ngineering University of alifornia Santa ruz, 95064, U.S.. mail: {jj, bstract generalized framework for loop-free routing based entirely on destination sequence numbers is presented. The framework eliminates the counting-to-infinity problem found in OV and other on-demand routing protocols based on destination sequence numbers. The Sequence- Number Window Routing (SWR) protocol is presented as an example of this framework. SWR is compared via simulations with SR, OV and OLSR using networks of 50 and mobile nodes; the results indicate that SWR is as efficient as OV, without incurring counting to infinity. 1 Introduction Several routing protocols have been proposed to date for wireless networks. Pro-active protocols for MNT like the Optimized Link State Routing (OLSR) [1] maintain routes to every possible destination in the network, and can incur temporary loops. On-demand protocols like the dhoc On-demand istance Vector (OV) [8], ynamic Source Routing (SR) [4], and the Labeled istance Routing (LR) protocol [2] establish routes to only those destinations for which there is traffic, and attempt to ensure loop freedom at every instant to limit control overhead. To avoid routing table loops, on-demand routing protocols use source routing, sequence numbers, or nodal synchronization. SR establishes a loop-free route to a destination by carrying the path traversed in the route request and the reverse path is then used to source route data packets. On a link failure, reliable error updates have to be sent to the source, so that a new route can be searched. Furthermore, we have recently shown [6] how path information can be used to attain loop-free routing, without the need for the header of a This work was funded in part by the askin hair of omputer ngineering at US. data packet to specify a source route. OV maintains loop freedom with the use of perdestination sequence numbers. The sequence number carried in a route request elicits route replies with an equal or higher sequence number. On a link failure, a node increases its sequence number for a destination and invalidates the route. The key limitation with OV s approach to destination sequence numbers is that it prevents responses from nodes that are closer to the destination but have an older sequence number, even if they have a valid loop-free path to the destination. onsequently, the likelihood that the destination itself must resolve a route request is very high, because the destination is the only node that can increase its own sequence number. LR [2] overcomes this limitation of OV by using distances as an additional invariant. Nodes towards the destination are ordered by their shortest known distance. The destination sequence number is used simply as a reset of such distances. lthough LR performs much better than OV [2], it requires the addition of an extra invariant to the destination sequence number. We present a new framework for the development of routing protocols that can attain loop freedom safely based solely on destination sequence numbers, even when nodes are allowed to delete such sequence numbers at any time. Section 2 shows how deleting destination sequence numbers can lead to counting-to-infinity behavior in such protocols as OV and LR. Section 3 describes a new framework for on-demand routing using solely destination-based sequence numbers. The novelty of our framework is that it treats destination sequence numbers as a finite label space, rather than the traditional notion of absolute timestamps. nother contribution in this work is the introduction of sequence number windows as a technique for realizing the progressive ordering of sequence numbers when establishing paths to a destination. This allows more intermediate nodes to resolve route requests, given that nodes closer to the destination have higher sequence numbers than nodes /04/$ I 426

2 farther away. Section 4 introduces the Sequence-number Window Routing (SWR) protocol as an example of the new framework. Nodes in SWR adopt sequence numbers for a destination in a non-decreasing order along each path to the destination within a window of sequence numbers whose range is controlled by the destination. To handle node failures, reboots, and nodes forgetting about destination sequence numbers in a safe manner, SWR forces the destination to reply to a route request relayed or originated by a node that has no route entry for the destination. In such a case, the destination issues a reply incrementing its own sequence number to a value greater than the upper bound of the previous sequence-number window. ach node propagating a valid route reply adopts a sequence number within the new window in a way that sequence numbers are always non-decreasing along any path to the destination. This allows destination sequence numbers within a window to be recycled along paths, before the destination is forced to resolve a route request by incrementing its sequence number again. Section 5 provides an example of how SWR operates. Section 6 analyzes the correctness of SWR. Section 7 compares the performance of SWR against two on-demand protocols (OV, SR) and a proactive link state protocol (OLSR). Section 8 provides our concluding remarks. 2 ounting to Infinity in OV In the rest of this paper, sn denotes the sequence number stored at node for destination, d denotes the distance from node to destination, lc denotes the cost of the link from node to neighbor, andrt denotes the state of the routing-table entry for destination at node (either null (φ), valid or invalid). The OV RF [8] recommends that nodes delete invalid route entries after a finite time equal to the maximum elapsed time after which a node can still send data packets to the next-hop specified in the routing table, called the LT PRIO. However, as we show, the condition is not safe. directed acyclic successor graph is shown in Fig. 1(a) for destination. We assume that all nodes run OV correctly and have data for at some point in time. The dotted node R between node and node X is used to indicate a set of one or more nodes that could be along the path. ll nodes are assumed to have sn 1 as the destination sequence number for in their routing tables. We consider path P = {Y,X,{R},,,} and we trace one of many sequences of events that can cause counting to infinity for destination. ssume that link e1 fails, which results in node being isolated from the connected component consisting of nodes,,,{r},x and Y. Now detects the unreachability of within a finite time through either a link-layer notification or HLLO messages. Node invalidates the route to, increments its sequence number for destination to sn 2 (hence, sn2 >sn1 ), and sends a route error (RRR) to node, which may not be delivered. This sequence of events is represented in Fig. 1(b). fter the above sequence of events, node searches for a new route to with sn 2 as the required sequence number. However, destination is unreachableand none of the other nodes can satisfy the request, because their sequence numbers equal sn 1. In our scenario, node eventually invalidates its route entry for destination, given that node sends RRRs to every time it receives a data packet for the invalid route to. Let t 1 be the time after which node receives no data packets from, node deletes the invalid route for with sn 2 at time t del = t1 + LT PRIO. Node invalidates its route entry for destination at a time t> t 1, and notifies of the unreachability of proceeding in the same fashion as the RRR exchange between and. This results in invalidating its routing entry for. The nodes along path P learn about the unreachability of node as the RRRs are propagated. Let t y be the time when Y invalidates its routing entry for. t any time t <t y, any route search for destination with a sequence number sn >sn 1 cannot be answered by any node in the network. t a time t req >t del, node sends a RRQ with an invalid sequence number for. If at time t rep Y <t y node Y receives the RRQ, then it sends a RRP for with a sequence number sn 1, which can now be used by node to create a routing entry for destination with sn 1. This results in the formation of an undirected cycle, which is shown in Fig. 1(c). Similarly, once the LT PRIO elapses, node deletes its invalid entry for after attempting to find a route with sequence number sn 2. RRQ for by node with an invalid sequence number can then be answered by node with sn 1. This effect cascades to other nodes along the path, and counting to infinity occurs in this connected component. The route lifetimes at each node can be kept alive by the constant flow of data packets for that either originate locally at the node or are forwarded along the undirected cycle. The above is an example of a basic problem that can be summarized as follows: node along a path P to destination should never delete its invalid route table entry for before guaranteeing that all its upstream nodes along path P have invalidated their active route entries for. Of course, temporary looping can occur in OV and any other protocol using the same destination-based sequence numbering approach, given that counting-to-infinity can happen. In practice, counting to infinity in OV can be avoided by waiting long enough before deleting invalid routes or rejoining normal operation after reboots. However, as the network size and its diameter change, what 427

3 sn(1) sn(1) sn(1) sn(1) sn(1) R X Y sn(1) e1 sn(1) (a) sn(1) sn(1) sn(1) sn(1) sn(1) R X Y RRR e1 sn(2,invalid) sn(1) sn( 1,invalid) (b) sn(2,invalid) sn(1) sn(1) sn(1) sn(1) R X Y sn( 1,invalid) sn(1,valid) e1 RRQ (sn: 1) RRP(sn: 1) sn(1) (c) Figure 1. OV ount-to-infinity example long enough means must also change. Given that internodal coordination spanning multiple hops incurs too much overhead and that very long waiting periods are undesirable for protocol efficiency, a more elegant solution to the counting-to-infinity problem is desirable, which we present in the next section. 3 Framework for Loop-Free On-demand Routing Using Sequence Numbers In the past, loop-free routing approaches based on destination sequence numbers have relied on the premise that a sequence number serves the purpose of time-stamping an update, and thus accepting the update for a destination with the latest sequence number maintains loop-freedom. dopting this approach, the following sufficient condition for loop-free routing using destination sequence numbers has been used in OV and other protocols in the past [8], [7]. Sequence Number ondition (SN): Node can make node its successor for destination after processing an input event if (sn <sn ) or (sn = sn d >d ). If no neighbor satisfies one of the above conditions, then node must keep its current successor if it has any. The proof that SN can be used to enforce loop freedom is presented in [7] under the implicit assumption that nodes never forget the last sequence numbers they learn for a given destination. Rather than considering sequence numbers as timestamps, we model the sequence numbers of a destination as a finite label space from [0,...,2 n 1 ] in which n is the number of bits allocated for storing the sequence number. y doing so, the problem of maintaining loop-freedom using sequence numbers reduces to a case of assigning destination sequence numbers as labels for a destination at each node along the successor path. Following this approach, we augment SN with the following new condition that allows nodes to label themselves with a sequence number for a destination without creating loops. Sequence Label ondition (SL): Let PS denote the set of neighbors of that use it as next hop to. When makes its successor for destination after processing an input event that satisfies sn <sn, node can assign (label) itself a destination sequence number that satisfies MX(sn j ) < sn sn, j PS. Theorem 1 Using SN for choosing successors and SL for updating sequence numbers at nodes for destination cannot create loops if no node ever forgets the largest sequence number it learns for a destination. Proof: The proof follows from the fact that SN is sufficient to enforce loop freedom by showing that sn ni sn ni 1 for i {2,k} along any successor path P = {n k,...,n 1 }. For path P to exist at a given time t, itmustbetrue that all nodes in P have a successor. ccording to SN, node n i can make n i 1 as its successor for destination if sn ni <snni 1 or sn ni = snni 1 d ni <dni 1. onsider first the case in which sn ni <snni 1. If node n i+1 uses ni as its successor to destination when n i makes n i 1 its successor for the same destination, then it follows from SN that sn ni+1 sn ni. Hence,node n i can set sn ni+1 < sn ni snni 1 according to SL, which does not violate the ordering of sequence numbers along path P. In the second case, if node n i sets sn ni the sequence-number ordering is not affected either. s stated, SL allows nodes to assign themselves a destination sequence number smaller than the latest destination sequence number received in an update. However, this requires synchronization with neighbor nodes to determine the current set of predecessors (neighbors using the node as sucessor) and their destination sequence numbers. Unfortunately, this synchronization incurs additional signaling. To avoid any synchronization, a node can update itself to the latest destination sequence number reported in a control message, which is the approach adopted in OV. However, this results in the destination node being the only one that can resolve most RRQs. For example, Fig. 2 (a) shows a five-node network topology. Node has an invalid route = snni 1, to with a sequence number sn =10. estination has a sequence number sn =. Node trying to establish a route to sends a route request (RRQ) that is answered by the destination, and the route reply (RRP) carries sn rep =. Nodes,, and along s successor path update their destination sequence numbers for to 428

4 RRQ 10 RRP (a) OV - Sequence numbers as absolute time stamps Z (b) OV - On Route Failure Figure 2. Sequence number assignment in OV RRQ RRP (a) Window of Sequence numbers Z 10< sn < (b) Fast recovery on route failure Figure 3. Sequence number Windows. Now, if at a later time if node crashes and an alternate path through node Z exists as shown in Fig. 2 (b). Node attempts to re-establish its route to. Node s RRQ carries a increased sequence number sn req =, which prevents any of the nodes along the path Z from replying, even though nodes and have a loop-free active route. ventually, the request reaches the destination, which now responds with a increased sequence number sn = and the successor path Z from to is established. y allowing a progressive orderingofthe sequencenumbers, it is possible to expedite route recovery and reduce control overhead. We introduce the Sequence Number Window (SNW) as a tool to achieve this type of ordering. sequence number window along any path to a destination is formed by a set of nodes {n k,...,n 1 } such that sn n k < sn n1 and (snni snn k snni <snn1 ), i {k 1, 2}. Fig. 3 (a) illustrates a sequence number window between node and ranging from [10,..., ] assuming a initial configuration where nodes,, and have no route for. Nodes label themselves with sequence numbers less than the latest known sequence number, which amounts to distributing the sequence numbers inside the window while maintaining the ordering. Fig. 3 (b) illustrates the benefits of distributing sequence numbers inside a window compared to OV s approach. s in the previous example, node fails, and node obtains a response from node when it attempts to obtain a new path to, because s increased sequence number in the request sn req =11can be satisfied by node. With on-demand routing protocols that resort to expanding ring searches, this scheme enables more nodes with active routes to to respond. In large MNTs, it is possible for nodes to forget previously known sequence numbers for a destination (e.g., after rebooting or by deleting old invalid routing-table entries). From Theorem 1, it follows that looping can occur only if nodes adopt new successors without knowing a prior sequence number for the destination. To ensure the safe use of an SNW or destination-based sequence numbers, our framework requires that any RRQ relayed or originated by a node without a valid sequence number for the destination be answered by the destination. The example shown in Fig. 3 with the added constraint for safety remains unchanged if node Z has a destination sequence number for lying in the range (10 sn < 60); however, if Z has no state for, then the request must be answered only by the destination. ased on the above approach to destination sequence numbering, the following rules for loop-free on-demand routing can be defined based on the facts that (a) each node stores a sequence number for every active destination, and (b) nodes invalidating their route to a destination retain the sequence number. We assume a generic control message framework consisting of route request (RRQ), route reply (RRP), and route error (RRR) messages similar to that of other on-demand routing protocols. The routing-table entry at node for destination includes the current sequence number (sn ), the current route cost (d ), and the successor (s ). If no routing entry exists at node for destination, then the current sequence number is considered unknown (i.e., sn = 1). The superscripts req and rep are used for variables included in a RRQ and RRP, respectively. The parameter reset denotes, if the RRQ requires the destination to reply or if the RRP was originated by the destination. S: (ccept Sequence number ondition). When node receives a RRP from node for destination, then node sets s if (sn < sn rep ) or (sn = sn rep ) (d > d rep should accept a RRP only if reset rep by the destination). ). If sn = 1, then node =1(i.e., generated SS: (Start Sequence number ondition). Node I can issue a RRP responding to a RRQ for destination if I has an activerouteto, sn I >sn req,andresetreq =0. If node I =, then it must set reset rep =1,ifresetreq =1. MS: (Maximum Sequence number ondition). If node relays a RRP for destination, itsetssn rep sn. 429

5 The relayed RRP must not change the value of reset rep. Node relays a RRQ for destination only if has not previously processed this RRQ and sets msn req = max{msn req,sn }. Ifsn = 1 or reset req =1; then, in the relayed request, it sets reset req =1. US: (Update Sequence number ondition). If node must change s,thenitsetsd and node sends a RRQ carrying sn. RS: (Reset Sequence number ondition). If node has no route entry for (i.e., sn = 1), then a RRQ originated must have reset req =1. RRQ travels a loop-free path and is relayed (MS) with the maximum of the destination sequence number of the nodes. The RRQ can be answered by a node that has a higher sequence number than the maximum sequence number carried in the RRQ (SS) or by the destination if the RRQ was originated or relayed by a node that had no sequence number for (RS). fter a route failure, a node attempts to reestablish a new path (US). US allows the destination to be the only node that can modify its sequence number. Nodes invalidating their routes on receiving a RRR are not required to update to the destination sequence number in the RRR. RS is a safety condition that handles nodes that cannot be ordered on the basis of sequence numbers; and MS as a special case handles nodes relaying RRQs with no sequence number state. With the above safety conditions, route entries storing destination sequence numbers can be purged safely, without causing any loops. US and SS differ from OV, which forces nodes invalidating their routes to increase the destination sequence number, and nodes reply to a route request only if they have a higher sequence number. 4 SWR SWR augments the rules of our basic framework with a condition for detecting the boundary of windows. W: (Window oundary ondition). If node receives a RRQ for destination and sn >sn req then node sets the window count wc 1, otherwise sets wc wc +1. Node caches wc for this RRQ and relays a RRQ with the cached wc. W allows nodes relaying a RRQ to determine distributedly the start and end of sequence number windows, and the number of hops spanned by the window. window count of one indicates the beginning of a new window and signals the end of a previous sequence number window (except at the source, where the window can only begin). The window count indicates the number of nodes over which the current sequence number window is being built. 4.1 Information Stored and xchanged The routing table at node maintains the following parameters for every destination : the successor (s ), sequence number (sn ), the distance (hop count) to the destination (d ), lifetime of route, and the state of route entry (rt ). If no entry for destination exists, then it is considered equivalent to an unknown sequence number (sn = 1). RRQ consists of the tuple {dst, src, rreqid, msn dst,wc dst,flags}. Thefieldsrc denotes the identifier of the source that is seeking a path to the destination (dst), rreqid along with the source (src) represents a unique identifier for a RRQ generated for a destination, msn dst is the maximum of the destination sequence numbers along the path traversed by this RRQ, flagscarries control bits, and wc dst is the window count used to infer about the current sequence number window. One control bit used is the reset bit that is set when the RRQ must be answered only by the destination. RRP consists of the tuple {dst, sn dst, src, rreqid, d dst, ttl, flags}. The field ttl states the lifetime of the route at the node relaying the RRP, rreqid is carried in the RRP to forward it along the reverse path to the source using information cached for the RRQ (src, rreqid), sn dst is the destination sequence number stored at the relaying hop, d dst is the distance to the destination at the relaying hop, and flags contains the reset bit, which may be set if the destination originates the RRP. The RRR is the tuple {orig, unreachdests}, where orig denotes the node originating the route errors, and unreachdests is the list of destinations that are not reachable at orig. node relaying a RRQ caches the tuple {msn dst, wc dst,revhop,reset dst },whererevhop is the identifier for the node that sent the request, and is used to relay a RRP received for this (src, rreqid) pair along the reverse path. ached entries are maintained for a period of time that is long enough, so that all RRPs for the RRQ (src, rreqid) will be received with high probability. 4.2 Initiating a RRQ Node is said to be active in a route computation for destination (i.e., the RRQ) when it initiates a RRQ for the destination, and the RRQ is uniquely identified by the pair (, I ). node relaying a RRQ (, I )originated by another node is said to be engaged in the RRQ. node that is not active or engaged in a route computation for destination is said to be passive for that destination. t any given time, a node can be the origin of at most one RRQ for the same destination. The RRQ (, I ) terminates when either node attains a feasible sequence 430

6 number for destination or the timer for its RRQ expires. If node is active or engaged for destination and receives data packets for the destination, it buffers those data packets. If node is passive for destination and requires a route for destination, itsetsi incremented request counter, reqid I, msn sn, wc 1, and RRQ timer (2.ttl.latency) (where ttl is the time-to-live of the broadcast flood and latency is the estimated per-hop latency of the network). If sn = 1, thenreset =1. Node then issues RRQ {,, reqid = I,msn, wc, reset}. If node receives no RRP after the expiry of its timer for RRQ (, I ) for destination, it sends a new RRQ with an increased ttl. If node does not receive a RRP for destination after a number of attempts, a failure is reported to the upper layer. The number of hops that a RRQ can traverse is controlled externally from the RRQ by means of the TTL field of the IP packet in which a RRQ is encapsulated, or by other means. 4.3 Relaying RRQs When node receives a RRQ {,, rreqid = I, msn req, wcreq, reset} from node I, itfirstdetermines its own status for (, I ). If is active (i.e., = ) or engaged (i.e., has cached the RRQ (, I )) in the computation (, I ), it silently drops the RRQ. Otherwise, node is passive. In this case, if SS is satisfied (i.e., sn > msnreq and reset = 0), then node issues a RRP (Section 4.4). lse, if SS is not satisfied, node becomes engaged and relays a new RRQ req with the following parameter values: msn req max{sn, msnreq },ifsn >snreq then 1 wcreq else wc req wc req +1,ifsn = 1 then resetreq 1 else reset req resetreq. node may be engaged in multiple RRQs for the same destination, but relays a RRQ from the same origin only once by caching the tuple {msn req, I, reset req,wcreq } for a given RRQ (, I ) it forwards. 4.4 Initiating and Processing RRPs When node I processes a RRQ {,, rreqid = I, msn req,wcreq, reset} and SS is satisfied (i.e., sni > msn req, rt = valid, and reset =0), it issues a RRP {,sn rep,,i,d rep,ttl,reset} with snrep sni and d rep di. t the destination (I = ), if resetreq =1, then sets sn sn +1; otherwise, if sn snrep then sets, sn snreq + dstseqinc. Ifresetreq =1, then issues RRP with reset =1. Section 4.6 addresses how the value for dstseqinc is chosen. If node receives a RRP {, src =, rreqid = I, sn rep, ttl, drep,reset}, itdeterminesifitisthe source src of the RRQ that caused the RRP. If so, it proceeds as Section 4.5 describes. If S, thenafter updating its routing table as per Section 4.5, the RRP is relayed along the reverse hop revhop, which is retrieved from the cache entry (, I ) ; the RRP is relayed with sn rep sni ; drep d. 4.5 dding, Updating, and Maintaining Routes Node updates its routing information when it receives a RRP {,,I,sn rep, ttl, drep,reset} from neighbor. Ifsn = 1 and resetrep =0,orresetrep (,I =1 ) and reset rep =0, or if SN is not satisfied, then the RRP is dropped silently. Node calculates sn adj,retrievingthe values of msn rep (,I ) and wcrep (,I ) from the cache for the relayed RRQ (, I ). sn adj = snrep snrep msnrep (,I ) wc rep (,I ) +1 (1) Node updates its routing table entry for according to its current state(rt ) as follows: ase (a): If rt = φ resetrep (,I ) =1,then sn sn rep (2) For cases (b) and (c), reset rep (,I ) must be 0. ase (b): if rt sn = invalid snrep >sn, snadj sn +1 ase (c): if rt = valid, sn sn adj sn if msn rep (,I ) sn otherwise if msn rep (,I ) sn if msn rep (,I ) <sn d >d rep + lc sn rep sn rep sn >sn If the route reply was used to update the routing table sequence number entry, then node sets s ; d d rep + lc. SWR handles link failures, and route lifetimes in the same way as OV. However, a route table entry for a destination can be purged at any time. RRRs do not carry the destination sequence number in SWR. 4.6 estination Sequence Numbers To handle reboots and node failures, SWR uses a 64- bit destination sequence number based on a real-time clock which ensures that RRPs issued by the destination have (3) (4) 431

7 a non-decreasing sequence number. dditionally, after a reboot, a node will lose its cached state and the lastused flooding identifier for the RRQs. Hence, the flooding identifier (rreqid) carried in the RRQs must also be based on a real-time clock, because old flooding identifiers will not be relayed by nodes which previously processed a (src, rreqid). Therreqid can be truncated to a 32-bit integer, provided it will not wrap-around during for the time an old (src, rreqid) might still be present in the network. RRQ that cannot be answered by any intermediate node will eventually reach the destination for a sequence number reset. OV resets the destination sequence number with a higher sequence number than the one carried in the RRQ. To avoid the destination being the only node that can answer, SWR resets the destination sequence number by a parameter dstseqinc. linear-increment scheme with a pre-configured dstseqinc parameter should suffice for most network configurations. However, performance can be improved by using adaptive increment schemes which derive dstseqinc as a function of the prevailing network conditions (i.e., number of RRQs received within a time interval). 4.7 Reverse Routes RRQ generated by a source can be considered as a RRP in the reverse direction. However, SNWs cannot be used for setting up routes in the reverse direction, because of the lack of window boundaries. Hence, SWR uses an optimization to use SNWs. If node receives a RRQ from and has no valid route towards the source S of the RRQ, node performs the following steps: creates a new route entry for the source S,setss S, sets the lifetime of the route equal to the reverse route lifetime, and flags the route entry with a special bit indicating that it is an invalid reverse route. When node has a flagged reverse route to S needs to send data packets to that destination, it sends a unicast RRQ to s S. This RRQ is forwarded on a hop-by-hop basis along a path of nodes with invalid reverse routes to S, and a RRP can be generated by either a node satisfying SS or the destination. unicast RRQ follows the same rules as a broadcast RRQ. 5 SWR xample Fig.4 shows a directed acyclic successor graph (SG) for destination for a six-node network at time t 1. Initially at time t 0, the routes are not established, the destination has a un-initialized sequence number (0); and other nodes in the network do not possess any knowledge about. Node initiates a route request req for destination with parameters (,,rreqid = I,sn = 1,wc =1,reset =1). Node upon receiving the route request (, I ), caches e1 76 () Time t 1 51 e () Time t e1 76 () Time t 3 Figure 4. SWR operation - xample the tuple (msn req = 1,wc =2,revHop =, reset = 1), and relays a new RRQ req with (,,rreqid,sn req = 1,wc = 2,reset = 1). Similarly, node relays the RRQ. Note that there is no significance for wc, whena reset is requested. route reply rep is generated by node upon receipt of the RRQ by. Node increments its destination sequence number by just one, because it is performing a reset. The RRP (,,I,sn rep =1,reset =1) is accepted by node as it satisfies S. y q. 2, node sets s ; sn 1; and relays the RRP along the cached reverse hop. Similarly, since the RRP carries reset =1, nodes and have to update their destination sequence numbers to one. Now, all nodes possess knowledge of s sequence number. The above additional steps are necessary to ensure the correctness of the protocol. To illustrate the use of SNWs, assume that the nodes expire their route lifetime; they have marked their route entry for as invalid. Now, assume node starts another RRQ (,, I,sn = 1,wc = 1, reset = 0). Nodes and relay the RRQ after increasing the wc to two and three, respectively. Node, on receiving the RRQ, now increments its sequence number to, using a linear increment (say dstseqinc = ). Node accepts the RRP because it satisfies S, adds a new routing table entry for destination, setss, and calculates a sequence number of 76 for destination using q. 3 (i.e., ( 1) 3+1 ). Similary, node and node update their routing tables to setup an entry for destination with sequence numbers, 51 and 26, respectively, using q.3. t time t 1, there is a progressive ordering of destination sequence numbers from node to destination. F 70 F F

8 fter a similar sequence of events, assume that nodes and F have set their destination sequence number for to 34 and 70, respectively, at some time t<t 1. t time t 2 > t 1, link e 2 fails. Node detects a link failure and sends the RRQ (,,I,msn req =34,wc =1) which evokes a response from which satisfies SS. Node activates routing entry for after processing the reply and updating sn 35 as per q. 3. Fig. 4(b) shows the state of the network. Let node detect the failure of link e 1 and sends the RRQ (,,I,msn req =51,wc =1) at a later time t 3 >t 2. Node does not satisfy SS and relays a new RRQ (,,I,msn req =51,wc =2). Note that there is a window between and spanning node. Node responds to the RRQ with a RRP carrying sn rep =76, because SS is satisfied. Node processes the RRP and sets sn 68 as per q. 4, which amounts to redistributing sequence numbers in the window between and. Node re-establishes a route to after updating its route entry to set sn 52 and s. In this case, we assume that node is performing a localized route repair, without which node would have received a RRR from and initiated a route search for. Fig. 4(c) shows the directed acyclic successor graph at time t 3. This example illustrates that the progressive ordering of sequence numbers allows SWR to recover quickly from route failures. OV operating in this scenario would have required a sequence number reset from the destination. 6. nalysis For SWR to be loop-free, it must be true that any successor path to a destination must have monotonically nondecreasing sequence numbers, even when nodes forget their sequence numbers for a destination, and loop-freedom follows directly from the SN proof of loop-freedom [7]. Theorem 2 If a node updates its routing table as per Section 4.5, then the sequence number towards a destination at a node is a non-decreasing function of time, even if nodes lose their sequence-number state. Proof: The route entry for destination at node can be in one of the three states when it must update its routingtable entry after receiving a RRP rep: (i) no information, (ii) invalid, or (iii) valid. In case (i), the route entry does not exist (sn = 1), and the RRP will be accepted only if reset =1. Since the destination sequence number is incremented by atleast 1whenaRRQwithreset =1is answered, the RRP must carry a sequence number which must be higher than any previously known to node n i ; and it updates itself to sn rep. For the other cases, we first derive the range of sn adj calculated from q.1 when msn rep (src,rreqid) sn, assuming >sn.saysnrep (src,rreqid) = sn + α and snrep = +β,whereα, β are integers such that α 0 and β>0. sn rep sn Then from q.1, we have sn adj = sn +β β α λ,where λ = wc rep (src,rreqid) +1 > 1,andβ>α. Therefore, we have the inequality sn msnrep (src,rreqid) <snadj snrep (5) In case (ii), from q. 3, either sn is set to snadj or incremented by one (sn +1), and the sequence number only increases in both cases. In case (iii), from q. 4, the sequence number (sn ) increases to the new adjusted value (sn adj ), or remains the same when the distance gets shorter. If on the other hand, reset =1 in the cache, and the node falls under any of the above three cases: The update follows q.2 which ensures that the node updates to a higher sequence number, using the same argument as in case (i). Hence the sequence number for the destination is nondecreasing when the node accepts and updates its routing table as per Section 4.5. Theorem 3 t any instant, SWR is loop-free. Proof: The proof for loop-freedom of SWR follows directly from Theorem 1 and 2, because S is equivalent to SN, provided that we can show that SL is satisfied when routetable entries are updated. onsider a node n i having a route to destination. The predecessor of n i, denoted by n i 1, can make n i its next hop towards only if SN is satisfied. Now, node n i 1 cannot increase its sequence number without receiving a new update from n i. From Theorem 2, node n i can only increase or maintain the same sequence number (path is of shorter cost which is not a SL case) when it switches to a new successor, which means that SL is satisfied, i.e., sn ni >snni 1, on a sequence number update. t a later time, node n i might relay another RRP to a new predecessor m i, but following the same argument it can only increase its sequence number before relaying the RRP, which ensures that sn ni >snni 1, or if node n i 1 increases its sequence number, without receiving any new update from node n i, it can only do so because it switched to another successor. To prove the correct termination of SWR, we first show that any source is able to establish a route to a destination within a finite time if there is a physical path between the source and the destination, assuming that the network is stable and error-free after an arbitrary sequence of topology changes. The proof is similar to the convergence proof of LR considering only sequence numbers [2](Theorem 5, pp.60). 433

9 We give only an outline of the proof: Let source issue a RRQ req which traverses a path, P = {n 1,n 2,..., n i }, before reaching the destination or a node that satisfies SS. The RRP issued will have a sequence number greater than, which will satisfy S along the entire path and at. If or a node along path P requested a reset, then therrp will carryreset =1, which will satisfy any such node. ecause the RRP is now relayed along the reverse path, the RRP must satisfy S, given that the relaying nodes after updating their routing tables follow MS, and the RRP at the relaying node has sn rep msn req >msnreq (,I ) acording to q. 5. When the RRP traverses the reverse path, if it does not satisfy S at a node, then the node learned a route with a higher sequence number and the new RRP generated will still satisfy S at the nodes along the reverse path to the source. In any case, the RRP forwarded along the reverse path will satisfy all the nodes and hence the source will be able to establish a successor path in finite time due to finite time for message exchanges. Next, we show that all nodes invalidate their routing table entries for the destination in the presence of link failures and node reboots/state loss that disconnect some nodes from a destination. Following the default RRR rules, the RRRs should eventually propagate upstream along the acyclic successor graph in finite time. uring this time, we argue that nodes cannot keep learning newer routes from upstream nodes, which can lead to count-to-infinity behavior. When nodes reboot or lose state, only RRPs with reset =1can be used to update their route entries, which is not possible in a partitioned network and hence these nodes can never learn a new route. On link failures or otherwise, nodes with valid sequence number entries can learn routes from a node that has a higher sequence number than the one in the request. However, because only the destination can reset (increase) its destination sequence number, within a finite time all nodes should have the highest destination sequence number entry and future route searches cannot be answered by any node in this partition. ssuming a finite probability that RRR messages will eventually be delivered, all nodes will invalidate their route entries for the destination. 7 Performance We present results for SWR over varying loads and mobility. The protocols used for comparison are two on demand protocols SR and OV, which reflect the state of the art in on-demand routing, and OLSR which is a proactive link state protocol. Simulations are run in Qualnet The parameters are set as in [9]. Simulations are performed on two scenarios, (i) a 50- node network with terrain dimensions of 1500m x 300m, and (ii) a -node network with terrain dimensions of 2200m x 600m. Traffic loads are R sources with a data packet size of 512 bytes. Load is varied by using 10 flows (at 4 packets per second) and 30 flows (at 4 packets per second). The M layer used is with a transmission range of 275m and throughput 2 Mbps. The simulation is run for 900 seconds. Node velocity is set between 1 m/s and 20 m/s. Flows have a mean length of seconds, distributed exponentially. ach combination (number of nodes, traffic flows, scenario, routing protocol and pause time) is repeated for nine trials using different random seeds. We present four metrics. elivery ratio is the ratio of the packets delivered per client/server R flow. Latency is the end to end delay measured for the data packets reaching the server from the client. Network load is the total number of control packets (RRQ, RRP, RRR, Hello, T etc) divided by the received data packets. ata hops is the number of hops traversed by each data packet (including initiating and forwarding) divided by the total received packets in the network. This metric takes into account packets dropped due to forwarding along incorrect paths. larger value for the data-hops metric indicates that more data packets traverse more hops without reaching the destination necessarily. Tables 1, and 2 summarize the results of the different metrics by averaging over all pause times for the 50-node and -node networks. The columns show the mean value and 95% confidence interval. Fig. 5 shows the delivery ratio for a -node network with 30-flows. onfidence intervals(95%) are shown with vertical bars in the graphs. SWR has a very consistent performance across all scenarios and outperforms other protocols in most cases. In the highest load scenario ( nodes, 30-flows), SWR has the highest packet delivery ( ± 0.04), and the lowest latency (0.9211±0.17). The exception is at high flows, low mobility scenarios where OLSR seems to do better. The latency of SWR is more than that of OV in the 10-flow scenarios; but that is due to the overhead incurred by the additional mechanisms for correctness of the protocol. In the -node, 30-flow scenarios, we believe that OV suffers from convergence problems as indicated by the poor confidence intervals obtained for the control overhead(18.29±13.06). The performance of SR suffers from stale caches, as indicated by its low packet delivery and high latency; and using cached source routes avoids route requests floods, characterized by the low control overheads. OLSR performs well in the low mobility scenarios; but, on the whole, is affected by poor performance in the high-mobility scenarios. The data hops metric provides a measure of the accuracy of the routes used for forwarding. SWR, OV and OLSR have statistically equivalent data hops across all scenarios, except in the scenario with 30 flows and nodes where 434

10 Table 1. Performance average over all pause times for 50 nodes network for 10-flows and 30-flows Flows Protocol elivery Ratio Latency (sec) Net Load ata Hops SWR 0.995± ± ± ± ± ± ± ±0.283 OV 0.994± ± ± ± ± ± ± ±0.324 SR 0.940± ± ± ± ± ± ± ±0.308 OLSR 0.887± ± ± ± ± ± ± ±0.161 Table 2. Performance average over all pause times for nodes network for 10-flows and 30-flows Flows Protocol elivery Ratio Latency (sec) Net Load ata Hops SWR 0.989± ± ± ± ± ± ± ±0.353 OV 0.988± ± ± ± ± ± ± ±0.434 SR 0.876± ± ± ± ± ± ± ±0.499 OLSR 0.821± ± ± ± ± ± ± ±0.277 SR incurs max data hops. The data hops metric reflects the number of hops traversed by each data packet whether or not it is delivered. SWR s data hops in correlation with the packet delivery ratio shows the high accuracy of the active routes. 0.9 results show that SWR provides comparable performance than that of OV while eliminating counting-to-infinity and looping problems when nodes can forget the sequence numbers to destinations. References Packet elivery ratio OV SWR SR OLSR Pause Time (Secs) Figure 5. elivery -nodes, 30-flow, 120pps 8 onclusion We extended the loop-free conditions for destination sequence number based protocols to allow nodes to treat sequence numbers as labels instead of absolute timestamps. We introduced a generic framework for on-demand protocols based on destination sequence number based protocols that is safe even when nodes are allowed to forget previously learned sequence numbers. We presented the Sequence Window Routing (SWR) protocol which adds sequence number windows to the framework and progressively labels the sequence numbers towards a destination. This novel scheme maintains loop-free routes while at the same time reducing control overhead and latency for setting up routes improving overall packet delivery. Simulation [1] T. lausen and P. Jacquet, Optimized Link State Routing Protocol, Request for omments 3626, October [2] J. J. Garcia-Luna-ceves, M. Mosko and. Perkins, New pproach to On-emand Loop-Free Routing in d Hoc Networks, Proc. M PO 2003, pp , oston, Massachusetts, July 13 16, [3] J. J. Garcia-Luna-ceves and M. Spohn, Source-Tree Routing in Wireless Networks, Proc. I INP 99, pp , Toronto, anada, October 31 November 3, [4]. Johnson et al, The ynamic Source Routing Protocol for Mobile d Hoc Networks (SR), ITF Internet draft, draft-ietf-manet-dsr-09.txt, pril [5] R. Ogier et al., Topology issemination ased on Reverse- Path Forwarding (TRPF), Request for omments 3684, February [6] H. Rangarajan and J.J. Garcia-Luna-ceves, Using Labeled Paths for Loop-free On-emand Routing in d Hoc Networks, Proc. M MobiHoc 2004, Tokyo, Japan, May 24 26, [7]. Perkins and P. hagwat, Highly ynamic estination- Sequenced istance-vector Routing (SV) for Mobile omputers, Proc. M SIGOMM 94, [8]. Perkins et al., d hoc On-emand istance Vector (OV) Routing, Request for omments 3561, July [9]. Perkins et al. Performance omparison of Two Ondemand Routing Protocols for d Hoc Networks, I Personal ommunications, 8(1):16 28, Feb