Subject: Re: Proposal for OSPF MANET Extensions Design Points

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 21 Jan 2004 09:08:57 -0800

> -----Original Message-----
> From: Richard Ogier [mailto:[email-masked]]
> Sent: Tuesday, January 20, 2004 9:44 PM
> To: [email-masked]
> Subject: Re: Proposal for OSPF MANET Extensions Design Points
> 
> 
> >>In other words, before adding new message types,
> >>you should try to use existing OSPF mechanisms as much
> >>as possible.  Your LSF message contains a new "flooding
> >>sequence number" to detect duplicates, but OSPF already
> >>detects duplicate LSAs using the LS sequence number.
> >>
> >
> >The LS sequence number is not sufficient to prevent
> >multi-hop broadcast messages from recirculating.  They are
> >tied to the LSAs.  LSF sequence numbers are tied to the
> >originator's IP address.
> >
> But each LSA contains the LS sequence number *and* the 
> advertising router
> (originator). Can you explain or give an example to show that the LS
> sequence
> number is not sufficient to prevent LSAs from recirculating?  I am
> really just talking
> about the way OSPF already does flooding, so this should not 
> be a problem.
> I guess you are talking about your flooding mechanism using 
> the LSF message,
> but my point is that LSF messages are not needed.
> 
If LSAs are broadcast periodically, and unacknowledged, then a node
may have to forward the identical LSA again (to send it downstream
to a node that may not have received it successfully the first time).
It cannot tell by inspection of the normal LSU (without sequence
number) whether this is a new LSU to be forwarded or an instance
of one that it has already forwarded.

If dissemination is reliable, then LSF is not needed.  The premise
of OLSR was that periodic unreliable dissemination was more transmission
efficient than reliable dissemination with acking (at a certain
mobility point, the performance benefits transition from reliable
to unreliable flooding).  In looking at how OSPFv2 behaves with or
without the wireless interface type, we have observed this behavior.
It would be nice if we had a hybrid mode of operation to account for
both stable and rapidly varying networks-- that is why the mechanism
you sketched out in sec. 5 of your draft is appealing.  But we would
like to make sure that there are no unanticipated downsides to that
mechanism before jumping on board with it.

Tom

---

From: Richard Ogier <[email-masked]>
Date: Wed, 21 Jan 2004 10:09:22 -0800

Tom,

>of one that it has already forwarded.
The LSU just carries LSAs one hop further from the originator. OSPF inspects
the LSA (with sequence number) to determine if it is a duplicate.
 Again, I am really
just talking about how OSPF already floods LSAs, with some minor
modifications
(but without requiring the new LSF packet type).   In OSPF, a router
retransmits
an LSA (to neighbors) after RxmtInterval if no ACK is received.  This is
the basis
of the idea I sketched in Section 5 of my draft (which also discusses
how a router
decides when to suppress ACKs).  The point I am making is that the LSF
message
is not required  in order to achieve periodic, unreliable flooding.
 (Whether it
improves performance is another question that can be studied.) And the
reason is
that OSPF correctly performs periodic, unreliable flooding (although not
in the
same manner as your method with LSF messages) if ACKs are supressed.

>
>
>If dissemination is reliable, then LSF is not needed.
>
My point is that LSF is not needed even if unreliable flooding is used,
as discussed above.

>The premise
I completely agree that it needs to be studied further to make sure
there are no
unexpected downsides.  But the only point I am trying to make now is
that the LSF
message is not *required* in order to achieve periodic, unreliable
flooding of LSAs.

Richard