Subject: Fwd: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 10, Issue 7

From: Aniket Desai <[email-masked]>
Date: Tue, 19 Sep 2006 10:05:10 -0400

>Date: Tue, 19 Sep 2006 10:04:19 -0400
>To: Richard Ogier <[email-masked]>
>From: Aniket Desai <[email-masked]>
>Subject: Re: [Ospf-manet] Re: Ospf-manet Digest, Vol 10, Issue 7
>
>Hi,
>
>After some thinking, I agree that it is greatly efficient to simply 
>include a list of neighbors in even a single LSA. Suppose the LSA is 
>describing 5 adjacencies (not uncommon for an MDR), its size is 672 
>bits. If this LSA is to be retransmitted to even 2 neighbors, adding 
>a list of neighbors and multicasting that LSA is more efficient. And 
>a smart implementation can track an LSU that was multicasted the 
>first time, and accordingly append these neighbors to the whole of 
>the LSU. The only issue there is that acknowledgements can be broken 
>down and sent in different packets from the receiver (due to MTU). 
>The receiver should send the acknowledgements to the same LSU in the 
>same packet, which is not difficult to do.
>
>I did not realize before that there is no options field in LSU 
>header field that can make use of LLS. This is indeed unfortunate. 
>We can make use of the LSA options bit instead. Dr. Ogier already 
>has some ideas, and hopefully, he can include this feature in the 
>upcoming draft. I also think that if retransmissions are multicast, 
>it should be possible to remove BMDR flooding, and instead, simply 
>reduce the recommended retransmission timer for MANET interfaces. As 
>I recall, the reasoning for BMDR flooding was only to save unicast 
>retransmissions, but it involves too much state-keeping and may not 
>be good for power conscious MANET routers.
>
>Thanks,
>
>Aniket
>
>
>At 03:44 AM 9/19/2006, you wrote:
>>Aniket Desai wrote:
>>
>>>
>>>
>>>At 06:25 PM 9/18/2006, you wrote:
>>>
>>>>4. Ack the first reception of an LSA, and ack any LSA received in an LSU
>>>>that contains the router in the Ack list.  Retransmitted LSAs are 
>>>>multicast.
>>>
>>>
>>>
>>>This may actually turn out to be a good idea if a router TLV was 
>>>included in the LSU packet. Currently, router TLVs are used in 
>>>hello and also in the initial DD handshaking. As I recall, OSPF 
>>>options field already reserves an LLS bit, which can be set when 
>>>retransmitting a multicast LSA.
>>
>>
>>But the LLS draft specifies that only Hello and DD packets can include
>>an LLS block.
>>http://www.ietf.org/internet-drafts/draft-ietf-ospf-lls-01.txt
>>
>>But we shouldn't let this unfortunate limitation of LLS keep us from
>>including a TLV in LSU packets to indicate which neighbors should Ack,
>>if this turns out to improve performance significantly.  We should be
>>allowed to modify the format of LSU packets on a MANET interface,
>>since this has no effect on non-MANET interfaces.
>>(Similarly, we should be able to change the format of Hellos on a
>>MANET interface, so I question the choice of using LLS for Hellos.)
>>Alternatively, we can use an LSA option bit to indicate that the
>>LSA should be Acked by all routers in the TLV attached to the
>>LSU packet. (We don't want to include a separate TLV for each LSA.)
>>
>>>A router can include a list of all neighbors in a router TLV (Type 
>>>must be unique and can be assigned, length and value are obvious), 
>>>which must acknowledge this LSA. Also, turning on the LLS bit can 
>>>act as an indication that the LSA is retransmitted, and hence each 
>>>receiving neighbor will try to find its own router ID in the 
>>>attached TLV. Such a change is not that extensive from legacy 
>>>OSPF, and the already existing TLV signaling can be used for this purpose.
>>>
>>>I still think that such a feature must be used with care, because 
>>>a router may expect different LSAs to be acknowledged by different neighbors.
>>
>>
>>But in most cases, an LSU that includes several LSAs will not be acked
>>by a subset of adjacent neighbors, and these LSAs will be retransmitted
>>to this subset of neighbors in another LSU.  In other words, it is really
>>the LSU that is usually retransmitted.  But it is possible that new LSAs
>>are added to the LSU (along with LSAs that must be retransmitted), so the
>>above idea of using an LSA option bit (to indicate which LSAs are being
>>retransmitted) might work well.
>>
>>>If a router starts appending a list of neighbors (each neighbor 
>>>takes 32 bits) for every single retransmitted LSA, that can 
>>>potentially annul the advantage of multicast retransmission. In 
>>>certain situations, this may make some sense. I would like this to 
>>>be an option (if included in the draft at all), that would 
>>>typically be only turned on the MDRs/BMDRs with many adjacencies.
>>
>>
>>Yes, this feature should be optional.  If this option is not used,
>>retransmitted LSAs will be unicast as before.
>>But I don't think this option will ever result in more overhead than
>>unicasting all retransmitted LSAs, since it is more efficient to include
>>a list of m neighbors in a single multicast LSU, versus unicasting the
>>LSU to each of m neighbors (even if the LSU sent to each neighbor contains
>>only a subset of the LSAs that must be retransmitted to the m neighbors).
>>
>>Note again that only LSUs containing *retransmitted* LSAs will include
>>a list of neighbors that must ack.  Also, an LSA option bit will indicate
>>which LSAs are being retransmitted.  As before, each router must Ack
>>the first reception of each new LSA.
>>
>>Richard
>>
>>
>>
>>>
>>>
>>>Thanks,
>>>
>>>Aniket
>>>
>>>
>>>
>>>_______________________________________________
>>>Ospf-manet mailing list
>>>[email-masked]
>>>https://www1.ietf.org/mailman/listinfo/ospf-manet

_______________________________________________
Ospf-manet mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-manet

---

From: Richard Ogier <[email-masked]>
Date: Tue, 19 Sep 2006 08:43:47 -0700

Aniket Desai wrote:

>> include a list of neighbors in even a single LSA.
>
I assume you mean to include a list of neighbors (that must ack) in an LSU
that contains even a single LSA.  It still would not be a good idea to 
include
a separate list of neighbors for each LSA.  For example, if the list 
includes
50 neighbors and the LSU contains 50 LSAs, then there would be 2500 entries
in the lists.

>> Suppose the LSA is describing 5 adjacencies (not uncommon for an 
>> MDR), its size is 672 bits. If this LSA is to be retransmitted to 
>> even 2 neighbors, adding a list of neighbors and multicasting that 
>> LSA is more efficient. And a smart implementation can track an LSU 
>> that was multicasted the first time, and accordingly append these 
>> neighbors to the whole of the LSU.
>

Right.  The LSU would contain the union of the neighbor sets that must
ack each LSA. It might even be efficient to send a separate LSU for each
different set of neighbors (each LSU would contain the LSAs that must be
retransmitted to a given set of neighbors), and a separate LSU for
new LSAs (not retransmitted).  But as I mentioned, an LSA option
bit can indicate which LSAs are being retransmitted.

>> The only issue there is that acknowledgements can be broken down and 
>> sent in different packets from the receiver (due to MTU). The 
>> receiver should send the acknowledgements to the same LSU in the same 
>> packet, which is not difficult to do.
>

This is not a problem, since we already use AckInterval, which is much
smaller than RxmtInterval.

>>
>>
>> I did not realize before that there is no options field in LSU header 
>> field that can make use of LLS. This is indeed unfortunate. We can 
>> make use of the LSA options bit instead. Dr. Ogier already has some 
>> ideas, and hopefully, he can include this feature in the upcoming 
>> draft. I also think that if retransmissions are multicast, it should 
>> be possible to remove BMDR flooding, and instead, simply reduce the 
>> recommended retransmission timer for MANET interfaces. As I recall, 
>> the reasoning for BMDR flooding was only to save unicast 

The BMDR mechanism is separate from retransmissions.  A BMDR floods an LSA
very quickly (faster than RxmtInterval) if it determines that 
neighboring MDRs
failed to cover all neighbors. (BMDRs also retransmit LSAs to adjacent 
neighbors,
as do all routers, and multicast retransmissions can be used for this.)
We can make the BMDR mechanism optional, but I think it is an important
mechanism to achieve robust flooding while MDRs are being updated.
You may be concerned that it will slow down simulations, but I don't think
it will even have that problem, since the number of BMDRs in a network
is relatively small.  (I think you will discover this to be true if you
ever implement this feature in OPNET.)

Richard

>>>> attached TLV. Such a change is not that extensive from legacy OSPF, 
>>>> and the already existing TLV signaling can be used for this purpose.
>>>>
>>>> I still think that such a feature must be used with care, because a 
>>>> router may expect different LSAs to be acknowledged by different 
>>>> neighbors.
>>>
>>>
>>>