Subject: [manet] Dymo routing information usefulness

From: Henner Jakob <[email-masked]>
Date: Thu, 8 Mar 2007 15:57:07 +0100

Hello,

at the moment I am creating testcases to test my update function for the dymo routing table.
Doing this, I encountered some problems.
In the case, that we have an existing route with a high hopcount, we will not update our table if we receive a route reply with the same sequence number and a much lower hop count.
According to the draft, information from route replies is inferior if the sequence number is smaller OR the sequence number is equal  AND the route is not broken  AND the hopcount is not more than 1 hop greater.
So, if we receive a route reply where the sequence numbers are equal, the route is not broken and the hop count is 3 hops smaller than the current route hop count, we should update the routing table.
According to the current check, it only updates after receiving a route reply with higher sequence number(ok) or same sequence number(ok) AND hopcount is not more than 1 hop greater (I dont like this, the route shouldn't be longer)) AND route is broken(not ok, we can't improve 'not broken' routes with better information from rreps).

With the new idea of not always incrementing the own sequence number after creating a route reply, it is possible, that a node creates a second route reply, with the same sequence number and  a much lower hopcount which will not be used by the source node.

Some additional thougths on this:
- if we have a broken route...a valid route with same hops and same sequence number should be superior. At the moment it is not, but somehow it sounds logic to me.

- if route requests for a broken route are received, with same hop and same sequence number, the route table should be updated.

maybe the superior check should look like:

(Node.SeqNum - Route.SeqNum > 0) OR
      ((Node.SeqNum == Route.Seqnum)
       AND ((Node.HopCnt <= Route.HopCnt) AND (Route.Broken == true))
       OR ((Route.Broken == false) 
           AND ((Node.HopCnt < Route.HopCnt) AND (RM is RREQ))
           OR  ((Node.HopCnt < Route.HopCnt + 1 ) AND (RM is RREP)))) 

Maybe my thougths are flawed, but I hope it helps.

regards,
Henner Jakob
-- 

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

---

From: Ian Chakeres <[email-masked]>
Date: Sat, 17 Mar 2007 17:12:16 -0700

Please see the new text I proposed for Inferior in my post with title  
"Re: [manet] Dymo hopcount update implementation question." on March  
6th. - I'll forward it to you too.

Does this new text and pseudo-code solve the issue you presented?

Ian

On Mar 8, 2007, at 6:57 AM, Henner Jakob wrote:

> In the case, that we have an existing route with a high hopcount,  
> we will not update our table if we receive a route reply with the  
> same sequence number and a much lower hop count.
> According to the draft, information from route replies is inferior  
> if the sequence number is smaller OR the sequence number is equal   
> AND the route is not broken  AND the hopcount is not more than 1  
> hop greater.
> So, if we receive a route reply where the sequence numbers are  
> equal, the route is not broken and the hop count is 3 hops smaller  
> than the current route hop count, we should update the routing table.
> According to the current check, it only updates after receiving a  
> route reply with higher sequence number(ok) or same sequence number 
> (ok) AND hopcount is not more than 1 hop greater (I dont like this,  
> the route shouldn't be longer)) AND route is broken(not ok, we  
> can't improve 'not broken' routes with better information from rreps).
>
> With the new idea of not always incrementing the own sequence  
> number after creating a route reply, it is possible, that a node  
> creates a second route reply, with the same sequence number and  a  
> much lower hopcount which will not be used by the source node.
>
> - if we have a broken route...a valid route with same hops and same  
> sequence number should be superior. At the moment it is not, but  
> somehow it sounds logic to me.
>
> - if route requests for a broken route are received, with same hop  
> and same sequence number, the route table should be updated.
>