On Demand Multpath Link State routing

In this chapter, we present a cross layer solution where the MAC protocol can perform power and interference control by querying a number of possible candidate terminals. Each candidate is a possible next hop forwarder toward the destination, as determined by the upper layer routing protocol.

For this scheme to work successfully we need a routing protocol that can setup multiple non-disjoint paths to destinations. The routing protocol should also be able to provide the MAC layer with information about possible candidates.

We are using a hybrid on demand scheme that consists of two parts: the route setup part and the route calculation part. The route calculation part consists of cal-culating the cost toward different destinations using a link state database. The link state database can be created either by listening on other nearby data transmissions and overhearing or forwarding routing messages. It could also be created in a more proactive way as is in OLSR [10] or Fisheye State Routing [11].

While multiple non-disjoint routes can be calculated using the link state database, this calculation can not ensure that loops will not exist when packets are transmit-ted and forwarded by intermediate nodes. When a packet arrives at an intermediate

6.3. On Demand Multpath Link State routing 105

node, where multiple next hop candidates exist, the forwarding node can not be sure that this packet has not already passed through one of the candidate nodes.

One way to avoid this is by using greedy forwarding, where a packet is only forwarded to a candidate whose distance to the destination is less than the mini-mum distance from the current node. A problem with this approach when diversity forwarding is applied, is that the minimum distance on the short time scale is not the same as the distance on the long time scale. The long time scale is the dis-tance information available from the link state database. The short time scale is the information learned through the querying of the different candidates. When both time scales are taken into consideration, the result might be that the candidate with the shortest distance, has a long term distance higher than the current nodes mini-mum long term distance. This is especially true if buffer queue size and contention information are taken into consideration when calculating the short term distance.

The result is that the shortest path for this packet might be very different than the average shortest path. This means that loops can be created as a forwarding node has no knowledge of the previous path. This problem can of course be solved by only querying candidates with a lower long term distance.

Another way of solving this problem is to use source routing. However, since source routing is performed at the source node based on information included in the link state database (or in the routing cache), which is not updated frequently enough to include the channel state information, source routing can never be chan-nel dependent. Yet another solution to the loop problem would be to include a record route option, where each hop is recorded. Each intermediate node can then make sure the packet is not forwarded to the same node twice.

In our solution, we use an on demand route setup phase that create loop free routing table entries. Loop freedom is ensured during the setup phase while still enabling diversity forwarding. When a node is about the send a packet to some destination, it first searches its routing table. If an entry can not be found, the node searches the link state database to see whether it can calculate one or more paths to the destination. If it can’t do this either, it issues a Route Request, RREQ, message. This enables the protocol to fall back and behave as a normal on demand routing protocol such as AODV [12], but where each rebroadcasting node also adds the previous link to the RREQ packet. Each forwarding node adds this previous link information, plus any link information it finds included in the RREQ packet.

This information will thus update the link state database in each of the forwarding nodes.

If the node do find a path in the link state database, it unicasts a Route Enforce, RENF message to each of its neighbors that it determines can be used as a next hop forwarding node towards the final destination. Each of these messages include the link state information of each forward hop as perceived by the sending node. Each node that receives this RENF message creates a forward and backward routing table entry, between the source and the destination. The node then forwards the message along the path toward the destination as specified in the RENF. Similar to the source node, each forwarding node also consult its own link state database

(a)

Fig. 6.1:Reuse of routes. A has a loop-free redundant route to destination E. If C were to reuse this route, it can not use B as next hop.

,creates and then sends a new RENF message to each of its own neighbors that it determines can be used for reaching the destination. Note that each RENF message associated between a source and destination setup can only be forwarded once.

Any subsequent RENF messages from the same source destination setup phase are dropped. This prevents loops and enables each intermediate node to have unique but multiple routing table entries toward a destination.

Each entry in the routing table maps the source of the route to the destination, and possibly a multiple number of next hops. This differs from a normal routing table, which only routes according to the destination and through a specified next hop. The source address of the route is needed in order to simplify the loop freedom criteria, as the originating source node has reserved multiple routes towards the destination. While it may be possible to create routing table entries that are loop free without using the source address, which can later be reused by other nodes, this will create less multiple paths. This is because when the route is being setup, the path doesn’t allow a packet to visit a previous node again. This means that any intermediate node that wishes to reuse the route also will not be able to visit these nodes, thereby limiting the number of multiple paths. An example of this is shown in figure 6.1(a). Here, A has a redundant route to E, where node B can use diversity forwarding to either C or E. If C were to reuse to this route to E, it can only use D as a next hop. By setting up its own route to E, C can forward packets to either B or D.

This is also in contrast to normal shortest single path routing schemes where the shortest path is the most important objective. Here, we wish to create redundant routes that can be used in case the link of the shortest next hop goes into a bad fading phase. Another important selection criteria besides the shortest path, is the state of the link after the next hop. If for example the buffer of one next hop candidate is queued up by three packets, choosing another next hop that is 1 hop further away can still be a good choice if its buffer is empty.

Since this is an on demand routing protocol, routing table entries will time