Subject: Re: Proposal for OSPF MANET Extensions Design Points

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 16 Jan 2004 11:23:57 -0800

Acee,
> 
> I guess this is where the "as much as possible" comes in. It would be
> nice if it looks like a single protocol with an extension for 
> MANET rather
> than two protocols that have been munged together.
> 

Well, it is possible to do nothing at all, if one is dead-set against
mechanism changes-- that is why I am suggesting that proposals be
considered also on the merits of their performance benefits, because
at least some mechanisms will need to be modified, otherwise
we wouldn't really need the extensions and could tweak timers, etc.

Tom

---

From: Vishwas Manral <[email-masked]>
Date: Sun, 18 Jan 2004 21:35:19 -0800

I agree with Acee here and on the 3 points. 

Venkata, isn't the reason we are trying to use OSPF because its deployed and well understood? We could have used OLSR/TBRPF or something similar otherwise.

Cheers,
Vishwas

-----Original Message-----
From: Mailing List [mailto:[email-masked]]On Behalf Of Acee
Lindem
Sent: Friday, January 16, 2004 8:01 PM
To: [email-masked]
Subject: Re: Proposal for OSPF MANET Extensions Design Points

Hi Venkata,

----- Original Message -----
From: "Naidu, Venkata" <[email-masked]>
To: <[email-masked]>
Sent: Friday, January 16, 2004 11:59 AM
Subject: Re: Proposal for OSPF MANET Extensions Design Points

> Hi Acee,
>
>   Your proposal is reasonable.
>
> -> I believe that for the foreseeable future the vast majority of
> -> networks will be fixed (although they may support wireless hosts).
> -> Based on this belief and the fact that what is being proposed for
> -> MANET is very different from base OSPFv3 I'd like to propose the
> -> following design points for the work:
> ->
> ->     1. A fixed network OSPFv3 implementation shouldn't require
> ->        changes to fully interoperate with an OSPFv3 implementation
> ->        supporting the MANET extensions.
> ->     2. The MANET extensions should be limited to wireless
> -> interfaces (or
> ->        whatever level of segregation we end up with).
> ->     3. As much as possible, an OSPFv3 implementation with the MANET
> ->        extensions should be a proper subset of an OSPFv3
> -> implementation
> ->        without the extensions. In other words, we should be extremely
> ->        suspect of changes to basic OSPFv3 mechanisms.
>
>   I don't know whether my proposal has already been suggested.
>   Here it is: If OSPFv3 changes to support MANET is so harmful
>   for existing fixed OSPFv3 operation. And if MANET thinks that
>   OSPF is a suitable protocol for their requirements, then it
>   will be a good idea to start OSPFv4 targeted only to support
>   IPv6 MANET requirements.
>
>   In such a case, OSPFv4 will satisfy all the above design
>   requirements proposed by you. Everybody will be happy.
>   What is your opinion ?

I'm not convinced we need a new protocol at this point. There are
a number of disadvantages of a new protocol including 1) Migration
of fixed networks in environments containing both MANET and
fixed nodes 2) Dual protocol maintenance for new features (standards,
development, deployment).

> Venkata.

---
Outgoing mail is certified Virus Free.
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.560 / Virus Database: 352 - Release Date: 1/8/2004

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Wed, 21 Jan 2004 11:16:34 -0800

> From: Richard Ogier [mailto:[email-masked]]
> Sent: Wednesday, January 21, 2004 10:09 AM
> Tom,
> Henderson, Thomas R wrote:
> 
> >>From: Richard Ogier [mailto:[email-masked]]
> >>Sent: Tuesday, January 20, 2004 9:44 PM
> 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.
> 

OK, I agree with your argument.  I was arguing from the perspective that
if you have multi-hop broadcast, you need a sequence number.  When using
MPRs, you want to have a multi-hop broadcast dissemination, or else you 
need to start tagging LSAs and remembering the last-hop nodes that 
forwarded them to you (and comparing against the MPR selector lists which
may change over time) before deciding whether you are keeping them on the
retransmission list-- we found it easier to use a multi-hop broadcast message
in that case.  Another reason we found the LSF useful was that it allowed
the LSA originator to control the retransmission frequency based on the 
source of the LSA-- LSAs from outside the subnet could be retransmitted at 
a lower frequency to save on overhead.  It also allows you to flood a 
default without configuring it as a stub area, as you pointed out earlier.  
If CDS is used for efficient broadcast instead of MPR, and adopting your 
proposed scheme, then LSF may no longer be needed.   

Tom

---

From: "Henderson, Thomas R" <[email-masked]>
Date: Tue, 27 Jan 2004 15:44:04 -0800

> From: Tony Przygienda [mailto:[email-masked]] 
> Sent: Saturday, January 24, 2004 12:46 AM
<snip>
> I would suggest that
>     having an 'manet-area' like an nssa-area is the best solution. 

This is an interesting possibility.  Although you cite some
"limit the implementation impact" reasons for defining this 
as an area, probably the most compelling argument would be the 
opportunity to limit the flooding scope of more rapidly 
varying LSAs, and take advantage of the opportunity to 
summarize at the area boundary.  

On the other hand, there are some potential drawbacks to this,
most notably the inability to handle area partitioning (which 
is very likely to occur in some scenarios), and the general 
difficulty of configuring/maintaining static area configurations.

What would be most desirable is a way to achieve the flooding
scope reduction and summarization qualities of the area without 
specifically requiring the area construct.  Some ideas that have 
been floated in this space include the Fuzzy Sighted Link State 
and the Limited Flooding proposal 
(draft-dovolsky-ccamp-ospf-limited-flooding-00.txt).

Tom