Revisiting On Demand Routing On Demand Routing schemes are reactive – a route is found when needed. This precludes the periodic exchange of routing tables or link-state updates. However, the disadvantages are that a latency is incurred before a destination is found and second, the route that is actually computed might not be optimal.

The Dynamic Source Routing Algorithm (DSR) Invented by Dave Johnson (Currently at Rice University) et al. as a part of the Monarch project at CMU. As the name suggests it is source routing i.e., the source specifies the entire route in the packet header. Avoids the need for “up-to-date” routing information in the intermediate nodes through which the packets are forwarded. Guarantees loop free routing. Consists of two basic mechanisms o Route Discovery. o Route Maintenance.

Promiscuous Mode of Receiving A node can enable promiscuous receive mode – enable the underlying hardware to pick up any packet – not just the ones that are destined for that node. The underlying filtering of packets is disabled. This enables nodes to eavesdrop on route discovery packets and thereby cache routes. The cached routes may speed up route discovery during later searches. However may increase software overhead (processing) and consumed power.

DSR has two mechanisms:  Route Discovery: A node S wishing to send a packet to a destination node D obtains a source route to D. o Note that A attempts to do this only when it needs to send something to D.  Route Maintenance: The mechanism that allows S to detect, while using a source route to D, that the network topology has changed such that the route is no longer valid. o At this time, Node S might use any other route that it happens to know or invoke Route Discovery to find a new route. o This is used only when S is sending packets to D.

This method is entirely on-demand. No routing updates; also no updates when changes that don’t interfere with current route occur. When topology is static, very infrequent updates required. Scales in accordance to number of routes in use at a given time.

Route Discovery in DSR When a node A wants to route packets to a destination E, it first searches its Route Cache to see if any route is available. If not, it initiates a discovery process. ABCD E A transmits a ROUTE REQUEST message as a single “local broadcast” packet. All nodes within wireless range receive this packet.

ABCD E ROUTE REQUEST packet includes initiator ID and request ID. Route record which includes intermediate nodes is embedded into the packet. When the target of the route discovery receives this, it responds with a ROUTE REPLY message. o Includes a copy of the route record alluded to above. The initiator caches this route and uses it for routing subsequent packets.

If an intermediate node receives a route request and notices that its address is already listed in the route record, it discards the request. Notice that this method supports unidirectional links. How ? Upon receiving the route request, E will first look in its cache to see if there is a route to A. If no route is found, it might perform its own Route Discovery. Notice – in order to avoid infinite recursion of route discoveries, E will piggyback the ROUTE REPLY to its own ROUTE REQUEST.

Sending Node maintains a copy of the ROUTE REQUEST in its send buffer. If no timely response is received, retry. Care is necessary – network may be partitioned and destination may be unreachable – leads to too many route discovery packets congesting the network. An exponential back-off scheme used. Limited number of route discoveries for target. Repeating Route Discovery

Route Maintenance in DSR ABCD E Link layer reliability. A is responsible for packet reaching B, B is responsible for packet reaching C and so on. MAC layer ack or passive overhearing –example: B overhears C’s transmission to D. If a packet is re-transmitted a maximum number of times across a link, but no confirmation of receipt is obtained (e.g., across C  D) a ROUTE ERROR message is generated reporting this link is broken and sent to A.

Node A now removes the broken link from its cache. Retransmission of the original packet up to a higher layer protocol – TCP! Check cache for alternate route – if none available initiate route discovery.

Caching Overheard Routing Info. A node forwarding or overhearing any packet may add the routing info. from that packet into its own cache. However, this might cause a problem when there are unidirectional links. Might be possible if unidirectional links are detected thanks to the underlying MAC.

Responding to Queries Using Cached Routes A node might respond to a Route Request by means of what is cached. It concatenates the route on which the ROUTE REQUEST packet is received with the one that is cached to the destination and sends this back in the ROUTE REPLY message. However care has to be taken in order to ensure that one of the nodes on the path on which the ROUTE REQUEST was received is not one of the nodes on the route in the cache.

