Subject: [Ospf-wireless-design] Differential Hellos draft-chandra

From: "Spagnolo, Phillip A" <[email-masked]>
Date: Wed, 9 Feb 2005 12:50:58 -0800

All,
 
Our initial implementation of differential hellos according to
draft-chandra 01 resulted in added overhead.  This arose due to a design
choice we made to send requests and answers immediately when the draft
said to send them unicast.  The savings from smaller hellos was
counteracted by the large number of hellos sent.
 
Recently, I have modified the differential hello mechanism to run
periodically.  To this end, the following changes were made.
-All hellos are sent multicast to all routers, so a router only
generates a hello upon expiration of the hello interval.
-A new Request TLV is added.  It has the same format as the neighbor
drop TLV, except the router ids represent neighbors who should respond
with a full state hello.
-If a router desires to request full state from a neighbor then the R
bit is set and the the neighbor's ID is included in a request TLV.
-If a router desires to request full state from all neighbors then the R
bit is set and a request TLV is not sent.
-When receiving a hello with the R bit set and a Request TLV is not
included then the router sends full state at the next hello send.
-When receiving a hello with the R bit set and a Request TLV is included
then the router sends full state at the next hello if its ID is included
in the request TLV.
 
These changes have improved the overhead generated by the differential
hellos.  As an example (just one run), I have seen 25% reduction of
hello overhead when running 20 nodes with 2 sec hello interval.  
 
Madhavi, what do you think of this design choice?  You had noted that
running periodic might be a better way.  How did you expect to go about
it?  
 
Thanks,
Phil Spagnolo 
Network Technology Engineer 
The Boeing Company 
Phone:  (425) 865-6723
_______________________________________________
Ospf-wireless-design mailing list
[email-masked]
https://www1.ietf.org/mailman/listinfo/ospf-wireless-design

---

From: Abhay Roy <[email-masked]>
Date: Wed, 9 Feb 2005 14:03:07 -0800 (PST)

Phil,

Good timing. We are playing with some changes which almost match
what you wrote down below ;) Basically the idea is use normal
multicast hello's for request/response. Hopefully we can update
this and a few more things before the ietf cut-off date.

Regards,
-Roy-

---

From: Richard Ogier <[email-masked]>
Date: Wed, 09 Feb 2005 16:03:12 -0800

That looks more reasonable, since it avoids unicast Hello requests. My 
main concern is that there will be a lot of Hello requests in a highly 
mobile, dense network, and perhaps most Hellos will be full Hellos 
(containing all neighbors).

But I noticed that they added the option of sending the entire 
incremental Hello packet k times, similar to what is done in TBRPF 
Hellos. For example, if each incremental update is sent in 3 consecutive 
Hellos, the probability of missing a given update is very low, and the 
neighbor will likely be declared lost anyway. So, I suggest running 
simulations with this option, to see if overhead is reduced. (I 
presented simulations previously showing that using this technique 
results in much lower overhead than using only full Hellos.)

One thing that bothers me regarding sending the entire incremental Hello 
packet 3 times, with the same sequence number, is that new incremental 
updates cannot be included in the 2nd and 3rd transmission of the Hello 
packet. So an entirely new Hello packet must be sent for new incremental 
updates?  Or can multiple Hello "packets", with different sequence 
numbers, be included in the same IP packet?  Or equivalently, maybe a 
given Hello packet should be allowed to contain multiple incremental 
updates having different sequence numbers.

Anyway, the differential Hello protocol in my updated draft (and also 
the TBRPF Hello protocol) avoids this problem by incrementing the Hello 
sequence number with each transmitted Hello message, and allows each 
neighbor state change to be reported in k consecutive Hellos having 
 different sequence numbers.

Richard

Spagnolo, Phillip A wrote:

> draft-chandra 01 resulted in added overhead.  This arose due to a 
> design choice we made to send requests and answers immediately when 
> the draft said to send them unicast.  The savings from smaller hellos 
> was counteracted by the large number of hellos sent.
>
>  
>
> with a full state hello .
>
> -If a router desires to request full state from all neighbors then the 
> R bit is set and a request TLV is not sent.
>
> -When receiving a hello with the R bit set and a Request TLV is 
> included then the router sends full state at the next hello if its ID 
> is included in the request TLV.
>
>  
>
> running periodic might be a better way.  How did you expect to go 
> about it? 
>
>  
>
> Thanks,
>
> Phil Spagnolo  
>------------------------------------------------------------------------
>