Subject: Re: Proposal for OSPF MANET Extensions Design Points

From: "Henderson, Thomas R" <[email-masked]>
Date: Fri, 16 Jan 2004 12:53:39 -0800

Richard,

> -----Original Message-----
> From: Richard Ogier [mailto:[email-masked]]
> Sent: Friday, January 16, 2004 11:08 AM
> To: [email-masked]
> Subject: Re: Proposal for OSPF MANET Extensions Design Points
> 
> 
> Acee Lindem wrote:
> 
> > 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 agree with Acee and Thomas regarding points 1 and 2,
> and I agree with Thomas regarding point 3.
> The extension should include all mechanisms of OSPFv3,
> but some of the mechanisms must be modified to
> support multi-hop (ad hoc) wireless interfaces.
> I agree that OSPFv3 mechanisms should be changed only
> when necessary, or if the change results in a substantial
> improvement in performance.
> 
> The main need is to support the multi-hop wireless interface type,
> whether or not the routers are mobile.
> Since OSPF already supports topology changes, this will also
> support mobile routers, although some additional changes may
> be needed to do this more efficiently.
> I think it is good to support mobile routers, since these can exist
> in vehicle networks, robot networks, military networks, etc.
> 
> I think the extensions that I proposed
>   draft-ogier-manet-ospf-extension-00.txt
> satisfy points 1 and 2, and also minimize the changes to OSPF.
> This may also be true for the other proposal
>   draft-spagnolo-manet-ospf-wireless-interface-00

Our proposal also satisfies 1 and 2.

> but as I discussed previously, the latter proposal has more
> changes than are necessary.

If this is indeed borne out, then I would support an alternative
that performed as well or better with fewer changes to OSPF.
I think it remains to be seen whether your I-D results in
a design with more or fewer changes.  As I've said, it's worth
studying as an alternative approach (we and, I hope, others are 
looking at it more closely), and I think that the ideas 
are promising, but it is not yet a complete proposal IMO. 

Tom

---

From: Richard Ogier <[email-masked]>
Date: Fri, 16 Jan 2004 15:16:00 -0800

Tom,

>are promising, but it is not yet a complete proposal IMO.
It is *certainly* not a complete proposal, as the draft states and I
have stated.
It is an informal proposal that discusses and recommends a few alternative
approaches.  For example, it recommends using a CDS, but does not say
exactly
how the CDS nodes are selected (not to mention the backup CDS nodes).
I think we need to discuss design issues/choices before specifying a
complete
solution in detail.

I'm glad you are considering some of the ideas from my draft.  That's
what it is for,
since I don't plan to turn it into a complete spec by myself.
I plan to update the draft in the next few weeks, to focus more on a single
approach and to provide some more details.   I look forward to seeing other
proposed solutions (e.g., from Fred Baker) and to discussing the different
solutions that are proposed.

Richard

---

From: Richard Ogier <[email-masked]>
Date: Tue, 20 Jan 2004 16:41:03 -0800

Tom,

See my new comments below.

>are promising, but it is not yet a complete proposal IMO.

I agree that a design with fewer changes to OSPF is preferable if
it results in similar or better performance.

Based on your positive comments regarding the idea
(from Section 5 of draft-ogier-manet-ospf-extension-00.txt)
of dynamically deciding when to suppress ACKs for a particular
LSA based on how frequently the LSA is being updated
(using an exponential moving average and hysteresis),
I assume that you agree that suppressing ACKs in
this manner is a good way to achieve periodic, unreliable
flooding of LSAs (whether this is done for all LSAs or only
for LSAs that are being updated frequently).

Therefore, this supports my claim that the Link State Flood
(LSF) message that you introduce in your solution is not
required.  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.

In an effort to make some progress, I would like to
focus on this aspect of your solution (the LSF message)
and try to reach an agreement on whether or not
the LSF message is required.

I can think of two other reasons why the LSF message might
be needed. One of these is given in Step 2.1 in Section 13.1
of your draft, where the "default route bit" of the LSF
is set to indicate a default route (to avoid flooding
outside LSAs within a stub wireless network).
However, as we discussed and agreed on the MANET list,
the same effect can be accomplished by using an OSPF stub area
as specified in Section 12.4.3.1 of RFC 2328.

Another possible need for the LSF message is to perform flooding
via MPRs, since an LSF is forwarded only if it was received from
an MPR selector. There are two questions:

1. Do we want to use MPRs to flood LSAs?
2. If the answer is yes, then can MPR flooding of LSAs
   be done without using the LSF message?

I am proposing that LSAs be flooding using a connected
dominating set (CDS) rather than MPRs, because it is simpler
and closer to OSPF: each CDS node is responsible for
forwarding all LSAs, whereas each MPR would be reponsible for
forwarding only a subset of LSAs which must somehow be defined.

But if one still wanted to use MPRs to flood LSAs, it is possible
to do so without using LSF messages, either by remembering
whether a given LSA was received from an MPR selector,
or by defining the set of LSAs that a given MPR is responsible
for forwarding as described in my draft.  (In this case, periodic,
unreliable flooding can be accomplished by suppressing ACKs
as mentioned above.)

Richard