Preventing Route Reply Storms Notice that by enabling this feature of responding using a cached route may lead to reply storms. Many nodes may have cached routes to the destination and all of them may attempt to respond. Moreover, these routes may be of different lengths. In order to ensure that this does not happen, a node should wait for a random time to see if the source starts transmitting on a path shorter than the one that it has cached.

This delay is specified to be : d = H x (h – 1+ r) where h is the length in number of network hops for the route to be returned by the ROUTE REPLY, r is a random number between 0 and 1 and H is a small constant delay to be introduced per hop. This method essentially randomizes the time at which each node sends its response. Notice  shorter the path, shorter the chosen delay.

Each ROUTE REQUEST may contain a “hop limit” that may be used to limit the number of intermediate nodes that are allowed to forward that copy of the ROUTE REQUEST. Expanding Ring Search – initial hop count limit =1, then increment it to 2 and so on might be used.

Salvaging Packets at Failure A node that notices a link failure might attempt to salvage the packet, by using another route that is cached at that node. In our earlier example, C might attempt to find a route that is cached. ABCD E Packet is marked as salvaged to prevent re-salvaging – might lead to loops – why ? Might concatenate the first part A  C with the rest which is retrieved C  E. ROUTE ERROR Message sent back to A.

Automatic Route Shortening Source Routes may be automatically shortened if one or more of the intermediate hops become unnecessary. This can happen if a later node overhears a packet carrying a source route. WXYZ In this case, the node Y sends a gratuitous ROUTE REPLY message to the original sender of the packet X.

Better handling of failures Source may piggyback information in ROUTE ERROR message to ensure that other nodes that are unaware that a particular link is down, do not report a route using that link. Example, in the previous example, A piggybacks info to the new ROUTE REQUEST that the link from C  D is down. Information with regards to a link failure may also be cached by intermediate nodes to avoid getting stale info from other nodes. There would be a time-out associated with such an entry after which new updates may be accepted.

Advantages: Simplicity Loop Free Scales in accordance with number of connections. New features such as caching etc. help a lot. Disadvantages: Works well for small networks but as network sizes grow, latency increases in discovering a route. Appropriate values for cache times, etc. are difficult to determine. Large header in each packet since the entire route has to be carried (new idea concept of flow number – look! )

References Chapter 5 of book – DSR. D.B.Johnson and D.A.Maltz, “Dynamic Source Routing in Ad hoc Wireless Networks”, In Mobile Computing, Kluwer Academic Publishers, 1996, pp txthttp:// 05.txt

The Ad hoc On-Demand Distance Vector Protocol (AODV) Invented by Charlie Perkins and Elizabeth Royer. The earlier work by Perkins DSDV had the disadvantage that system wide broadcast was initiated for every time that a topology change occurred. This happened for every broken link / formed link. This lead to a large amount of overhead. AODV – builds on DSDV to eliminate such system-wide broadcasts.

In AODV, link formations or deletions do not require system-wide broadcasts. Localize the effects of local movements. Remember in DSDV  local movements have global effects. No overhead on each and every packet carrying data – i.e., overhead only at route establishment.  Compare with DSR  overhead on each and every packet since a packet has to carry the entire source route. AODV also supports multicast.

AODV Properties Routes are discovered only on a need-to basis. Loop free – how ? Use of sequence numbers which are destination based as in DSDV. Assumes bi-directional or symmetric links. AODV uses route tables to store pertinent information.  Contains the destination, next-hop IP address and the destination sequence number.  In addition for each destination the node maintains a list of “precursor” nodes that route through it in order to reach the destination  needed for route maintenance as we shall see later.

Unicast Route Establishment The following steps are followed for Unicast Route Establishment: To find a destination broadcast a RREQ message. Any node with a current route to the destination (including the destination) can send a RREP to source. Route info is maintained by each node in its routing table. Info obtained through RREQ and RREP is kept in the routing table. Sequence numbers are used to eliminate old routes. Routes with old sequence numbers are aged out of the system.

