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

["Ian Chakeres" <[e-mail]>]

An intermediate node might not have a good route (the route might have
broken). In this scenario, the intermediate node cannot fill in the
RREP, since it does not have a good route. In this case, if the
sequence number is not higher (or equal with additional logic
including the hop count) then the RREP will be dropped. One more thing
to keep in mind, I currently do not see a way to predict the state
(sequence number and hopcount) required to create a good route at the
intermediate nodes.

Also, I would like  to avoid modifying packets'/messages' information
while in flight. Any modification to information added by the
originator would make end to end security extremely difficult if
message signing were used.

Ian

On 8/27/06, mase <[e-mail]> wrote:
> 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