Re: [Manet-dt] [Fwd: Re: DYMO SeqNum Decisions]

[mase <[e-mail]>]

Dear Ian and Charlie,

When an intermediate node receives a RREQ and it has a valid route to the 
destination and its destination sequence number is  greater than or equal 
to the sequence number, the node can behave as 1) or 2).
1) If an intermediate node is allowed to issue a RREP, it does so.
2) If it is not allowed to issue a RREP, it simply re-broadcasts the RREQ.

I think that you are discussing the case of 2. Here is a concern, as 
pointed by Ian, that when this node receives the RREP, it may discard the 
RREP because it already has the valid route with the destination sequence 
number, that is same as or greater than that included in the RREP, if the 
destination have not incremented its sequence number when it received the RREQ.

If this understanding is correct, I would propose the following solution.
When the intermediate node receives the RREP, it compares its content with 
its valid route to the destination. If the destination sequence number of 
the route is same or greater than that in the RREP, the node modifies the 
RREP so that it becomes consistent with its route information. (As if it 
creates RREP in the case of 1))

In this solution, the RREP includes the same information as that issued by 
this node in case 1). No copy of RREQ is required. No discarding of RREP 
occurs. Note that this modification method must be used only in the case of 
2), where RREP is delivered in a manner of unicast  from the destination to 
the source. Thus, an intermediate node receives the RREP only once for a 
given RREQ.  In the case 1), some nodes may simultaneously issues RREPs for 
the given RREQ and modification of RREP is not allowed.

Do you think that this solution is workable?

Cheers,
Kenichi

  At 17:16 06/08/25 -0700, Ian Chakeres wrote:
>Comments inline.
>
>On 8/25/06, Charles E. Perkins <[e-mail]> wrote:
>>
>>Hello again Ian,
>>
>>A few follow-on comments...
>>
>>ext Ian Chakeres wrote:
>> >> > Pedro & Fran ran into seq num problems last year. During IETF 65 Ramon
>> >> > identified another sequence number issue related to this discussion.
>> >> > Both had problems with RREP being blackholed.
>> >> Were those problems caused by the scenario outlined in recent e-mails?
>> >
>> > Both these problems were because the RREP originator was not
>> > incrementing its sequence number.
>>That formulation prejudices the outcome.  I will interpret it to mean that,
>>both problems would be solved if the RREP originator would
>>increment its sequence number.  But the problem is _caused_ by
>>some other occurence.  It is this true cause of the problem that
>>I want to know more about.
>
>"The problem"  is that RREP were not being considered as fresh or
>superior, and therefore dropped.
>
>I would like to find a solution that does not require the RREQ target
>(RREP originator) to increment its sequence number, but I have not
>found one yet.
>
>Finding such a solution appears difficult, since the target does not
>know the state of routing tables in nodes along the path from the RREP
>originator to the RREP target (RREQ originator).
>
>I am querying you and others to propose a solution that would solve
>"The problem". Hopefully, one that does not require the RREP
>originator to increment its seqnum.
>
>One other note lower.
>
>> >> > If we force intermediate nodes to examine information about the target
>> >> > (last known seqnum and hopcnt) we might be able to know something at
>> >> > the target node about the route traversed. But we still need to ensure
>> >> > that a RREQ will reach the target, and I think any such logic could
>> >> > result in RREQ blackholing.
>> >> I think I am missing something here, unfortunately.  Can you say
>> >> just a little more about when the blackholing would occur?
>> >
>> > This condition would occur whenever an intermediate node discarded a
>> > RREQ (due to new rules) and it was the only route to the target.
>>Do you mean the new DYMO rules?  Or, which ones specifically?
>
>A possible set of new processing rules associated with dropping RREQ
>based on the target's last know sequence number and hop count that
>would allow the RREQ target to know something about the route
>traversed.
>
>I do think blackholing could occur if this (new processing rules) were
>implemented.
>
>Ian
>
>>--
>>Please address return e-mail to [e-mail]
>>
>
>_______________________________________________
>Manet-dt mailing list
>[e-mail]
>https://www1.ietf.org/mailman/listinfo/manet-dt


_______________________________________________
Manet-dt mailing list
[e-mail]
https://www1.ietf.org/mailman/listinfo/manet-dt