Subject: Re: Extensions to OSPF to Support Mobile Ad Hoc Networking

From: "Spagnolo, Phillip A" <[email-masked]>
Date: Fri, 20 Feb 2004 10:27:46 -0800

Madhavi,

Below are a few questions about your optimizations for Link State
Acknowledgements.  

section 2.4.7 states 
   Note that a node can determine whether its further flooding a LSA
   will only result in a redundant transmission by already having heard
   link state acknowledgements (ACKs) or floods for the LSA from all of
   its peers.

section 2.4.8 states
   2.   Typically, LSAs are acknowledged by all of the adjacent speak-
        ers. In the case of relayed information, the relay MUST only
        expect either explicit or implicit acknowledgements from peers
        that have not previously acknowledged this LSA. The retransmis-
        sion procedures, if any exist, for the underlying protocol MUST
        be followed.
   3.   Because routing updates are sent via multicast, the set of over-
        lapping speakers will usually receive the same update more than
        once. A speaker SHOULD only acknowledge the first update
        received on the link.

The draft does not specify how the following mechanisms are to be
implemented. However, the statements seem to imply memory of each ACK
that has been received.  Does this mean you keep a new database of ACKs
received for a particular LSA from a particular router?  Do you only
keep track of ACKs for LSAs in your link state database, or do you
record ACKs for LSAs not yet received?  To determine if you should
further flood an LSA (sec 2.4.7), it seems that the later will be
needed.  Also, in sec 2.4.8 a router needs past ACK information, so the
speaker only has to acknowledge the first LSA, and the LSA source does
not expect an ACK.  

My desire is to understand the complexity of keeping ACK information.

Thanks for your response,
Phil

> -----Original Message-----
> From: Russ White [mailto:[email-masked]] 
> Sent: Wednesday, February 11, 2004 6:53 AM
> To: [email-masked]
> Subject: Extensions to OSPF to Support Mobile Ad Hoc Networking
> 
> 
> Y'all:
> 
> We are past the new work cutoff, so I'm posting this directly 
> here, rather than waiting 'til after IETF to do so. I'll post 
> it in the normal way after IETF is over.
> 
http://www.riw.us/temp/draft-chandra-ospf-manet-00.txt

Abstract:

This document describes extensions to OSPF to support mobile ad hoc
networking. Specifically, the document specifies a mechanism for
link-local signaling, a OSPF-MANET interface, a simple technique to
reduce the size of Hello packets by only transmitting incremental state
changes, and a method for optimized flooding of routing updates.

:-)

Russ

__________________________________
[email-masked] CCIE <>< Grace Alone

---

From: Madhavi Chandra <[email-masked]>
Date: Fri, 20 Feb 2004 14:43:39 -0500

Hi Tom,

On Tue, 17 Feb 2004 18:11:57 -0800, Henderson, Thomas R
<[email-masked]> wrote:

>I have some questions and comments on this document.
>
>- it is unclear whether this is intended for v2.  At the
>start of section 2, it seems to be intended for both v2 and
>v3, but the discussion is very v3 specific.

Yes, the proposal details are for v3....however, they do have
applicability for v2 as well...although the details may differ
slightly.

>- at the end of page 4, there was discussion about the fact
>that too many neighbors will cause scalability problems.  This
>was also discussed in Fred Baker's MANET draft from 2002.
>Do you intend to introduce mechanisms for minimizing the
>number of neighbors that a router tries to become adjacent with,
>or is that outside the scope of this proposal?

We are looking into ways for synchronization optimization that
alleviates much of the overhead associated with two neighbors
becoming adjacent.

>- could you please explain why LLS extensions are preferable
>to defining a new packet type (such as Incremental Hello)?
>If there is no advantage, LLS seems a more roundabout way to do it.

Using LLS gives you the ability to add anything to an existing OSPF
packet, rather than always declaring a new type...thus, preserving
backwards compatability. If an OSPF router receives a Hello packet with
LLS, and doesn't support LLS, it will simply ignore it.  The sender can
then decide to build the adjacency normally, or just not build an adjacency
at all.  On the flip side, if a Hello is replaced with a new Incremental
Hello packet type that is not supported, this breaks backwards
compatability.

>- in section 2.3.4.1, last bullet, what do you mean by neighbors
>possibly being DR or BDR?

Actually, we had designed this part for use 'beyond MANETs' and thus the
reference.

>- do you foresee additional significant extensions beyond
>use of MPRs/ack strategy for flooding and use of incremental Hellos?

Well, as many others, our research also continues. :)  We are looking into
further optimizations for scalability...but, it's pretty much work in
progress.

Regards,
Madhavi

>Tom
>> here, rather
>> than waiting 'til after IETF to do so. I'll post it in the
>> normal way after
>> IETF is over.
>>
>reduce the size of Hello packets by only transmitting incremental
>state changes, and a method for optimized flooding of routing
>updates.
>
>:-)
>
>Russ
>

---

From: Madhavi Chandra <[email-masked]>
Date: Mon, 23 Feb 2004 14:45:10 -0500

Hi Phillip,

>My desire is to understand the complexity of keeping ACK information.

Sure.  This is pretty much implementation specific.  We
implement a new ACK cache (the ACKs aren't saved in the
existing data structures).  We cache ACKs for LSAs that have
not yet been received. The cache also contains information on router-
ID's from which the ACK has been received. Entries are aged-out
based on a timer, or can be explicitly removed.

Regards,
Madhavi