RE: [Manet-dt] DYMO SeqNum Decisions

Hi Ian

I have a small clarification to your slides. You have listed all
lopp-prone, stale & inferior cases (1st & 2nd slides), which we should
drop the RM. 

Isn't that following case is missing ?

"[When Seq Nums are equal]If the route is valid (by examining
Route.ValidTimeout and the current time), then the
      new information is inferior if Node.HopCnt > Route.HopCnt"

Koojana

> -----Original Message-----
> From: Ian Chakeres [mailto:ian.chakeres@gmail.com] 
> Sent: 13 August 2006 00:40
> To: manet-dt@ietf.org; Elizabeth M. Belding (work); Charles 
> E. Perkins (work)
> Subject: [Manet-dt] DYMO SeqNum Decisions
> 
> 
> As an exercise in ensuring dymo sequence numbers work 
> properly, I've created a few slides discussing important dymo 
> sequence number decisions.
> 
> Pages 1 & 2 talk about judging routing information 
> usefulness. The goal is to not have loops, while not 
> requiring nodes to increment their OwnSeqNum unless 
> absolutely necessary. Incrementing OwnSeqNum essentially 
> disqualifies existing routing information in the network that 
> may not be bad.
> 
> Pages 3 & 4 talk about incrementing OwnSeqNum. Since nodes 
> issuing RREQ don't know the state of routing tables at 
> intermediate nodes, they need to increment their sequence 
> number. Otherwise, receiving nodes might discard this 
> information. The target on the other hand has more 
> information from the RREQ message (last known values and some 
> information about the route traversed). The target can use 
> this information to optimize sequence number incrementing.
> 
> Intermediate nodes that append their routing information have 
> two options, updating their sequence number and ensure it 
> will be fresh at other nodes, or not.  If the sequence number 
> is not incremented it might not be considered fresh by 
> intermediate nodes. It is not clear what the recommended 
> procedure should be. Please make a suggestion. I suggest 
> incrementing OwnSeqNum.
> 
> Page 5 talks about the cases when an Intermediate node could 
> reply. Currently we don't define intermediate node replies, 
> but it is a useful concept. One more thing, I've introduced a 
> concept "MaxAge" which is the maximum amount of time a piece 
> of routing information can be maintained. This is to assist 
> in reboots, by having a hard deadline on the maximum amount 
> of time that a node must wait before participating.
> 
> Please review the flowcharts and let me know if something 
> doesn't make sense or is wrong.
> 
> Ian Chakeres
> 

_______________________________________________
Manet-dt mailing list
Manet-dt@ietf.org
https://www1.ietf.org/mailman/listinfo/manet-dt