Subject: [manet] backup routes

From: "Nast, Douglas P" <[email-masked]>
Date: Thu, 11 Apr 2002 12:09:03 -0700

Do any of the proposed pro-active manet routing protocols support an idea
analogous to the feasible successor concept in EIGRP?   That is, a
guaranteed loop-free backup route is maintained in a topology database for
immediate use when the link to the best path goes down?   

Doug Nast

_______________________________________________
manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/manet

---

From: [email-masked]
Date: Thu, 11 Apr 2002 17:08:32 -0700

> immediate use when the link to the best path goes down?   

Doug,

In TBRPF, when a route fails, the source tree and routing table
are updated immediately, based on the topology database, to provide 
immediate rerouting (even if the new path is longer, unlike EIGRP 
as explained below).  Since TBRPF is a link-state protocol, the source 
node knows the entire path (and therefore knows that it is loop free).  
EIGRP is a distance-vector protocol, and must send "query" messages
if the distance to some destination increases, to ensure loop freedom.
EIGRP is not being considered for MANETs.  DSDV is another distance-vector 
protocol that is a better candidate for MANETs.  

Richard

---

From: [email-masked]
Date: Thu, 11 Apr 2002 17:08:32 -0700

Doug,

Richard

---

From: Gaurav Srivastava <[email-masked]>
Date: Fri, 12 Apr 2002 14:13:06 +1000

Hi,                                                                   
                                                                      
I was performing a simple simulation in glomosim 2.02.                
A static 25 node network, with nodes arranged in a grid topology      
with grid spacing of 200 m. The transmission range of every node is   
376 m                                                                 
                                                                      
I had set up CBR traffice bitween nodes  0 1, 1 2, 0 2, 2 1, 2 0.     
I am using static routes.                                             
                                                                      
When I looked at the collisions metric, I found that there are a lot  
of collisions on                                                      
node  5 6 7 8.                                                        
This is very odd as they are not involved in the communication an are 
not used for routing.                                                 
                                                                      
I changed the MAC protocol form 802.11 to CSMA but still there are a  
large number of collisions noticed                                    
at node 5 6 7 8.                                                      
                                                                      
I decreased the CBR traffic on nodes 0 1 2 and sent only about 8      
packets per node.                                                     
The collisions on node 5 6 7 8 were still there and a were very large.
                                                                      
Is this a bug in glomosim, Can some one help ???                      

Gaurav

---

From: Gaurav Srivastava <[email-masked]>
Date: Fri, 12 Apr 2002 14:13:06 +1000

Hi,                                                                   

                                                                      

                                                                      

Gaurav

---

From: "Philippe Jacquet" <[email-masked]>
Date: Fri, 12 Apr 2002 20:22:12 +0200

Dear Doug,

OLSR provides natural route back-up because of link state knowledge of the
network. The links that are advertized througout the network are the MPR
links that reduce the overhead of link state control. Their number can be
tuned to increase path redundancy if necessary. It is a priori not necessary
to compute the back-up route in parallel with the main route, since
recomputation will be triggered by link breakage. However if you feel that
recomputation may take time, it could be done in anticipation for fast
rerouting purpose (implementation issue).

Philippe

---

From: "Philippe Jacquet" <[email-masked]>
Date: Fri, 12 Apr 2002 20:22:12 +0200

Dear Doug,

Philippe