Details of Route Discovery Node first checks to see if it has a route. If not, it creates a RREQ message which includes its own ID, a sequence number, destination address, last known sequence number for that destination, and a broadcast ID. Broadcasts this RREQ message and sets a time-out. When a node receives an RREQ it checks if it has seen the source ID, broadcast ID pair. If yes, discard message. If no, record the information and process the packet. Processing: Set up a “reverse route” entry for the source in its route table and associate a lifetime with that entry. Why ? See if it can respond to the RREQ.

To respond to the RREQ node must have an unexpired entry for the destination (more recent sequence number is also requried) in its route table. If the answer to this is yes, it responds with an RREP message back to the source. If no, it increments hop-count in the RREQ and broadcasts the packet to its neighbors. If RREQ is lost, i.e., no response is received within the time-out, a source node can retry the broadcast for a pre-specified additional number of attempts after which it gives up.

S D An Example of Route Discovery Propagation of RREQ Reverse Route Entry S sends RREQ to 1,2,3. Each establishes a reverse path to S and then forward the RREQ to 4,5, and 6. These nodes establish reverse paths and forward the RREQ and so on. Finally destination D responds along D,5,1,S.

Expanding Ring Search Flooding is expensive. Use small TTL (Time to Live in terms of hop count) first and hope the dest can be found within this TTL. Set a time out and wait. If no response is received, then increase TTL and try again – this RREQ now goes further in terms of number of hops. This method is called Expanding Ring Search. Good if it is more likely that the destination is closer than further off. But if the destination is really far far away, could give a performance worse than flooding.

If the destination is responding to the RREQ, it includes its “new” sequence number in the RREP message, sets hop- count to “0”, and includes a lifetime for which the route is valid. If an intermediate node is responding to the RREQ, it includes the latest sequence number known for the destination in the RREP message, sets hop-count to its hop-count from the destination. In addition, it includes the lifetime for which this route is “still” valid. It then “unicasts” the RREP message towards the source node – using what ? When an intermediate node receives the RREP, it sets up a “forward path” entry to the destination in its routing table.

If a node receives multiple RREP messages, it forwards the first one. Subsequent RREPs are forwarded only if this RREP contains a greater destination sequence number (more up to date message) or a smaller hop count (better route). Source node begins data transmission as soon as it receives the first RREP message and then, if it discovers a better route, it will choose to use that route.

Route Maintenance in AODV A path being used is called an active path. Movements that are not along any active path do not trigger any protocol action. If the source node moves, it can reinitiate route discovery to re-establish connection to the destination. When either the destination or some intermediate node moves, a RERR message is sent to the affected source nodes. This RERR message is initiated by the nodes upstream of the failed link (as in DSR).

The RERR message would list the destinations that are now unreachable. If the node upstream of the break has one or more precursor nodes for the destination, it broadcasts the RERR message to those nodes. This message now propagates towards the source. When the source receives the RERR, if it still needs to reach the destination, it can re-initiate route discovery. Route Entries with an infinite metric are not immediately deleted since they contain useful info – destination is unreachable is useful info !

ABCD E X D’ RERR ABC E X D’ Route Failure due to motion of D triggers a RERR message from C to A. Subsequently, a new Route Discovery by A finds the new route to E via X.

AODV advocates the use of hello packets to keep track of neighbors  periodic broadcast. REFERENCES Chapter 6 of Book. C.E.Perkins, E.M.Royer and S.R.Das, “Ad Hoc On- Demand Distance-Vector (AODV) Routing”, IETF Internet draft (draft-ietf-manet-aodv-06.txt). C.E. Perkins and E.M.Royer, “Ad Hoc On-Demand Distance Vector Routing. In Proceedings of Second Annual IEEE workshop on Mobile Computing Systems and Applications, February 1999.