Re: Extensions to OSPF to Support Mobile Ad Hoc Networking

[Madhavi Chandra <[e-mail]>]

Hi Phillip,

On Fri, 20 Feb 2004 10:27:46 -0800, Spagnolo, Phillip A
<[e-mail]> wrote:

>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.

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

>Thanks for your response,
>Phil
>
>
>
>
>> -----Original Message-----
>> From: Russ White [mailto:[e-mail]]
>> Sent: Wednesday, February 11, 2004 6:53 AM
>> To: [e-mail]
>> 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
>
>__________________________________
>[e-mail] CCIE <>< Grace Alone